多 Agent 如何可靠协作：从 CAP、Raft 到拜占庭故障

当团队里出现多个“真相”

把同一个任务交给三个 Agent，通常不会自然得到一支配合默契的团队。
更常见的情况是：它们各自掌握一部分上下文，各自维护一份状态，还可能在不同时间得出互相冲突的结论。

单个 Agent 犯错，我们会追问模型能力、提示词或工具调用。
多个 Agent 协作失灵，还要多问一层：信息有没有送达，大家看到的是不是同一版状态，某个成员的话又凭什么可信？

分布式系统几十年来一直在处理类似的麻烦。
CAP、Raft 和拜占庭容错因此常被拿来解释多 Agent 协作。
这组类比很有启发，但三个概念分别处理不同层次的问题，混在一起反而容易误判：

可以把它们记成三句话：联系不上，看 CAP；意见要落成一个决定，看共识；连发言者都不能完全相信，看拜占庭故障。

图中的三层是递进关系。
通信恢复只能解决消息能否到达；状态达成一致之后，系统仍要继续判断参与者和证据是否可信。

从一次发布说起

假设三个 Agent 合作发布一个新版本。

• Agent A 核对需求与改动范围
• Agent B 运行测试并检查构建产物
• Agent C 汇总结论，在条件满足后执行发布

理想流程很简单：A 和 B 完成检查，C 收到证据，版本发布。
但只要协作跨越多个执行单元，问题就会一层层出现。

第一层是通信问题。
A 已经完成检查，消息却没有传到 C；C 无法判断 A 是尚未完成、已经宕机，还是单纯网络延迟。

第二层是状态问题。
A 检查的是提交 v2，B 跑测试时拿到的却是 v1，两份“通过”放在一起也不能证明 v2 可以发布。

第三层是信任问题。
B 可能被恶意网页中的提示注入影响，没有真正运行测试，却向 C 返回“全部通过”。
这时通信完全正常，团队也达成了共识，结论仍然可能是错的。

这三个失败场景表面上都叫“协作不顺”，根因却分别是消息不可达、状态不一致和参与者不可信。
CAP、Raft 与拜占庭容错的价值，正在于把这三层问题拆开。

CAP：失联之后，停下来还是继续走

CAP 中的三个字母分别是 Consistency、Availability 和 Partition tolerance。

• 一致性（Consistency）：一次成功写入之后，后续读取不会再看到更旧、互相冲突的权威状态
• 可用性（Availability）：每个到达正常节点的请求都能在有限时间内得到响应，不会因其他节点失联而一直挂起或直接拒绝
• 分区容错（Partition tolerance）：节点之间出现丢包、断网或长时间延迟时，系统仍有明确的处理方式

CAP 经常被压缩成“C、A、P 三选二”，这个说法太容易让人误会。
选择发生在网络分区已经出现、节点无法确认彼此状态的时候。
此时系统无法同时保证强一致和持续可用，只能决定哪一边优先。

回到发布场景。
如果 C 联系不上 A，它有两种基本选择。

一种选择是暂停发布，直到重新取得 A 的确认。
团队损失了可用性，却守住了“未经完整检查不得发布”这一条一致规则，这更接近 CP 的取向。

另一种选择是让 C 根据已有信息继续发布，待连接恢复后再补齐记录。
流程没有停，但不同成员可能暂时对“这个版本是否已经获批”持有不同答案，这更接近 AP 的取向。

这里没有脱离业务的最优解。
资料搜集、候选方案生成通常可以容忍暂时分叉；支付、删除、正式发布则往往宁可等待，也不能制造两个都声称有效的结果。
合适的一致性强度，取决于动作是否可逆以及出错成本有多高。

Git、CRDT 与 Raft：三种不同的协作思路

Git、CRDT 和 Raft 常被放在一起讨论，因为它们都处理“多个副本”的问题。
三者对冲突的态度并不相同。

Git：先允许分叉，再由人解决语义冲突

两名开发者断网后都可以继续提交。
网络恢复时，Git 能找到历史分叉的位置，也能合并互不冲突的文本改动，但它不知道两个修改在业务上能否同时成立。

所以，把 Git 类比为 AP，只是在强调“离线也能继续工作”，并非对 Git 进行严格的 CAP 分类。
Git 提供了保存分歧和重新汇合的机制，最后的语义裁决仍由人或更高层系统完成。

CRDT：提前限制操作，使副本可以自动收敛

CRDT 是一类为自动收敛而专门设计的数据结构，能力范围受数据模型约束。
它通过让并发操作满足交换、结合或幂等等性质，使不同副本即使以不同顺序收到更新，最终也能收敛到同一个结果。

例如，甲离线时向共享集合加入 A，乙同时加入 B。
如果这个集合采用合适的 CRDT，重连后双方都能得到 {A, B}，不需要判断谁覆盖谁。

代价也很明确：业务状态必须能被表达为这种可合并的数据结构。
“是否批准发布”包含责任、时序和约束，不能简单套用集合并集；自动收敛解决的是数据冲突，不等于解决了业务决策。

Raft：用多数派确定唯一的提交顺序

Raft 处理的是另一类需求：系统不能接受多个并存的权威历史，必须让节点对日志顺序达成一致。

