最近构思了一个小项目，叫 Claw Fact Bus。

核心想法其实很简单：

让 AI Agent 围绕「事实（ Fact ）」协作，而不是围绕「命令（ Command ）」协作。

多 Agent 系统常见的问题

在很多多 Agent 系统里，协作方式通常是这样的：

A 调 B → B 调 C → C 调 D

或者：

• 用户发一堆消息
• 多个 agent 一起感知
• 再互相触发

这种方式在 agent 数量少的时候还能工作，但一旦系统变复杂，很快就会遇到问题：

• 需要维护越来越多的 workflow / DAG
• 编排逻辑越来越复杂
• 新增一个 agent 就要改旧逻辑
• 场景稍微变化，整条调用链就会变得脆弱

换句话说：
系统越来越依赖“命令链”，而不是“状态”。

Fact：系统里流动的是「事实」

在 Claw Fact Bus 的设计里，Agent 不直接调用彼此。

它们只做一件事：

发布 Fact 。

例如：

incident.latency.high

db.query.slow

code.review.needed

change.proposed

这些 Fact 描述的是：

系统里发生的一件事情

而不是：

请某个 Agent 去做某件事情

每个 Agent 只需要关注 自己感兴趣的 Fact 类型。

Bus：所有事实在一条总线上流动

所有 Fact 都会发布到 Fact Bus 上。

Agent A → 发布 fact Agent B/C/D → 根据过滤器感知 fact Agent → 响应并产生新的 fact

于是系统的协作方式变成：

fact → agent 响应 → 新 fact → 下一个 agent

在这个模型里：

• Agent 不需要知道其他 Agent 的存在
• 不需要维护调用关系
• 不需要中心化 orchestrator

工作流不是提前写死的，而是从 Fact 的因果链自然形成。

为什么要这样做

AI Agent 和传统服务有一个很大的区别：

• 输出可能不稳定
• 同一事实可能被不同 Agent 质疑
• 新事实可能替代旧事实
• 观察（ observation ）和推断（ assertion ）需要区分

所以在 Fact Bus 中，每个 Fact 都带有一些认知层的信息，例如：

• semantic_kind

  • observation
  • request
  • resolution

• confidence

  • 发布者的可信度

• corroborate / contradict

  • 其他 agent 可以佐证或反驳

• supersede

  • 新事实可以替代旧事实

因此它更像是：

AI Agent 协作的事实层（ Fact Layer ）

而不是简单的消息队列。

一句话总结

Claw Fact Bus = 一个围绕「 Fact 」而不是「 Command 」设计的 AI Agent 协作总线。

不是 Workflow Engine
不是 Task Queue

而是：

Fact-Driven Coordination for AI Agents

项目地址：

https://github.com/YangKGcsdms/claw_fact_bus