OpenClaw多Agent架构教程：从瑞士军刀到专业团队

超级个体｜柿子 2026-04-01 24.0 KB 26.6K 𝕏 文章列表

文章深入探讨了OpenClaw框架下的多Agent协作模式。作者指出单Agent面临认知负荷瓶颈，难以同时承担理性分析与感性创作。核心论点在于“身份驱动”优于“功能驱动”，应按PM、媒体、工程等角色拆分Agent，而非按搜索、写作等功能拆解。文章详细介绍了多实例、多架构、Sub-Agent三种模式，并分享了4-Agent系统的实战设计原则、协同机制及治理避坑指南。

OpenClaw 多Agent 架构设计认知负荷 AI协作身份驱动 SOUL.md 技术教程超级个体团队协同

# OpenClaw教程-多agent架构篇 **作者**: 超级个体｜柿子 **日期**: 2026-03-31T02:24:38.000Z **来源**: [https://x.com/yaohui12138/status/2038804633964237266](https://x.com/yaohui12138/status/2038804633964237266) --- ![Image](/doc/129/image/img_1b3bcfccf8fe.jpg) 应广大粉丝朋友要求，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编程入门、海外支付指南、工具推荐清单，全部在补充和迭代优质资源也在陆续收录中，群友推荐的好工具经过我验证后会进入清单，标注推荐人 ![Image](/doc/129/image/img_637119b8b5b1.jpg) 第二件：固定节奏的社群服务每三天一次集中答疑——群友发问题，我集中文字回复，典型问题整理进飞书FAQ ![Image](/doc/129/image/img_895bf98fc1ec.jpg) 每月一次AI + 自媒体深度分享——不只讲技术，还讲怎么用AI做内容、做自媒体、找商业机会。主题群友投票选下个月第一周的周末就是新一轮分享，想参加的要提前进群 ![Image](/doc/129/image/img_52dfc9a7c627.jpg) 第三件：我做了一个微信消息提取助手这件事我觉得值得单独说群聊最大的问题是什么？好内容会沉没。今天有人分享了一个绝妙的配置方案，三天后就被几百条聊天记录淹没了，再也找不到我写了一个微信消息提取工具，能自动把群聊中的精华内容提取出来提取出来干什么？存进知识库群友的每一次有价值的讨论、每一个被验证的配置方案、每一个踩坑记录——都不会再丢失，全部变成知识库的一部分这意味着什么？你今天进群，不只能看到我写的教程，还能看到从建群到现在所有群友贡献的精华。群聊不是聊完就完，聊的东西会沉淀成资产这也是我知识库积累的一部分——群友的实战经验反哺知识库，知识库又服务新进来的群友。飞轮转起来了 ![Image](/doc/129/image/img_9f94921d0715.jpg) 你能拿到什么：【内容】 → 基础篇+中级篇+高级篇+多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*