ARTICLE · 1044387

OpenClaw 团队模式:搭建中真实踩过的 10 个坑

发布时间：2026-09-20 15:18:01 最近访问：2026-09-20 15:18:01

OpenClaw 团队模式：搭建中真实踩过的 10 个坑

OpenClaw 团队模式已经上线一段时间了。这段时间里，最常被问到的一句话不是"怎么搭"，而是"搭起来怎么跑不通"。

读者里有的刚把 4 个角色铺开，发现消息互相串；有的把顶级模型挂上去，跑三天账单直接爆掉；还有的图省事跳过了审稿，结果 AI 编的内容直接发出去——粉丝一查是假的，取关比关注还快。

这篇整理 10 个真实会踩的坑，挑法三个标准——任何用户搭团队模式都会遇到、有明确避法、读者能照着改自己配置。每坑收尾给一条具体动作，不是"应该这样想"，是"现在去做什么"。

坑 1：角色路由都堆在 default

•坑是什么：多个 Agent（coordinator / researcher / writer / reviewer 等）的 peer 路由都设成 default，所有消息进同一个兜底入口。

•为什么踩：图省事。default 路由是"啥也不配也能跑"的默认选项——刚搭时先跑通再调优，是大多数人的本能。

•怎么避：每个 Agent 配明确 peer 指向。比如 researcher 只接 coordinator 转发的查资料任务，writer 只接写稿任务。default 只留给真正兜底的角色。配完后跑一次"随便发一条消息看哪个 Agent 抢答"的验证。

•踩了的后果：一条消息进来所有 Agent 都抢答，所有 Agent 都被刷一遍；日志里全是噪声，真正有用的信号被淹没。

•现在去做什么：打开路由配置，逐个检查每个 Agent 的 peer 指向是不是唯一的。

•来源：OpenClaw 团队模式多 Agent 路由层级（综合通用消息总线设计原理）——待证具体 OpenClaw 官方文档章节。

坑 2：MEMORY 不按岗位分桶

•坑是什么：把单兵模式下的 MEMORY 文件直接给所有 Agent 共用，不按岗位拆。

•为什么踩：团队刚搭时复用现有 MEMORY 文件最省事——拷一份给每个角色，改个名字就行。

•怎么避：按岗位拆。researcher 的记忆不共享给 writer（里面可能有客户信息），writer 的风格纲要不写到 researcher 的桶里（跟查资料无关）。MEMORY 边界跟角色边界一一对应。

•踩了的后果：A 角色的隐私内容被 B 角色读到——串味——对外发布的内容里出现不该出现的细节；或者 B 角色的内容被 A 误读，A 的判断跑偏。

•现在去做什么：把每个 Agent 的记忆文件单独建一份，按岗位命名，跨岗位不互相引用。

•来源：OpenClaw MEMORY 隔离原则（综合多角色权限分离、数据最小化通用实践）——待证。

坑 3：岗位说明书只写 Owns，不写 Does not own

•坑是什么：写角色说明书时，只写"这个 Agent 管 X、Y、Z"，不写"这个 Agent 不管 A、B、C"。

•为什么踩：人的本能是先写"做什么"再写"不做什么"，正面定义永远比负面定义让人舒服。

•怎么避：每条 Owns 后强制跟一条 Does not own。比如 researcher 不写文章、writer 不查资料、reviewer 不修改原文只标问题。每条 Does not own 写明边界外的任务应该派给谁。

•踩了的后果：边界不清，多个 Agent 都觉得"这事归我管"——抢活——重复劳动；或者都觉得"这不归我"——互相等——流程卡死。

•现在去做什么：把每个角色的说明书打开，每条 Owns 后补一条 Does not own。

•来源：通用 RACI 矩阵 / 角色责任定义原则（项目管理的标准做法）——综合多源，未引用具体出处。

坑 4：协调者当主角（边界未清先上协调者）

•坑是什么：4 个 worker Agent 的 Owns / Does not own 还没写清，先加一层 coordinator，让协调者管派活。

