如何借助 Agent 应用将软件交付工作流引入 GitHub

软件开发中，围绕一个 Pull Request 往往要打开多个工具页面：确认产品决策、检查依赖风险、配置发布策略、判断能否安全部署。GitHub Agent 应用尝试把这些问题对应的工具直接带到开发者所处的位置——GitHub 之内，从而减少上下文切换。

文章以“邀请队友”步骤改为可选为例：产品团队需要判断这个改动是否合理。通过 Amplitude Agent，开发者在 Agents 标签页直接询问这一步骤与后续漏斗成功的关系。得到的数据显示，团队用户完成该步骤后留存更高，而个人用户没有这种关联，因此将步骤改为仅对团队保留、对个人用户延迟。这样，在产品数据不离开 GitHub 的情况下就完成了方案调整。

进入开发阶段后，Pull Request 涉及依赖更新。开发者用 Endor Labs Agent 在评论中询问变更依赖是否有风险。Agent 识别出被改动的依赖，检查已知漏洞和包级风险，并直接在 PR 中回复；这次没有发现需要处理的问题。依赖审查因此从 CI 失败后的补救，变成了开发过程中的主动确认。

功能实现时，由于“团队”和“个人”在注册阶段即可区分，开发者请 LaunchDarkly Agent 创建功能开关：键名、类型、默认值、目标人群和发布节奏都通过一条 PR 评论指定。Agent 会在 LaunchDarkly 中创建开关，并把代码实现作为一次提交交给开发者审查；如果目标环境需要审批，则会先生成审批请求，由人来决定是否放行。

合并之前，PagerDuty Agent 被用来评估部署风险。它把仓库映射到 PagerDuty 中的服务，查看当前是否有活跃事件，回看过去 90 天的事件历史，并将 PR 涉及的文件与历史事件区域进行比较。评估结果是风险较低：没有活跃事件，也与当前改动无明显关联，因而建议继续部署。

整体来看，开发者仍然使用原有工具，但这些工具的能力不再分散在多个界面中。从想法到生产，每个服务都在其上下文或能力重要的时刻进入 GitHub。Agent Apps 已上架 GitHub Marketplace，用户可为组织安装后，在 Issue 中指派任务、在 PR 评论中 @ 提及，或在仓库的 Agents 标签页选择使用，从而把技术栈直接带到已经工作的环境中。