多智能体协作需要一个专门质疑的角色

Agent 工具领域的一切，几乎都在围绕交付做优化：更快的迭代、更长的上下文、更高的自主性。整个技术栈里，几乎没有什么机制是专门用来叫停的。所以，当 Agent 团队偏离方向时——而这迟早会发生——没有任何角色能及时发现，因为你定义的每个角色，都是为了产出而设的。

几个月来，我一直用一家由 16 个角色组成的 AI“公司”辅助编程。其中，最有价值的组织结构决策，不是换上更聪明的规划者，也不是找来更强的执行者，而是增加一个角色：它的全部职责，就是提出异议。

失效模式：层层叠加的“同意”

多 Agent 系统往往在不知不觉中出问题。每个 Agent 都经过了倾向于顺从的训练，因此，一个糟糕的计划不会在争论中被否决，反而会被不断补充完善。我曾亲眼看着一项“改进”依次经过情报部门（“看起来很有前景”）、产品部门（“定义得很清楚”）、工程部门（“可以实现”）和增长部门（“已经可以推广”）——四次同意，层层叠在一个根本没人验证过的假设上。这一串流程让人感觉方案得到了验证，其实只是多绕了几道手续，继续顺势往前冲。

最近，dev.to 上的一篇文章通过测量，很好地揭示了这个问题的一种表现：直接询问时，模型能正确指出“这个标签是错的”；但让它生成内容时，它仍然会照样输出那个错误标签。验证模式和生成模式，是两种不同的工作模式。如果流水线里的每个角色都处于生成模式，错误的东西就会在一片客气声中交付出去。

解决模式：设置独立的否决角色

我最终采用的解决办法，借鉴了人类组织处理同类问题的方式：设置一名风险官，并赋予它三个组织结构上的特征：

1. 独立的汇报关系。 风险角色不向“CEO”Agent 汇报，也不隶属于任何部门，而是与它们平级。这比角色本身有多聪明更重要：如果一个审查者的评价由被审查的人来打分，它就算不上真正的审查者。

2. 先叫停，后说明理由。 风险角色可以立即叫停任何部门的行动，之后再提交书面理由，由负责人（人类，或指定的仲裁角色）在固定时限内裁决。这个顺序是刻意设计的。如果行使否决权之前必须先论证，那么争论还没结束，行动就已经执行完了。

3. 靠职责章程，而不是凭感觉。 “小心一点”毫无用处。角色文档必须写清楚它要检查什么：没有验证记录的断言、没有回滚方案的不可逆操作、任务中途扩大的范围，以及任何触犯明确红线清单的行为。同时，也要规定它必须提交什么：叫停理由、具体证据和申诉途径。

它实际能发现什么

下面这些例子，都来自我这套系统中真实发生过的事件，经过了通用化处理：

无法验证的“已完成”。 工程角色宣布某个问题已经修复；风险角色追问了一句“把验证运行记录拿出来”，结果发现测试套件根本没执行。这不是恶意，只是拿着记录板的乐观主义。

实为垃圾信息的增长策略。 负责推广的角色提出了一套“社区触达”方案，仔细一看，其实就是把同一套推销话术发到十二个论坛。有了明确的红线清单，一句话就能叫停，无须争论。

悄悄扩大的任务范围。 一次“小规模重构”，不知不觉变成了对一个正常运行的子系统进行重写。叫停迫使团队按照变更的实际规模，重新论证其必要性。

这些都不需要天才。它们需要的，只是一个把检查当作本职工作的角色。

我最常听到的质疑：“这不会拖慢所有事情吗？”

从 token 消耗来看，会——也许有 10% 的预算要花在检查角色上。但从减少返工的角度看，这是我所有开销里最划算的一项。关键就在于这种成本不对称：做错一次，得花上一个完整周期来撤销；否决一次，只需要写一段话。

还有一点需要说清楚：否决并不是最终裁决。它会把问题上报给人类决策者。否决权真正改变的是默认规则——从“只要没人反对，行动就继续”，变成“有疑问的行动先暂停，等裁决后再继续”。对于一个行动速度很快的系统来说，这个默认规则的切换，就是整套机制的核心价值。

如果你也想借用这套模式

你不需要使用我的角色包。这套模式用四段话就能说清楚：

增加一个审查角色，不承担任何产出职责，也不向它所审查的角色汇报。

赋予它先叫停的权力，同时强制要求提交书面理由，并设定固定的仲裁时限。

把它的职责章程写成可检查的条件，而不是态度要求。

保留人类（或职责章程单独制定的仲裁者）的最终决定权，避免否决权变成针对自己团队的拒绝服务攻击。

我把完整版本打包成了一个开源项目：GitHub 上的 empire-iron-corps，包含 16 份角色职责章程，其中就包括这名风险官，以及否决条款、明确的红线清单和仲裁流程。文档采用 CC BY 4.0 许可，代码采用 MIT 许可；项目介绍页提供了安装指南。角色章程目前使用中文，英文版已列入路线图。所有角色名称都明确设定为虚构的 AI 人格。也一如既往：不作任何收入承诺——这是一套组织模式，按原样分享。

利益披露：这是我自己的开源项目，本文没有任何付费推广内容。

你的 Agent 系统是如何处理“谁有权说不”这个问题的？我确实很好奇——这似乎是整个技术栈里最少被讨论的角色。

如需进一步采取措施，可以考虑屏蔽此人和／或举报滥用行为。