让 Agent 盯 PR，四个开关决定它能不能上夜班

一个 PR 卡在 CI 里，最磨人的往往不是那段代码。

是它在凌晨两点红了，没人知道是 flaky test、构建机抽风，还是刚合进去的改动真把东西弄坏了。早上有人打开 Slack，发现线程已经叠了二十几条，大家开始轮流补一句「我看一下」。这种活没有技术含量吗？有。可它又特别容易把整块工作时间切碎。

Factory 这两天把 Automations 正式开放了。它的 Droid 可以按时间表、Slack 消息、GitHub 事件或 webhook 启动，去做 PR 跟进、失败 CI 分诊、安全审查、文档更新这一类总会再回来的工程工作。官方产品公告列出的模板里，甚至已经有 Ticket to PR、PR Reviewer、Security Audit 和 PR Babysitter。

很多人看到这里，脑子里大概已经有画面了，找个模型，写段 prompt，把它排进 cron，然后从此安睡。好家伙，真正危险的部分恰好从这里开始。

Agent 能把一次任务跑通，和它值得每天替团队跑一次，中间隔着的不是一个定时器，而是一套谁来负责、怎么验收、失败往哪儿去的规则。

不是把 Agent 接进流程，而是给它一张夜班工单

一条自动化不是普通对话的重复播放。普通对话里，你还在屏幕前，发现它跑偏了可以立刻打断。定时任务没有这个缓冲，它收到事件就会带着某个身份和一组权限往下走。

Factory 把一条自动化拆成四个基础部件，触发器、指令、模型和计算机。这个拆法很朴素，却刚好把许多团队最容易混在一起的决定拆开了。

触发器决定它为什么醒来。每天上午九点的汇总，和某个 GitHub 事件一出现就启动，风险完全不同。前者漏一次，通常只是少一封摘要。后者如果把每个失败 CI 都当成要修的回归，可能会把一整晚的预算和分支都耗在基础设施抖动上。

指令决定它要交什么。这里最容易写成「检查失败并修复」这种看着很勤奋、实际没有验收边界的话。更能落地的版本应该把工作切开，例如先归类失败原因，再只对明确的测试回归开草稿 PR，外部依赖超时则只贴回链接和日志位置。别让一个动作词把诊断、修改、提交和合并偷偷打包。

模型决定这趟夜班花多少钱，也决定它在模糊证据面前有多容易自信。Factory 允许每条自动化选模型和推理强度，也支持路由。官方称其现有用户的代码审查自动化中，30% 使用了开源权重模型。这个数字不是选型建议，但提醒了一件事，日常分类和高风险审查不必共用同一档能力与成本。

计算机则决定任务实际摸得到什么。跑在受限的 CI 环境、团队管理的远端机器，还是某位同事连着本地凭据的电脑，表面上都是「让 Agent 做事」，权限半径却差得很远。把这件事说清楚，才能谈后面的自治。

Factory 官方公告的主视觉。本文没有对产品做第一手实测。

真正该写进自动化里的，是四个问题

如果你准备把一个重复工作交给 Agent，不妨先把下面四个问题写进任务说明或评审单里。不是为了把流程写复杂，而是为了让它在没人盯着的时候还有刹车。

第一，它碰到什么才应该启动。触发条件要能被复查，别写「有异常就处理」。比如只在主分支的 CI 失败时唤醒，或者只处理带某个标签、已经有人确认需要修复的工单。触发范围越大，后面误跑的成本越高。

第二，它要交付什么证据。对于 PR 审查，交付物可以是一条带文件位置和复现命令的评论。对于 CI 分诊，交付物可以是「回归、脆弱测试、基础设施」三选一，加上判断依据。让 Agent 交证据，不是只交一句「已完成」，人接手才不需要从头猜。

第三，它以谁的身份做事。Factory 的文档把 run identity 单独列出来，自动化既可以按个人身份跑，也可以按服务账号跑。这个差别不能藏在配置默认值里。读仓库、发评论、创建分支、使用密钥，各自应该对应不同身份和最小权限。服务账号看起来省心，却意味着它的每一次动作都不再天然对应某个正在在线的人。

第四，失败后它去哪儿。官方提供事件流、运行历史、七天成功率和失败通知，这些不是后台装饰。它们该成为自动化上线条件的一部分。连续失败三次时停掉还是降级成通知，低置信度时创建草稿还是只提工单，超过预算时保留哪些上下文，这些出口不写，所谓自动化只是把值班从人转给了一个不会喊累的黑箱。

自动化不是一条直线。它必须有人工确认的出口，也必须有失败回到队列的路。

