作者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 的情况下回答这些问题并完成这项需求。开始开发之前支持团队表示对于正在使用产品进行引导的客户来说“邀请你的团队成员”这一步很令人困扰但他们并没有提供具体信息说明究竟是谁提出了投诉也没有说明这些投诉是否会导致用户流失。对此保持怀疑是合理的。因此与其打开 Amplitude 并创建查询来验证自己的判断不如直接在 Agents 选项卡中向 AmplitudeAgent提问Ampamplitude[agent] is completing the team invite step correlated with success later in the funnel? Break it down by segments were measuring.分析结果非常明确完成这一步的团队用户后续留存的可能性更高而对于个人用户则不存在这种相关性。因此重新界定需求范围是合理的对于个人用户的注册流程可以将这一步延后而对于团队用户则继续保留现有流程。现在你无需编写任何代码就可以直接在 GitHub 中获取产品数据和洞察从而及时调整方向。开发过程中Copilot 会针对这项修改创建一个 Draft Pull Request。与此同时实现过程中还需要更新免费试用引导流程所使用的依赖项。与其等到 CI 扫描失败后再处理不如直接在评论中询问 Endor Labs Agentendorendor-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 扫描失败后再进行修复。显然这种方式更加高效。发布过程中前面的分析结果现在会进一步落实到实现中个人用户注册时进入可选路径而团队用户继续使用现有流程。由于这些用户群体在注册时就已经确定因此可以直接通过 Feature Flag 针对不同用户群体进行控制。你可以像向团队成员分配任务一样请 LaunchDarkly Agent 帮你完成设置darklylaunchdarkly-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。发布之前代码审查可以告诉你代码本身是否正确但服务当前是否处于适合部署的状态则是另一个问题。在合并之前你可以询问 PagerDuty Agentpagerdutypagerduty-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 中一个常规的步骤。有什么变化你仍然在使用 Amplitude、LaunchDarkly、Endor Labs 和 PagerDuty。但现在你不再需要在这些工具之间不断转移上下文它们都可以直接融入 GitHub 工作流。随着工作从想法逐步走向生产环境开发者可以在某项服务的上下文或能力发挥作用时将其引入 GitHub。借助 Agent AppsGitHub 成为了开发者与 Agent 协调下一步工作的中心而开发者无需不断切换工作上下文。开始使用Agent Apps 已经可以通过 GitHub Marketplace 获取。安装其中一个为组织启用然后开始体验将 Agent 分配给一个 Issue启动任务。在 Pull Request 评论中使用mention让 Agent 进行分析或执行操作。在代码仓库的Agents选项卡中选择 Agent。你的工具仍然是你的工具。现在它们会出现在你已经工作的地方——GitHub。探索其他首批推出的 Agent Apps将你的技术栈直接带入现有工作流Packfiles 的 Agent 可以读取你的 Backlog并制定迁移策略。Miro 的 Agent 可以将可视化协作与代码工作流连接起来。Bright Security 的 Agent 可以在 GitHub 中自主执行端到端动态安全测试。SonarQube 的 Agent 可以将代码分析、质量门禁和问题修复能力带入 GitHub Agent 会话。Octopus Deploy 的 Agent 可以识别、诊断并解决部署失败问题。探索 GitHub Marketplace 中的 Agent Apps