我不是在做一个“多 Agent 聊天玩具”

过去很长一段时间里，我对大模型多 Agent 系统一直有一种强烈的不满足。

我看过太多“看起来很热闹”的系统：

• 几个角色轮流发言
• 一堆观点互相点评
• 最后合成一段像模像样的结论

它们很像团队协作。但它们不是生产协作。更不是预测协作。

因为真正的预测，不是一次漂亮回答。真正的预测，是长时间、多路径、反复修正、持续校准的推演过程。

如果一套系统只能让几个 Agent 聊天，它就承受不了我要的目标：

• 单机或并联服务架构下承载几十个 Agent
• 千级、万级任务单元准确交互
• 长时运行，24 小时不休
• Agent 之间进行可控讨论，而不是互相带偏
• 最终产出低幸存偏差、低漂移、低 token 成本的辅助预测结果

我真正想做的，不是“多 Agent 对话”。我想做的是一套面向复杂预测任务的协作底座。

而最近把基于 OpenClaw 的 Telegram Topic 协作架构跑到现在这个阶段后，我第一次觉得，这件事开始从想法进入工程现实了。

因为这次做成的，不是“又多了几个角色”，而是把这些底层机制真正接起来了：

• 协议层
• 共享状态层
• 组合执行器
• gateway 内置 guard
• 外置 notifier
• 固定周期 timer

结果是：

• 多 Agent 并行任务不再主要依赖 transcript 印象
• 正式消息可以被机器判定、登记、追踪、复盘
• 超时以后不再天然等于任务死掉
• 主控、助理、专业 Agent、子代理可以在一个代码化框架里长期协作

如果只看表面，这像是在做一套更复杂的 Agent 协作系统。但如果放到工程视角里看，这件事更接近于：

我们开始把多 Agent 协作从提示词工程，推到了系统工程。

而且这条路，恰恰是 OpenClaw 最值得走、也最难走的一条路。

一、为什么要先讲 OpenClaw，而不是直接讲多 Agent

如果拿 OpenClaw 跟 Claude Code 的 agent team 做对比，你会发现两者从起点就不一样。

Claude Code 的 agent team 更像一种强耦合的临时协作模型：

• 同一轮任务里临时拉起
• 天然共享当前主上下文
• 更像主会话的一次扩展执行
• 协作边界紧，局部任务很好拆

这类模型的优势很明显：

• 上手快
• 一致性强
• 短链路任务很顺
• 不太容易在一开始就出现角色漂移

但 OpenClaw 走的是另一条路。

OpenClaw 的多 Agent 更像一组长期存在、各自独立的专业工作体：

• 独立工作区
• 独立会话
• 独立身份
• 独立长期记忆
• 可以持续演化自己的专业能力、工作风格和规则理解

这套机制的价值非常大。因为它让多 Agent 不再只是“同一个大模型的几个临时分身”，而更接近真正意义上的专业角色系统。

但问题也恰恰出在这里。

越独立，协作就越难。

因为一旦每个 Agent 都是长驻的、独立的、可持续进化的，它们之间天然就不像 Claude Code agent team 那样强耦合。它们没有一个天然共享、天然一致、天然同步的全局上下文。

于是工程问题会迅速出现：

• A 觉得已经发出去了，B 觉得没收到
• B 已经回了，主控还在等
• 某个 Agent 本地 transcript 里看起来完成了，系统真值没登记
• 长链任务跑久了以后，局部记忆、共享状态、主控判断开始漂
• 如果没有底层机制约束，最后就会退化成“人人都觉得自己完成了，但系统没有一个唯一可验证的结果”

所以 OpenClaw 的多 Agent 协作，技术上比 Claude Code agent team 更难。

但反过来说，一旦 OpenClaw 把这件事做成，它的上限也会更高。

因为它不是在做一套一次性协作工具，而是在做一套可以长期运行、持续进化、角色明确、可扩展的 Agent 组织系统。

