GitHub 官方博客演示：四款 Agent 应用把软件交付全流程留在平台内

GitHub 官方博客发文介绍如何借助 agent apps 将软件交付工作流整体搬进 GitHub。这些应用与 GitHub 自家的 Copilot cloud agent 基于同一平台和 harness 运行，开发者可以在已有的 Agents 标签页或 PR 评论中直接 @ 调用。

文章以一个具体需求为例：将产品免费试用引导流程中的"邀请队友"步骤改为可选。在动手写代码前，先在 Agents 标签页询问 Amplitude agent，分析完成该步骤与后续漏斗成功之间的相关性。返回结果显示，团队用户完成该步骤后留存更高，而单人用户没有这种相关性，从而在编码之前就完成了需求范围的重新界定。

进入开发阶段后，Copilot 开出草稿 PR，实现同时会更新引导流程用到的依赖。开发者可以在 PR 评论中 @ Endor Labs agent，让它识别被改动的依赖、检查已知漏洞和包风险并直接在 PR 中回报，把依赖审查从"CI 扫描失败后补救"变成主动检查。

发布环节由 LaunchDarkly agent 承担：在 PR 评论中给出 flag 的 key、类型、默认值、目标人群和灰度节奏后，agent 会在 LaunchDarkly 中创建 feature flag，并把代码实现作为一个 commit 提交供人审查；如果目标环境要求审批，它会创建审批请求而不是直接应用变更，发布决定权仍保留在人手中。

上线之前，文章演示了向 PagerDuty agent 询问该 PR 相对于 onboarding 服务的部署风险（本站抓取的原文文本在此处截断，后续细节以 GitHub 博客原文为准）。整体思路是把原本散落在多个工具里的上下文，通过 agent 形式收拢到开发者已经在用的 GitHub 界面中。