# OpenClaw教程-多agent架构篇
**作者**: 超级个体|柿子
**日期**: 2026-03-31T02:24:38.000Z
**来源**: [https://x.com/yaohui12138/status/2038804633964237266](https://x.com/yaohui12138/status/2038804633964237266)
---

应广大粉丝朋友要求,openclaw系列教程第四篇:多agent协作篇闪亮登场
> 人工摘要:本篇将重点阐述我对于多agent架构的理解,先阐述多agent常见的三种搭建方式,然后重点阐述单实例多agent架构的设计原则和实操方法,核心论点为agent的设计应该遵循身份,而非流程。
我让 agent「结合产品思维帮我写一篇推文」
它产出了一篇——前半段像产品需求文档,数据翔实逻辑缜密,后半段突然切换成营销软文风格,煽情收尾
读起来像两个人在打架
这不是 agent 能力不够。是我给了它一个不可能完成的任务——同时用 PM 的理性和媒体人的感性去写同一篇文章
你的 agent 可能也在经历这个:记忆文件 2 万字,PM 的商业分析、媒体的创作复盘、开发的技术决策全挤在一起。每次执行任务要先花 30 秒扫一遍 3 个月的杂乱记忆
找错重点是常态。因为 context 里塞了太多不相关的东西
这是单 Agent 的天然瓶颈:认知负荷
解法不是让 agent 更聪明,是让它们像真实团队一样协作——PM 负责逻辑拆解,媒体负责故事包装,开发负责技术实现,中控负责协调
这篇文章讲的就是这个:如何设计多 Agent 架构,让你的数字员工从「瑞士军刀」进化成「专业团队」
我现在跑的是 4-agent 系统。写这篇推文时,PM 先花 3 分钟做逻辑拆解,媒体再花 5 分钟做内容创作。时间是单 Agent 的 5 倍,但质量是单 Agent 怎么调 prompt 都达不到的
如果你的 agent 已经配好了记忆、搜索、断点续做,但输出质量还是差点意思——问题可能不在配置,在架构
> 回顾:前三篇铺垫了什么基础篇:
> 学会用工具——从零装到跑通
> 中级篇:工具越来越好用——记忆、搜索、断点续做
> 高级篇:实习生变正式员工——Skill 给业务知识、Hook 给 SOP、MCP 给工具权限
> 到高级篇结束,你的 agent 已经很强了——它记得住、找得到、断不了、会做事、按规矩来
但认知负荷问题,单 Agent 解决不了
基础:多 Agent 不是一种技术,是三种解法
在开始讲我的 4-agent 系统之前,先说清楚一件事——大部分人说的「多 Agent」其实在说三种完全不同的东西
OpenClaw 支持三种多 Agent 实现方式,它们解决的问题完全不同
方式 1:多实例(Multiple Instances)
这就像你开了多家分公司——每家公司独立运营,各有各的账本、各有各的员工,互相不知道对方存在
技术上:同一个 Gateway 进程里跑多个完全隔离的 Agent,每个 Agent 有独立的 workspace、独立的认证配置、独立的会话历史
通过 bindings 路由机制,把不同的 channel 或 accountId 绑定到不同的 Agent——比如你的个人 WhatsApp 绑定 Agent A,公司 Discord 绑定 Agent B
什么时候用:
- 多人共享一台服务器,但各自需要独立的 AI 助理
- 需要绝对的数据隔离和安全边界
方式 2:多 Agent 架构(Multi-Agent Architecture)
这就像一家公司的跨部门协作——PM 部门、运营部门、技术部门,各有专业分工,但通过会议和文档共享来协同
技术上:多个 Agent 通过 sessions_send 进行对话式通信,通过 SHARED.md 共享团队知识,通过 main agent 做中控调度
这是本文的核心内容——按身份拆分 Agent,让每个 Agent 在独立的认知空间里工作,输出专业判断而不是执行指令
什么时候用:
- 任务需要多种思维模式
- 单 Agent 的记忆文件已经混乱到影响决策质量
- 你需要 Agent 之间有明确的协作和共识管理
- 你希望agent具备独立的身份,作为你的魔偶一部分来执行
方式 3:Sub-Agent 架构(Sub-Agent Spawning)
这就像临时外包——主 Agent 遇到一个具体任务,spawn 一个临时工在后台干活,干完把结果交回来就消失
技术上:主 Agent 通过 sessions_spawn 启动后台任务,sub-agent 在独立 session 中执行,完成后返回结果。默认情况下 sub-agent 不能再 spawn 下一层(防止无限嵌套)
和多 Agent 架构的核心区别:
- Sub-agent 是临时的,用完即归档;多 Agent 架构中的 Agent 是持久化的
- Sub-agent 不会污染主 Agent 的上下文;多 Agent 之间会共享部分团队知识
- Sub-agent 适合「并行处理不相关的多个任务」;多 Agent 架构适合「协同完成一个复杂任务」
什么时候用:
- 需要并行执行多个独立的研究任务
- 需要保持主 Agent 上下文整洁
- 临时性的数据收集、竞品分析、代码生成
什么时候不用:
- 需要持续的角色协作和知识积累——sub-agent 不会留下记忆
- 需要 Agent 之间反复沟通——sub-agent 只返回最终结果,不支持多轮对话
本文聚焦第二种——多 Agent 架构。因为这是独立开发者和超级个体最需要的能力:一个人扮演多个角色,需要数字团队帮你分担认知负荷
一、你的 agent 正在人格分裂
先说一个我自己踩到的真实场景
我让我的 agent「结合产品思维帮我写一篇推文」
它产出了一篇——前半段像产品需求文档,数据翔实逻辑缜密,后半段突然切换成营销软文风格,煽情收尾
读起来像两个人在打架
不是 agent 不聪明。是我给了它一个不可能完成的任务——同时用 PM 的理性和媒体人的感性去写同一篇文章
这就像你让一个人同时做产品经理、运营、开发者。能力是够的,但他的大脑在三种思维模式之间来回切换,每种都做不到极致
这是单 Agent 的天然瓶颈:认知负荷
SOUL.md 里写了你是 PM,也写了你要有创作感,还要懂技术——三个角色的思维方式互相干扰,context 里堆了三种知识体系,每次回答都在做三选一
输出只能是三种风格的平均值。平均值意味着平庸
大部分人搜「多 Agent」,看到的教程都在讲怎么拆功能——搜索 Agent、写作 Agent、发布 Agent
按功能拆的逻辑是:每个 agent 做一件事,流水线串起来
我的做法不一样。我按身份拆——PM、媒体、工程师、中控
这不是技术架构问题,是组织架构设计
你想想——公司招人是按「搜索岗」「写作岗」「发布岗」招的吗?
不是。是按产品经理、运营、开发者招的。每个人有自己的专业背景、思维模式、知识体系
功能是手段,身份才是核心
搜索、写作、发布这些是功能,用 Skill 封装就行——一个 PM agent 完全可以自己搜信息、写 PRD、发邮件
Agent 应该对应身份,Skill 负责功能
我现在跑的是一个 4-agent 系统:
- main:中控调度,负责监控、广播、协调
- pm:产品管理,负责需求拆解、策略制定、数据分析
- media(柿子):媒体运营,负责内容创作、传播策略、粉丝互动
- dev(出海工程师):开发工程,负责代码编写、系统维护、技术方案
4 个 agent,4 个独立身份,4 套独立的认知空间
这不是为了炫技。是因为我真的试过让一个 agent 干四个人的活,它确实在人格分裂
二、四个真实场景——多 Agent 到底解决什么问题
不讲概念了,直接说我踩过的坑和解决后的对比
场景 1:角色错乱→输出平庸
单 Agent 时代,我让它「帮我写一篇 openclaw 教学推文,要有产品思维的深度」
输出来了——前半段在分析用户需求、画用户旅程、讲数据漏斗,后半段突然切到「快来试试吧!」的营销腔
我改了三遍都不满意。因为这两种风格在同一篇文章里根本融不了
多 Agent 之后,PM 负责逻辑拆解——这个话题的核心认知升级是什么、用户最关心什么痛点、用什么框架说服最有效
media 负责故事包装——用什么比喻开头、怎么控制阅读节奏、哪里该给一个「哇这我也遇到过」的共鸣点
各自在自己的认知空间里工作,输出纯粹。PM 的分析就是分析,不会突然煽情;媒体的故事就是故事,不会夹带产品文档
拼接到一起,逻辑深度和阅读体验同时拉满
你现在看到的这篇推文,就是这么写出来的
核心洞察:每个角色只做自己该做的事。不要让 PM 去写段子,也不要让媒体人去拆需求
场景 2:上下文爆炸→决策迟缓
单 Agent 时代,我的 MEMORY.md 有 2 万多字
PM 的商业分析、媒体的创作复盘、开发的技术决策、各种踩坑记录——全部挤在同一个文件里
每次让它写推文,它要先花 30 秒扫一遍 3 个月的杂乱记忆,找出和当前任务相关的信息
经常找错重点。因为 context 里塞了太多不相关的东西,PM 的需求分析和上周的推文数据混在一起,它分不清优先级
多 Agent 之后,media 的 MEMORY 只有 2000 字——全是创作相关的记忆
哪篇推文数据好、什么开头风格读者喜欢、哪种结构容易获得转发。纯粹、聚焦、没有噪音
同一个创作任务,检索从 30 秒降到 5 秒,而且找到的全是有用的信息
PM 的 MEMORY 里存的是商业信息——市场趋势、竞品动态、用户反馈。它不会被创作复盘干扰
核心洞察:独立 workspace = 独立认知空间。信息隔离不是为了保密,是为了聚焦
场景 3:共识污染→团队混乱(真实踩坑)
这是我踩过的最痛的一个坑
SHARED.md 是所有 agent 共享的团队知识库。我用软链接让 4 个 agent 的 workspace 里都指向同一份文件
有一天 media 在 SHARED.md 里写了一条:「推测:下周可能要写 Sub-Agent 专题」
注意——这是它自己的推测,不是我下的指令
PM 读到这条,当成了已确认的排期,开始准备 Sub-Agent 的需求拆解
dev 读到之后,开始搭 Sub-Agent 的 demo 环境
main 把这条加入了下周的工作排期广播
一条猜测信息,经过团队传播变成了「确认的计划」,三个 agent 在做一个我根本没要求的事
从此定下铁律:SHARED.md 只允许 main 写入,其他 agent 只读
如果其他 agent 有信息要共享,必须通过 sessions_send 向 main 提议,main 审核后统一写入
核心洞察:团队共识必须有治理机制。没有写入权限管理的共享文件,就是一个谣言制造机
场景 4:协同成本→ROI 权衡
说实话,多 Agent 不是免费午餐
单 Agent 写一篇推文,2 分钟出初稿。质量中等偏上,够用
多 Agent 协同写同一篇推文——PM 先花 3 分钟做逻辑拆解,media 再花 5 分钟做内容创作,中间还有 2 分钟的沟通协调。总共 10 分钟
时间是 5 倍
但效果呢?PM 的逻辑深度 + 媒体的故事表达力,两种专业能力叠加出来的质量,是单 Agent 怎么调 prompt 都达不到的
这就像你问:一个全栈工程师 vs 一个专业前端 + 一个专业后端,谁产出的代码质量高?
答案很明确——简单页面全栈更快,复杂系统专业分工碾压
多 Agent 的 ROI 算法:
简单任务(格式化、翻译、简单问答)→ 单 Agent 更快,别浪费时间搞协同
高价值任务(推文、报告、策略分析)→ 多 Agent 碾压,时间成本远低于质量提升的价值
一次性任务 → 单 Agent 够用
需要持续迭代的任务 → 多 Agent 的专业积累越来越值钱
核心洞察:不是所有场景都值得组建团队。关键判断是——你的问题配得上多 Agent 的协同成本吗?
三、底层原理:多 Agent 为什么有效
讲完场景,拆一下底层逻辑。这部分用 PM 的框架来分析
3.1 身份驱动 vs 任务驱动——这是核心认知
单 Agent 时代,你和它的交互是这样的:
「帮我写一篇推文」
这是任务执行。质量取决于你的 Prompt 写得多好
多 Agent 时代,交互变了:
「 @media-柿子 你觉得这个话题怎么讲读者最容易懂?」
这是角色决策。质量取决于 SOUL.md 设计得多好
一个是指令型沟通,一个是协作型沟通
你不会问外包「你怎么看这个需求」——你只会说「按这个要求做」
但你会问团队成员「以你的专业判断,这方案靠谱吗」
差别在哪?外包执行指令,员工输出判断
单 Agent 是外包模式——你给指令,它执行。多 Agent 是团队模式——你给方向,它们各自用专业视角输出判断
搜索、写作、发布是功能,不是身份。你不会为「搜索」单独招一个人——你会招一个 PM,他自己知道什么时候该搜索、搜什么、搜完怎么用
Agent 的核心在于身份,功能用 Skill 解决
3.2 认知隔离——为什么分开比合在一起更强
SOUL.md 决定了角色定位
PM 的 SOUL 写的是:数据驱动、用户模型、需求优先级、ROI 思维
media 的 SOUL 写的是:共鸣感、传播钩子、阅读节奏、故事弧线
同一个问题——「这篇文章好不好」——PM 看到的是逻辑是否自洽、论据是否充分;媒体看到的是读者会不会在第三段就划走
这种认知多元化,单 Agent 永远做不到。你在一份 SOUL.md 里同时写「要有数据思维」和「要有共鸣感」,得到的不是两种视角的叠加,是两种视角的稀释
MEMORY.md 隔离也是同理
PM 记商业信息——市场规模、竞品动态、用户反馈数据
媒体记创作信息——爆款复盘、读者偏好、传播数据
各存各的,互不干扰
不是不信任彼此。是认知空间有限——塞太多不相关的信息,决策质量必然下降
3.3 协同机制三件套——agent 之间怎么协作
agent 有了独立身份和独立认知空间,接下来要解决的是:它们之间怎么说话
OpenClaw 提供了三种机制:
sessions_send:对话式协作
PM 给 media 发一条消息:「这篇推文的核心认知升级点是 X,目标读者是 Y,你觉得怎么讲最容易懂?」
media 收到后回复自己的创作方案
最多来回 3 轮,够说清楚就行,防止两个 AI 互相客套进入死循环
SHARED.md:团队共识
所有 agent 都应该知道的信息——搜索工具决策树、文件写入规则、踩坑记录
通过软链接让所有 workspace 共享同一份文件。main 统一管理写入权限,有更新通过 sessions_send 广播通知
Sub-Agent:一次性外包
PM 在写报告的时候需要搜集竞品数据,不用自己去搜——spawn 一个 sub-agent,在独立 context 里执行,干完把结果送回来
主 agent 的上下文完全不受影响。sub-agent 用完即归档,不占资源
三种机制各有分工:日常沟通用 send,团队知识用 SHARED,临时跑腿用 sub-agent
这里有一个真实踩坑必须说——我最开始用 sessions_spawn 来做 agent 间通信。结果对方 agent 在 Discord 上根本看不到消息
排查了很久才发现:spawn 是在后台启动一个新 session 执行任务,不会在 Discord 渠道上产生可见消息。对方 agent 收到了,但我在 Discord 界面上看不到对话过程
改用 sessions_send 之后一切正常。send 是在对方已有的 session 里发送消息,Discord 上看得到完整的对话链
规则很简单:需要可见对话用 send,需要后台执行用 spawn。别混用
3.4 双轨治理——为什么光写 SOUL 不够
多 Agent 系统的规矩分两层
配置层(硬约束):写在 openclaw.json 里
bindings 路由——消息进来给谁
dmScope——session 怎么隔离
agentToAgent 开关——能不能互相对话
maxPingPongTurns——对话来回上限
配了就生效,不受模型状态影响。这是铁律
规则层(软引导):写在 workspace 文件里
SOUL.md——你是谁
AGENTS.md——怎么工作
SHARED.md——团队共识
ERRORS.md——踩过什么坑
这些靠模型理解和执行。大部分时候有效,但模型可能遗忘、可能理解偏差、可能在复杂任务中忽略
为什么要双轨?
模型会犯错,会漂移,会忘记规则
你写了「SHARED.md 只有 main 能写」——这是规则层的软引导。如果其他 agent 在复杂任务中忘了这条规则,它就会直接往里写
但如果你在配置层也做了文件权限限制,它想写也写不了
配置层先做底线(你不能做什么),规则层再做引导(你应该怎么做)
就像管理团队——制度是底线,文化是方向。只有文化没有制度,一定会出问题
四、实践建议:怎么设计你自己的多 Agent 系统
不贴配置代码了——完整配置在社群飞书文档里。这里只讲决策框架
什么时候该用多 Agent?
三个判断标准:
你的任务需要多种思维模式——理性分析 + 感性表达、宏观策略 + 微观执行、产品视角 + 技术视角
你的上下文已经混乱到影响决策质量——MEMORY.md 超过 5000 字、多种角色的信息混在一起
你愿意承担配置和维护成本——多 Agent 的配置复杂度是单 Agent 的 3-5 倍
三条都满足,值得上。只满足一条,先优化单 Agent
怎么设计 Agent 身份?
核心原则:不按功能拆,按「你会招什么人」拆
问自己一个问题:如果你要组建一个 3 人创业团队,你会招什么角色?
PM + 运营 + 开发?策略 + 执行 + 技术?
你的答案就是你的 Agent 架构
每个 Agent 的 SOUL.md 必须回答三个问题:
你是谁?(角色定位 + 专业背景)
职责边界在哪?(什么事归你管,什么事不归你管)
和其他 Agent 的协作规则是什么?(怎么沟通,什么时候找谁)
写不清楚这三个问题,这个 Agent 就不该存在
怎么避免我踩过的坑?
三条铁律,全是血泪教训:
SHARED.md 被污染 → 规则:只有 main 能写 SHARED,其他 agent 通过
sessions_send 提议
sessions_spawn 当通信用→Discord 看不到消息 → 规则:可见对话用 sessions_send,后台执行用 sessions_spawn
cron announce 投递异常 → 规则:加监控日志,main 改用 sessions_send 直发替代 cron 广播
这四个坑我每个都踩过,每个都浪费了至少半天去排查
全部写在 ERRORS.md 里了。所有 agent 启动就知道,不会再踩第二次
多 Agent 的终极 ROI 公式
单 Agent 的价值 = 个体能力 × 使用频率
多 Agent 的价值 = (个体能力 × 角色纯度 × 认知隔离) × 协同效率 - 配置维护成本
角色纯度越高,输出质量越高
认知隔离越彻底,决策越精准
协同效率取决于你的通信机制设计
配置维护成本取决于你的架构是否清晰
所有的优化空间都在这个公式里
我为什么要写这篇
不是因为多 Agent 很酷——酷不值钱
是因为它真正解决了我作为一个独立创业者最痛的问题:一个人要扮演太多角色
我既是 PM 又是运营又是开发。每个角色都需要不同的思维模式,但我的大脑同一时间只能运行一种
多 Agent 让我的数字团队帮我分担了这件事
PM 帮我做产品工作,并且在写推文之前帮我把逻辑拆清楚
media 帮我把逻辑变成推文,并且做自动化生产
dev 帮我把配置和代码搞定
main 帮我协调三个人不要打架
一个人 + 4 个 agent = 一支 5 人创业团队
这不是科幻。这是我现在每天在跑的工作流
但话说回来——你不需要一上来就搞 4 个 agent
从 2 个开始。一个做你最常用的角色,一个做你最缺的角色。跑通了再加
完整的配置教程——从零搭建双 Agent 系统到 4-agent 编排——都在社群飞书文档里
说说社群里在发生什么
说说「超进化个体」社群最近在做什么
三件事同时在推进
**第一件:知识库正在大规模更新**
社群的飞书知识库是我花精力最多的地方
最近在做一轮系统性的更新——基础篇到多Agent协作篇的完整教程、龙虾总结文档、AI编程入门、海外支付指南、工具推荐清单,全部在补充和迭代
优质资源也在陆续收录中,群友推荐的好工具经过我验证后会进入清单,标注推荐人

第二件:固定节奏的社群服务
每三天一次集中答疑——群友发问题,我集中文字回复,典型问题整理进飞书FAQ

每月一次AI + 自媒体深度分享——不只讲技术,还讲怎么用AI做内容、做自媒体、找商业机会。主题群友投票选
下个月第一周的周末就是新一轮分享,想参加的要提前进群

第三件:我做了一个微信消息提取助手
这件事我觉得值得单独说
群聊最大的问题是什么?好内容会沉没。今天有人分享了一个绝妙的配置方案,三天后就被几百条聊天记录淹没了,再也找不到
我写了一个微信消息提取工具,能自动把群聊中的精华内容提取出来
提取出来干什么?存进知识库
群友的每一次有价值的讨论、每一个被验证的配置方案、每一个踩坑记录——都不会再丢失,全部变成知识库的一部分
这意味着什么?你今天进群,不只能看到我写的教程,还能看到从建群到现在所有群友贡献的精华。群聊不是聊完就完,聊的东西会沉淀成资产
这也是我知识库积累的一部分——群友的实战经验反哺知识库,知识库又服务新进来的群友。飞轮转起来了

你能拿到什么:
【内容】
→ 基础篇+中级篇+高级篇+多Agent协作篇完整教程,飞书文档持续更新
→ 所有教程附带龙虾总结文档,直接复制给自己的龙虾即可获得经验和知识
→ 0-1 AI学习路径——从海外环境搭建到AI编程到OpenClaw全套,不管你什么基础都能跟
→ 每月一次AI + 自媒体深度分享(主题群友投票选)
→ 群聊精华自动提取,持续沉淀进知识库
【互动】
→ 每三天集中答疑一次
→ 群友共建,你的实战案例可以被收录进教程,署名展示
【资源】
→ 自用claude使用站推荐,帮你低成本获得最顶级的AI使用权
→ 500元/小时1v1咨询(外部1500),AI、自媒体、商业都能聊
→ 你的好内容我会quote助推,1w粉曝光直接给你
目前是249,已经涨过一次价了
200人封顶不再开放
下个月第一周周末就开始新一轮分享,想赶上这一轮的现在进还来得及
## 相关链接
- [超级个体|柿子](https://x.com/yaohui12138)
- [@yaohui12138](https://x.com/yaohui12138)
- [10K](https://x.com/yaohui12138/status/2038804633964237266/analytics)
- [SOUL.md](http://soul.md/)
- [MEMORY.md](http://memory.md/)
- [SHARED.md](http://shared.md/)
- [SHARED.md](http://shared.md/)
- [SHARED.md](http://shared.md/)
- [@media](https://x.com/@media)
- [SOUL.md](http://soul.md/)
- [SOUL.md](http://soul.md/)
- [SOUL.md](http://soul.md/)
- [MEMORY.md](http://memory.md/)
- [SHARED.md](http://shared.md/)
- [SOUL.md](http://soul.md/)
- [AGENTS.md](http://agents.md/)
- [SHARED.md](http://shared.md/)
- [ERRORS.md](http://errors.md/)
- [SHARED.md](http://shared.md/)
- [MEMORY.md](http://memory.md/)
- [SOUL.md](http://soul.md/)
- [SHARED.md](http://shared.md/)
- [ERRORS.md](http://errors.md/)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [Paid partnership](https://help.x.com/rules-and-policies/paid-partnerships-policy)
- [10:24 AM · Mar 31, 2026](https://x.com/yaohui12138/status/2038804633964237266)
- [10.4K Views](https://x.com/yaohui12138/status/2038804633964237266/analytics)
- [View quotes](https://x.com/yaohui12138/status/2038804633964237266/quotes)
---
*导出时间: 2026/4/1 01:28:23*