二、OpenClaw 真正难的，不是角色够不够多，而是怎样不漂

今天很多多 Agent 系统，问题不在“不会分工”，而在“分工以后没法稳定收口”。

最典型的漂移有几种：

• 消息漂移：发出去的正式消息没人能最终确认到底算不算有效
• 状态漂移：某个阶段看起来已经完成，系统真值还没推进
• 收口漂移：某个 Agent 说自己总结了，但 guard 并没有登记为合法 final
• 记忆漂移：任务一长，大家开始依赖本地 transcript 印象而不是统一真值

如果没有底层工程机制，这些问题不会因为提示词更长就消失。相反，Agent 越多、任务越长、交互越密，漂得越厉害。

我们这次解决的核心问题，不是“怎么让每个 Agent 更聪明”，而是：

怎么让整个系统在高复杂度协作下仍然保持单一真值。

如果把这件事再往深一点说，它其实已经不只是 prompt 工程问题了。

一旦任务复杂度上来，你面对的会是一个真正的复杂系统：

• 多个主体并发行动
• 不同假设路径同时存在
• 任务要分叉、合流、回滚、重试
• 状态要保留，不能被一句顺滑的话覆盖掉
• 一次错误通信，可能在后面几十轮里放大成系统性偏差

这也是为什么我越来越不愿意把它理解成“多 Agent 聊天”。

从方法论上看，它更接近：

• agent-based modeling
• Markov 式状态转移
• Monte Carlo 式多路径采样
• data assimilation 式持续校正
• distributed systems 式消息语义、确认与恢复

而在这一切问题真正能成立以前，挡在最前面的第一道门，不是模型够不够聪明，而是一个更基础、也更残酷的问题：

通信会不会漂移。

对复杂预测系统来说，这甚至是第一杀手。

因为预测不是一句话。预测是一个状态演化过程。

如果系统连下面这件事都不能稳定回答，后面所有多路径推演、状态采样、持续校正都会沦为空谈：

这条任务单元消息，到底有没有真正进入接收方的有效通道？

所以我后来越来越确定：

要想做严肃的多 Agent 预测系统，第一件必须做对的事，不是让 Agent 更会说，而是先把通信真值做出来。

三、这套架构的核心，是把协作拆成三层

1. 协议层：先定义什么叫正式协作

我们先把正式动作收敛成有限协议类型，比如：

• ROUND_START
• ROUND_ACK
• EXECUTION_OPEN
• question
• answer
• final_view
• final_summary
• main_final_delivery

这一步的作用不是“看起来更规范”，而是把自然语言协作转成机器可判定动作。

一旦协议固定下来，系统就能明确知道：

• 哪些消息才算正式消息
• 最小合规字段是什么
• 谁可以发给谁
• 哪个阶段允许发什么
• 哪些动作能推进轮次状态

如果没有这一层，后面所有所谓的 guard、审计、恢复、收口都只是空谈。

2. 共享状态层：把每轮任务从聊天记录变成机器真值

我们把每轮任务拆成独立共享状态目录，至少包含：

