共享现实驱动的 Agent 协调理论，关于 multi-agent 的一些个人见解

一、哲学核心：世界是事实的总和

维特根斯坦在《逻辑哲学论》开篇写道：

世界是事实的总和，而不是事物的总和。

这句话是当前我对于 Agent 协作思考的理论种子。

在现实世界中，一张桌子是事物，桌子在房间里很碍事是事实，让人把桌子搬开是命令。

事物是世界中静态的存在，事实是关于世界状态的陈述。

任何协调系统选择以什么作为基本粒子，决定了这个系统的全部性质。

我所持有的立场是:

在 Agent 集群的协调中，一等公民应该是事实，而非命令。

因为命令传递的是意图——“你，去做这件事”。它预设接收方存在、在线、有能力、愿意服从。命令的有效性，建立在发送方对接收方状态的充分支配之上。

而事实传递的是现实——“这件事需要被做”。它不预设任何接收方，不要求服从，只是把世界的当前状态公开出来，等待有能力响应的主体自主决策。

但这并非否定命令的价值，而是想对 Agent 群体协调的原语重新选择,总结一下就是:

以共享现实事实作为默认协调原语，以命令作为系统治理。

二、事实作为一等公民的利弊

先说好处

现在主流的 Multi-Agent 方案，不管叫 workflow 、orchestrator 还是 supervisor ，都在做同一件事：有一个中心节点掌握全局状态，把任务分下去。

编排器
│
├──▶ Agent A （去做 X ）
├──▶ Agent B （去做 Y ）
└──▶ Agent C （去做 Z ）

这个模式在流程稳定、边界清楚的时候没问题。

但它有一个内置的脆弱性：命令要成立，发送方必须对接收方知道得足够多。对方在不在，能不能做，现在忙不忙，出了问题谁兜底。

Agent 数量少的时候完全没问题。一旦规模变大，成员动态加入退出，任务边界开始模糊，编排器就会越来越重，维护这些假设的代价越来越高。

更根本的问题是：命令驱动的系统，工作流必须被预先设计好。但很多真实协作场景，下一步要做什么，要等上一步的结果才能确定。你没办法提前画出所有可能性。

不过换成事实驱动之后，这个问题就不存在了。

发布者只需要陈述现实，不需要知道谁会响应。响应者看到事实，根据自己的能力和判断，自主决定要不要处理。没有中心在分活，工作流从事实的因果链里自然涌现出来。

新的 Agent 加入，只需要声明自己关心什么类型的事实，不需要修改任何现有配置。Agent 宕机了，总线上的事实还在，其他有能力的 Agent 可以接手。

这恰恰是命令驱动做不到的。

接下来是弊端:

设想很美好，现实很骨感。

第一个弊端是:事实驱动把复杂度从连接拓扑转移到了语义治理

命令驱动系统，复杂度集中在谁能命令谁、接口怎么定义、状态怎么同步。这些复杂度分散在每个 Agent 对之间，难以集中管理。

事实驱动系统，复杂度集中在事实类型怎么定义、命名怎么统一、schema 怎么治理。这些复杂度可以集中管理。

但它是真实存在的——你需要一套事实类型注册表，需要命名规范，需要有人维护 schema 的演化。

简单说：复杂度没有消失，只是搬到了更可治理的层。

第二个弊端是:事实驱动不适合所有场景

强事务、强时序、责任必须明确到人的流程，传统 workflow 更直接、更可审计。所以两套东西应该共存，不是谁取代谁。

三、有趣的是，蚂蚁其实早就解决了这些事
在人类开始思考 Multi-Agent 协调之前，自然界在几亿年年就已经有了答案。

一个蚁群可以有几百万成员，协调完成觅食、筑巢、防御这些极其复杂的任务。但没有一只蚂蚁是指挥官，没有任何一只蚂蚁掌握全局状态，没有命令链。

它们用的是信息素。

一只蚂蚁发现食物，不去找另一只说"你去搬"。它在路上留下信息素——关于食物在哪、路径质量如何、危险在哪里的陈述。其他蚂蚁感知到，自主决定要不要响应。

这个自然机制与我思考的事实驱动协议的对应关系，我觉得不是简简单单的类比，几乎就是同一件事：

信息素会衰减: 事实有 TTL ，过期自动失效，系统自动清理过时信息

信息素可叠加: 多个独立来源确认同一事实，可信度提升。注意是独立来源——几个共享同一上游错误的 Agent 互相确认，不比一个 Agent 更可信。真正的可信度来自来源多样性

