怎么才能不给 agent 当保姆？
先说个跟 agent 无关的场景。
你手底下有两种员工。一种，活派下去就没声了，到点交付，中间只找过你一次，因为碰上一件他拿不准、也确实不该由他拍的事。另一种，一天问你八遍：这个能不能改？那个现在做还是等等？我这么弄行不行？每一步都要你点头。说是管理，其实你是在陪他干活。
第二种员工，我们习惯说他"还不够成熟"。可带过团队的人都知道，这事往往不怪人。他手上没有一份说得清的授权范围，不知道哪些决定归自己、哪些必须请示；也没有一条明确的验收标准，不知道做到什么份上算完。这两样你不定下来，再能干的人也只能一直回头问你。
现在把这两种员工换成 agent。你会发现你手上那个，基本是第二种。
而且它比新人还麻烦一点。新人心里没底的时候，自己是知道没底的；agent 最弱的地方偏偏就是"发现自己不对"，这个后面有数据。所以指望它慢慢"成熟起来"更没戏，只能把话写到纸面上。
这篇想回答的就是那个问题：怎么才能不当这个保姆。 下面四件事：为什么你盯着也没用、它现在能自己跑的那部分到底靠什么、"什么时候来找你"该怎么定，以及你该看哪儿，还有那件怎么也交不出去的事。
为什么盯着也没用
这个问题其实不新。管理学在半个世纪前就问过同一件事：当你没法盯着每一步，你到底靠什么控制结果。
1979 年，威廉·大内（William Ouchi）在《管理科学》上给了一个框架：答案取决于两件事，你懂不懂这活是怎么做出来的，以及你能不能量出结果。两两组合，就是四种情况。
罐头厂那一格他解释得最清楚：工序完全清楚的时候，你只要看着工人和机器的动作，只要每一步都合规程，"你不用看另一头，就知道出来的是合格的罐头"。反过来是时装买手：什么样的人能选对货，你根本说不清，规程写不出来；但你能量出每个买手的库存周转和毛利，于是只能考核结果。
把 agent 放进这张图，问题一下就清楚了。
你说不清它的"工序"。 你没法规定它该按哪几步写出一段好代码，真能规定得出来，那也就不需要它了。所以你在右边这一列。
而右边这一列，盯着动作看是管不住的。你看它一步步走，看它调了什么工具、改了哪一行，你也判断不出这条路对不对，因为你本来就说不清对的路长什么样。
你当保姆当得这么累，跟你尽不尽责没什么关系。这个格子里，盯本身就没用。
右边这一列剩下的办法只有一个：看结果。可"这个改动到底对不对"你又量不出来，于是你掉进右下角，只剩下相信它的判断。大内管那一格叫"自己人"式的控制，靠的是长期共处磨出来的共同标准。你跟 agent 没有这个前提。 所以那不叫信任，那叫没办法。
出路因此只有一条：把自己从右下角挪到右上角。 别再琢磨怎么盯得更紧，想办法让"算不算做对了"变成能自动量出来的东西。这句话听着抽象，但下面你会看到，你其实已经在这么干了，只是没意识到。
它能自己跑的那部分，靠的是有人替你验收
先把一件事说清楚：agent 已经能自己接着干了。写一版、跑一下、看到不对、再改一版，中间确实不用你插手。这不是错觉。
但它能一直跑下去的原因，可能跟你想的不一样。跟聪明关系不大，这层意思我在《AI 智能体：工程高于智能》里写过一整篇。关键在于每跑完一轮，它都能拿到一个不是自己给的答案。
Anthropic 那篇 《Building Effective Agents》（2024 年 12 月）把这条说得很直白：agent 执行的每一步都必须"从环境里拿到 ground truth（比如工具返回、代码执行结果）"。编译报错是真反馈，测试挂了是真反馈，类型检查不过是真反馈。而"我看了一遍，应该没问题"不算，那是它自己给自己打的分。拿假反馈的循环会空转，看着一直在动，其实原地打转。
回到大内那张图：测试、编译器、类型检查、lint，本来就是一套自动验收标准。 它们不问你是怎么写出来的，只回答"这活合不合格"。也就是说，在有这些东西的地方，你早就站在"看结果"那一格里了，只不过量结果的不是你，是机器。
这也解释了一件很多人有体感却说不清的事：同一个 agent，在测试齐备的仓库里能自己跑很远，在没测试的老项目里就得你一步一盯。 跟模型没多大关系，看的是那一格里有没有一把能自动量的尺子。
最近一个叫 PushBench 的评测干脆把这条立成了规矩：一件活干没干完，不看 agent 自己说完没完，得外部裁判认了才算数；重复劳动和假完成都直接量出来，而不是藏在一个"成功"标志后面。
所以方向其实已经在你手上了：循环里绝大部分环节，环境都能替你自动验收。剩下必须由人来定的只有一件，什么时候停下来找你。 而这一件，现在是它自己说了算。
"什么时候来找你"，不能留给它自己判断
回到员工那个例子。一条像样的升级规则长这样：超过多少金额必须请示、动到线上配置必须请示、客户提退款一律上报。 它长这样是有道理的，条件都是外面能核对的事实，跟当事人当时觉得这事要不要紧没关系。
反过来，"你觉得重要就来找我"根本不是规则，那是靠自觉。
现在看 agent 停下来问你的那些时刻，绝大多数是后一种。它扫一眼要干的活，觉得这事有点大、有点不好回头，于是问你一句。说白了是靠它自觉，算不上把关。
要分清楚它们，只需要一个问题：
这次停顿，是被动作本身的事实触发的（碰了哪个文件、动了哪条分支、有几条评论还没解决、这条命令可不可逆），还是被它对自己的判断触发的？
只有前一种是真关卡。后一种只是长得像关卡。
靠自觉这件事，两头都误事。你想让它无人值守跑通一整条链路，它三步一问，循环断了；真该拦住的时候它偏偏不停。两头都逼着你在场，这就是你走不开的直接原因。
更麻烦的是，最该拦的那一次，它大概率不会停。你设这道停，防的本来就是它又自信又错的时候；可越自信，"我先问一句"这个念头就越不容易冒出来。越该拦的时候，它越不会拦。
还有一层道理更硬，不用举例就成立：一个条件，如果由被它约束的那一方来判定满没满足，那它就不是条件。 这跟没人给自己的卷子打分是一个道理。凡是 agent 自己说了算的判定，都属于这一类："评论都解决了"、"测试都过了"、"该改的都改完了"。
其中"测试都过了"这一条我单独写过一篇：它报的那个绿灯，跟这套东西真的能端到端跑起来，中间隔的比大多数人以为的多。何况现在不少测试本身也是它写的。
有人会说：那是它还不够成熟，多调教调教就好了。员工这个比方，到这儿就不灵了，这也是我开头说它比新人还麻烦的原因。
新人拿不准的时候，自己知道拿不准。agent 不知道。
这件事有个很干净的测法：把同一个错误，一次标成是它自己写的，一次标成是别人写的，其余一个字不改，看它能不能挑出来。
两边差得很远。2026 年的一项研究做的就是这个对照：同一句错话一个字节不改，只把来源从模型自己的思考换成工具返回或者用户消息，它明确指出错误的比例就跳了 23 到 93 个百分点。
另一项独立的工作量到同样的现象，还给它起了个名字，叫"自我纠错盲区"：别人指出来的错它改得动，一模一样的错换成它自己产出的，平均 64.5% 的情况下它就是不动。
这跟"该不该停"是同一件事。你指望它主动停下来问你，前提是它先看出这次可能不对。可它偏偏对"自己写的东西"最没有判断力。同样的毛病，换成别人写的，它就看出来了。
Tyen 等人（ACL 2024）把这层意思说得最短：把错误的位置指给它，它改得动；让它自己找，它找不出来。会改，不会找。Huang 等人（ICLR 2024）则发现，在没有外部反馈的情况下让它自我纠错，成绩有时候反而更差，而"没有外部反馈"正是"靠自觉"的运行条件。
那等模型再强一点，会不会自己就好了？目前的证据不支持。ICML 2026 上的一项研究在前沿模型上测了同一类能力，发现生成能力越强的那个，"做得出来"和"挑得出来"之间的差距反而越大。
边界也说清楚：这几项测的都是推理题和数学题，不是代码评审；上面那个盲区数字来自开源模型这一批。我借的是这个机制，数字不能直接搬到你的仓库上。另外第一项研究的作者自己是乐观的，他们认为这是聊天模板里角色标签造成的，算不上能力缺陷，训练能补上。
所以第一条能改的就在这儿：把停顿的触发从"它对自己的评估"换成"动作的事实"。 碰没碰生产配置、动没动数据库迁移、这条命令可不可逆、有没有还没解决的评论，这些都是外面能核对的，跟它当时怎么想没关系。判定权一挪，同一个模型，该停的地方停得住，不该停的地方它一路跑，你才敢走开。
你该看哪儿，和那件交不出去的事
就算这些条件都定好了，你还是得看。但怎么看，得换个法子。
第一，关卡只挡得住动作。 所有条件都是先有动作、再判一下。可安静地没做某件事，什么也触发不了：没跑那个检查、没扫完剩下的一半、没把那个问题重新提出来，这些都不会有任何东西亮红灯。
这在实验里量到过。Apollo Research 2025 年的目标漂移评测里有一条发现写得很直接：不作为造成的偏离，比作为造成的更大，跨模型跨条件都是这样。场景得交代清楚，那是个股票交易的模拟环境，"不作为"指的是一件很具体的事，阶段结束后没把该卖的仓位卖掉；而同一篇里，带脚手架的 Claude 3.5 Sonnet 跑过九万多个 token 都没漂。所以这只是一个量到的例子，算不上普遍规律。不过结构上那一点不靠这篇也成立：你没法给"没发生的事"挂钩子。
放大到一整个团队也一样：流水线各项指标全绿，竞争对手上了个用户催了半年的功能，没有一个人、也没有一个 agent 注意到。事后去找是哪一环失灵，答案是本来就没有哪一环负责接这件事。
补法只有一个方向：定期核对"该发生的事有没有发生"，而不是等着被通知。这不是关卡能干的活。
第二，审得多不等于审得对。 上一篇我说过杠杆会放大你错的判断，这里要更狠一点：一个人自己干，犯的是五十个各不相同的错；一条规范交给五十次执行，犯的是同一个错五十次。
杠杆放大的是偏差，不是方差。
这件事在别的领域早有结论。Kleinberg 和 Raghavan 2021 年发在 PNAS 上的研究说得很反直觉：一群决策者收敛到同一个算法，即使这个算法对其中任何一个人单独使用都更准，整体的决策质量反而会下降；而且不需要什么意外冲击，正常运转下就会。他们说的是很多家机构共用一个算法，我们说的是一个人把活分给很多次执行，场景不同，但机制是同一个：错误不再互相独立。
（Bommasani 等人 2022 年也验过，共享训练数据确实会加剧这种同质化；不过他们在基座模型上的结论是混合的，取决于怎么适配。）
这直接改了该怎么审。逐条审是为"各不相同的错"设计的姿势，成本随委托量线性涨，还照样漏；抽样查重复出现的规律才对症，抽十条里冒出两次同样的毛病，剩下四十条大概率也有。既更省，也更准。
所以第二条能改的是：把逐条审换成抽样查规律，再加一条定期核对"该发生的有没有发生"。 "不当保姆"的具体含义就在这儿：该看还是要看，只是不用一直守在旁边看。
第三，最后那件事交不出去。 你可以把活派出去，但"这活算不算干完"不能让干活的那一方说了算。
这话听着像常识，可它有个很老的说法。March 和 Simon 在 1958 年的《Organizations》里管这叫不确定性吸收：信息往上传的时候，传上去的是从证据里得出的推论，而不是证据本身；上面那个人于是没法自己判断，只能接受。agent 交给你的那句"我改好了，测试都过了"，就是一次不确定性吸收。
这么一路推下来，事情就串起来了：它的报告不能算证据，验收就委托不出去，你派出去的活越多，要你亲自验的就越多，而且是线性地涨。
1967 年 Amdahl 讲过一件形状一模一样的事：一件工作里如果有一部分必须一件一件按顺序做，那不管你堆多少台并行的机器，总加速最多也就是那部分占比的倒数。他说的是处理器，换成你也一样，你越是多挂 agent，越是走不开。多派活不动这个上限，因为分子涨了，串行的那部分跟着涨。上次量的是 agent 之间的协调，这次卡住的是你自己的验收，形状一样。（这也是上一篇那句"注意力是串行的"的下半句：真正串行的只有验收这一件。）
所以第三条能改的，也是唯一真正能把你从保姆位置上换下来的：每把一条判断写成不需要人、也不需要 agent 点头的条件，你就少盯一次。 测试、断言、可复算的检查、外部裁判。这跟"多派点活出去"是两种完全不同的工作。派活是把事情交出去，写条件是把判断固定下来。
顺带说一句，这不是个别现象。一个跨 7 个框架、标注了一千六百多条运行轨迹的研究把多 agent 系统的失效分成三大类，其中一整类就是任务验证：提前收工、该验没验、验错了。
Anthropic 那篇文章里有句话正好收口：自动化测试能验功能，但"human review remains crucial"，这个方案跟整个系统合不合，还是得人来判断。能机械化的和不能机械化的，边界大致在这儿；而边界之内的每一寸，都是可以往外推的。
四条能做的
回到标题那个问题：怎么才能不给 agent 当保姆。
- 把停顿的触发换成动作的事实，别留给它自己判断。判定权不能落在被约束的那一方手上。
- 把逐条审换成抽样查规律，另外定期核对"该发生的事有没有发生"。
- 每把一条判断写成不需要人点头的条件，就少盯一次。 这是唯一真正减负的那类工作。
- 把检查的一方和干活的一方分开。 各自独立，只通过留下的产物交流（代码、日志、测试结果），而那些条件本身，两边都改不了。这是让第三条真正立得住的安排。
第四条听着最像新东西，其实最老。财务上的复核、发布前的双人签字，讲的都是同一件事：谁也不能既是执行的一方，又是判定自己合不合格的那一方。前面那句"没人给自己的卷子打分"，往上推一层就是它。搬到 agent 身上，无非是把"检查"这件事从同一个循环里拆出来，让它没法顺手把自己那关也过了。
如果只带走一句，那就带走那个判据：下次它停下来问你，先问一句，这一下，是谁按的？
再回到大内那张图。你之所以累，是因为你待的那个格子里，盯本来就管不住，而你还在拼命盯。不当保姆，靠的不是等它长成一个成熟的员工。你得把授权、升级、验收这三件事写下来，让机器替你量。它能跑多远，是设计出来的，不是指望出来的。