•为什么踩：觉得"团队得有领导"。协调者是团队模式里最显眼的角色，先搭它心理上觉得"团队成型了"。

•怎么避：先写清 worker 边界，再决定要不要协调者。协调者本质是"管信息流的"——没清晰的 worker 边界就上协调者，协调者拿到任务也不知道派给谁。判断标准：worker 边界清到"发一条任务能立刻定位到 1 个 worker"时，才加协调者。

•踩了的后果：协调者接到任务后反复派活、反复回炉，流程被放大 2-3 倍，平均任务耗时翻倍。

•现在去做什么：把 4 个 worker 的 Owns / Does not own 写完，验证一次任务派发不返工，再加 coordinator。

•来源：通用分层架构设计原则（先底层清晰再上层聚合）——综合推断，待证 OpenClaw 团队模式官方文档对应章节。

坑 5：跳过审稿 / 事实核查

•坑是什么：派活链路是 researcher 查资料 → writer 写 → 直接对外发布，整条链路没有独立 reviewer。

•为什么踩：觉得"AI 写的应该没问题"或者"省一个角色省一份成本"。研究员的引用准不准、writer 的事实陈述对不对，都没人复核。

•怎么避：审稿 / 事实核查是必选环节，不是可选项。独立 reviewer 至少做三件事——核对引用是否真实存在、核对数字是否对得上原文、核对事件时间线是否一致。reviewer 只标问题不直接改稿，改稿权在 writer。

•踩了的后果：AI 编造的数据、引用、事件直接上线——读者一查发现是假的，取关比关注快。掉粉事故往往是一次性的，恢复需要十次正面输出。

•现在去做什么：把 reviewer 加进流程，跑一次完整链路验证。

•来源：通用内容生产线原则（编辑流程必备 fact-check 环节）——综合通用出版 / 媒体行业规范。

坑 6：消息路由优先级顺序错

•坑是什么：路由匹配顺序（peer / account / channel / default 等层级的先后）写反或排乱，常见错配是"channel 优先于 peer"或"default 比 account 先匹配"。

•为什么踩：没仔细读路由层级的设计意图，照抄示例。路由层级看着像 CSS 优先级，谁先谁后无所谓。

•怎么避：特定 > 通用是路由设计的通用原则。具体顺序以 OpenClaw 官方文档为准，但思路是——越具体的 sender + channel 组合，优先级越高；越通用的兜底层，优先级越低。每加一条路由都跑一次验证：在某个具体 sender + channel 下，看匹配到的第一个 Agent 是不是预期的那个。

•踩了的后果：一条普通消息被多个 Agent 抢答，所有 Agent 都被刷；或者本该路由到 coordinator 的私聊消息被 channel 路由截胡，coordinator 永远收不到自己该看的任务。

•现在去做什么：跑一次"发送方 + 频道"组合的路由验证，确认匹配到的是预期 Agent。

•来源：OpenClaw 团队模式路由层级设计——具体优先级顺序待证，原则"特定 > 通用"是通用路由设计共识。

坑 7：会话粒度过细（每个任务一个 Agent）

•坑是什么：为了"上下文干净"，给每个短期任务都开一个新 Agent，任务结束就关。

•为什么踩：觉得"上下文干净 = 输出质量高"，每个任务都"重新开始"听起来更可控。

•怎么避：按"长期角色"开 Agent，按"短期任务"开 sub-session。判断标准：handoff 开销（context 拷贝 + 角色初始化 + 工具加载）是否小于任务本身的执行成本。开销更大就别拆，用 sub-session 隔离上下文即可。

•踩了的后果：每次任务开始都付一次完整的 Agent 初始化代价，延迟翻倍；长期角色的"经验"丢失（关掉就清空），下次开新 Agent 又从零学起。

•现在去做什么：盘点最近一周开过的新 Agent 数，把可以用 sub-session 替代的合并回去。

•来源：通用进程 / 会话成本权衡（进程 vs 线程类比）+ 长期身份 vs 短期任务的工程常识——综合推断。

坑 8：每个 Agent 都用顶级模型（成本失控）

