如何利用 Agent Apps 将软件交付工作流带入 GitHub

你打开了多少个标签页来处理你的 Pull Request？ 想象一下，要在产品的免费试用引导流程中处理一个新需求：把“邀请队友”这一步设为可选。随着注册用户增多，支持团队一直将这一步标记为阻碍体验的痛点。这显然是个快速见效的机会，对吧？ 从需求范围到最终部署，你需要回答这四个问题：

• 这真的是正确的改动吗？
• 我要修改的依赖项是否干净？
• 如何安全地发布？
• 现在部署是否安全？

每个答案都分散在不同的工具中，因此处理 Pull Request 意味着要在四个地方来回切换，携带相同的上下文。 GitHub Agent Apps 将你需要的工具带到了你正在工作的地方，它与我们自己的 Copilot Cloud Agent 使用相同的平台和底层架构。下面的演示展示了如何利用你现有的服务（如 Amplitude、Endor Labs、LaunchDarkly 和 PagerDuty）来回答这些问题并完成请求，而无需离开 GitHub。

1. 构建之前

支持团队表示，“邀请队友”这一步让试用用户感到困扰，但他们没有提供具体是哪些用户投诉，或者这些投诉是否导致了流失。保持怀疑是合理的。因此，你不需要打开 Amplitude 并编写查询来验证猜想，而是直接在 Agents 标签页中询问 Amplitude Agent：

@amplitude[agent] is completing the team invite step correlated with success later in the funnel? Break it down by segments we're measuring. 

分析结果很明确：完成该步骤的团队用户后续留存率更高，而单人用户则没有这种相关性。现在可以调整需求范围了：对单人注册推迟该步骤，对团队注册保留该步骤。 现在，你可以在 GitHub 内直接获取产品洞察，从而在编写任何代码之前进行纠偏。

2. 构建过程中

Copilot 会为此变更创建一个草稿拉取请求，实现过程还会更新入职流程所需的依赖。与其等待 CI 扫描稍后失败再补救，不如直接在评论中询问 Endor Labs 代理：

@endor-labs-github-agenthq[agent] 这个 PR 涉及的依赖有什么需要注意的吗？

代理会识别出变更的依赖项，检查其中是否存在已知漏洞和更广泛的包风险，并在拉取请求中反馈结果。这次一切都很干净，无需修复。 依赖审查变成了在代码变更面前主动进行的检查，远比在 CI 扫描失败后再补救要好得多。

3. 部署上线

之前的发现被延续到了实现阶段：单人注册走可选路径，团队则沿用现有路径。由于这些分群在注册时即已确定，特性开关可以直接针对它们。你可以像请求团队成员一样，让 LaunchDarkly 代理来帮你设置：

@launchdarkly-agent[agent] 请为此 PR 创建一个特性开关并将其接入代码。
   - key: defer-team-invite 
   - type: boolean 
   - default: false 
   - target: solo-intent signups 
   - rollout: internal > 5% > 25% > 100% 

代理会在 LaunchDarkly 中创建开关，并将代码实现作为一个提交供你审查。如果目标环境需要审批，它会创建审批请求而不是直接应用分群变更。最终是否继续上线，仍由人工决定。 开关设置从原本需要第二个工具、手动交接代码以及 Slack 协调，简化为只需一条拉取请求评论和一个供你审查的提交。

4. 发货前

代码审查确认了代码的正确性，但服务是否处于适合部署的良好状态则是另一个问题。合并前，你可以询问 PagerDuty 代理：

@pagerduty-agent-app[agent] 请评估此 PR 针对入职服务的部署风险。检查活跃事件和近期事件历史，然后建议是否继续。

代理会将仓库映射到其 PagerDuty 服务，检查活跃事件，回顾过去 90 天的情况，并将拉取请求中的文件与过去涉及的事件区域进行对比。 这次风险很低。没有活跃事件，且当前变更与过去的事件没有显著关联。建议继续进行。 没有什么戏剧性的变化，但这正是重点所在。检查部署风险变成了拉取请求的常规步骤，而不再是你仅在发布感觉危险时才做的事情。

发生了什么变化

你依然使用 Amplitude、LaunchDarkly、Endor Labs 和 PagerDuty。但现在，你不再需要在它们之间传递上下文，它们都能直接在 GitHub 工作流中运行。 随着工作从构思走向生产，当某个服务的上下文或能力至关重要时，开发者可以将其引入 GitHub。借助代理应用，GitHub 成为了开发者和代理协调后续行动的场所，开发者无需切换上下文。

尝试一下

代理应用可在 GitHub Marketplace 中获取。安装一个，为你的组织启用它，然后试用一下：

• 分配给一个问题以启动任务。
• 在拉取请求评论中 @提及它以进行分析或执行操作。
• 从仓库的 Agents 选项卡中选择它。

你的工具依然是你的工具。现在，它们出现在你已经在工作的地方：GitHub。探索其他首批代理应用，并开始直接将你的技术栈引入工作流：

• Packfiles 的代理读取你的待办事项并构建迁移策略。
• Miro 的代理将视觉协作与代码工作流连接起来。
• Bright Security 的代理在 GitHub 内部自主处理端到端动态安全测试。
• SonarQube 的代理将分析、质量门禁和修复措施带入 GitHub 代理会话。

Octopus Deploy 的代理能够识别、诊断并解决部署失败。