GitHub推出覆盖全SDLC的Agent应用

你在打开 pull request 的同时，还开着多少个标签页？

想象你在产品的免费试用引导流程中遇到一个新的 issue：把"邀请团队成员"这一步设为可选。随着注册量增加，支持团队不断标记这一步是摩擦点。快速胜利，对吧？

从需求确认到部署，你需要回答这四个问题：

• 这真的是正确的改动吗？
• 我涉及的依赖是否干净？
• 如何安全地推出这个改动？
• 现在部署是否安全？

每个答案都存在于不同的工具中，所以处理 pull request 意味着要在四个地方之间来回携带同样的上下文。

GitHub agent apps 把回答这些问题所需的工具带到你已经工作的地方，基于与我们的 Copilot 云端 agent 相同的平台和框架构建。下面的说明性演示展示了如何使用你已经依赖的服务（如 Amplitude、Endor Labs、LaunchDarkly 和 PagerDuty）来回答这些问题并完成这个需求，全程无需离开 GitHub。

1. 在动手之前

支持团队说"邀请团队成员"这一步让使用产品的客户感到烦恼，但他们没有说明是谁投诉的，也没有表明这些投诉是否导致了用户流失。你有理由持怀疑态度。所以，你不用打开 Amplitude 并构建一个查询来验证你的直觉，而是直接从 Agents 标签页询问 Amplitude agent：

@amplitude[agent] 完成团队邀请步骤与后续漏斗中的成功留存有相关性吗？按我们正在衡量的用户细分来拆解。

分析结果很清晰：完成这一步的团队用户后续留存的可能性更高，而个人用户则没有这种相关性。现在有理由重新调整范围了：给个人注册暂缓这一步，给团队保留现有的做法。

产品洞察现在可以在 GitHub 中获取，在任何代码写出之前就能进行方向修正。

2. Copilot 打开了改动草稿

Copilot 为这个改动打开了一个草稿 pull request。实现方案同时也更新了引导流程所使用的依赖。与其等待后续 CI 扫描失败，不如直接在评论中询问 Endor Labs agent：

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

agent 识别出被修改的依赖，检查它们是否存在已知漏洞和更广泛的包风险，然后在 pull request 中报告回来。这次，一切都很干净。没有需要修复的问题。

依赖审查变成了主动检查，而改动还呈现在你面前。比等到 CI 扫描失败后再去修复要好得多。

3. 功能标志设置

前面的发现被带到实现阶段：个人注册走可选路径，团队保留现有流程。因为这些用户细分是在注册时确定的，所以功能标志可以直接针对他们。向 LaunchDarkly agent 询问，让他帮你设置，就像询问团队成员一样：

@launchdarkly-agent[agent] 请为这个 pull request 创建一个功能标志并将其接入代码。
   - key: defer-team-invite
   - type: boolean
   - default: false
   - target: solo-intent 注册用户
   -  rollout: internal > 5% > 25% > 100%

agent 在 LaunchDarkly 中创建了标志，并将代码实现作为提交让你审核。如果目标环境需要审批，它会创建一个审批请求，而不是直接应用定向变更。人类仍然决定推广是否继续。

标志设置从第二个工具、手动代码交接和 Slack 协调，变成了一条 pull request 评论和你需要审核的一次提交。

4. 部署前风险评估

审核告诉你代码是正确的，但服务是否处于适合部署的状态是另一个问题。在合并之前，你询问 PagerDuty agent：

@pagerduty-agent-app[agent] 评估这个 pull request 相对于引导服务的部署风险。检查活跃事件和最近的事件历史，然后建议是否继续。

agent 将仓库映射到其 PagerDuty 服务，检查是否有活跃事件，审查过去 90 天的情况，并将 pull request 中的文件与过去事件涉及的领域进行比对。

这次风险很低。没有活跃事件，与当前改动也没有有意义的关联。建议是继续进行。

没有戏剧性的事情发生，但这就是重点。检查部署风险成为你 pull request 的常规步骤，而不是只有在发布已经感觉危险时才做的事情。

5. 总结

你仍然使用 Amplitude、LaunchDarkly、Endor Labs 和 PagerDuty。但现在，你不再需要在它们之间来回携带上下文，而且它们都将直接在你的 GitHub 工作流中运作。

随着工作从想法到生产的推进，开发者可以在需要其上下文或能力的时刻将每个服务引入 GitHub。有了 agent apps，GitHub 成为了开发者和 agent 协调下一步行动的地方，开发者无需切换上下文。

Agent apps 可从 GitHub Marketplace 获取。安装一个，为你的组织启用它，然后开始使用：

• 将其分配给一个 issue 来启动任务。
• 在 pull request 评论中 @提及它以获取分析或操作。
• 从仓库的 Agents 标签页中选择它。

你的工具仍然是我的工具。现在，它们出现在你已经工作的地方：在 GitHub 上。探索其他首批 agent apps，开始将你的技术栈直接引入工作流：

• Packfiles 的 agent 阅读你的待办列表并构建迁移策略。
• Miro 的 agent 将视觉协作与代码工作流连接起来。
• Bright Security 的 agent 在 GitHub 内自动处理端到端动态安全测试。
• SonarQube 的 agent 将分析、质量门禁和修复引入 GitHub agent 会话。
• Octopus Deploy 的 agent 可以识别、诊断和解决部署失败。

在 GitHub Marketplace 发现更多 agent apps >

GitHub Copilot 产品经理

使用 GitHub Copilot 应用编写你的第一个 prompt

了解如何在 GitHub Copilot 应用中编写你的第一个 prompt，选择正确的上下文和模型，并充满信心地开始你的第一个任务。

面向 Java 开发者的 GitHub Copilot SDK

企业级 Java 开发者获得了新的超能力——用注解、虚拟线程等idiomatic Java 代码驱动 GitHub Copilot。

GitHub Copilot 应用中斜杠命令指南

在 GitHub Copilot 应用中超越聊天，使用这些斜杠命令。它们将帮助你规划、协作、自动化和定制你的开发工作流。