GitHub Agent Apps 实践：把软件交付工作流搬进 Pull Request
2026/08/15 00:00阅读量 2
GitHub 发文介绍如何用 Agent Apps 在 GitHub 内完成软件交付。以一个产品需求为例，开发者在 Agents 标签页用 Amplitude agent 验证改动方向，在 PR 评论中用 Endor Labs agent 检查依赖风险，再用 LaunchDarkly agent 创建功能开关并灰度发布，全程无需离开 GitHub。
事件概述
GitHub 介绍了 Agent Apps 如何将软件交付工作流带到 GitHub 内：利用与 GitHub Copilot 云代理同一平台和基础架构的 Agent Apps，开发者可以在 Pull Request 环境中完成原本分散在多个工具中的任务，无需切换上下文。
核心信息
- 场景：产品免费试用注册流程中，“邀请队友”步骤被支持团队标记为摩擦点。工程师接到需求后，没有先去 Amplitude 手工建查询，而是在 Agents 标签页直接向 Amplitude agent 提问：
@amplitude[agent]完成该步骤是否与后续漏斗成功相关，并按现有分群拆分。 - 结果与方案调整：分群数据显示，团队用户完成该步骤后留存更高，个人用户没有这种相关性。因此需求被重新界定：个人注册时延后该步骤，团队用户保留原流程，在写代码前完成方向修正。
- 依赖审查：实现过程中，PR 改动了 onboarding 流程使用的依赖。开发者在 PR 评论中让 Endor Labs agent 检查：
@endor-labs-github-agenthq[agent]识别被改动的依赖，检查已知漏洞和包风险，并在 PR 内直接反馈。本次检查结果干净，无需修复，依赖审查成为 CI 失败前的主动检查。 - 灰度发布：针对 signup 时已经确定的分群，开发者在 PR 中要求 LaunchDarkly agent 创建功能开关：
@launchdarkly-agent[agent]创建布尔开关defer-team-invite（默认 false），定向 solo-intent 注册用户，并按 internal → 5% → 25% → 100% 的节奏放量。Agent 创建开关后会把代码改动作为一次 commit 供审阅；如果目标环境需要审批，则创建审批请求。
值得关注
文章以四个 Agent Apps 对应软件交付中的四个关键问题：改动是否正确、依赖是否干净、如何安全上线、现在能否部署（分别涉及 Amplitude、Endor Labs、LaunchDarkly 和 PagerDuty）。核心思路是把这些判断集中到 PR 工作流中，让 Agent 在开发者所在的位置直接提供答案。