把这四个问题落到纸面，最好别只写「有审批」这么一句空话。审批的是哪一个动作，谁有权通过，超时后谁接班，审计记录留多久，都应该能被新加入项目的人读懂。权限边界也是同理。允许读日志，不等于允许改配置。允许创建草稿 PR，不等于允许合并。允许调用测试环境，不等于允许把生产密钥带进上下文。看起来有点啰嗦，真出一次问题时却能少掉一大截「到底是谁让它这么干的」追问。

还有一个经常被漏掉的点，触发器本身也是输入。Factory 的 webhook 自动化会生成 URL 和 secret，而且 secret 只在创建时展示一次。把它当成普通通知地址，等于在自动化入口放了一个没有来客登记的侧门。事件来源要能验证，负载要能回放，异常频率要有限制。Agent 再会写代码，也不该替你给陌生输入背书。

Factory 的文档还提到，删除自动化、以及让服务账号运行自动化，属于风险更高的操作，需要额外审批。这条挺值得抄。创建一个会动手的流程，不该比删一行 cron 更随意。

从「PR Babysitter」开始，比从「自动修一切」靠谱

官方最有意思的模板之一叫 PR Babysitter。它盯住开放中的 PR，发现失败 CI 后做处理，并可以接上失败分诊。这个切口比「让 Agent 自动开发」小很多，却更接近真实团队的堵点。

一个靠谱的第一版，可以只做三件事。

它扫描指定仓库里新失败的 PR，拉取失败步骤和最近改动。它把失败归到几个有限类别，并把证据贴回 PR。只有当类别是明确回归、改动范围小、测试可复现时，才创建一个不合并的修复分支或草稿 PR。其余情况，它不抢着表演，只把需要人看的地方提出来。

这套安排有点笨，甚至没有「全自动修复」听上去那么酷。但它把最容易扩散的动作压到后面，把最容易复查的动作放到前面。工程系统里，能稳定地少打扰一次人，比偶尔英勇地替人做完一切，更接近长期收益。

这也给了自动化一个很实用的试运行方法。先把它安排成「影子夜班」。它照常读取事件、给出分诊和建议，却不创建分支、不改文件、不发外部消息。跑上一段时间后，拿它的判断和人工结果对照，看看它误报在哪里，漏报在哪里，哪类失败总会被归错。等这些偏差收敛，再把权限从评论、到草稿 PR、到有限范围的修复，一格一格打开。不是因为人类不信任 Agent，而是因为每一格权限都应该换来可核验的新证据。

Factory 公告中给出的数据也适合这样看。过去 30 天，其企业用户中 52% 使用自动代码审查、48% 使用安全审查、35% 使用 AutoWiki，自动化会话量增长 51%。Factory 自己则称 Droid 审查了 99.5% 可合并 PR，工程师解决了其中 81% 的评论。这些都来自厂商自报，不能当成你团队也会得到的结果。不过它们至少说明，最先被反复交给 Agent 的，并不是凭空造一个大功能，而是审查、分诊、知识同步这些已经有明确输入和输出的循环。

自动化的单位不是任务，而是可撤回的承诺

很多 Agent 产品喜欢用「从工单到 PR」做演示，因为从头到尾很完整。可日常工程里更常见的情况是，任务本身没问题，环境、权限、依赖和上下文不断变。你让它跑一百次，第九十九次出错的原因可能根本不在 prompt。

所以第一条自动化最好有三个很具体的限制。限定一个仓库或一类 PR。限定一个不能跨越的权限边界。限定一个能让人接手的失败出口。这样它就算跑错了，也能撤回、追溯、复盘，而不是留下一个「昨夜已经处理」的谜语。

跑稳以后，也别只看成功率。一个自动化的价值还藏在它替团队留下了什么。失败分类能不能反过来暴露最脆弱的测试，人工驳回原因能不能变成下次的规则，反复被转回人工的任务是不是根本不该自动化。把这些信号留在同一条运行记录里，才有可能从「省掉几次点击」走到真正减少返工。否则它只是把忙碌搬到了一个更安静的地方。

这也是我更愿意把这类能力叫成「夜班工单」，而不是「无人团队」的原因。团队没有消失，只是把最反复、最可观察的一段工作先交出去。人依然决定什么时候启动、信任什么证据、谁拥有最终动作。

Factory 的新功能值不值得上，取决于你的团队是否已经把这些边界写清楚。要是还没有，倒也不必等产品全配齐。先挑一个每周都会回来、出错后也能安全退回人工的循环，把触发、交付、身份和失败出口写成四行字。

能把这四行写清楚，Agent 才真的有资格上夜班。

你们团队里，哪一类重复工程工作最适合先交给 Agent，又最不该让它直接合并？