依赖升级是软件开发里最容易被低估的一类工作。它不一定困难，却会不断打断开发者：打开一个 Dependabot 拉取请求，查看升级幅度，确认是否涉及安全修复，再看 CI 是否通过，最后决定合并、延后还是需要人工排查。项目一多，这套动作就会变成每天都要重复的清单。
8 月 26 日，GitHub 分享了一个很具体的做法：用 GitHub Copilot App Automations 每天检查开放的 Dependabot 拉取请求，按风险归类，核对 CI 状态，再把结果整理成一份摘要。它的价值不在于替开发者直接合并所有升级，而在于把分散在仓库、拉取请求和 CI 里的信息先收拢起来，让人把时间留给真正需要判断的变化。
依赖维护为什么适合做成自动化
GitHub 的 Dependabot 包含三类相互关联的能力：安全告警会提示依赖存在漏洞，安全更新会针对已知漏洞自动创建升级拉取请求，版本更新则负责让依赖保持较新状态。它们解决了“发现问题”和“提出修改”，却没有完全解决“今天该先处理哪些请求”。
一个成熟项目里，开放的依赖请求通常混在一起：有些只是补丁版本更新，有些是小版本升级，有些跨越大版本，可能带来 API 变化。另一些请求虽然改动不大，但 CI 还没有通过，或者会和当前分支的改动产生冲突。开发者真正需要的不是再看一遍请求列表，而是一张经过初步整理的决策清单。
这正是 Agent 自动化比较合适的切入点。它要做的工作大多是读取信息、比较状态、执行固定检查和生成摘要，最终的合并与升级策略仍然由团队掌握。
GitHub 这套自动化具体做什么
GitHub 给出的示例提示词可以概括成四步：读取开放的 Dependabot 拉取请求，按风险分组，确认每个请求的 CI 状态，再输出简短的后续建议。运行结束后，Copilot 可能把安全补丁更新集中列出，把小版本和大版本升级分开，并标出需要额外调查的依赖。
它的完整链路大致是：
1 | 定时触发 |
这里有一个容易被忽略的细节：如果某个大版本升级需要进一步处理，开发者可以直接从自动化结果继续开启 Copilot 会话。新的会话带着前面已经收集的上下文，不必重新寻找拉取请求、变更范围和失败的检查。
每次运行也会被保存。开发者可以回看它什么时候执行、做过哪些动作以及产生了什么结果。对自动化工具来说，这段历史很重要，它让日常维护不至于变成一个只返回结论、却无法追溯过程的黑盒。
触发器和运行位置决定了它的边界
GitHub 文档显示，Copilot App Automations 支持手动、每小时、每天、每周等时间触发，也可以在 issue 或拉取请求事件发生时触发。对于依赖维护，按工作日每天运行一次通常已经够用；每小时扫描反而可能制造更多通知和重复结果。
自动化还可以选择运行在本地环境或云端：
| 运行方式 | 适合的情况 | 需要注意的地方 |
|---|---|---|
| 本地自动化 | 需要本地文件、脚本或自定义工具 | 依赖本机可用，权限与凭据由本地环境承担 |
| 云端自动化 | 主要读取 GitHub 仓库、请求和 CI 状态 | 电脑关闭后仍可运行，但需要管理员启用相关能力 |
云端运行并不等于可以不管权限。文档允许为自动化选择工具，例如推送修改、更新标签或创建拉取请求。实践中应只开放当前任务需要的工具。一个“每天整理依赖请求”的任务通常只需要读取请求、查看检查结果和输出摘要，不应该默认拥有合并、推送或修改仓库设置的权限。
自动分组不等于自动批准
把依赖请求分成“安全补丁”“小版本升级”和“大版本升级”很有帮助，但这只是信息整理，不是合并规则。即使 CI 通过，大版本升级仍然可能改变默认配置、移除 API 或带来运行时行为变化；即使只是补丁更新，也需要确认它是否确实解决了当前告警。
比较稳妥的分工是让自动化完成这些事情：
- 找出开放请求及其升级类型；
- 汇总安全告警、变更范围和 CI 状态；
- 标记互相冲突、检查失败或信息不足的请求；
- 生成一份按优先级排列的待办摘要。
开发者继续负责这些决定：
- 是否合并具体的依赖升级；
- 是否需要先阅读变更日志和迁移指南；
- 是否要调整版本范围或拆分升级；
- 是否接受暂时保留某项风险。
这样设计的好处是，Agent 处理“看什么、怎么归类”，人处理“是否承担这个变化”。两者之间的分界越清楚，自动化就越容易被团队信任。
给团队的一份提示词模板
如果要在自己的仓库里尝试，可以从只读摘要开始，明确输入、检查项和禁止动作：
1 | 每天检查当前仓库中开放的 Dependabot 拉取请求。 |
这段提示词还可以根据团队习惯补充过滤条件，例如只关注生产依赖、只报告有安全告警的更新，或者把已连续失败多次的请求单独列出。提示词越具体，摘要越容易直接进入工作流。
先从低风险、可验证的任务开始
依赖维护自动化不应该一上来就追求全自动升级。可以先观察一段时间，检查摘要是否遗漏请求、是否把升级类型分错、是否正确读取 CI 状态，再逐步增加能力。
一个简单的推进顺序是：
- 只读仓库和拉取请求，生成日报；
- 增加风险分组和失败原因归类；
- 允许在明确条件下创建辅助 issue 或添加标签；
- 对低风险补丁更新提供合并建议；
- 经过持续验证后，再讨论是否对极少数规则明确的更新开放更强的操作权限。
每一步都应该保留运行记录，并设定可以人工接管的出口。尤其是云端自动化，团队需要提前确认它能看到哪些仓库信息、能调用哪些工具，以及运行失败后谁负责处理。
对开发者的实际意义
GitHub 这个案例说明，Agent 的落地不一定从复杂的代码生成开始。依赖升级、issue 分类、CI 结果汇总和发布前检查，都有大量重复但不能完全省略的工作。它们不够“炫”，却有明确输入、可观察结果和相对清晰的人工边界。
对个人开发者来说，每天一份依赖维护摘要可以减少在多个页面之间切换的时间。对团队来说，自动化运行记录还能形成一条简单的维护审计线索，帮助回答“这个请求什么时候被看过、当时的 CI 状态如何、为什么暂时没有合并”。
但自动化也会带来新的维护责任：提示词会过时，仓库权限会变化，CI 检查名称会调整，Dependabot 的请求数量也会随着项目依赖变化。它不是配置一次就永远可靠的脚本，仍然需要定期抽查结果和修正规则。
结语
GitHub 把 Dependabot 拉取请求整理成一个每日自动化任务，抓住的是软件维护中很实际的一段空隙：信息已经产生，决策却还没有被组织起来。Copilot 可以先把升级类型、风险信号和 CI 状态放到同一份摘要里，开发者再针对真正复杂的请求深入处理。
这类工作流的关键不在于让 Agent 替人做完所有事情，而是把权限、触发条件和输出边界写清楚。自动化负责减少重复浏览，人负责理解变化并承担发布决定。对于依赖维护这样的日常工作，这种“先整理、后判断”的分工，可能比直接追求无人值守更容易稳定下来。