共享现实驱动的 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 集群里，默认传播的东西不该是“谁去做什么”，而应该是“世界上出现了什么需要被响应的状态”。
这套东西还很早期，有很多没想清楚的地方。但方向我觉得是对的。
以上，欢迎大家讨论。
网友解答：--【壹】--：
我直接先码住再读！
--【贰】--：
关于sub-agent申请认领（claim）任务：
- 如果多个sub-agent同时来认领一个任务，又没有公允权威的置信度（xx%的确认性由某个sub-agent认领），那么就会出现错误抢占的情况？
- 认领模式，一项任务发布后，需要同时激活所有子代理，每个子代理独立判断是否与自己相关，子代理数量多了不是更加费token么？
--【叁】--：
放搞七捻三比较合适吧
--【肆】--：
谢谢分享 把哲学具体化了
--【伍】--： 神驱一梦:
发布者只需要陈述现实，不需要知道谁会响应。响应者看到事实，根据自己的能力和判断，自主决定要不要处理。没有中心在分活，工作流从事实的因果链里自然涌现出来。
看着有点像多对多的消费生产模式？用一个固定的队列处理需要处理的事件？/事实？，发布的不还是你预想的计划、命令吗
--【陆】--：
其实主agent指挥子agent才是最废token的，理想状态下，事实明确，执行高效，每个agent只需要关注自己的短小的上下文即可，相反的主agent指挥决定了主agent会有一个大而全的上下文，这个比较反直觉
--【柒】--：
逻辑是这么个逻辑，但是当前ai的能力感觉还做不到，等能做到的时候可能又会有新的问题，比如推诿。
但是慢慢研究折腾对大公司大项目还是需要的，小任务靠主线驱动够用了。
--【捌】--：
其实有点儿像jj中的change（修订）概念，在版本控制中反映的就是各个工作快照，不过那个是以代码文档为主要承载物的
这类想法在版本控制中也有相近的迭代方向，总体上从中心化到去中心化、从集中到分散、从固定到灵活
--【玖】--：
放开发调优吧
--【拾】--：
我申请一下自我管理
--【拾壹】--：
agent只需要关心自己能做的事情就行了，参考openclaw加skill其实就能做的很好，主要是要为其设立好单一职责，防止上下文中要做的事情太多，导致幻觉严重。基于这个原则让他去总线上找事情解决就可以了
--【拾贰】--：
个人感觉workflow的话灵活性太低了，模型能力更强之后不需要这些强约束
--【拾叁】--：
看到了neo已迁移帖子
--【拾肆】--：
抱歉，第一次发帖子，不知道放在这里是否合适
--【拾伍】--：
是的，基于事实与因果建立底层语义层，在未来具身智能落地的时候也是很有意义的
--【拾陆】--：
前沿快讯吗
--【拾柒】--：
图片864×522 84.2 KB
图片1556×612 36.5 KB
概念对我来说偏多。我让ai总结了一下，感谢分享！
--【拾捌】--：
是的，可以这么理解，但是推论出的事实与因果，要作为语义层沉淀到底，并不是简单的mq消息，但是mq消息可以达到这个效果。
--【拾玖】--：
之前看过一点ROS，ROS里面有这种数据流的概念，决策器会去认领数据和事件。自动驾驶和机器人里面这种实时的感知和事件流我感觉非常重要。
但对于AGENT而言，我觉得固然可以根据事件流和数据流的实时的确认，认领，并完成任务。
首先任务编排是一个非常难的一个任务，需要一个非常聪明的大脑，不然后面所有的行为都是浪费，一定要交给一个主脑。而看自然界的多智能体的情况下面，其实往往不要太聪明的大脑的，基本是感知为主，决策可能只要基于简单规则就可以。
我想到一个词叫文人相轻。聪明人一多是会打架的，组织和协调通信会有很大的问题。相应的太大规模的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 集群里，默认传播的东西不该是“谁去做什么”，而应该是“世界上出现了什么需要被响应的状态”。
这套东西还很早期，有很多没想清楚的地方。但方向我觉得是对的。
以上，欢迎大家讨论。
网友解答：--【壹】--：
我直接先码住再读！
--【贰】--：
关于sub-agent申请认领（claim）任务：
- 如果多个sub-agent同时来认领一个任务，又没有公允权威的置信度（xx%的确认性由某个sub-agent认领），那么就会出现错误抢占的情况？
- 认领模式，一项任务发布后，需要同时激活所有子代理，每个子代理独立判断是否与自己相关，子代理数量多了不是更加费token么？
--【叁】--：
放搞七捻三比较合适吧
--【肆】--：
谢谢分享 把哲学具体化了
--【伍】--： 神驱一梦:
发布者只需要陈述现实，不需要知道谁会响应。响应者看到事实，根据自己的能力和判断，自主决定要不要处理。没有中心在分活，工作流从事实的因果链里自然涌现出来。
看着有点像多对多的消费生产模式？用一个固定的队列处理需要处理的事件？/事实？，发布的不还是你预想的计划、命令吗
--【陆】--：
其实主agent指挥子agent才是最废token的，理想状态下，事实明确，执行高效，每个agent只需要关注自己的短小的上下文即可，相反的主agent指挥决定了主agent会有一个大而全的上下文，这个比较反直觉
--【柒】--：
逻辑是这么个逻辑，但是当前ai的能力感觉还做不到，等能做到的时候可能又会有新的问题，比如推诿。
但是慢慢研究折腾对大公司大项目还是需要的，小任务靠主线驱动够用了。
--【捌】--：
其实有点儿像jj中的change（修订）概念，在版本控制中反映的就是各个工作快照，不过那个是以代码文档为主要承载物的
这类想法在版本控制中也有相近的迭代方向，总体上从中心化到去中心化、从集中到分散、从固定到灵活
--【玖】--：
放开发调优吧
--【拾】--：
我申请一下自我管理
--【拾壹】--：
agent只需要关心自己能做的事情就行了，参考openclaw加skill其实就能做的很好，主要是要为其设立好单一职责，防止上下文中要做的事情太多，导致幻觉严重。基于这个原则让他去总线上找事情解决就可以了
--【拾贰】--：
个人感觉workflow的话灵活性太低了，模型能力更强之后不需要这些强约束
--【拾叁】--：
看到了neo已迁移帖子
--【拾肆】--：
抱歉，第一次发帖子，不知道放在这里是否合适
--【拾伍】--：
是的，基于事实与因果建立底层语义层，在未来具身智能落地的时候也是很有意义的
--【拾陆】--：
前沿快讯吗
--【拾柒】--：
图片864×522 84.2 KB
图片1556×612 36.5 KB
概念对我来说偏多。我让ai总结了一下，感谢分享！
--【拾捌】--：
是的，可以这么理解，但是推论出的事实与因果，要作为语义层沉淀到底，并不是简单的mq消息，但是mq消息可以达到这个效果。
--【拾玖】--：
之前看过一点ROS，ROS里面有这种数据流的概念，决策器会去认领数据和事件。自动驾驶和机器人里面这种实时的感知和事件流我感觉非常重要。
但对于AGENT而言，我觉得固然可以根据事件流和数据流的实时的确认，认领，并完成任务。
首先任务编排是一个非常难的一个任务，需要一个非常聪明的大脑，不然后面所有的行为都是浪费，一定要交给一个主脑。而看自然界的多智能体的情况下面，其实往往不要太聪明的大脑的，基本是感知为主，决策可能只要基于简单规则就可以。
我想到一个词叫文人相轻。聪明人一多是会打架的，组织和协调通信会有很大的问题。相应的太大规模的AGENT编排可能也会带来组织和协调的问题。组织规模一大，有的时候听话就变的很重要。