十个 Agent 跑了一夜，OpenClaw 多智能体编排的架构和坑

事情是这样的。头天晚上 11 点，我关电脑睡觉。第二天早上 8 点打开通讯平台，消息列表里整整齐齐躺着四份完工报告，情报部采完了当天的 AI 行业热点，内容部按热点写好了一篇深度长文初稿，课程部把最新的工具测评整理成了教学大纲，研发部审完了昨天提交的代码。全程没人值班。

不是请了实习生，是 10 个 AI Agent 在 OpenClaw 里跑了一夜。

这两年帮企业做 AI 落地，我见过太多团队把 AI 用成一次性工具，用完即弃，下次对话从头来过。这篇把这套多 Agent 编排的架构思路、通信机制和踩过的坑全拆开，给你一份能照着做的选型清单。

先回答一个问题，为什么要给 AI 分部门

你大概率碰过这种场景，让 AI 助手写完小红书笔记，接着写深度长文，它把种草语气带了过来。你说别用那种语气，它说好的，下一段又犯。

问题不在 AI 不行，在你让一个 AI 同时干十个部门的活。换个角度想，哪家公司的老板亲自写文案、亲自修 Bug、亲自追热点还亲自剪视频，不会吧。正常公司的做法是分部门，各司其职。AI 也一样。

OpenClaw 是一个开源的多 Agent 编排框架，能让多个 AI Agent 像公司部门一样 24 小时协作，名字取自小龙虾的钳子，多只钳子协同作业，恰好就是多 Agent 协作的隐喻。有一点要先说清，OpenClaw 本身不是 AI，它是编排层，真正干活的是大语言模型，OpenClaw 负责让它们各司其职。

我们部署了 10 个 Agent，直接套用公司组织架构，总部管全局调度，情报部采集热点，内容部写长文，视频部管脚本和字幕，研发部审代码做工具，行政部管日程归档，运维部盯系统监控，各管一摊，24 小时自动运行。

每个 Agent 只做一件事，好处立刻显出来。写作人格不打架，小红书 Agent 的身份文件写着活泼有趣、标题要有钩子，长文 Agent 的写着逻辑严密、术语加注释，两套人格绝不互相污染。工作记忆不串台，小红书 Agent 的记忆里只有哪类标题容易爆、什么时段发布效果好，不会突然跟你聊 Bug。还能同时干活，最大并发配到 8 个，你在写笔记的时候，情报部正在采热点，研发部正在审代码。

五个概念，把 Agent 当员工管

用开公司做类比，五个概念一次说清。

Agent 是员工。每个 Agent 有三样独有的东西，SOUL.md 是岗位说明书，写它是谁、负责什么、行为准则。MEMORY.md 是工作笔记本，只记自己领域的经验，跨会话保留。TOOLS.md 是工具箱，内容 Agent 会用发布工具，研发 Agent 会用代码执行工具。

Guild 是公司，通讯平台上的一个服务器，就是你这家 AI 公司的物理空间。Channel 是办公室，我们开了 10 个频道对应 10 个部门，你走进哪个频道，就跟哪个 Agent 对话。频道不只是消息入口，更是上下文边界，同一频道的对话共享会话，不同频道的会话完全隔离。

Binding 是门牌号，把频道和 Agent 关联起来的路由规则。它是纯配置，不靠 AI 判断，所以路由零误差，你不会走进内容部的频道，结果出来一个修 Bug 的。

Session 是对话记忆，关键在隔离。会话按 Agent 加频道天然分离，内容部 Agent 看不到你在研发频道聊了什么，隔离保证了专注。

还有 Heartbeat 心跳巡检，每 55 分钟自动唤醒一次 Agent，检查收件箱里有没有别的部门委派的任务。这是后面整套协作机制的基石。

三级通信，Agent 之间怎么传话

10 个 Agent 各管各的，但业务是交叉的，情报部采完热点，内容部要拿去写稿。我们在 OpenClaw 里设计了三级通信体系。

第一级，shared/inbox 文件委派，像把文件放到对方桌上。发起方写一个任务文件放进共享目录，目标 Agent 的心跳巡检发现文件，读取、执行、写回执，全程异步，不依赖对方在不在线，还有完整的文件审计链。缺点是慢，最坏要等一个心跳周期，55 分钟。适合正式的、上下文复杂的、不急的任务。

第二级，sessions_spawn 即时派发，像给对方打个电话。系统自动给目标 Agent 创建临时会话，对方马上执行，结果自动广播回传。即时响应，不需要对方在线，但派发深度上限是 2，不适合复杂多轮任务。适合一句话说得清、当场要结果的查询。