• state.json
• deliveries.jsonl
• receipts/*.jsonl
• agents/<self>.json

这背后的意义很大。

它意味着：

• 主控看到的是轮次真值，不是 transcript 猜测
• 运行期看到的是 delivery / receipt 事件，不是“好像已经到了”
• 每个 Agent 的局部推进状态，会写回自己的状态文件，而不是只留在它自己脑子里

这一步本质上是在做一件事：

把不可验证的语言协作，变成可审计、可追踪、可回放的状态协作。

3. 组合执行器：把执行权拆成内置、外置和周期驱动

只有协议和共享状态仍然不够。系统还必须知道：

• 什么时候登记
• 什么时候确认
• 什么时候超时
• 什么时候纠偏
• 什么时候允许收口

所以我们把执行器拆成三部分：

gateway 内置部分

直接嵌进主链，负责：

• 正式消息最小合规判定
• 正式类型解析
• delivery 生命周期登记
• receipt 双阶段确认
• 布尔真值回写
• 收口状态迁移

外置部分

只消费已登记真值，负责：

• 超时通知
• 停滞通知
• 主控督办提示

它不再拥有新的判定权。

timer

固定周期驱动，不依赖人盯着系统跑。

它会周期性触发：

• guard 巡检
• notifier 轮询
• 主控督办链

这意味着多 Agent 长任务不再需要人肉陪跑，而是开始具备无人干预推进的基础条件。

四、真正把漂移压住的，不是提示词，而是代码化流程

这套架构最关键的变化，是我们不再把关键路径建立在“Agent 应该会自觉遵守”上。

我们把关键动作做成了代码化流程。

比如：

• 什么叫合法 question
• 什么叫合法 answer
• 什么叫 final 收口
• 什么叫第一阶段确认
• 什么叫第二阶段确认
• 什么叫 closure gate ready
• 什么叫 round closed

这些不再只是自然语言描述，而是：

• 代码里的状态机
• 机器字段
• 审计事件
• 可验证布尔真值

所以这套架构的价值不是“协作更好看”，而是：

• 无漂移
• 高精准度交互
• 可审计
• 可追踪
• 可复盘

从工程上说，这就是多 Agent 系统从“靠自觉”进入“靠机制”。

这也是为什么我会这么强调“代码化”。

这件事如果只写成文档，是跑不起来的。文档不会自动拦截，不会自动判定，不会自动回滚，也不会自动推进状态。

多 Agent 协作要真正成立，核心规则必须从“写在纸上”推进到“写进代码”：

• 协议要代码化
• 状态机要代码化
• Guard 要代码化
• 超时策略要代码化
• 审计事件要代码化

只有代码化以后，系统才会从：

• “大家都知道应该怎么做”

变成：

• “系统强制所有 Agent 按同一真值做”

这两者的差别，就是 demo 和生产的差别。

五、一个真实高压测试，说明这套架构已经不是纸上谈兵

如果只讲架构，永远容易显得抽象。所以更重要的是它有没有在压力场景里真的跑出来。

我们刚做过一轮真实高压测试，目标不是看任务能不能完成，而是看在高消息量、超时、迟到确认、重复重发场景下，这套架构能不能把主链稳住。

这轮测试里，最终跑出了非常关键的一组结果：

• 业务主链里一共形成了 61 个正式问题
• 同时形成了 61 个正式回复
• 总计 122 条业务交互链
• 最终永久丢失的业务链是 0
• 大量链路不是一次性顺滑完成，而是在超时、迟到确认、重发要求、撤销重发之后，仍被系统稳定恢复

更关键的是，这 122 条链并不是在理想网络下“一次性顺滑成功”的。

恰恰相反，这轮测试最重要的价值在于，它把最麻烦的场景真正打出来了：

• timeout
• notifier 督促重发
• 旧消息迟到确认
• 撤销重发要求
• 恢复旧链为权威链

也就是说，系统验证的不是“理想情况下会不会成功”，而是：

当协作已经开始出故障时，它还能不能自己恢复。

这就是为什么这轮测试的意义很大。因为多 Agent 真正难的，从来都不是 happy path，而是 fault path。

六、这轮高压测试补出的关键闭环，是“迟到确认后撤销重发”

多 Agent 协作里一个特别常见的问题是：

• 发件方认为超时了，要重发
• 收件方其实晚一点收到了
• 主控不知道旧消息和新消息哪个才算真
• 最后不是重复劳动，就是整轮卡住

我们这次补齐的关键闭环是：

迟到确认后撤销重发要求。

也就是当一条正式消息先被判超时，但后续又拿到了接收侧有效确认时，系统可以自动：

• 修复旧 attempt 的确认状态
• 撤销已发出的重发要求
• 折叠多余的重复 attempt
• 把旧链恢复为权威链

这一步不是体验优化，而是稳定性分水岭。

因为从这一刻开始，超时不再天然等于任务死掉。它变成了一个可恢复状态。

这对长链任务尤其关键。因为交互越多、时间越长、角色越多，超时和迟到确认只会越来越常见，不会越来越少。

换句话说，这次真正跨过去的一道门，不只是“又修了一个 bug”，而是：

通信漂移第一次开始被架构级压住了。

只要通信真值能成立，任务单元才有资格被继续采样、保留、淘汰、回滚和重构。这才是复杂预测系统真正的基础设施。

七、这套架构已经不只是父代理并行，父代理下面还能继续带子代理

这是我们最近新验证出来的第二层价值。

原先大多数多 Agent 设计，停留在“几个父角色互相问答”。但复杂任务真正落地时，父代理本身也会成为瓶颈。

于是我们在这套架构里又往下扩了一层：

父代理之下允许继续 spawn 子代理。

但这里不是随便放开，而是有硬边界：

• 每个父代理最多只允许启动 3 个子代理
• 子代理只允许承担局部辅助工作
• 子代理不得直接进入 Telegram Topic 主链
• 子代理不得直接发送 question / answer / final_view / final_summary
• 父代理必须先吸收子代理结果，再进入正式主链

这一步很重要。因为它把系统从“平面协作”推进成了“分层协作”。

最近一轮子代理验证里，已经出现了明确样本：

• cto-topic 真实启动了 3 个子代理，先把全局架构比较、风险清单、方案评估拆出去，再吸收结果后生成正式问题链
• techlead-topic 真实启动了 2 个子代理，并把服务拆分、部署拓扑两类重任务先拆出去，再整合回父代理方案

从共享状态结果看，techlead-topic 的子代理结果已经完成吸收，并推进到了 final_view_submitted。

这意味着子代理不是摆设，而是已经开始承担父代理的局部生产工作。

八、子代理为什么有价值

它的价值不只是“多开几个 worker”。

真正的价值在于：

1. 降低父代理单点认知负担

复杂任务里，父代理最容易成为瓶颈。因为它既要保持主链协作，又要做本领域的深分析。

子代理的意义，就是把一部分局部高负载工作拆出去，让父代理只做：

• 任务分解
• 结果整合
• 正式输出

2. 提高复杂任务的生产效率

这不是说所有任务都一定更快。准确说法是：

• 复杂度更高的局部子任务，更适合先拆给子代理
• 父代理的主链响应速度和结构化程度会明显提高

换句话说，子代理最明显提升的，是高复杂任务里的“有效产出效率”，而不只是某一次单步响应速度。

3. 给未来更大规模协作留下扩展位

一旦父代理下面能稳定带子代理，系统以后就不只是一层角色网络，而是可以向更复杂的执行树扩展。

这也是为什么我们判断它有潜力支撑更大规模复杂预测任务。

九、为什么说它有潜力支撑千级交互以上的复杂预测任务

先说清楚：

这不等于我们已经完成了千级真实生产验证。但从架构角度看，这条路已经不是空想。

原因有三点。

1. 它不依赖单个 Agent 永远记住全局

全局状态不再只在 transcript 里，也不只在某个主控脑子里。它被拆进：

• 协议层
• 共享状态层
• guard 真值

所以随着任务链拉长，系统不会立刻退化成上下文记忆游戏。

2. 它已经具备恢复链

大规模交互一定会遇到：

• 延迟
• 超时
• 重发
• 重复 attempt
• 状态分歧

如果没有恢复链，规模一大就会崩。我们现在至少已经把最关键的一条恢复链跑通了：

超时后仍可恢复，而不是直接卡死。

3. 它具备继续扩链的结构基础

目前已经验证可以共存的执行层包括：

• 长链话题级协作
• 父代理正式主链
• 子代理局部辅助链
• 外置巡检和主控督办链

这意味着它天然适合继续向更复杂的树状协作扩展，而不是只能做平面式多角色聊天。

而且这件事对我特别重要的一点是，它不是在把系统推向“更忙”，而是在把系统推向“更低幸存偏差”。

我想要的不是一个更会包装叙事的大模型系统。我想要的是一个尽可能低幸存偏差的系统。

什么叫低幸存偏差？

不是只记住最后活下来的那条叙事。而是系统必须能保留：

• 失败路径
• 边缘路径
• 暂时弱势但未被证伪的路径
• 因新证据出现而值得重新调权的路径

这类系统一定依赖严肃的任务与状态机制，而不是长对话里的印象流。

十、这件事对当前 Agent 并行写作到底意味着什么

很多系统今天也在做“多个 Agent 一起写”。

但如果底层还是：

• 临时起几个角色
• 互相发几轮话
• 最后人工挑一个最像结果的答案

那它本质上仍然只是更复杂的聊天系统。

真正的分水岭不在于角色数量，而在于：

这些角色之间有没有统一协议、统一状态、统一真值、统一收口。

如果没有，这些系统在短任务里也许能跑，在长任务、重任务、复杂预测任务里很快就会露出上限。

而我们这次做成的，恰恰是把最难的底层问题工程化了：

• 正式动作有协议
• 协作状态有共享状态层
• 正式消息有双阶段确认
• 超时以后有恢复链
• 收口有唯一真值
• 主控与助理有督办职责
• 父代理下面还能继续挂子代理

这才是多 Agent 真正开始进入生产系统阶段的标志。

十一、下一步重点，不是再堆角色，而是优化 token 成本

当系统已经能稳定完成复杂协作以后，下一个现实问题就非常明确了：

token 成本。

因为随着正式消息越来越多、角色越来越多、子代理也开始加入，系统下一步最应该优化的是：

• 哪些广播可以压缩
• 哪些状态同步可以更轻
• 哪些检查可以做成更短 machine path
• 哪些子代理结果应该更早被摘要吸收
• 哪些问题链和回复链可以减少不必要往返

也就是说，下一阶段不是推翻现在这套架构，而是在已经跑通的基础上做效率工程。

这会直接决定它从“已经能用”走向“长期高性价比可用”的速度。

如果说前一阶段解决的是“能不能稳定完成”，那下一阶段解决的就是：

• 能不能更便宜地完成
• 能不能更长时间地完成
• 能不能在更高交互密度下完成

也就是把这套系统从“已经像生产系统”继续推进到“更接近预测工业能力”。

十二、结语

OpenClaw 的多 Agent 协作，比 Claude Code agent team 更难做。

因为它不是几个天然强耦合的临时分身，而是一组长期存在、独立工作区、可持续演化的专业 Agent。

但也正因为这样，一旦它把底层协作机制做成，它的上限也会更高。

我们这次真正做成的，不是一组更花哨的提示词，而是一套把多 Agent 协作压进工程体系里的底层架构：

• 协议层定义正式动作
• 共享状态层承载机器真值
• 组合执行器负责推进与巡检
• 内置 guard 负责门控与收口
• 外置 notifier 和 timer 负责长期无人值守运行
• 父代理还能继续通过最多 3 个子代理提升复杂任务的生产效率

它已经证明了一件事：

多 Agent 协作不是不能做生产级，而是必须先把真值、状态、执行、恢复、收口这些底层问题解决掉。

一旦这些问题解决，系统就不再只是“几个模型一起聊天”，而是一个真正可扩展、可审计、可长期运行、可承载复杂任务的协作执行系统。

而对我来说，这件事真正重要的地方还不止于此。

它意味着我终于可以比较有底气地说：

我不是在做一个多 Agent 聊天玩具。

我是在给一种未来的复杂预测引擎修地基。这条路还远没有结束，但它第一次开始像一条真实存在、而且值得继续走下去的路。