Agent 批量生产：把核实从生产里拆出来单独做

2026-08-25

我自己带着一批子代理做过一条内容量产线：一次给出一批选题，每篇派一个实现者去写，写完再派一个独立的评审员去审，人只站在流程的两端——开工前定规格和事实来源，收工后验收。这篇复盘的是这条线上的一次结构调整：我把”核实”从”生产”里拆了出来，变成开工前必须先做完的一道单独工序。

这不是什么普遍规律，是我在自己这条线上撞出来的安排。下面五段按顺序讲：当时看到了什么、我是怎么发现的、为什么会这样、改成了什么、以及从这一次里我带走了哪句话。

一、当时看到的是什么

最早那版流程很朴素：规格里写清楚这批文章的范围和口径，事实来源写一句”以某某材料为准”，剩下的交给实现者——你自己去查、自己去核、自己写。听上去很合理，每个子代理都是完整的、能独立交付的单元。

跑起来之后出现的不是”写得不好”，而是三种更别扭的状况同时冒出来。

第一种，一批任务里总有几个长时间停在运行中，既不报错也不返回。第二种，同一个事实在不同篇文章里写法不一样——不是措辞差异，是口径本身对不上，同一个东西在这篇是一种说法，在那篇是另一种说法。第三种最麻烦：整批的完成时间被少数几个”还在查”的任务拖住，而它们查的往往是同一件事。

我一开始的判断是错的。我以为这是写作质量问题，想去改提示词、加约束、把文风要求写得更细。改完之后该慢的还是慢，该打架的还是打架。

二、当时是怎么发现的

发现问题的方式跟问题本身几乎没关系，这一段我觉得比结论更值得记。

我当时养成了一个习惯：验收从不看编排层给我的汇总，只回磁盘上数产物。这个习惯本身是另一次踩坑逼出来的——汇总层的状态两个方向都会骗人，既可能报着没完成而文件早已落盘，也可能报着已完成而实际什么都没写出来。我认的是产物，不是状态。

正是这个习惯让我撞见了那条关键线索：有几个任务显示着运行中，但磁盘上零文件。

这个组合很反常。写作类任务哪怕跑偏了、写砸了，也会留下点东西；“运行中 + 零文件”意味着它压根没走到写的那一步，是卡在了前面。我顺着往前推，前面只有一件事——它在查资料。再往下看，被卡住的那些任务有个共同点：都调用了联网检索。

后来我把这个组合固定成了一条识别信号，也把”挂死”和”空转”分开处理：空转是催一下还能回来的，挂死是催不动、只能杀掉重派的。两者外观很像，处置完全不同。还有更难受的一点——被挂住的任务在某些情况下会把已经写好的成品覆盖掉，所以发现零文件必须立刻终止，不能观望着等它自己好。

线索找到之后再回头看那两条”打架”和”慢”，就串起来了：这三种表现是同一个原因的三种外观。

三、为什么会这样

因为在这条线上，写作根本不是瓶颈，核实才是。

一篇文章里真正拖时间、真正决定对错的部分，是那些必须一条条对回原始材料的硬事实。写作是把已知的东西组织起来，核实是把未知的东西变成已知。前者子代理干得挺利索，后者不是它们不能干，而是这种干法本身有结构性问题。

第一，重复。同一批文章共享的硬事实其实高度重合，让每个实现者各查一遍，是把同一件事做了很多遍。

第二，失败模式不可观测。联网检索这类动作在我这条线上出现过不报错、不返回、一直挂着的情况，而这种失败恰恰没有明显的外部表现——它看上去和”正在认真工作”一模一样。一个能力好不好用，不能只看它有没有用，还得看它失败的时候你能不能一眼看出来。

第三，也是最要命的一条：各自核出的结论会互相矛盾。 独立的子代理拿到的材料片段不同、取舍不同，得出的口径自然不同。它们各自都”言之有据”，合到一起就是一批自相打架的文章。这种矛盾在单篇视角下完全看不出来，只有把整批摊开才会暴露——而那时候已经写完了。

想明白这三条之后，改法就很清楚了：核实这件事不该在生产环节里做，它该在生产之前做完，而且只做一遍。

四、改成了什么

现在这条线的开工顺序是：先出事实卡，再派实现者。

事实卡由我这个主导者自己产，把这批文章要用到的可核实硬事实一条条固化下来，逐条标注两件事——这条是实际做过的还是推测的，这条可以进正文还是不能进正文。每一条都标明来源。然后把卡交给子代理，规矩只有一句：卡里没有的不许补。

配套的约束有四条，缺一条这个机制就漏：

卡里每条标来源。 没有来源的条目等于没有这条，写不进文章。
子代理禁止联网。 联网核验只由我来做。子代理的职责收窄成一件事：写文件。
规格里写明唯一事实源，并绑定到具体的文件。 不是”参考相关材料”这种含糊说法，是把那一份卡指死，同时明确写上：不要去读原始材料。因为原始材料里混着标了”不进正文”的内容，直接读会把它们带出来。
评审员有权质疑事实卡本身。 这条是后来补的，下面单说。

卡的条目大致长这样，形式很土，但标注必须齐：

条目：<一句可核实的陈述>
状态：实际做过 / 推测
是否可进正文：可进 / 不进
来源：<具体到哪一份材料的哪一段>

改完之后，那三种表现一起消失了：没有子代理再去联网，所以不再有”运行中零文件”；口径来自同一张卡，所以不再打架；核实只做一遍，整批也就不再被少数任务拖住。

但这个改法带来了一个新的风险，我很快就领教了：卡一旦错，错误会等比例放大到整批。 以前每个子代理各查各的，错也是零星的错；现在每一篇共用一个源，源里错一条，用到这条的每一篇同时错。

这件事是评审员帮我逮住的。评审阶段有一篇被指出某个具体数值对不上，我去实测，发现错的不是文章，是卡本身。当时已经有几篇同时踩了这一条，只能由我修正卡、再全批回头检查。

所以我把评审员的职责补了一条：评审员不只核对文章是否符合卡，还要在觉得卡本身有问题时直接提出来，而不是自行”修正”后写进文章。 后面这半句同样重要——评审员擅自把它认为对的版本写进文章，会制造出一批和卡不一致、又谁也没核过的内容，比原来那条错更难查。

五、我从这一次带走的判断

把”核实”从”生产”里拆出来单独做，是批量内容生产可靠性的分水岭。

这句话我愿意再往前推一层：拆的判据不是”这件事重不重要”，而是”这件事在并发时会不会产生分歧”。写作不会——十个子代理各写各的，风格有差异但不构成矛盾。核实会——十个子代理各核各的，会核出十个版本的”事实”，而且每个都自带理由。我现在的做法是：并发会产生分歧的工序收到上游做一次，并发只产生差异的工序才放开并行。

另外两条附带的：

一是给子代理配能力，判据是”它失败的时候我能不能一眼看出来”，不是”这个能力有没有用”。失败静默的能力，宁可不给。

二是任何单点事实源都是双刃的。它把矛盾收敛了，也把错误集中了。所以下游必须留一条向上质疑的通道——审的人只被允许”对照卡检查”，那这张卡就成了系统里唯一没人检查的东西。

这篇写的是我自己那套流程里的一次实际情况，不是通行做法。你的场景、工具和团队规模不同，结论未必适用，判断方式可能比结论更值得拿走。