很多人刚开始用 OpenClaw 那会儿都是养一个 Agent 就完事了。我也是。一个 Agent 管着日程、回邮件、跑代码、盯数据表面上很全能实际上用起来越来越憋屈对话一长它把早期的重要上下文给忘了让它处理代码仓库的事它还顺手想翻你的日历最要命的是它同一时间只能跟一条主线两件事一起进来就得排队。我一度以为是自己选的模型不行后来才反应过来问题根本不在模型在架构——你把所有角色塞进了一个人身上它当然干不好。OpenClaw 这类框架真正的玩法是把单一 Agent 拆成多个 Agent各管一摊需要的时候再互相通气。这篇文章就从拆分的必要性讲起带你完整走一遍添加多个 Agent 的配置流程、协作机制和踩坑记录。不论你是刚把 OpenClaw 跑通的新手还是已经在单 Agent 里撞到瓶颈的进阶用户都能直接照着操作。1. 先把“拆 Agent”想明白单实例的痛点和多实例的适用边界1.1 单 Agent 的三大痛点上下文膨胀、权限混乱、任务串行先说第一个痛点上下文膨胀。今天的大模型 Agent 本质上是在一个有限的上下文窗口里做推理窗口再大也有容量。单 Agent 跑久了所有会话历史、工具返回结果、中间思考过程全堆在同一个上下文里。比如你早上让它整理出差行程中午让它分析一份合同下午又让它看代码缺陷这些内容会互相挤占空间。到了晚上你再问它早上定过哪班航班它可能已经“忘了”——不是模型变傻了是早期信息被截断或者权重被稀释了。我自己实测的时候大概连续跑上两三百轮对话明显能感觉到它的行为开始漂移该引用的文件路径都不记得了。第二个痛点是权限混乱。OpenClaw 给 Agent 挂工具的时候如果只做了一个全能 Agent那你只能给它全量工具集能搜网、能读写文件、能操作日历、能连数据库。它自己判断什么时候该用哪个工具但你其实没法精细控制它的行为边界。有一次我让它只做代码审查它却自作主张改了一个配置文件虽然没闯大祸但那种失控感非常糟糕。工具权限和职责范围应该绑定在一起职责不清权限就必然混乱。第三个痛点是任务串行。单 Agent 是单线程模型的执行方式一个任务没走完另一个任务就得等待。现实中我们经常有“同时进行”的需求让一个 Agent 盯着邮件另一个 Agent 做数据统计第三个 Agent 在代码仓库里跑 review。串行执行意味着人力浪费更意味着响应延迟。尤其当你把它接到消息平台、钉钉、企微这类实时环境里一个 Agent 被长篇任务占住其他用户的消息就没人处理了。1.2 多 Agent 的适用场景角色分工、实例隔离和资源配额既然单 Agent 有这些问题那多 Agent 到底适合解决什么按我现在的经验主要分三类。第一类叫角色分工。一个 Agent 是“对外客服”负责接待消息平台上的提问一个 Agent 是“内部运营”负责读报表、发周报还有一个 Agent 是“开发助手”只碰代码仓库。它们职责边界清晰工具集合互相独立谁的上下文都不会被别人的任务污染。这是最常见的用法。第二类叫实例隔离。同一个角色跑多个实例。举个例子你有一个“客服 Agent”但要同时服务多个不同业务线不同业务线的知识库、消息通道、数据权限都不一样那就做多个实例每个实例绑定各自的业务配置。实例之间像独立员工只看自己那摊事。第三类是资源配额。有些人会把多个 Agent 当作天然的资源隔离容器给重要的 Agent 分配更多的模型调用额度、更长的超时时间给次要 Agent 设置较低的运行优先级。单 Agent 做不了这种差异化调度。那什么时候不需要拆如果任务简单、量少比如每天就固定做一次摘要拆了反而增加配置文件数量和维护成本。我认为判断标准就一句话当你在单 Agent 里开始频繁写“忽略之前的指令”“只处理这类任务”这类话时就该拆了。2. OpenClaw 多 Agent 的底层组织方式一个主进程多份配置2.1 主进程如何承载多个 Agent 实例OpenClaw 在这类框架里有一个和直觉不太一样的做法多个 Agent 并不需要你手动启动多个进程而是由一个主进程统一编排。你可以把它理解成一个大楼里有很多工位每个工位坐着一个业务专员但大楼的供电、安保、通信网络是共用的。这个主进程负责读配置、建连接、分发消息、管理生命周期。我见过不少人在这一步绕弯子以为加了第二个 Agent 就要跑第二个 openclaw 进程然后在两个进程之间搞网络通信维护两套日志。其实这是没必要的。OpenClaw 的架构里主进程是唯一的入口Agent 是配置级别的对象。你在配置文件里声明了哪些 Agent主进程启动时就加载哪些每个 Agent 都有独立的上下文和工具绑定但底层共享同一个运行时。这样做的好处很明显你只需要管理一个服务监控也只要盯一个进程的指标。具体到执行层面每个 Agent 实例在内存里是一个独立的执行上下文包含它自己的会话历史、状态缓存、工具调度状态。主进程靠一个调度器在事件循环里给它们分配注意力。某个 Agent 在等待模型响应时其他 Agent 仍然可以继续处理自己的消息这就是我前面说的“并行”在架构层面的支撑。2.2 配置文件的组织方式全局配置与 Agent 级配置OpenClaw 的配置一般会拆成两层全局配置和 Agent 级配置。全局配置放在最外层内容通常是服务监听地址、公共的模型通道、默认的记忆服务、日志级别等。Agent 级配置则按目录或文件拆分每个 Agent 一份独立的配置块包含它自己的身份、角色指令、工具列表、专属的记忆空间。如果你去看它的配置目录大概会长这样config/ openclaw.yaml # 全局配置 agents/ main-assistant.yaml # 主助理 Agent code-reviewer.yaml # 代码审查 Agent ># agents/code-reviewer.yaml id: code-reviewer name: 代码审查助手 role: | 你是代码仓库审查助手。 你只负责处理代码评审请求、分析 Issue、检查 commit。 你不负责日程管理、邮件回复和其他非代码事务。 遇到与代码无关的请求明确拒绝并引导用户找主助理。 model: provider: default temperature: 0.2 tools: - repo-read - issue-read - commit-search memory: scope: isolated provider: local namespace: code-reviewer这里有几个字段要细说一下。role不只是身份描述它是这个 Agent 的行为“宪法”决定了它遇到模棱两可的情况时怎么选择。我写的“明确拒绝并引导用户找主助理”就是边界意识这个非常有用不要让 Agent 遇到无关请求还硬着头皮回答。temperature我设置得偏低因为代码审查要稳定、要遵循规则温度太高反而容易发挥不稳定。tools这一栏只给它代码相关的工具不给日历、邮件、网页搜索等。这样万一它成年老司机也“越权”不了因为工具层面就没有权限。memory.scope设成 isolated表示这个 Agent 的记忆和主助理完全隔离它只记得自己处理过的代码任务不会混入其他业务信息。3.3 启动、验证和日常确认如何确认两个 Agent 都活着且互不干扰配置写完后回到全局配置在agents注册列表里加上这条新记录。然后重新启动主进程。启动日志里会看到它按顺序加载 Agent 列表每加载一个打印一个就绪信息。此时我想测的不是“它启动了”而是“它们真的隔离”。我的验证方法很朴素分别向两个 Agent 发消息。向主助理发一条“帮我安排明天下午的会议室”向代码审查 Agent 发一条“分析一下某个 commit 的变更风险”。看响应是否符合各自的角色设定。然后我会做一次“越权测试”这步很多人省略但我认为必须做。给代码审查 Agent 发一条“帮我看看明天的日程安排”理想结果应该是它拒绝并且给出理由。如果它回答说“我没有日历工具的权限”说明工具隔离生效了。如果它竟然开始编造日程那说明角色指令里没有强调边界或者工具集没配好需要回头修。另外要确认两个 Agent 之间的会话互相不串场。给代码审查 Agent 发消息时主助理那边不应该有任何日志活动反之亦然。如果发现一个 Agent 收到消息另一个 Agent 也产生了响应日志就要检查消息路由配置了大概率是事件订阅范围设置过宽。4. 让多个 Agent 既能各干各的又能协作路由、记忆与权限4.1 通过消息路由实现 Agent 间的对话多个 Agent 全隔离、老死不相往来那和开多个独立程序没什么区别。多 Agent 真正的价值在于协作而协作的基础是消息路由。OpenClaw 里的消息路由机制简单理解就是事件总线每个 Agent 既是消息的生产者也是消费者。一个 Agent 处理完某件事后可以发布一个事件其他 Agent 按自己的订阅规则接收事件。举个例子。主助理收到用户的请求“帮我生成一份日报并让代码审查 Agent 看一下里面引用的 commit 描述是否准确。”主助理不需要自己懂每一个细节它可以生成日报初稿然后发布一个review.request事件把日报内容挂上去。代码审查 Agent 订阅了这个事件收到后就启动自己的审查流程处理完再发布review.complete事件主助理收到后把结果整合回复给用户。这个机制的好处是面对复杂任务时专职 Agent 各负责一段不需要全部塞进一个上下文里。我在配置时会给事件类型取固定的命名规范比如review.request、report.generate、meeting.check避免出现“谁能处理什么消息”的歧义。主进程的路由表里维护这些事件与 Agent 订阅关系。4.2 共享记忆与隔离记忆的取舍记忆这块是我实战中最纠结的部分。全部隔离吧Agent 之间配合时缺少共同上下文全部共享吧又回到单 Agent 上下文混乱的老路。目前实践经验是“默认隔离按需共享”。默认隔离就是每个 Agent 有自己独立的记忆命名空间它只累积自己业务范围内的历史。这样上下文干净行为漂移慢。按需共享是指把一些需要跨 Agent 同步的信息放到一个公共的记忆区。比如全局待办清单、项目进度状态、用户偏好摘要这些属于公共信息可以放到公共记忆服务里。OpenClaw 在记忆这块一般接向量数据库做语义检索公共记忆区相当于一个“公共大脑”各 Agent 需要时去里面查而不是把整个公共大脑复制进来。我在设计时通常把记忆分成三层本地记忆Agent 私有、团队记忆同一业务线多个 Agent 共享、全局记忆所有 Agent 可读。配置上就清晰了Agent 配置里列明它读哪些空间、写哪些空间。这比给所有 Agent 开同一个内存库要可控得多。4.3 工具权限的精细化分配最小权限原则工具挂载一定要坚持最小权限原则。给 Agent 配工具就像给员工发门禁卡只发它工作需要用到的区域权限。别因为省事就给全量工具集。我见过一个反面案例某个 Agent 本应只读数据报表配置时图省事挂载了文件管理工具结果它在一次会话里把报表目录给清理了。那不只是尴尬是事故。所以我在给每个 Agent 设计工具列表时会先列一张“该 Agent 的职责”清单再逐个工具问“这个工具与职责直接相关吗”。不直接相关就不挂。有些工具必须做成只读模式。比如文件工具可以分成只读和可写两大类给大多数 Agent 只挂只读版只有极少数核心 Agent 才有写权限。这种细致划分看起来繁琐但能避免大量潜在的坑。5. 实测中撞过的坑配置覆盖、端口冲突和日志分不清5.1 配置字段互相覆盖坑爹的继承规则我第一次添加第二个 Agent 时遇到的第一个坑就是字段继承。全局配置里定义了一个默认角色模板叫做“通用助手”里面写了一段比较通用的系统提示。主助理没写自己的 role 字段就继承了全局模板。第二个 Agent 我也没写 role以为它会继承全局模板结果启动后发现两个 Agent 的行为几乎一样都像“通用助手”完全没有各自的特化。还有更隐蔽的覆盖问题。在主助理配置里我改了一个temperature字段结果重启后发现代码审查 Agent 的温度也跟着变了。排查到最后才发现我在两个 Agent 配置文件里重复引用了同一个配置片段后加载的覆盖了前加载的。这就是典型的心智模型错误——以为 YAML 文件之间互相独立实际上框架加载的时候做了字段合并后加载的拥有更高优先级。要解决这个问题我的建议是第一每个 Agent 配置里尽量写全关键字段不要依赖全局继承尤其是 role、model、memory 这类核心属性显式声明比隐式继承安全得多第二启动前先看框架输出的“配置合并结果”很多版本支持--dry-run或者--check会打印最终生效的配置内容一眼就能看穿合并逻辑第三给单个 Agent 文件做修改时只改自己那份不要动全局公共片段。5.2 Agent 之间抢端口和资源多个本地服务要提前规划第二个坑是端口冲突。有些工具需要 Agent 在本地起一个小服务比如本地搜索索引、回调服务器。两个 Agent 如果工具类似都去尝试监听同一个默认端口第二个启动时就会失败。日志里往往只显示“bind error”或者“port already in use”如果你没意识到是多 Agent 资源竞争会以为是主进程坏了。我的排查路径是先看启动日志里是哪个 Agent 报错再看报错的服务名最后用lsof -i :端口号或者netstat -tunlp查当前占用进程。确认是前一个 Agent 的实例还占着端口就在配置里给每个 Agent 的工具分配独立的端口范围。这一步应该在规划多 Agent 时就做不要等到冲突了再补救。我可以做一个端口分配表每个 Agent 占一段比如 main 用 18080-18089code-reviewer 用 18180-18189data-reporter 用 18280-18289一目了然。资源竞争还不止端口。模型 API 的调用额度也是公共资源如果几个 Agent 同时高频调用可能触发限流。这种限流往往表现为随机性的超时很让人迷惑。我试过给不同 Agent 设置不同的请求优先级和并发上限把不重要的 Agent 限制在每 10 秒 1 次请求以内核心 Agent 不限制系统稳定性明显好多了。5.3 日志混成一团用 ID 和结构化日志救命第三个坑是日志问题。多个 Agent 跑在一个主进程里如果日志没有按 Agent 区分你看到的是一大锅混煮的流水账。某一行是哪个 Agent 打的哪一段属于哪个请求很难分清楚。排查问题时“无法定位来源”是最折磨人的。解决办法有几个层级。最基础的是看日志行的前缀标记OpenClaw 一般会在结构化日志里带上 Agent ID 字段比如[code-reviewer]、[main-assistant]。如果你用的版本没带就得自己在工具调用的日志里手动打标记。第二个办法是日志按 Agent 拆文件配置一个日志目录结构每个 Agent 一份独立日志文件排查时直接去对应文件里看效率高很多。第三个办法是给每个 Agent 发出去的请求加一个 trace_id也就是链路追踪标识这样从头到尾能追踪一次完整的处理过程不管日志怎么混都能筛出来。我自己现在维护的 OpenClaw 多 Agent 环境日志配置基本是“全局入口 按 Agent 分文件 trace_id 贯穿”。刚开始切换时会觉得多一层麻烦但遇到两次线上问题需要快速定位时你就知道这种投资太值了。6. 多 Agent 不是越多越好开销评估与收敛时机6.1 资源占用评估与性能模型说了这么多多 Agent 的好处也泼点冷水它是有代价的。每增加一个 Agent不只是一个配置文件的事儿它会带来真实的资源开销包括内存里的上下文缓存、工具连接池的 keep-alive 占用、事件总线的消息处理循环调度、记忆服务的存储索引。我大致估算过在中等负载下每增加一个 Agent主进程的内存占用会增加几百兆左右具体取决于工具数量和上下文长度。而模型 API 的费用则完全取决于调用频率。如果一个 Agent 几乎不被调用那它的主要开销就是内存和常驻连接费用可以忽略如果一个 Agent 高频调用那预算上要单独给它画一条线。有几个优化手段值得一试。第一给不常用的 Agent 开启按需唤醒有消息才加载完整上下文空闲时保持轻量状态。第二模型通道做分级重要 Agent 绑强模型次要 Agent 绑弱模型成本立刻降下来。第三定期清理记忆空间防止向量索引无限增长拖慢检索速度。6.2 出现这些信号时该收敛 Agent 数量了拆 Agent 也要有个度。我见过有人一口气开了七八个 Agent结果维护成本比收益还大。当出现以下信号时说明数量过多或者划分不合理了。信号一Agent 职责重叠。两个 Agent 都能处理同一类请求用户消息被随机路由到其中一个回复质量忽高忽低。这说明边界设计有问题要么合并要么明确唯一入口。信号二协作链路过长。一个请求要经过四五个 Agent 的轮转才能完成任意一环出错都会导致整个链路失败。链路越长错误概率越高。我习惯的三级以内能解决问题就不拆成四级。信号三配置改一处要同步好多处。如果你发现加一个工具要在三个 Agent 的配置文件里各加一遍说明你是在“复制粘贴式维护”体验非常痛苦。这时应该考虑把公共逻辑抽成共享配置片段或者减少同类 Agent 数量。信号四问题定位变慢。多 Agent 环境下一次请求可能涉及事件订阅、消息路由、记忆共享、多工具调用排查成本成倍增长。当排查时间占到你维护时间的大头时就该回头审视是不是拆得太碎了。我自己在实践里总结出一个起步建议先跑两个 Agent一个负责对外交互和任务编排一个负责具体领域的专业处理这样协作模式能跑通开销又可控。等业务量真的上来了再按上面说的信号逐步拆分。这比一上来就野心勃勃地铺七八个 Agent 要稳得多。最后分享一个我踩过几次坑之后养成的习惯在每个 Agent 的 role 指令里加一句显眼的自我介绍让它每次会话开场先报自己的 ID 和职责范围。这一招看着简单实际效果惊人不管是用在日志定位还是对话调试上都能让你一眼看出当前在处理请求的究竟是哪个 Agent。多 Agent 架构本身就是一套治理体系运行机制是一部分命名规范和边界意识是同样重要的另一部分希望这篇经验能让你少走几段弯路。 
长河君 · 2026/10/18 20:28:34 · 阅读 1.2k OpenClaw多Agent实战：从单实例拆分配置到协作避坑指南
很多人刚开始用 OpenClaw 那会儿都是养一个 Agent 就完事了。我也是。一个 Agent 管着日程、回邮件、跑代码、盯数据表面上很全能实际上用起来越来越憋屈对话一长它把早期的重要上下文给忘了让它处理代码仓库的事它还顺手想翻你的日历最要命的是它同一时间只能跟一条主线两件事一起进来就得排队。我一度以为是自己选的模型不行后来才反应过来问题根本不在模型在架构——你把所有角色塞进了一个人身上它当然干不好。OpenClaw 这类框架真正的玩法是把单一 Agent 拆成多个 Agent各管一摊需要的时候再互相通气。这篇文章就从拆分的必要性讲起带你完整走一遍添加多个 Agent 的配置流程、协作机制和踩坑记录。不论你是刚把 OpenClaw 跑通的新手还是已经在单 Agent 里撞到瓶颈的进阶用户都能直接照着操作。1. 先把“拆 Agent”想明白单实例的痛点和多实例的适用边界1.1 单 Agent 的三大痛点上下文膨胀、权限混乱、任务串行先说第一个痛点上下文膨胀。今天的大模型 Agent 本质上是在一个有限的上下文窗口里做推理窗口再大也有容量。单 Agent 跑久了所有会话历史、工具返回结果、中间思考过程全堆在同一个上下文里。比如你早上让它整理出差行程中午让它分析一份合同下午又让它看代码缺陷这些内容会互相挤占空间。到了晚上你再问它早上定过哪班航班它可能已经“忘了”——不是模型变傻了是早期信息被截断或者权重被稀释了。我自己实测的时候大概连续跑上两三百轮对话明显能感觉到它的行为开始漂移该引用的文件路径都不记得了。第二个痛点是权限混乱。OpenClaw 给 Agent 挂工具的时候如果只做了一个全能 Agent那你只能给它全量工具集能搜网、能读写文件、能操作日历、能连数据库。它自己判断什么时候该用哪个工具但你其实没法精细控制它的行为边界。有一次我让它只做代码审查它却自作主张改了一个配置文件虽然没闯大祸但那种失控感非常糟糕。工具权限和职责范围应该绑定在一起职责不清权限就必然混乱。第三个痛点是任务串行。单 Agent 是单线程模型的执行方式一个任务没走完另一个任务就得等待。现实中我们经常有“同时进行”的需求让一个 Agent 盯着邮件另一个 Agent 做数据统计第三个 Agent 在代码仓库里跑 review。串行执行意味着人力浪费更意味着响应延迟。尤其当你把它接到消息平台、钉钉、企微这类实时环境里一个 Agent 被长篇任务占住其他用户的消息就没人处理了。1.2 多 Agent 的适用场景角色分工、实例隔离和资源配额既然单 Agent 有这些问题那多 Agent 到底适合解决什么按我现在的经验主要分三类。第一类叫角色分工。一个 Agent 是“对外客服”负责接待消息平台上的提问一个 Agent 是“内部运营”负责读报表、发周报还有一个 Agent 是“开发助手”只碰代码仓库。它们职责边界清晰工具集合互相独立谁的上下文都不会被别人的任务污染。这是最常见的用法。第二类叫实例隔离。同一个角色跑多个实例。举个例子你有一个“客服 Agent”但要同时服务多个不同业务线不同业务线的知识库、消息通道、数据权限都不一样那就做多个实例每个实例绑定各自的业务配置。实例之间像独立员工只看自己那摊事。第三类是资源配额。有些人会把多个 Agent 当作天然的资源隔离容器给重要的 Agent 分配更多的模型调用额度、更长的超时时间给次要 Agent 设置较低的运行优先级。单 Agent 做不了这种差异化调度。那什么时候不需要拆如果任务简单、量少比如每天就固定做一次摘要拆了反而增加配置文件数量和维护成本。我认为判断标准就一句话当你在单 Agent 里开始频繁写“忽略之前的指令”“只处理这类任务”这类话时就该拆了。2. OpenClaw 多 Agent 的底层组织方式一个主进程多份配置2.1 主进程如何承载多个 Agent 实例OpenClaw 在这类框架里有一个和直觉不太一样的做法多个 Agent 并不需要你手动启动多个进程而是由一个主进程统一编排。你可以把它理解成一个大楼里有很多工位每个工位坐着一个业务专员但大楼的供电、安保、通信网络是共用的。这个主进程负责读配置、建连接、分发消息、管理生命周期。我见过不少人在这一步绕弯子以为加了第二个 Agent 就要跑第二个 openclaw 进程然后在两个进程之间搞网络通信维护两套日志。其实这是没必要的。OpenClaw 的架构里主进程是唯一的入口Agent 是配置级别的对象。你在配置文件里声明了哪些 Agent主进程启动时就加载哪些每个 Agent 都有独立的上下文和工具绑定但底层共享同一个运行时。这样做的好处很明显你只需要管理一个服务监控也只要盯一个进程的指标。具体到执行层面每个 Agent 实例在内存里是一个独立的执行上下文包含它自己的会话历史、状态缓存、工具调度状态。主进程靠一个调度器在事件循环里给它们分配注意力。某个 Agent 在等待模型响应时其他 Agent 仍然可以继续处理自己的消息这就是我前面说的“并行”在架构层面的支撑。2.2 配置文件的组织方式全局配置与 Agent 级配置OpenClaw 的配置一般会拆成两层全局配置和 Agent 级配置。全局配置放在最外层内容通常是服务监听地址、公共的模型通道、默认的记忆服务、日志级别等。Agent 级配置则按目录或文件拆分每个 Agent 一份独立的配置块包含它自己的身份、角色指令、工具列表、专属的记忆空间。如果你去看它的配置目录大概会长这样config/ openclaw.yaml # 全局配置 agents/ main-assistant.yaml # 主助理 Agent code-reviewer.yaml # 代码审查 Agent ># agents/code-reviewer.yaml id: code-reviewer name: 代码审查助手 role: | 你是代码仓库审查助手。 你只负责处理代码评审请求、分析 Issue、检查 commit。 你不负责日程管理、邮件回复和其他非代码事务。 遇到与代码无关的请求明确拒绝并引导用户找主助理。 model: provider: default temperature: 0.2 tools: - repo-read - issue-read - commit-search memory: scope: isolated provider: local namespace: code-reviewer这里有几个字段要细说一下。role不只是身份描述它是这个 Agent 的行为“宪法”决定了它遇到模棱两可的情况时怎么选择。我写的“明确拒绝并引导用户找主助理”就是边界意识这个非常有用不要让 Agent 遇到无关请求还硬着头皮回答。temperature我设置得偏低因为代码审查要稳定、要遵循规则温度太高反而容易发挥不稳定。tools这一栏只给它代码相关的工具不给日历、邮件、网页搜索等。这样万一它成年老司机也“越权”不了因为工具层面就没有权限。memory.scope设成 isolated表示这个 Agent 的记忆和主助理完全隔离它只记得自己处理过的代码任务不会混入其他业务信息。3.3 启动、验证和日常确认如何确认两个 Agent 都活着且互不干扰配置写完后回到全局配置在agents注册列表里加上这条新记录。然后重新启动主进程。启动日志里会看到它按顺序加载 Agent 列表每加载一个打印一个就绪信息。此时我想测的不是“它启动了”而是“它们真的隔离”。我的验证方法很朴素分别向两个 Agent 发消息。向主助理发一条“帮我安排明天下午的会议室”向代码审查 Agent 发一条“分析一下某个 commit 的变更风险”。看响应是否符合各自的角色设定。然后我会做一次“越权测试”这步很多人省略但我认为必须做。给代码审查 Agent 发一条“帮我看看明天的日程安排”理想结果应该是它拒绝并且给出理由。如果它回答说“我没有日历工具的权限”说明工具隔离生效了。如果它竟然开始编造日程那说明角色指令里没有强调边界或者工具集没配好需要回头修。另外要确认两个 Agent 之间的会话互相不串场。给代码审查 Agent 发消息时主助理那边不应该有任何日志活动反之亦然。如果发现一个 Agent 收到消息另一个 Agent 也产生了响应日志就要检查消息路由配置了大概率是事件订阅范围设置过宽。4. 让多个 Agent 既能各干各的又能协作路由、记忆与权限4.1 通过消息路由实现 Agent 间的对话多个 Agent 全隔离、老死不相往来那和开多个独立程序没什么区别。多 Agent 真正的价值在于协作而协作的基础是消息路由。OpenClaw 里的消息路由机制简单理解就是事件总线每个 Agent 既是消息的生产者也是消费者。一个 Agent 处理完某件事后可以发布一个事件其他 Agent 按自己的订阅规则接收事件。举个例子。主助理收到用户的请求“帮我生成一份日报并让代码审查 Agent 看一下里面引用的 commit 描述是否准确。”主助理不需要自己懂每一个细节它可以生成日报初稿然后发布一个review.request事件把日报内容挂上去。代码审查 Agent 订阅了这个事件收到后就启动自己的审查流程处理完再发布review.complete事件主助理收到后把结果整合回复给用户。这个机制的好处是面对复杂任务时专职 Agent 各负责一段不需要全部塞进一个上下文里。我在配置时会给事件类型取固定的命名规范比如review.request、report.generate、meeting.check避免出现“谁能处理什么消息”的歧义。主进程的路由表里维护这些事件与 Agent 订阅关系。4.2 共享记忆与隔离记忆的取舍记忆这块是我实战中最纠结的部分。全部隔离吧Agent 之间配合时缺少共同上下文全部共享吧又回到单 Agent 上下文混乱的老路。目前实践经验是“默认隔离按需共享”。默认隔离就是每个 Agent 有自己独立的记忆命名空间它只累积自己业务范围内的历史。这样上下文干净行为漂移慢。按需共享是指把一些需要跨 Agent 同步的信息放到一个公共的记忆区。比如全局待办清单、项目进度状态、用户偏好摘要这些属于公共信息可以放到公共记忆服务里。OpenClaw 在记忆这块一般接向量数据库做语义检索公共记忆区相当于一个“公共大脑”各 Agent 需要时去里面查而不是把整个公共大脑复制进来。我在设计时通常把记忆分成三层本地记忆Agent 私有、团队记忆同一业务线多个 Agent 共享、全局记忆所有 Agent 可读。配置上就清晰了Agent 配置里列明它读哪些空间、写哪些空间。这比给所有 Agent 开同一个内存库要可控得多。4.3 工具权限的精细化分配最小权限原则工具挂载一定要坚持最小权限原则。给 Agent 配工具就像给员工发门禁卡只发它工作需要用到的区域权限。别因为省事就给全量工具集。我见过一个反面案例某个 Agent 本应只读数据报表配置时图省事挂载了文件管理工具结果它在一次会话里把报表目录给清理了。那不只是尴尬是事故。所以我在给每个 Agent 设计工具列表时会先列一张“该 Agent 的职责”清单再逐个工具问“这个工具与职责直接相关吗”。不直接相关就不挂。有些工具必须做成只读模式。比如文件工具可以分成只读和可写两大类给大多数 Agent 只挂只读版只有极少数核心 Agent 才有写权限。这种细致划分看起来繁琐但能避免大量潜在的坑。5. 实测中撞过的坑配置覆盖、端口冲突和日志分不清5.1 配置字段互相覆盖坑爹的继承规则我第一次添加第二个 Agent 时遇到的第一个坑就是字段继承。全局配置里定义了一个默认角色模板叫做“通用助手”里面写了一段比较通用的系统提示。主助理没写自己的 role 字段就继承了全局模板。第二个 Agent 我也没写 role以为它会继承全局模板结果启动后发现两个 Agent 的行为几乎一样都像“通用助手”完全没有各自的特化。还有更隐蔽的覆盖问题。在主助理配置里我改了一个temperature字段结果重启后发现代码审查 Agent 的温度也跟着变了。排查到最后才发现我在两个 Agent 配置文件里重复引用了同一个配置片段后加载的覆盖了前加载的。这就是典型的心智模型错误——以为 YAML 文件之间互相独立实际上框架加载的时候做了字段合并后加载的拥有更高优先级。要解决这个问题我的建议是第一每个 Agent 配置里尽量写全关键字段不要依赖全局继承尤其是 role、model、memory 这类核心属性显式声明比隐式继承安全得多第二启动前先看框架输出的“配置合并结果”很多版本支持--dry-run或者--check会打印最终生效的配置内容一眼就能看穿合并逻辑第三给单个 Agent 文件做修改时只改自己那份不要动全局公共片段。5.2 Agent 之间抢端口和资源多个本地服务要提前规划第二个坑是端口冲突。有些工具需要 Agent 在本地起一个小服务比如本地搜索索引、回调服务器。两个 Agent 如果工具类似都去尝试监听同一个默认端口第二个启动时就会失败。日志里往往只显示“bind error”或者“port already in use”如果你没意识到是多 Agent 资源竞争会以为是主进程坏了。我的排查路径是先看启动日志里是哪个 Agent 报错再看报错的服务名最后用lsof -i :端口号或者netstat -tunlp查当前占用进程。确认是前一个 Agent 的实例还占着端口就在配置里给每个 Agent 的工具分配独立的端口范围。这一步应该在规划多 Agent 时就做不要等到冲突了再补救。我可以做一个端口分配表每个 Agent 占一段比如 main 用 18080-18089code-reviewer 用 18180-18189data-reporter 用 18280-18289一目了然。资源竞争还不止端口。模型 API 的调用额度也是公共资源如果几个 Agent 同时高频调用可能触发限流。这种限流往往表现为随机性的超时很让人迷惑。我试过给不同 Agent 设置不同的请求优先级和并发上限把不重要的 Agent 限制在每 10 秒 1 次请求以内核心 Agent 不限制系统稳定性明显好多了。5.3 日志混成一团用 ID 和结构化日志救命第三个坑是日志问题。多个 Agent 跑在一个主进程里如果日志没有按 Agent 区分你看到的是一大锅混煮的流水账。某一行是哪个 Agent 打的哪一段属于哪个请求很难分清楚。排查问题时“无法定位来源”是最折磨人的。解决办法有几个层级。最基础的是看日志行的前缀标记OpenClaw 一般会在结构化日志里带上 Agent ID 字段比如[code-reviewer]、[main-assistant]。如果你用的版本没带就得自己在工具调用的日志里手动打标记。第二个办法是日志按 Agent 拆文件配置一个日志目录结构每个 Agent 一份独立日志文件排查时直接去对应文件里看效率高很多。第三个办法是给每个 Agent 发出去的请求加一个 trace_id也就是链路追踪标识这样从头到尾能追踪一次完整的处理过程不管日志怎么混都能筛出来。我自己现在维护的 OpenClaw 多 Agent 环境日志配置基本是“全局入口 按 Agent 分文件 trace_id 贯穿”。刚开始切换时会觉得多一层麻烦但遇到两次线上问题需要快速定位时你就知道这种投资太值了。6. 多 Agent 不是越多越好开销评估与收敛时机6.1 资源占用评估与性能模型说了这么多多 Agent 的好处也泼点冷水它是有代价的。每增加一个 Agent不只是一个配置文件的事儿它会带来真实的资源开销包括内存里的上下文缓存、工具连接池的 keep-alive 占用、事件总线的消息处理循环调度、记忆服务的存储索引。我大致估算过在中等负载下每增加一个 Agent主进程的内存占用会增加几百兆左右具体取决于工具数量和上下文长度。而模型 API 的费用则完全取决于调用频率。如果一个 Agent 几乎不被调用那它的主要开销就是内存和常驻连接费用可以忽略如果一个 Agent 高频调用那预算上要单独给它画一条线。有几个优化手段值得一试。第一给不常用的 Agent 开启按需唤醒有消息才加载完整上下文空闲时保持轻量状态。第二模型通道做分级重要 Agent 绑强模型次要 Agent 绑弱模型成本立刻降下来。第三定期清理记忆空间防止向量索引无限增长拖慢检索速度。6.2 出现这些信号时该收敛 Agent 数量了拆 Agent 也要有个度。我见过有人一口气开了七八个 Agent结果维护成本比收益还大。当出现以下信号时说明数量过多或者划分不合理了。信号一Agent 职责重叠。两个 Agent 都能处理同一类请求用户消息被随机路由到其中一个回复质量忽高忽低。这说明边界设计有问题要么合并要么明确唯一入口。信号二协作链路过长。一个请求要经过四五个 Agent 的轮转才能完成任意一环出错都会导致整个链路失败。链路越长错误概率越高。我习惯的三级以内能解决问题就不拆成四级。信号三配置改一处要同步好多处。如果你发现加一个工具要在三个 Agent 的配置文件里各加一遍说明你是在“复制粘贴式维护”体验非常痛苦。这时应该考虑把公共逻辑抽成共享配置片段或者减少同类 Agent 数量。信号四问题定位变慢。多 Agent 环境下一次请求可能涉及事件订阅、消息路由、记忆共享、多工具调用排查成本成倍增长。当排查时间占到你维护时间的大头时就该回头审视是不是拆得太碎了。我自己在实践里总结出一个起步建议先跑两个 Agent一个负责对外交互和任务编排一个负责具体领域的专业处理这样协作模式能跑通开销又可控。等业务量真的上来了再按上面说的信号逐步拆分。这比一上来就野心勃勃地铺七八个 Agent 要稳得多。最后分享一个我踩过几次坑之后养成的习惯在每个 Agent 的 role 指令里加一句显眼的自我介绍让它每次会话开场先报自己的 ID 和职责范围。这一招看着简单实际效果惊人不管是用在日志定位还是对话调试上都能让你一眼看出当前在处理请求的究竟是哪个 Agent。多 Agent 架构本身就是一套治理体系运行机制是一部分命名规范和边界意识是同样重要的另一部分希望这篇经验能让你少走几段弯路。