•坑是什么：4 个 Agent 全部配顶级模型，整条团队链路用同一个高规格模型。

•为什么踩：觉得"都用最好的，质量肯定有保障"。模型选型时图省事，"统一规格"听起来最稳。

•怎么避：按任务难度分级配模型。路由 / 分类 / 简单判定用小模型（便宜快），核心推理 / 长文写作用大模型，reviewer 可以比 writer 略小（review 不需要创作级能力）。一份典型配比：router 小模型 + researcher 中模型 + writer 大模型 + reviewer 中模型。

•踩了的后果：单次任务成本翻 3-4 倍，质量提升通常 < 20%。性价比曲线在某个阈值后就平了，再往上堆模型不划算。

•现在去做什么：把每个 Agent 的模型规格列一张表，标出每个角色需要的实际能力上限。

•来源：通用模型路由成本优化（多模型协作推理的标准做法）——综合多源。

坑 9：fire-and-forget vs blocking 不区分

•坑是什么：派活时所有任务都设成"等响应 / 阻塞模式"，主流程等每个派活都返回再走下一步。

•为什么踩：阻塞模式最"安全"——等结果回来再决定下一步，不用处理"任务还没回来"的中间状态。

•怎么避：派活时显式标注模式。独立任务（不依赖其结果的）用 fire-and-forget，主流程继续；依赖任务（下一步必须等这个结果的）用 blocking，等结果。判断标准：把派活从流程里"拔掉"，主流程还能不能跑——能跑就是 fire-and-forget，不能跑就是 blocking。

•踩了的后果：所有派活都阻塞，主流程平均延迟 = 派活数 × 单次响应时间；4 个派活串行阻塞下来，主流程比单 Agent 直接干还慢 2-3 倍。

•现在去做什么：把最近一次任务的派活逐个标模式，看哪些可以改 fire-and-forget。

•来源：通用异步任务编排原则（消息队列 fire-and-forget vs request-reply）——综合推断。

坑 10：工具权限全开（每个 Agent 都给 shell root）

•坑是什么：每个 Agent 的工具权限默认全开——shell 执行、文件写入、对外发消息、删除文件全部能用。

•为什么踩：图省事"先能跑通"。权限最小化原则是"优化项"，先开权限把流程跑通再回头收，是常见本能。

•怎么避：每个 Agent 按职责最小化工具集。researcher 不需要 shell 写入、writer 不需要发布、reviewer 不需要修改原文的工具。审批操作显式 ask——任何"对外发消息 / 删文件 / 改配置"操作必须 human-in-the-loop。先按最小权限跑，跑不通再加权限，而不是先全开再回收。

•踩了的后果：单个 Agent 遭遇 prompt injection 或判断失误——一句话执行删除命令或对外发不该发的消息。这是安全事故，不是质量事故——一次就可能把整个团队配置清空或把内部内容泄露出去。

•现在去做什么：逐个 Agent 检查工具列表，把不需要的工具从权限集里移出去。

•来源：通用最小权限原则（Principle of Least Privilege）+ OpenClaw 工具权限分层设计——综合通用安全工程实践。

5 条避坑纲领

1.协调者后于 worker 边界——worker 的 Owns / Does not own 没写清，别加 coordinator。协调者是放大器，底座没稳就先放大，必然乱。

2.岗位说明书里"不管什么"比"管什么"更重要——每条 Owns 后强制跟一条 Does not own，边界写在负面定义里。

3.审稿 / 事实核查是 AI 内容生产线的强制环节——reviewer 只标问题不改稿，改稿权在 writer。

4.工具权限先最小化，能跑通再加——任何对外 / 删 / 改的操作都走 human-in-the-loop。

5.会话粒度按长期角色切，不按短期任务切——handoff 开销比任务成本还高，是常见的死法。

搭团队模式不是把 4 个 Agent 堆起来就能跑——是 10 个工程细节一个不漏地踩过、改过，才跑得起来。

正在搭的读者，先按这 10 条逐项检查目前的配置，比读任何"团队模式教程"都管用。