第三级，message 公告，在频道里留个言。划重点，这条只给人看，不会触发目标 Agent 做任何事。适合公告、进度提醒，以及前两级失败时的兜底。

正式任务走 inbox，当场要结果用 spawn，只想让人看见就留言。

老雷给大家提个醒，别依赖单一通信方式，这三级的意义在冗余，一种挂了另一种兜底。我们最早用 sessions_send 让 Agent 互传消息，目标 Agent 没有活跃会话时，消息直接丢失，改用 spawn 加 inbox 兜底之后，这个坑才填平。还有一回用 message 通知情报部素材已更新，等了半天毫无反应，后来才明白 message 压根不触发 Agent，想要它动起来，得用 spawn。

六种架构，为什么选 1 比 1 专职

同样跑多个 Agent，组织方式可以完全不同，核心变量就两个，Agent 数量和路由策略。我们穷举了六种，从简到繁过一遍。

模式 A，单 Agent 管所有事。零协调成本，配置最简单，代价是身份文件指令冲突、记忆污染、无法并行，像让一个人同时接十个电话，每个都接不好。适合只有一两个简单需求的用户。

模式 B，1 比 1 专职，每个 Agent 独占一个频道。身份专精、会话隔离、能并行，一个 Agent 挂了不影响其他，代价是配置量大，每个 Agent 都要配齐三件套，心跳巡检也消耗 Token。适合多业务线、要专业化分工的场景。

模式 C，N 比 1 共享，多个频道指向同一个 Agent。省 Agent 数量，心跳和 Token 开销能降六成，但一份身份文件要覆盖多个平台的策略，专业度下滑，频道之间也没法并行。适合领域相近、资源有限的业务。

模式 D，层级制，在专职模式上加一层主管 Agent，调度只管三个主管，主管再往下派。管理层清晰，还多了一道质量审查，但多一层派发延迟，要注意派发深度上限。适合 Agent 超过 15 个的大规模部署。

模式 E，@提及路由，所有 Agent 绑同一个频道，@谁谁来。听着方便，实际有个致命问题，上下文碎片化，每个 Agent 只能看到你 @ 它的那几句，忘了 @ 就没人响应。一周后你回来翻记录，根本分不清哪句是跟谁说的。

模式 F，总调度单入口，一个频道只绑调度 Agent，它理解你的话再派发。最省心，但调度是绝对瓶颈，路由靠 AI 理解就会偶尔派错，目标 Agent 只拿到转述的一句话，看不到完整上下文。

我们最终选了 B，理由很朴素，切频道的成本是一次点击，换来的却是每个 Agent 完整的会话上下文、干净的记忆、专精的身份文件，这笔买卖太划算了。也有人觉得 10 个频道管不过来，实际情况相反，左侧栏一目了然，消息按部门分类，比几百条消息挤在一个频道里清晰得多。

上手别贪多，成本要盯着

别被 10 个 Agent 吓到，老雷的建议是从 1 个起步。第一步，初始化，建一个 Agent，写好身份文件，绑定频道，发消息测试。第二步，加到 3 个，把最核心的职能拆出来。第三步，按业务线拆到 5 到 10 个，每个配齐三件套。第四步，再打通跨 Agent 通信，叠加协作。

什么时候该拆，有个实用判据，当你发现一个 Agent 的身份文件超过 100 行，或者你经常要对它说别用那种语气，说明它在干两件冲突的事，该一拆为二了。我们自己也是从 4 个起步，跑顺了才扩到 10 个。

成本这块必须交代清楚，多 Agent 现阶段的 Token 开销确实不低，心跳巡检、三件套、并行任务都在花钱，要靠合理调度来控制。好的一面是 AI 推理成本过去一年降了 10 倍不止，趋势只会更便宜，模式先跑通，成本降下来那天，你就是第一批直接用上的人。

收尾说个判断。把 AI 当工具用，用完即弃，下次从头来过。把 AI 当员工养，给它身份、给它记忆，时间越长它越懂你的业务。每个 Agent 的 MEMORY.md 里沉淀着几百次任务的经验，什么选题容易爆，什么代码模式容易出 Bug，这些记忆不是聊天记录，是组织的核心资产。

下一步动作，装好 OpenClaw，先养一个 Agent 一周，给它写份像样的岗位说明书，让它把经验记进 MEMORY.md。养出一个合格的数字员工，再考虑开第二个部门。多 Agent 协作这套架构，就是 AI 应用的演进方向，早理解的人早受益，这也是老雷AI实验室在持续验证的方向。