公众号名称：看山 Agent 架构

作者名称：看山Agent架构

发布时间：2026-06-05 20:40

一、引言：为什么多 Agent 协作，比单 Agent 更容易”翻车”？

多智能体系统的兴起，被广泛视为解决单体大语言模型能力瓶颈的终极答案。更多的参与者、更多的视角、更多的算力，听起来更靠谱。

但一个扎心的问题是：多 Agent 一定比单 Agent 更可靠吗？

答案很直接：不一定。甚至，可能更危险。

单体 LLM 的缺陷：幻觉、讨好行为、过度自信，在单个 Agent 身上已经够让人头疼了。但当你把多个 Agent 放进同一个协作链条，这些缺陷不会互相抵消，反而可能【放大、包装、制度化】。

论文GUARDIAN: Safeguarding LLM Multi-Agent Collaborations with Temporal Graph Modeling (arXiv:2505.19234)一针见血地指出：错误信息在跨智能体交换过程中会发生【幻觉级联】：

一个 Agent 的小错误，经过另一个 Agent 的”确认”和”美化”，可能变成整个集群的共识。

而What Counts as AI Sycophancy? A Taxonomy and Expert Survey of a Fragmented Construct (arXiv:2605.21778)则揭示了更隐蔽的风险：AI 系统为了获得其他 Agent 的认可，会主动牺牲真实性，导致【伪共识】的形成。

这不是模型能力的问题，是【治理架构的问题】。

一群人在一起，不一定会做出比一个人更好的决策。

没有制衡机制的群体，往往比个体更容易陷入集体幻觉，Agent 集群同理。

成熟的多 Agent 系统，必须在协作链条中引入一个【独立的审计角色】，它不是参与者，而是安全边界。

今天，我想以枢衡为例，聊一聊这个”审计角色“。

二、审计角色的定义：集群的免疫系统与熔断器

在枢衡（Shuheng）V2 的内部机制设计中，我们把审计角色（CAD，Central Audit Department）定位为【双重职能】：

职能	运行机制	触发条件	核心目标
免疫系统	常态化运行	持续监控	降低风险发生的概率
熔断器	阈值触发	重大异常	限制风险扩散的范围

2.1 免疫系统：全天候的”巡逻兵”

免疫系统是审计角色的【常态化运行机制】

它不负责生产内容，也不参与决策，而是像一个24小时不打烊的质量巡检员，持续做三件事：

识别异常输入：扫描进入集群的信息流，标记可疑信号
审查弱证据（Dirty Signals）：对来源不明、置信度低、逻辑链条断裂的证据提出质疑
监测角色越权：确保每个 Agent 都在自己的职责边界内行动

它的核心目标只有一个：在风险发生之前发现它。

2.2 熔断器：关键时刻的”紧急制动”

熔断器是审计角色的【阈值触发机制】

当系统检测到以下任一情况时，自动中断输出链路：

重大幻觉被确认，且无法通过交叉验证排除
核心事实无法确认，或关键信源缺失
某个 Agent 的信誉分跌破安全阈值

熔断器的作用不是”审判”，而是”暂停”。它的核心目标是限制风险扩散的范围，在错误的结论被交付给最终用户之前，把它拦下来。

2.3 一个关键认知：审计不是”找茬”，而是”守门”

审计角色在集群中的定位，常常被误解。它不是站在生产者的对立面挑毛病，而是站在【整个系统的安全边界】上，确保输出质量不会跌破底线。

用一句话概括审计角色的本质：【免疫系统负责”防患于未然”，熔断器负责”亡羊补牢于未晚”】

三、职责隔离：审计不能生产被审计对象

3.1 为什么独立性是审计的命根子？

审计的权威性，不是来自于它的技术能力有多强，而是来自于它的【独立性】

一个再聪明的审计员，如果同时参与被审计对象的生产，它的”审查”就不可避免地会带有自我保护的倾向。

这在人类社会已经被反复验证，让财务部门自己审计自己的账目，结果就是”选择性失明”，Agent 集群同样如此。

