作者：Sam Zhang

排版：Alan Wang

了解 GitHub 中的四款 Agent App 如何帮助你在整个软件开发生命周期（SDLC）中完成需求范围界定、安全保障、逐步发布和功能交付，并且全程无需离开 GitHub。

你在 Pull Request 旁边还打开了多少个标签页？

想象一下，你正在处理产品免费试用引导流程中的一个新 Issue：将“邀请你的团队成员”这一步设为可选。随着注册量不断增加，支持团队一直反馈这一步会给用户带来阻碍。看起来是个很容易解决的问题，对吧？

但从需求范围界定到部署，你需要回答以下四个问题：

• 这真的是正确的修改方向吗？

• 我正在修改的依赖项是否安全可靠？

• 如何安全地逐步发布？

• 现在适合进行部署吗？

每个问题的答案都来自不同的工具，因此处理这个 Pull Request 时，你需要在四个不同的地方之间不断传递相同的上下文。

GitHub Agent Apps将回答这些问题所需的工具带到了你已经工作的地方，并使用与 GitHub 自身 Copilot Cloud Agent相同的平台和运行框架。下面的示例演示了如何使用你已经依赖的服务，例如 Amplitude、Endor Labs、LaunchDarkly 和 PagerDuty，在完全不离开 GitHub 的情况下回答这些问题并完成这项需求。

GitHub Agent Apps

https://docs.github.com/copilot/concepts/agents/agent-apps/?wt.mc_id=3reg_webpage_reactor

Copilot Cloud Agent

https://docs.github.com/copilot/concepts/agents/cloud-agent/about-cloud-agent/?wt.mc_id=3reg_webpage_reactor

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 中获取产品数据和洞察，从而及时调整方向。

Amplitude

https://github.com/apps/amplitude/?wt.mc_id=3reg_webpage_reactor

2. 开发过程中

Copilot 会针对这项修改创建一个 Draft Pull Request。与此同时，实现过程中还需要更新免费试用引导流程所使用的依赖项。与其等到 CI 扫描失败后再处理，不如直接在评论中询问 Endor LabsAgent：

@endor-labs-github-agenthq[agent] is there anything I need to watch out for in the dependencies being touched by this pull request?

该 Agent 会识别发生变更的依赖项，检查它们是否存在已知漏洞以及更广泛的软件包风险，然后直接在 Pull Request 中返回分析结果。这一次，一切看起来都很干净，没有需要修复的问题。

依赖项审查因此成为修改仍处于当前 Pull Request 阶段时的一项主动检查，而不是等 CI 扫描失败后再进行修复。显然，这种方式更加高效。

Endor Labs

https://github.com/marketplace/endor-labs-agenthq-plugin/?wt.mc_id=3reg_webpage_reactor

3. 发布过程中

前面的分析结果现在会进一步落实到实现中：个人用户注册时进入可选路径，而团队用户继续使用现有流程。由于这些用户群体在注册时就已经确定，因此可以直接通过 Feature Flag 针对不同用户群体进行控制。你可以像向团队成员分配任务一样，请 LaunchDarklyAgent 帮你完成设置：

@launchdarkly-agent[agent] please create a feature flag for this pull request and wire it into the code.

- key: defer-team-invite

- type: boolean

- default: false

- target: solo-intent signups

- rollout: internal > 5% > 25% > 100%

Agent 会在 LaunchDarkly 中创建 Feature Flag，并将代码实现作为一个 Commit 添加到 Pull Request 中，供你审核。如果目标环境要求审批，它会创建审批请求，而不是直接应用用户定向配置。是否继续推进发布，仍然由人来决定。

Feature Flag 的配置流程因此从“切换到另一个工具、手动交接代码、再通过 Slack 协调”，变成一条 Pull Request 评论加一个供你审核的 Commit。

LaunchDarkly

https://github.com/marketplace/launchdarkly-agent/?wt.mc_id=3reg_webpage_reactor

4. 发布之前

代码审查可以告诉你代码本身是否正确，但服务当前是否处于适合部署的状态，则是另一个问题。在合并之前，你可以询问 PagerDutyAgent：

@pagerduty-agent-app[agent] assess the deployment risk for this pull request against the onboarding service. Check active incidents and recent incident history, then recommend whether to proceed.

Agent 会将代码仓库映射到对应的 PagerDuty 服务，检查当前是否存在活跃事件，回顾过去 90 天的事件记录，并将 Pull Request 中涉及的文件与过去事件中涉及的区域进行比较。

这一次，风险较低。当前没有活跃事件，当前修改也没有与过去的事件表现出明显关联。因此，Agent 建议继续推进。

整个过程没有发生什么戏剧性的事情，但这正是重点。部署风险检查不再是只有当某次发布看起来已经非常危险时才会进行的操作，而是成为 Pull Request 中一个常规的步骤。

PagerDuty

https://github.com/apps/pagerduty-agent-app/?wt.mc_id=3reg_webpage_reactor

有什么变化

你仍然在使用 Amplitude、LaunchDarkly、Endor Labs 和 PagerDuty。但现在，你不再需要在这些工具之间不断转移上下文，它们都可以直接融入 GitHub 工作流。

随着工作从想法逐步走向生产环境，开发者可以在某项服务的上下文或能力发挥作用时，将其引入 GitHub。借助 Agent Apps，GitHub 成为了开发者与 Agent 协调下一步工作的中心，而开发者无需不断切换工作上下文。

开始使用

Agent Apps已经可以通过 GitHub Marketplace获取。安装其中一个，为组织启用，然后开始体验：

• 将 Agent 分配给一个 Issue，启动任务。

• 在 Pull Request 评论中使用 @mention，让 Agent 进行分析或执行操作。

• 在代码仓库的 Agents选项卡中选择 Agent。

你的工具仍然是你的工具。现在，它们会出现在你已经工作的地方——GitHub。探索其他首批推出的 Agent Apps，将你的技术栈直接带入现有工作流：

• Packfiles的 Agent 可以读取你的 Backlog，并制定迁移策略。

  https://github.com/marketplace/packfiles-agent/?wt.mc_id=3reg_webpage_reactor

• Miro的 Agent 可以将可视化协作与代码工作流连接起来。

  https://github.com/marketplace/miro-agent-app/?wt.mc_id=3reg_webpage_reactor

• Bright Security的 Agent 可以在 GitHub 中自主执行端到端动态安全测试。

  https://github.com/marketplace/bright-security-agent/?wt.mc_id=3reg_webpage_reactor

• SonarQube的 Agent 可以将代码分析、质量门禁和问题修复能力带入 GitHub Agent 会话。

  https://github.com/marketplace/sonarqube-agent/?wt.mc_id=3reg_webpage_reactor

• Octopus Deploy的 Agent 可以识别、诊断并解决部署失败问题。

  https://github.com/marketplace/octopus-deploy-intelligence-agent/?wt.mc_id=3reg_webpage_reactor

探索 GitHub Marketplace 中的 Agent Apps>

Agent Apps

https://docs.github.com/copilot/how-tos/use-copilot-agents/cloud-agent/use-agent-apps/?wt.mc_id=3reg_webpage_reactor

GitHub Marketplace

https://github.com/marketplace?type=apps&category=agent-apps/?wt.mc_id=3reg_webpage_reactor

探索 GitHub Marketplace 中的 Agent Apps

https://github.com/marketplace?type=apps&category=agent-apps/?wt.mc_id=3reg_webpage_reactor