如何用agent应用将软件交付工作流引入GitHub

你的 pull request 旁边开着多少个标签页？想象一下，你在产品的免费试用引导流程中接手一个新问题：把“邀请队友”步骤设为可选。随着注册量增加，支持团队一直将该步骤标记为摩擦点。快速搞定，对吧？从范围界定到部署，你需要回答这四个问题：这真的是正确的改动吗？我接触的依赖项是否干净？如何安全地推出？现在部署是否安全？每个答案都存在于不同的工具中，因此处理 pull request 意味着要在四个地方携带相同的上下文。GitHub agent apps 将回答这些问题所需的工具带到你已经在工作的地方，由与我们的 Copilot 云 agent 相同的平台和框架驱动。下面的示例演示了如何使用你已经依赖的服务（如 Amplitude、Endor Labs、LaunchDarkly 和 PagerDuty）来回答这些问题并完成此请求，而无需离开 GitHub。

1. 在构建之前 支持团队表示，“邀请队友”步骤对正在注册产品的客户来说很烦人，但他们没有指出谁抱怨过，或者这些抱怨是否导致流失。你持怀疑态度是对的。因此，与其打开 Amplitude 并构建查询来确认你的直觉，不如直接从 Agents 标签页询问 Amplitude agent：@amplitude[agent] 完成团队邀请步骤是否与漏斗后期的成功相关？按我们衡量的细分群体拆分。结果清晰：完成该步骤的团队用户更有可能在后期留存，而个人用户则没有这种相关性。重新界定范围现在有了依据：对个人注册延迟该步骤，对团队保留。产品洞察现在可以在 GitHub 内获取，从而在编写任何代码之前实现方向修正。

2. 在构建过程中 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 signups - rollout: internal > 5% > 25% > 100% 5% > 25% > 100%" tabindex="0" role="button"> agent 在 LaunchDarkly 中创建标志，并将代码实现添加为你审查的提交。如果目标环境需要审批，它会创建审批请求，而不是直接应用目标更改。人类仍然决定是否推进推出。标志设置从第二个工具、手动代码交接和 Slack 协调，变成一个 pull request 评论和你审查的提交。

4. 在发布前 审查告诉你代码是正确的，但服务是否处于适合部署的状态是另一个问题。在合并之前，你询问 PagerDuty agent：@pagerduty-agent-app[agent] 评估这个 pull request 对引导服务的部署风险。检查活跃事件和近期事件历史，然后建议是否继续。agent 将仓库映射到其 PagerDuty 服务，检查活跃事件，回顾过去 90 天，并将 pull request 中的文件与过去事件涉及的领域进行比较。这次，风险很低。没有活跃事件，与当前更改没有显著相关性。建议是继续。没有戏剧性的事情发生，但这正是重点。检查部署风险成为你 pull request 的常规步骤，而不是只在发布感觉危险时才做的事情。

有什么变化 你仍然使用 Amplitude、LaunchDarkly、Endor Labs 和 PagerDuty。但现在，你不再需要在它们之间携带上下文，它们都将直接在 GitHub 工作流中工作。随着工作从想法走向生产，开发者可以在上下文或能力重要时，将每个服务带入 GitHub。借助 agent apps，GitHub 成为开发者和 agent 协调下一步行动的地方，而开发者无需切换上下文。

试试看 Agent Apps 可从 GitHub Marketplace 获取。安装一个，为你的组织启用，然后试用：将其分配给问题以启动任务。在 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 >

这篇帖子《如何通过 agent apps 将你的软件交付工作流带入 GitHub》最初出现在 GitHub 博客上。