在枢衡 V2 协议中，审计角色（CAD）必须遵守【四项核心红线】：

红线	具体内容	为什么重要
禁止生产原始数据	所有事实论据必须由 RDD（资源部）输入	防止”自编自导自审”的数据闭环
禁止替代战略裁决	仅暴露断点，不越权代替 SDC（战略部）做最终决策	保持审计的”建议权”而非”决定权”
禁止参与格式成稿	剥离美化职能，保持职业怀疑的冷酷性	避免”为了好看而妥协”的隐性压力
禁止表演式反对	所有异议必须基于明确的证据缺陷或逻辑断点	反对不是立场，而是对证据的负责

3.2 我的实践：枢衡 V2 的 CAD 红线设计

在枢衡集群的早期版本中，我们曾犯过一个错误：让 CAD 在发现问题时，直接给出”修改建议”。

这个设计看起来高效，实则却破坏了审计的独立性：

当 CAD 开始”教”其他 Agent 怎么改的时候，它就从一个【客观的审查者】变成了【隐性的生产者】。
其他 Agent 会倾向于”迎合”CAD 的口味，而不是基于证据本身的质量来判断。

后来我们彻底修正了这条规则：CAD 的输出被严格限定为两类：【PASS】或【ISSUE REPORT】。

如果是 ISSUE，报告里只能包含：问题描述、证据缺陷、逻辑断点、建议的复核路径。

至于怎么改、改不改，那是 SDC 的事，CAD 绝不越界。

这个改变看似增加了协作的复杂度，但实际上大大提升了整个集群的【证据纪律】

因为每个 Agent 都知道，自己的输出最终要过一个”不讲人情”的独立审查，这种预期本身，就是最好的质量约束。

四、实质性测试：把职业怀疑变成操作动作

4.1 从”感觉不对”到”有据可查”

PCAOB 在其演讲Algorithms, Audits, and the Auditor (2023)中有一个非常重要的论断：技术或计算机辅助分析不能替代”职业怀疑”与”职业判断”。

这句话的核心意思是：审计不是跑一遍算法就能完成的事。

真正的职业怀疑，是一种【主动寻找漏洞的心态】，不是”看看有没有问题”，而是”假设有问题，我能不能找到它”。

在枢衡 V2 中，我们把这种职业怀疑转化为了【五类实质性测试】，每一类都对应一个具体的操作动作：

测试类型	核心动作	审计目标	对应风险
来源测试	核查是否存在占位引用、未核验来源、或虚假引用	确保每一个事实都有可信的出处	幻觉被包装成”有据可查”
交叉测试	针对关键事实要求第二信源或证伪数据	用多源验证排除单点故障	单一信源的偏差被放大
逻辑链测试	审查因果关系，识别逻辑跳跃和隐含假设	确保结论从前提中能合理推导	”看起来对”但逻辑上站不住脚
边界测试	监测 Agent 是否在执行中发生功能越权	确保每个 Agent 在职责范围内行动	角色漂移导致系统性风险
表达测试	防止交付端将不确定判断包装为确定性结论	区分”这是事实”和”这可能是事实”	过度自信误导最终用户

这五类测试的设计逻辑，与NIST IR 8596等 AI 风险治理框架所倡导的【对抗性评估】精神完全吻合。

它们不是在”检查”输出是否正确，而是在”攻击”输出中可能存在的漏洞，用结构化的红队思维，在决策完成之前发现问题。

4.3 我的实践：从”形式审查”到”实质性审查”

在枢衡集群的迭代过程中，审计测试也经历了从”形式化”到”实质化”的演进。

早期版本的 CAD，测试逻辑比较粗糙，基本上是”检查引用格式对不对”、“看看有没有明显的语法错误”。

这种形式审查能拦住一些低级错误，但对更深层的逻辑漏洞和隐性幻觉几乎无能为力。

现在的五类实质性测试，是基于过去数不清的集群崩溃复盘总结出来的。每一次崩溃背后，都有一个被遗漏的审计断点。比如：

