一、哲学核心：世界是事实的总和
维特根斯坦在《逻辑哲学论》开篇写道：
世界是事实的总和，而不是事物的总和。
这句话是当前我对于 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 集群里，默认传播的东西不该是“谁去做什么”，而应该是“世界上出现了什么需要被响应的状态”。
这套东西还很早期，有很多没想清楚的地方。但方向我觉得是对的。
以上，欢迎大家讨论。
维特根斯坦在《逻辑哲学论》开篇写道：
世界是事实的总和，而不是事物的总和。
这句话是当前我对于 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 集群里，默认传播的东西不该是“谁去做什么”，而应该是“世界上出现了什么需要被响应的状态”。
这套东西还很早期，有很多没想清楚的地方。但方向我觉得是对的。
以上，欢迎大家讨论。
 |
1
sillydaddy 1 天前
给 Agent 加上一个人格，再配上选举，齐活了。
不过，谁来决定给谁安排什么人格呢？是否要 Agent 之间通过竞争，看谁解决问题的能力强？但是为何解决问题能力强的，就可以被赋予某个人格（比如领导者）呢？还是需要一组底层的逻辑。 |
 |
2
tftNExtLife OP @sillydaddy 那倒不用，同一事实的多个 agent 靠争抢与排它锁就行，主要是按照事实过滤而不是看 agent 谁强谁弱
|
 |
3
charlie21 1 天前 via Android
蚂蚁对蚁群负责 所以蚂蚁有良性自主意识
agent 的注意力是怎样的都是黑箱，agent 哪里比得过蚂蚁？ |
|
4
tftNExtLife OP |
 |
5
maolon 1 天前  1
我觉得不是很妥，
1. 怎么算是事实？ 观察，推断，需求，结果这些被塞在一起，agent 本身就很容易判断出错，一旦树的上层出现错误就会级联影响下层的结果 2. 虽然 agent 的编排基于事实自然生长看上去更优雅，但是没有解决复杂度的问题，只是把复杂度从谁命令谁变成了谁来定义事实，谁来做冲突解决，谁来撤回和重跑 3. llm 现在本身也不是为“事实治理”训练出来的，而是任务驱动的，基于事实治理的任务成功率存疑 4. 多 agent 至少目前不是版本答案，在很多问题 domain 里单 agent 系统（ SAS ） ，效果并不差甚至是最优的选择，多 agent 一般在任务可拆解（上下文容易隔离），可探索，低耦合的任务上占优，所以也不是说什么任务都需要一个事实总线 5. 最后收敛条件是什么，谁来决定收敛（这也就是为什么 planner- excuter 被这么广泛的被使用的原因），没有这个系统会无限扩展下去 |
 |
6
extrem 1 天前 1
从第一性原理出发分析，我越来越感觉像管理人一样去管理 agent 是很不科学的，或者说 agent 本来就不存在，谈何管理？谈何协作？
现在 agent 应用本质上只是把上下文组装好发给 lm api ，可能在程序逻辑设计上需要“agent”这种抽象来辅助编码以及在日常便于讨论，但不代表任何场合任何时候都要将它作为第一优先级考虑的实体，否则就是本末倒置，容易陷入歧途 用类比的方式思考 agent 协作根本没意义，因为 agent 最核心部件：lm 接口能否按预期工作根本不取决于这些看似精巧的无关设计 |
|
7
tftNExtLife OP @extrem 不是这样的，llm 可以当做函数被调用，被组装，agent 需要升维看待了，当前 agent 已经到了要建立语义层的地步
|
|
8
tftNExtLife OP @maolon
 昨天基于事实协议做的一个五六十 agent 的居民小镇 |
 |
9
coefu 21 小时 16 分钟前
|
|
10
tftNExtLife OP @coefu 额 你这个文章不是在说怎么让单个 agent 做更好的事么，其实 Harness 补偿的是模型执行力的不足，但工作流本身的结构依然是中心化设计出来的。如果是流程边界清晰、责任链确定的任务，Harness 的结构化设计是合理的。如果涉及任务边界模糊、Agent 动态加入退出、下一步依赖上一步结果的场景，我的这个涌现逻辑更合适
 另外我也不是想当然的 yy ，我是实打实的在做落地 |
|
11
tftNExtLife OP @coefu 还有就是你发的文章内几百 Agent 集体摸鱼的案例，恰恰能说明命令驱动编排器在规模化时会集体崩塌，最后只能用状态机强行隔离。我的方案是从协调原语上就避免这个问题，而不是等崩了再打补丁
|
|
12
tftNExtLife OP 现有的 Multi-Agent 系统，本质上还是在用分布式的壳包一个中心化的大脑。🥱
|
|
13
coefu 19 小时 52 分钟前
@tftNExtLife #10 要是你这个真落实到实际生活中了，才可怕。以后你接了哪些项目，先发上来，让哥们儿知晓一下。
那篇文章太长了，我认为你肯定没有仔细完整的看完过。中心思想是 壳是过渡状态，LLM 本身能力的提升 会让 harness 这个壳 一直变化，一直迭代堵 LLM 的能力短板。至于 多 agent ，就和社会化治理一样多样化，甚至很难决出个第一。所以，你说你的 多 agent 方案，怎么样怎么样，讲句实话，就和 腾讯和阿里他们讲公司治理一样。这不是什么技术层面的事情。 什么是“涌现”，你先搞清楚了，再用这个词。 |
|
14
tftNExtLife OP @coefu #13
我这里的涌现指的是让 agent 可以主动的去承接任务，从而让工作流不必定义，由能够干对应活的 agent 一直动起来去处理自己关心的事情，文章内的 harness 与我做的事情并不冲突，单个 agent 越强大，在总线上的处理的事情就越好，其他 agent 发布的事实也能更好的协作，这两件事本质上并不冲突。 文章内提到的多 agent 遇到的困难，按照一元论来说必然是走 workflow 才是最优解，因为他们是要解决一个特定任务的最优执行路径。但是我是在探究一个持续运转的 Agent 集群，怎么在没有人预先设计工作流的情况下，让活儿自己被认领、被做完。 附上我本地跑的 MVP 系统，我发出一个需求事实（做一个简单的 CRUD 页面），各 AGENT 一直主动的处理 bus 上的东西最终做到的效果，   他们不互相指挥，只处理总线上的东西  在这个 MVP 系统中，各个 agent 仅有 SOUL.md 描述自己的职责，没有向 harness 角度持续优化自身，强化之后就可以做更复杂的系统了 代码感兴趣的话可以参考一下: https://github.com/YangKGcsdms/antlegion-platform 不过加了 UI 角色之后，我对于 MVP 场景的事实领域还没有做治理，导致几个 AGENT 跑起来会经常发呆 |
|
15
coefu 12 小时 46 分钟前
@tftNExtLife #14 你在你自己的世界里，玩耍的开心就行。不用再回复了。
|
|
16
tftNExtLife OP @coefu 6
|
Select Language