信息素形成路径: 处理结果发布为新事实，引用父事实，因果树自然涌现。工作流是被设计出来的，因果链是长出来的

信息素有种类: 事实有语义分类：观测、需求、判断、结果、修正。Agent 声明自己只响应哪类，总线做内容路由

信息素是蚂蚁的事实总线。蚁群协调不靠命令，靠共享对世界状态的陈述。

但有一类问题信息素解决不了。

蚂蚁没法强制停止另一只蚂蚁，没法重新分配一个已经被认领的任务。

工程系统里这类操作是必要的：强制停止失控的 Agent ，重新分配认领，管理员覆盖状态。这些需要原子性保证，最终一致性撑不住。

所以一个完整的系统可能需要两个平面：

1 、数据平面—— 事实流转，处理绝大多数协调场景。发布事实、过滤、响应、涌现。

2 、控制平面—— 命令操作，处理治理和仲裁的例外情况。独占认领、强制干预、系统管理。

命令不是不能存在，是应该被限制在它合适的地方。

另外我认为控制平面的存在不是简单的哲学妥协，是落地的工程成熟。

四、想法来源
我之前做过车身控制开发，接触过 CAN Bus 。CAN 总线的特性就是：它是广播的，每个节点发出的帧所有节点都能看到，但每个节点自己决定要不要处理这条消息。没有主节点在分配，没有人告诉你该做什么，节点根据消息 ID 和自己的过滤器判断。

在遇到多 Agent 协作的场景后，我第一时间就想到了这个东西，同时也有一个疑问：多 Agent 系统为什么一定要有一个编排器来分活？ CAN 总线上的 ECU 就不需要。

思考过程中也参考了上世纪的经典黑板架构，简单来说就是假设房间有一块黑板，房间里的大家协作的时候不互相呼来喝去，只是在黑板登记内容，有能力的直接去做，带入很多小说的悬赏榜也类似，有兴趣的可以搜一下看看这个架构思想，不过传统的黑板架构中还是存在调度器的，这一点需要辩证看待。

五、事实如何在 Agent 中流转
参考 CAN BUS 的思想，一条事实发布到总线，总线根据每个 Agent 声明的过滤器做内容匹配，把事实推给匹配的 Agent 。

Agent 收到之后自己判断：这是我能处理的吗？我现在要处理吗？

如果是独占模式的事实，Agent 可以发起认领（ Claim ），总线保证原子性，最多一个 Agent 拿到处理权。处理完之后，Agent 发布结果——一条新的事实，引用原来那条事实的 ID 作为父节点。

这样基于事实的因果链就建立起来了。

需求事实（ root ）
└── 设计完成事实（ depth: 1 ，parent: 需求）
└── 代码提交事实（ depth: 2 ，parent: 设计）
└── 测试通过事实（ depth: 3 ，parent: 代码）
└── 部署成功事实（ depth: 4 ，parent: 测试）
没有人预先设计这棵树。它从 Agent 的响应行为里长出来的。

而这也是我想要的: 工作流是被设计出来的，因果链是长出来的。

这棵树还可以分叉。同一条事实，可以同时触发多个下游 Agent 的响应，每条支线独立推进，互不干扰。这在命令驱动系统里要预先设计分支逻辑，在事实驱动里是自然发生的。

事实不只是数据，它有认识论状态

这是和消息队列最大的区别。

Kafka 不知道一条消息是不是可信的。它只管传，不管内容对不对。

但 AI Agent 的输出本质上不可靠。一个 Agent 发布的事实可能是错的，可能是基于错误信息推断出来的，可能有幻觉。

所以事实需要一个信任生命周期：

asserted → 有人发布了，但还没被验证
corroborated → 有独立来源确认了
consensus → 多个独立来源都确认了
contested → 有人提出了异议
refuted → 被多个独立来源反驳了

注意这里的"独立"。

几个用同一个模型、同一套数据、同一个 prompt 模板的 Agent 互相确认，不比一个 Agent 更可信。这只是回声。真正的可信度来自来源多样性——不同工具、不同推理路径，得出了相同的结论，这才算佐证。

这个状态和工作流状态是独立的两个维度。一条事实可以是处理完了（ resolved ）但后来被证伪（ refuted ）。这不是矛盾，是真实世界的常态。把这两个维度分开，才能描述这种情况。

所以我觉得，在开放、动态、能力异构的 Agent 集群里，默认传播的东西不该是“谁去做什么”，而应该是“世界上出现了什么需要被响应的状态”。

这套东西还很早期，有很多没想清楚的地方。但方向我觉得是对的。

以上，欢迎大家讨论。