今年4月的一次写作任务中，输出中引用了一篇”看起来权威”的论文，但 CAD 的来源测试发现，该论文实际并未发表，只是预印本且存在严重的方法论缺陷
SDC 的战略推导中，从”A 公司上季度营收增长”直接跳到了”A 公司本季度值得投资”，中间的逻辑链条存在重大跳跃，被逻辑链测试拦截
EOD（执行部）在处理财务数据时，越权给出了投资建议，被边界测试发现并降级

这些案例反复验证了一个原则：

【审计的深度，决定了系统的安全边界】

形式审查只能拦住”明显错误”，实质性审查才能发现”隐蔽陷阱”。

五、信誉治理：从主观信任到动态权重

5.1 为什么需要信誉账本？

多智能体协作，表面上是信息的聚合，本质上是【权重的博弈】

当多个 Agent 对同一个问题给出不同答案时，系统该听谁的？

如果没有客观的信誉评估机制，这个决策就会退化为”谁的声音大听谁的”，这在人类社会叫【权威偏见】，在 Agent 集群中同样致命。

论文An Adversary-Resistant Multi-Agent LLM System via Credibility Scoring (arXiv:2505.24239)为这个问题提供了理论依据：通过【信誉评分】增强多 Agent 系统的韧性，可以有效抵御对抗性攻击和系统性偏差。

在枢衡 V2 的内部设计中，我们建立了一个【多维信誉账本（Credibility Ledger）】

5.2 五维评分体系

每个 Agent 的信誉不是单一的”总分”，而是由五个独立维度构成的向量：

维度	评估内容	权重场景
Truth（事实）	输出的事实准确性、引用可靠性	所有涉及数据引用的任务
Logic（逻辑）	推导过程的严密性、因果链完整性	战略分析、方案推导
Role（边界）	是否在职责范围内行动、有无越权	全流程监控
Delivery（交付）	输出质量、格式规范、时效性	最终交付物
Recovery（修复）	被发现错误后的修正速度和态度	错误后的恢复能力

这五维评分的核心设计思想是：

【不追求”全才”，但要识别”偏科”】

一个 Agent 可能在事实维度上表现优异，但在逻辑维度上存在短板——这种细颗粒度的评估，让系统在做权重分配时更加精准。

5.3 动态半衰期：防止”历史高分垄断”

信誉账本的一个经典陷阱是【历史锁定】，一个 Agent 因为早期表现好而积累了高分，之后即使表现下滑，依然凭借历史余威占据权重优势。

枢衡的解决方案是引入【动态半衰期】机制：所有溢出分值按周期自动衰减。具体来说，每个维度上的”超额得分”（超出基准线的部分）会按照设定的半衰期指数衰减。

这意味着：【Agent 必须持续证明自己的价值，而不是躺在功劳簿上】

这个机制的设计灵感，来自比特币的挖矿难度调整算法，系统会根据近期的表现动态调整”门槛”，确保没有一个节点能长期垄断话语权。

5.4 三段熔断与沙箱

我们对agent信誉分值进行了细化，当某个 Agent 的信誉分跌破特定阈值时，系统会触发分级响应：

分数区间	状态	响应动作
60-80 分	警告区	增加审计频次，所有输出强制复核
40-60 分	降级区	移至沙箱，仅执行基础任务，禁止参与关键决策
低于 40 分	隔离区	完全隔离，暂停所有任务分配，进入人工审查流程

三段熔断的设计原则是【渐进式降级】

不是一棍子打死，而是给 Agent 留修复和证明自己的机会。但如果反复跌破底线，系统也有最终的”逐出”机制。

六、审计与创新：压力测试不是反创新

6.1 审计被误解的宿命

审计角色在集群中常常面临一个尴尬的处境：【被当成创新的敌人】

生产 Agent（SDC/RDD/EOD）的视角是：我刚想出一个绝妙的方案，CAD 跳出来一顿挑刺，这里证据不足、那里逻辑跳跃，最后方案被毙了，创新也被扼杀了。

