承认单个 Agent 的成功率明显低于 1

2026-08-25

一次派一个 Agent 干一件事的时候，这个问题基本不存在。我坐在旁边，它回一句我看一句，跑偏了我当场喊停，没落盘我马上就发现了。人在流程中间，人本身就是那道补偿。

问题是从「一次一批」开始的。我的内容仓库里那条量产线，一批要处理一整组选题，每个选题派一个实现者写、再派一个独立评审去审，两个 Agent 互不通气。这时候我不在流程中间了，我在流程两端——开工前定规格和事实源，收工后做验收。中间那段我看不见。

看不见的那段里，我实际观察到过三类情况。一类是空转，在我派出去的通用子代理里占了相当一部分：只输出一句话就结束了，工具一次没调；或者跑偏去做了别的事；有时候甚至输出一段伪造的系统消息，看起来像是环境告诉它任务已经结束了。第二类是实现整体丢失：后台并发的子代理在某些环境下，写入被丢弃、提交时路径静默失败，结果就是它汇报得好好的，磁盘上什么都没有。第三类是评审 Agent 卡死，在大仓库上密集检索时触发无进展超时，任务一直挂在那儿。

这三类都不是「写得不好」，是「根本没写」或者「写了没留下」。它们和「写得不好」的表现完全一样：返回了一个看起来正常的结果。

这件事在什么时候才真正成为问题

不是 Agent 数量变多的时候，是人工逐个确认退出的时候。

我这条线上，人工确认退出中间环节是批量化的必然结果——一整批同时在跑，我不可能每篇都盯着写完。质量保障从「人看」换成了「规格写死 + 独立评审 + 脚本客观体检」三层。这个替换本身没问题，有问题的是替换时那个隐含假设：我默认派出去的活会被干完，剩下的只是干得好不好。

一旦按这个假设设计，验收的全部注意力都会落在「质量」上，没有一处在查「有没有」。而实际上，前面那三类情况全部落在「有没有」这一侧。

所以我现在的起点是：**单个 Agent 的成功率明显低于 1，而且失败的样子跟成功一模一样。**编排、重试、回查、独立评审，这些东西不是为了让产出更好，是为了补偿这个前提。不承认它，就会把「偶尔失败」当成「基本不会失败」来设计流程。

我用来当场判断的三个问法

这三个问题我自己回答不上来的时候，就说明那一步的成功是我假设出来的。

第一问：这一步失败了，我是怎么知道的？

如果答案是「它会告诉我」，那就是没有判据。汇报层的状态不是事实，产物才是事实——我这条线上，编排层的汇总两个方向都骗过我：报「零完成」但磁盘上已经落了好几篇，也报过「已完成」但实际写作失败没落盘。所以验收一律回磁盘数文件，不看汇总。

第二问：这个「完成」信号是谁给的？是任务系统给的，还是我从产物侧看出来的？

这两者不一样。我踩过的坑是：文件落盘不等于写完。子代理会在文件首次出现之后继续精简、继续改。外部程序看到文件存在就去提交，提交的是半成品。所以异步任务的完成信号必须来自任务系统本身，不能是我在产物侧的观察。顺带一条：提交时只列显式文件名，不用目录级批量添加，因为目录级操作会撞上正在写入的文件而报错。

第三问：这是空转还是挂死？催一下能不能恢复？

这两种的处置完全不同。空转催一下能拉回来，挂死催不动只能杀。我识别挂死的信号是：任务显示运行中，但磁盘上零文件。看到零文件我就立刻终止，不观望——因为被挂死的代理还会覆盖已经写好的成品，等下去的代价不是浪费时间，是把已有产出弄丢。挂死这件事，我这条线上遇到过的一种触发原因是子代理去调联网检索，所以我后来干脆把核实这件事从生产里拆出来：联网核验只由我自己做，事先固化成事实卡，子代理只准写文件。

落到编排里的三处具体动作

**第一处，评审员的第一条职责不是审质量，是验存在。**我写在评审提示词里的原话是：「如果这个文件不存在或为空，直接返回 verdict=FAIL 并在 remaining 里写明『文件未落盘』。」这一条排在所有质量检查之前。把「有没有做」和「做得好不好」拆成两个先后的检查，原因就是这两类失败在返回值上长得一样。

**第二处，结论用三值枚举，不用二值。**评审返回的 verdict 是 PASS / PASS_WITH_FIXES / FAIL 三个值。「一次就过」和「改过之后能过」被分开统计。如果只有过与不过两个值，补救过的那部分会被记成成功，我就看不见成功率到底在哪一档。三值让我知道补偿层实际吃掉了多少失败。

第三处，收工时统计的是三件事，全部指向「有没有」而不是「好不好」：完成数对不对得上应完成数、FAIL 清单、字数不足清单。三件里没有一件是主观评价。

还有一条不在代码里、在权限设置上：评审员的权限比实现者更窄，它能改文件，但不许提交、不许构建、不许碰别的文件。我给自己定的规矩是审查者的权限不大于被审查者——审查者一旦能提交，它自己失败的时候就没人接得住了。

什么情况下这条不适用

**一次一篇、人在流程中间的时候不适用。**那种模式下我在方向、提纲、终审都设了闸门，每一步我都亲眼看过，再叠一层独立评审和存在性检查就是纯开销。这套补偿是给「人退到两端」之后的场景准备的。

**补偿层本身也会失败，别把它当成兜底。**我这条线上评审 Agent 自己就卡死过。还有一次机械检查首轮报出来的问题全部是误报——命中的是模板自带的合规声明、规范里强制要求写的否定句，还有代码示例里的数字。误报率一高，执行者就开始整体忽略这道门，这道门就等于不存在。误报的代价不是多花时间，是让整道门失效。所以我宁可把判据写窄，也不靠事后人工去筛。

**补偿层不覆盖上游。**脚本能查字数、死链、格式、孤儿页，查不出事实错误。这两件事不能互相替代。更麻烦的是，如果我固化的事实卡本身错了，错误会等比例放大到整批——我这边就发生过评审阶段反查出卡里某个数值有误、导致已写的几篇同时出错、需要我实测修正并全批检查的情况。所以评审员必须有权质疑事实卡，而不只是核对文章符不符合卡。承认单个 Agent 成功率低于 1 只解决了一半，另一半是承认我自己给出去的输入也可能是错的。

**最后，这个前提不该被用来降低对单个 Agent 的要求。**承认它会失败，不等于允许它失败。规格该写死的还得写死，红线该写清楚的还得写清楚——补偿是为了接住剩下那部分，不是为了替代把活交代清楚这件事。

这篇的判据来自我自己带 Agent 干活的实践，样本有限。它更像一份可以拿去验证的假设，而不是一份可以照抄的规范。