它通常会选出一个 Leader，由 Leader 接收变更并复制给其他节点。
以五节点集群为例，一条日志至少得到三个节点确认，才可能被视为已提交。
网络分区后，拥有多数节点的一侧可以继续推进；少数派无法独立确认新的权威状态。

多数派的意义不只是“票多者胜”。
任意两个多数派必然至少共享一个节点，这种重叠让已经提交的历史不容易被另一套历史取代。
Raft 用分区期间的部分不可用，换取了单一、连续的权威日志。

放到 Agent 团队里，Raft 提供的是一种组织协作的思路：明确协调者、记录决策顺序、规定提交门槛，并让少数失联成员无法单独改变最终状态。
这种机制针对日志复制与提交顺序，既不等同于汇总几个 Agent 的自然语言投票，也不会判断投票依据是否真实。

Raft 的边界：多数派可能整齐地做错事

标准 Raft 解决的是崩溃故障容错（Crash Fault Tolerance，CFT）。
它假设节点可能宕机、重启、延迟或失联，但节点一旦发送消息，就会遵守协议，不会伪造日志，也不会故意对不同成员讲不同版本的故事。

拜占庭故障放宽了这条假设。
一个故障节点不仅可以沉默，还可以任意行动：

• 对 A 声称“发布已经获得批准”，对 C 又声称“仍在等待确认”
• 把没有执行过的测试包装成通过结果
• 选择性隐瞒失败日志，只转发有利片段
• 冒用其他成员身份，伪造一条看似完整的证据链

经典的拜占庭将军问题之所以困难，正是因为正常参与者无法仅凭收到消息，就判断消息是事实、误传还是蓄意欺骗。

Agent 的幻觉未必带有恶意，提示注入也未必意味着模型本身“叛变”。
但从接收方看，两者都可能产生不受协议约束的任意输出。
因此在安全设计上，把这类输出当作拜占庭式故障处理，比猜测 Agent 的主观意图更有用。

经典 BFT 模型中，容忍 f 个拜占庭节点通常至少需要 3f + 1 个节点。
这个数字依赖网络同步性、身份认证方式和具体协议，不能直接当作 Agent 产品的节点配置公式。
对 Agent 产品更重要的提醒是：只增加节点数量，并不会自动增加可信度。

为什么“三个 Agent 都同意”仍然不够

多数机制能够抵御独立故障，前提是各个判断真的足够独立。
现实中的 Agent 团队往往共享同一个基础模型、系统提示、检索源和工具链，这会制造高度相关的错误。

如果三个 Agent 都从同一篇错误文章取证，三票赞成仍然只有一个信息源。
如果三个 Agent 都会被同一种提示注入攻击，增加副本只是在复制同一处薄弱点。
如果所谓“复核 Agent”只阅读执行 Agent 的摘要，它最多能检查措辞是否自洽，无法确认任务是否真的完成。

因此，多 Agent 系统里的“独立验证”至少应拆成三个维度：

• 来源独立：关键事实由不同的原始来源互相印证，避免多次转述同一材料
• 方法独立：结论由不同机制验证，例如静态检查、自动测试和运行时观测互相补充
• 权限独立：提出操作、批准操作和执行操作不由同一个身份包办

有价值的冗余会刻意增加验证路径的差异，让同一个错误难以同时穿透所有检查。

工程上先守住证据门禁

大多数 Agent 产品并不需要直接实现 PBFT 一类完整的拜占庭共识协议。
它们通常运行在中心化编排器上，成员数量有限，关键状态也可以落在可信数据库中。
此时更有效的做法，是把分布式系统的原则翻译成具体的产品约束。

这条链路中最关键的断点，位于“Agent 自述”和“可验证事实”之间。
只要发布门禁读取的是原始证据，单个 Agent 的错误就不容易直接变成外部副作用。

什么时候该用这套视角

“多 Agent”这个名称本身，并不足以构成分布式系统问题。
如果几个 Agent 由同一个进程顺序调用，共享一份数据库，也没有独立权限，首要矛盾通常是任务拆分、上下文传递和验收标准。

当系统出现以下特征时，分布式系统的视角才开始变得关键：

• 成员拥有独立、可持续的本地状态
• 通信可能延迟、丢失、重复或乱序
• 多个成员可以并发修改同一业务事实
• 部分成员失联后，其他成员仍被允许继续工作
• 输入、工具或参与者不能被完全信任

这组判断也给出了一个实用顺序。
先问通信中断后是否允许继续，再问哪个状态需要唯一权威，最后问参与者和证据是否可信。
只有前一层的边界说清楚，后一层的机制才不会沦为术语堆砌。

结语：共识保证一致，不保证正确

CAP 告诉我们，通信分区会迫使系统在一致性和可用性之间做选择。
Raft 告诉我们，一群遵守协议的节点可以通过 Leader、日志和多数派形成唯一的决定。
拜占庭问题则提醒我们：如果参与者可能任意出错，形式上的一致仍然可能建立在假消息之上。

对多 Agent 系统来说，可靠协作来自清晰的状态边界和证据链。
哪些状态可以分叉、哪些动作必须串行，哪些结论可以讨论、哪些事实必须拿证据说话，都要在系统里得到明确表达。

共识解决的是“大家最终认哪一个结果”。
可信系统还必须回答另一件事：这个结果为什么值得相信。