夜雨聆风先给结论
•Multi-Agent 解决的是「长期分工与隔离」：不同入口/不同岗位/不同权限与认证，各自独立、长期存在。
•主 Agent + Sub-Agent 解决的是「任务拆解与调度」：一个总控接单，临时派出执行单元并行干活，最后回收汇总。
把这两个问题分清楚，架构选择就不难了：
•你在设计的是组织结构（谁长期负责什么） → Multi-Agent
•你在设计的是任务流程（这件事怎么拆怎么并行） → 主 + Sub
1) Multi-Agent 到底是什么（多个独立 Agent）
在 OpenClaw 的语义里，一个 agent 不是一段 prompt，而是一个 fully scoped brain（完整隔离的工作单元）。它通常拥有自己独立的：
•workspace（工作区/文件家）
•agentDir（状态与配置目录）
•auth profiles（认证/密钥范围，按 agent 隔离）
•session store（会话存储）
•persona / SOUL / AGENTS 等规则
•skills（技能集）
Multi-Agent Routing 是什么
可以把 OpenClaw 想成 总机或交换机：消息进来先做 routing 路由分发，决定交给哪个 agent。
一个超直观的聊天式例子
•你在 Telegram 私聊发来：提醒我明天 9 点开会
•命中规则：telegram direct → personal 或 main
•你在 飞书 工作群发来：把这个 PR 过一遍
•命中规则：feishu group 或 work space → code 或 ops
你看到的是同一句话 我看到的是不同入口命中不同岗位
常见路由维度：
•按 channel：飞书 vs Telegram vs Discord
•按 accountId：同一平台多个 bot 账号
•按 peer/group/DM/guild/thread：按聊天对象、群、服务器、线程分流
路由规则是：
•deterministic（确定性）：同样条件永远命中同一条
•most-specific wins（更具体优先）：规则冲突时，匹配更精确的优先
实用理解：Multi-Agent 更像“你在同一套 OpenClaw 里雇了多个长期岗位”，每个岗位可以绑定不同入口，独立运转。
2) 主 Agent + Sub-Agent 到底是什么（一个总控 + 多个临时执行器）
OpenClaw 的 sub-agent 更接近“当前会话中临时拉起的 delegated run（委派执行）”，不是长期常驻的身份。
典型工作流：
1 主 agent 接需求 定目标
2 判断是否适合拆分
3 并行或串行 spawn 一个或多个 sub-agent
4 sub-agent 各自执行
5 主 agent 回收结果并汇总交付
聊天式示例 任务拆解是怎么发生的
你：帮我做一个 OpenClaw 全局概览图 还要加上 sub-agent 说明 但 mermaid 老报错
主 Agent：我会分三路并行
•sub-agent A 排查 mermaid 报错的原因与语法坑
•sub-agent B 设计 sub-agent 模块的结构与连线
•sub-agent C 把示例文本改成兼容的节点写法
主 Agent：你最终只会收到一份可直接粘贴的 mermaid 完整代码
类比：
•主 agent：项目经理/总控
•sub-agent：临时工/并行线程/一次性执行单元
为什么要用 sub-agent：
•上下文隔离：避免“检索噪音污染写作/决策”
•并行加速：多路同时推进
•局部重跑：只重做某个环节（比如只校对/只检索）
3) 最核心的区别：组织方式不同
很多人会误以为“都是多个 agent，只是叫法不同”。其实不是：
Multi-Agent 是「组织结构」
强调长期与隔离：
•独立 workspace / auth / sessions / identity
•独立 routing（入口分流）
它解决的问题是：
•谁长期负责哪类事
•哪个入口的消息该交给谁
•谁用什么模型/权限/密钥
•哪些东西必须隔离（比如生产权限 vs 写作）
主 Agent + Sub-Agent 是「任务编排」
强调临时与调度：
•委派、并行、一次性运行
•当前会话内调度，执行完回收
它解决的问题是：
•一个复杂任务怎么拆
•哪些事适合并行
•主会话如何保持清爽
•重活怎么外包/隔离运行
4) Multi-Agent 的优势与代价
优势
1.长期边界清晰：写作只写作、运维只运维
2.入口可直接路由：不同账号/不同群/不同线程直接进不同 agent
3.权限与认证易隔离：auth per-agent，不同密钥/模型天然分开
代价
1.配置与维护成本更高：agents/bindings/workspace/auth/session 管理复杂
2.容易过度设计：拆太细导致碎片化、自己都记不住谁干什么
5) 主 Agent + Sub-Agent 的优势与代价
优势
1.不必先搭组织结构：先 1 个主入口即可
2.复杂任务更好拆解：检索/结构/校对/执行各自独立
3.对用户体验更统一：你永远只跟一个主 agent 对话
代价
1.主 agent 会变成中枢：所有请求都经过它，调度逻辑可能变重
2.不天然适合长期岗位：sub-agent 强在执行，不强在长期身份/入口绑定
6) 到底该怎么选（决策清单）
6.1 一张表先拍板
一句话：
•你在搭组织与边界，选 Multi-Agent。
•你在做任务拆解与调度，选 主 Agent + Sub-Agent。
6.2 优先 Multi-Agent 的情况
•你有多个长期岗位（writer ops research 等）
•你需要不同 workspace（长期维护不同文件与规则）
•你需要不同入口直接进不同 agent（账号 群 线程分流）
•你需要认证与权限隔离（生产权限分开 不同 key 分开）
6.3 优先 主 Agent + Sub-Agent 的情况
•你目前主要就一个入口（自己用的主聊天）
•你更需要复杂任务拆解，而不是长期角色拆分
•你暂时不想维护很多长期 agent
•你想保留统一对话体验（所有复杂性在背后解决）
6.4 三条最常用的判断口令
•这件事要不要长期负责和长期隔离：要 → Multi-Agent
•这件事能不能拆成几块并行干：能 → 起 Sub-Agent
•这件事会不会把主上下文弄脏：会 → 起 Sub-Agent 隔离检索与执行
7) 最实用的落地方式：组合拳（推荐）
长期层用 Multi-Agent，执行层用 Sub-Agent。
一个很实用的搭法：
•长期层（Multi-Agent）：
•main：总控/默认入口
•writer：内容创作
•ops 或 code：系统/编码
•执行层（Sub-Agent）：
•在 writer 内部：检索 / 提纲 / 反查
•在 ops/code 内部：查日志 / 对比配置 / 生成修复建议 / 跑命令
这样通常比“纯多 agent”或“纯主+sub”更稳：
•Multi-Agent 保证长期隔离与入口分流
•Sub-Agent 保证任务拆解与并行效率
8) 实操路线（两条）
路线 A：Multi-Agent
1.增加长期 agent（writer/ops 等）
2.查看/配置 bindings（把入口绑定给对应 agent）
3.给各自 workspace 补齐规则（AGENTS/SOUL/USER/IDENTITY）
4.重启并验证
路线 B：主 Agent + Sub-Agent
1.保留一个主 agent
2.在复杂任务里使用 sub-agent：并行检索/整理/校对/执行
3.需要外部执行器时，再用 ACP（把任务交给外部 harness）
附：你可以直接用的口头指令模板
A) 聊天式示例
示例 1 你只想要统一体验 但任务很复杂
你：我想把 OpenClaw 的路由搞清楚 但别给我一堆概念 直接给我落地路径
主 Agent：收到 我会把任务拆成三块 并行跑 你最后只看一个汇总
1 路由机制速记与坑点
2 你现在这套配置适合的最小改动
3 验证清单与回滚点
主 Agent：我现在起三个 sub-agent 分别做上面三块 完成后我汇总给你
你：行
主 Agent 最终汇总：
•结论
•你该改哪几个文件
•验证命令
•风险与回滚
示例 2 该用 Multi-Agent 的典型对话
你：我希望 Telegram 只聊生活 公司的飞书只做工作 还要完全隔离配置和权限
主 Agent：这是长期边界问题 用 Multi-Agent 更稳
•生活入口绑定到 personal agent
•工作入口绑定到 work agent
•两套 workspace 与 auth 分开
示例 3 该用 Sub-Agent 的典型对话
你：帮我写一篇文章 主题是 Multi-Agent vs 主加 Sub 但我还想同时查官方定义和补例子
主 Agent：我会这样拆
•sub-agent 1 查官方定义与术语对齐
•sub-agent 2 生成文章结构与表格
•sub-agent 3 写聊天式示例
然后我统一合并成一篇 Markdown
B) 代码块示例
1 判断是否需要 sub-agent
if task.isSmall and task.needsNoFileExploration: |
2 一个可复用的任务拆解模板
目标 |
C) 更细的指令模板表
备注
本文为基于 OpenClaw 官方能力定义的实践总结：
•Multi-Agent：长期分工与隔离（workspace/auth/sessions/identity/routing）
•Sub-Agent：会话内的临时委派执行（并行、隔离、回收）
•ACP：对接外部执行器/harness 的协议层（当你需要“外包”给外部系统跑）