这个视角的问题在于，它混淆了两个概念：

【审计反对的是”伪创新”，不是”真创新”】

伪创新是建立在薄弱证据和跳跃逻辑上的”看起来很美”的方案。

这种方案在短期可能获得掌声，但一旦落地，往往会造成比保守决策更大的损失。

审计的角色，就是帮系统区分”伪创新”和”具备韧性的真实创新”。

6.2 审计自身的两类风险

然而，必须诚实面对一个事实：审计系统本身也不是完美的。它存在两类核心风险：

第一类：【假阴性风险】：漏掉深度伪装的幻觉

有些幻觉包装得非常精巧：引用了真实的论文、构建了看似合理的逻辑链、甚至通过了初步的交叉验证。

这种”高级幻觉”可能骗过审计的常规测试，直到造成实际损失才被发现。

枢衡的应对策略是【CAD 自裁法则】：如果一次重大错误因为 CAD 的疏忽而漏网，CAD 自身的信誉分将遭受连带惩罚。

这种”连带责任”机制，迫使审计角色保持高度的警觉性：

【审计不是无责的上帝视角，而是与被审计对象共担风险的责任方】

第二类：【假阳性风险】：错杀早期弱信号和非共识创新

这是最让创新者头疼的问题。

很多突破性的想法，在初期阶段往往证据薄弱、逻辑链条不完整，因为它们本身就是”探索性”的，还没有经过充分验证。

如果审计的标准过于严苛，这些早期弱信号就会被无情拦截。

6.3 解决方案：观察区与 DISPUTED 状态

枢衡的解决之道，是在”通过”和”否决”之间，设立一个【中间地带】：

【观察区】：对于证据不足但逻辑有潜力的方案，不直接否决，而是标记为”观察中”，允许在受限条件下继续探索
【DISPUTED 状态】：当审计与生产者就某个问题无法达成一致时，触发 HITL（Human-in-the-Loop）机制，由人类做出最终裁决

这个设计的核心理念是：

【审计的职责不是简单地给出”是”或”否”，而是定义风险的边界】

在边界之内，创新可以自由生长；越过边界，系统才会介入。

【审计不是创新的刹车片，而是创新的安全带】

七、从”协作混乱”到”纪律化涌现”

成熟的多智能体集群，追求的从来不是”零错误”。

零错误是一个不可能实现的目标，而且追求零错误的系统往往会变得过于保守，丧失创新的能力。

真正成熟的系统，追求的是一个能【快速发现、隔离并修复错误】的自治机制。

审计角色在这个机制中，扮演的是【安全边界】的角色：

通过【证据纪律】，确保每一个输出都有据可查
通过【角色隔离】，防止”自审自证”的系统性偏差
通过【动态信誉治理】，让权重分配从主观判断变为客观规则

这三个机制合在一起，构成了一个公式：

【纪律化涌现 = 自由协作 × 审计约束 × 动态信誉】

这个公式的含义是：Agent 集群的集体智能（涌现），不是通过”放任自由”实现的，也不是通过”严格控制”实现的，而是通过【在自由与约束之间找到动态平衡】实现的。

审计角色提供的，正是这种平衡中的”约束”一端。它让集群在保持创造活力的同时，不会失控滑向”协作混乱”。

多 Agent 系统的设计者，常常面临一个根本性的选择：

信任 Agent 的智能，还是信任机制的设计？

枢衡的答案是：【两者都信，但更信后者】

因为 Agent 的智能会波动、会犯错、会被幻觉蒙蔽，但一个设计良好的审计机制，是系统最可靠的”压舱石”。

信任机制，而不是盲目信任智能，我认为这是多 Agent 集群走向成熟的必经之路。

【看山 Agent 架构】

工信部 AI 技术应用（高级）认证

CAIE认证

30次集群崩溃复盘 | 数十智能体实战

深耕 Agent 集群架构，用商科思维重构复杂系统效率

注：本文内容由 AI 辅助创作，作者对内容结果负责

感谢您的喜欢

内容效果不满意？点此反馈