评审 Agent 必须有权质疑事实卡本身

2026-08-25

我这条内容流水线是这么分工的：我先把可核实的硬事实固化成一张事实卡，每篇文章绑定一张卡，写作的子代理只准使用卡里的内容，不许自己去核、也不许联网。写完之后有一个独立的评审 Agent，它拿不到实现者的推理过程，只拿到落盘的文件和那张卡，逐条核对文章有没有超出卡的范围。

这套分工是我自己搭的，用了一段时间之后我给评审的返回结构里多加了一个字段：允许它对事实卡本身提异议。加上之后连着几批，它交回来的不是文章的问题，是卡的问题——而卡是我亲手写的。

一、现象：审查者开始往上游报错

加字段之前，评审的输出全是关于文章的：哪一段超出卡的范围、哪句话是推断、字数够不够、结构缺了哪一节。这些反馈的方向是一致的，都指向被审查的那篇产物。

加字段之后出现了另一类反馈，方向是反的，指向我。几批下来它实际报上来的大致是这几种：

某一节的小标题里写明了「这是几段结构」，下面实际列出来的条数比标题说的多。实现者按标题写还是按列表写，会得到两种不同的文章骨架。
某一条判据和同一张卡里的负面清单互相打架：判据要求写出某类内容，负面清单又把这类内容划成禁区。两条都是我写的，分开看都成立，放一起执行不了。
某处对「有几个节点」的表述有歧义，不同的实现者会读成两个不同的意思，而且两种读法都不能算读错。
最难堪的一次：我改过一次卡，只改了后面那处，忘了回改上文里对应的旧表述，于是同一张卡里两种说法并存。评审把两处原文一起贴上来，问我以哪个为准。

这四种里没有一种是文章写错了。它们全都是标准写错了。

二、当时是怎么发现的

这个口子不是我设计出来的，是先撞上、后补的。

最早的信号是一种很特别的失败形态：同一处问题在同一批的好几篇里同时出现，而且措辞几乎一样。我第一反应是实现者的共性偏差——同一个模型、同一份规格，写出相似的毛病很正常，那就改提示词。但改提示词这个动作我做到一半就卡住了：我发现我说不清要改成什么，因为那几篇的写法确实是卡里那句话最自然的读法。

回头去看卡，问题就在卡里。

这个发现方式我后来专门记下来了，因为它比问题本身更有用：**如果一个错误在整批里等比例出现，根因大概率在共享的上游，不在各自的执行者身上。**执行者的错误是散的、各错各的；上游的错误是齐的、整整齐齐一起错。看到「齐」就该往上游查，而不是去改下游的提示词。

第二个信号来自我回头去看评审的返回结构长什么样。那时候它要填的格子是：这篇的标识、字数、改掉了哪些、还剩哪些没解决、以及一个三值的结论。我照着这几格从上到下过了一遍，发现一件很简单的事——每一格问的都是文章层面的事，卡有没有问题，它没有格子可以填。

这跟「它看不看得出来」是两回事。一个没有位置承接的判断，就算它心里有，也没有被要求每轮都想一遍。我当时把评审做得不够好，归因归到了它的能力上，其实是我给的返回结构里少了一格。

两个信号合起来，要补的东西才变得具体：不是把提示词写得更严，是在返回结构里开一格。

三、为什么会这样

想明白之后，原因其实不复杂，是我自己的分工留下的结构性缺口。

**第一，事实卡是整批的单点上游。**我把「核实」从「生产」里拆出来单独做，好处是核实只做一次、口径统一、子代理不用联网。代价是所有篇共用同一个源头。源头对，整批受益；源头错，错误会等比例复制到整批的每一篇里去，而且每一篇看起来都很规范——它们确实忠实地执行了标准。

**第二，只授权「核对产物是否符合标准」，等于把标准本身放在了检查范围之外。**这是最要命的一点。一个只被允许比对产物和标准的审查者，面对一条错误的标准，它的正确行为恰恰是判定文章合格。它越尽职，错误传得越干净。这不是它的失职，是我给的职责边界里就没有这一格。

**第三，卡是人写的，人改卡的时候一样会犯改一处漏一处的错。**上面那个「两种说法并存」就是我自己改出来的。我没有理由假设自己写的标准比子代理写的文章更不容易出错。

四、改成了什么

改动很小，就两处。

一是在评审的返回结构里给「对事实卡的异议」留一个独立的位置，而不是让它塞进别的字段里。结构化的位置和自由发挥的区别在于：有位置，它每次都会去想一遍「卡有没有问题」；没位置，它只在忍不住的时候才顺嘴提一句。

二是在评审规范里把这条权限写成明文，同时给了一条限制：

你有权质疑事实卡本身。如果卡里某条与另一处矛盾、或明显不合理，在返回里写明，不要自行「修正」后写进文章。

这条限制是关键，也是我一开始没想到的。评审 Agent 是有能力直接改文件的，它完全可以自己判断哪个说法对，把文章按正确的那个改一改交上来。但那样只救得了它手上这一篇——卡还错着，同批的其它篇继续按错的写，下一批也继续。异议必须回到我这里，由我去改卡，再回头把整批已经写完的按新口径查一遍。

所以这个字段真正的用途不是「让评审顺手把错纠了」，而是把一次局部发现升级成一次整批处置。我处理这类异议的动作固定是三步：确认卡确实写错了、改卡、回查这一批里所有可能受影响的篇。少了第三步，前两步等于白做。

顺带说一个我之前没意识到的对称性。评审 Agent 的权限在别的方向上是被我收窄的：它能改文件，但不许提交、不许构建、不许动别的文件——审查者的操作权限不应该大于被审查者。但在「提异议」这个方向上，它的权限必须比实现者更宽：实现者被死死约束在卡内，卡里没有的一个字都不许补；评审则被允许对卡本身说不。

同一个角色，一边收紧一边放宽，看着矛盾，其实是一件事的两面：**限制它改变世界的能力，扩大它指出问题的范围。**能动手的地方越少越好，能开口的地方越多越好。

五、可迁移的判断

如果只带走一句，是这句：审查者的职责必须包含质疑标准本身，而不只是核对产物是否符合标准。

判断什么时候必须开这个口子，我用的问法是：**这个标准被多少个下游共享？**只被一个执行者用，写错了就错一次，事后能看出来。被一整批共享，它的错误就是等比例扩散的，而且扩散出来的产物个个合规、挑不出毛病——这种错最难在下游发现，因为下游根本没有发现它的立场。

配套的两点，是我这次实际付出代价才补上的：

一是反馈通道要有结构位置。指望审查者「觉得不对就说一声」是不可靠的，它会说得很含糊、藏在别的字段里、或者干脆不说。给它一个必须填的格子，它每一轮都会去想。

二是向上的异议不许就地消化。谁发现的谁顺手改了，这次是解决了，但标准还错着，下一批照样中招。异议要回到能改标准的那个人手里，并且触发一次对已完成产物的回查。

我现在回看，加这个字段之前那段时间里，我的审查其实只覆盖了一半——产物那一半。上游那一半一直是靠「我自己写的应该没问题」撑着的。撑不住的时候，它不会报错，只会安安静静地按批放大。

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