太典了。我一开始用 OpenClaw 跑多 Agent 协作，几个智能体放在同一个会话里自由发挥，看起来是“群策群力”，实际上不到十分钟就开始互相跑题，一个说东一个说西，最后产出的稿子还得我自己重写。后来试了试 OpenClaw 里的“龙虾场主模式”，把流程改成场主只做编排、每只“龙虾”各守一摊、干完一个阶段就蜕一层壳交一次货，整个协作才算真正稳定下来。
这篇文章就围绕“龙虾场主模式”展开，把它的角色设计、配置方法、状态恢复、观测手段讲清楚，也把我实际跑任务踩过的坑一并列出来。适合准备把多个 Agent 真正用于生产任务，而不是停留在 Demo 阶段的开发者参考。
1. 先理解“龙虾场主模式”到底解决什么问题
1.1 “农场”和“龙虾”各指什么
“龙虾场主模式”这个名字乍看有点怪，但把它的实体对应关系理清之后，所有配置都变得顺理成章。
“场主”指的是 OpenClaw 里那个常驻的协调进程，一般命名为 Farmer，它不参与具体内容生成，只做四件事：拆解任务、判定阶段、登记检查点、调度重试。场主维护的是一套状态机，而不是维护某段对话。它手里的数据是任务 ID、阶段名、检查点路径、评分和超时时间这些结构化信息，基本不碰大段文本。
“龙虾”指的是真正执行任务的工作智能体。每个智能体都有自己固定的“水池”，也就是 Pool。池子划定了它的输入范围、可访问的数据目录、能调用的工具集合。比如负责调研的龙虾只能读资料库和搜索引擎接口，负责起草的龙虾只能看上一阶段的检查点文件，不能翻原始资料，不能碰其他任务的中间结果。这个约束在配置里写死，而不是靠提示词里说一句“别乱看”。
“蜕壳”是整个模式里最关键的隐喻。龙虾长到一定程度必须蜕掉旧壳才能继续生长，这里指一个智能体不能在同一个上下文里无限膨胀，而必须在阶段结束时把产物固化成检查点文件，清空自己的上下文，带着新壳进入下一阶段。具体到工程实现，就是每个阶段结束时不返回自由文本，而是产出结构化的结果对象。
这套设计解决的是多智能体协作最常见的三个问题：上下文污染、单点故障、结果不可回滚。把长期对话拆成短期任务，每个阶段通过物件而非聊天记录传递信息，集群的可维护性会明显提高。
1.2 和其他协作组织方式的对比
第一个阶段先往后放，我再展开谈谈。主流的 Agent 协作方式无非几种：
- 链式协作：Agent 1 的完整输出作为 Agent 2 的上下文输入，Agent 2 再输出给它后面的 Agent。队列简单直接，但阶段越长上下文越大，前面的一点小错误会延续到后面所有环节。
- 路由分发式：一个中心调度器接收请求，分发给多个独立智能体并行处理，最后把结果收集在一处。节省时间，但合并阶段经常出现格式不一致、事实冲突。
- 群聊式：所有智能体共用一个会话上下文，自由发问、随时插话。灵活性最高，但也最容易跑偏，而且每次调用都会携带整段历史，成本高。
- 龙虾场主模式：场主编排、分池隔离、批次移交、门禁验收。它解决的问题是“目标明确、阶段清晰、需要验收”的长期生产任务。
把它们放在表格里对比会更直观。
| 组织方式 | 决策机制 | 适用场景 | 主要风险 |
|---|---|---|---|
| 链式 | 前一个阶段输出直接驱动下一个 | 阶段固定的短流程 | 上下文累积污染、单点阻断 |
| 路由式 | 中央调度，并行分发 | 信息收集、结果汇总 | 合并冲突缺少标准 |
| 群聊式 | 共同讨论 | 头脑风暴、开放探索 | 成本高、容易跑题 |
| 龙虾场主模式 | 场主编排加门禁准入 | 中长流水线、需要阶段产物验收 | 前期建模耗时、配置较复杂 |
要注意，群聊模式不是被替代的对象。我现在的经验是：探索一个未知方案、需要多个角色互相质询的时候，群聊式仍然最顺手。但一旦方向定了，要按批次产出稳定结果，就必须切换到龙虾场主模式，让每个智能体缩回自己的池子里老实干活。
2. 最小可运行的集群怎么搭
2.1 角色拆解与池子划定
搭建之前先明确角色。我在项目里常用的最小角色集合是四个：
- Farmer（场主）：协调进程，不接大模型生成任务，只做状态流转。
- Researcher（调研龙虾）：负责收集资料、整理引文、输出结构化的参考资料清单。
- Drafter（起草龙虾）：基于调研检查点生成初稿。
- Reviewer（质检龙虾）：自动评分检查格式、事实引用一致性，输出通过或打回意见。
- 人工审批节点：最后一道门禁，由人确认后释放产物。
每个角色的关键配置是“池子”。OpenClaw 里的 Pool 类似数据库连接池，是一个逻辑隔离容器。池子定义了该智能体能看到的输入目录、能触达的工具、可写出的路径。这是和群聊式最不一样的地方：群聊式是所有人坐在一张桌上谈，场主模式是每人一个独立工位，只有交接文档会被传递。
我上一线配置的时候会先把每个角色的输入输出 Schema 画出来，只允许结构化字段通过。例如 Researcher 的输出是一个 JSON，包含 topic、key_arguments、source_links、core_facts 四个字段，不允许自由文本串进下一阶段。这能直接把很多上下文污染问题消灭在结构层。
2.2 一份可以运行的 openclaw.yaml 核心配置
以下是我实际跑通过的一份简化配置，生产环境里会加更多认证和限流字段，但核心骨架是这样。字段名以 OpenClaw 当前版本为准，老版本可能有差异。
api_version: v1 mode: lobster_farm coordinator: name: farmer state_store: postgres checkpoint_dir: s3://openclaw-demo/checkpoints window: 30m agents: - id: researcher pool: pool_research model: deep-research-m max_concurrency: 2 timeout_sec: 600 output_schema: research_note read_scope: [datasets, web_search] - id: drafter pool: pool_draft model: long-form-l requires: research_note timeout_sec: 900 read_scope: [checkpoints] - id: reviewer pool: pool_review model: critic-x auto_gate: true score_threshold: 0.85 read_scope: [checkpoints] - id: formatter pool: pool_release requires: approved_draft read_scope: [checkpoints] gates: - stage: review type: auto_score min_score: 0.85 - stage: release type: human这个文件里最值得琢磨的是 read_scope。researcher 只能读信息源，drafter 只能读检查点，reviewer 也只读检查点。每一层能访问的数据面都被强制缩小，而不是靠提示词约束。
还有人会问，为什么 coordinator 还要一个 window 参数。它的含义是阶段超时窗口，超过 30 分钟没收到检查点提交，场主就会把这个任务标记为超时，转入失败队列。有了这个参数，异常任务不会永远挂在那消耗资源，也不要小看这一行配置，它能省掉很多线上排查的体力活。
2.3 任务信封和消息拓扑
部署好 YAML 结构之后，需要明确消息在各角色之间怎么流动。OpenClaw 的底层消息机制是消息总线和任务队列，每个任务会封装成一个信封，字段大致如下。
{ "task_id": "T-20240513-001", "stage": "research", "input": { "topic": "智能家居场景下的内容生产流程" }, "checkpoint_ref": "s3://openclaw-demo/checkpoints/T-20240513-001/research.json", "deadline_sec": 600, "retry_count": 0 }task_id 是整个流程的主键。stage 标记当前处于哪个阶段。checkpoint_ref 是智能体必须产出并登记的对象存储路径。deadline_sec 用于场主超时判定。
每个工作智能体消费一个任务信封后，去自己的池子拿输入，跑完模型逻辑，把结构化结果写入 checkpoint，向场主上报一个完成事件。场主验证 schema 和门禁规则，合格就构造下一个阶段信封，不合格就把信封打回并附上原因。整个过程不依赖某段 prompt 里的隐式传播，任何一步都能被审计。
消息拓扑里需要两个核心队列：一个主链表记录所有待执行阶段，一个死信队列存失败任务。我在 Redis 里用两个 Stream 来模拟，实际规模大了再上专门的队列系统。最开始只有单机时，只用 PostgreSQL 的一个 task 表加一个状态字段也能撑住 Demo，完全没有必要一上来就铺分布式队列。
3. 一次真实任务的全过程：从拆解到出稿
3.1 先把任务拆成可验收的阶段
理论说再多都不如跑一次。我当时接到一个具体需求：给某智能家居品牌写一篇发布长文，外加一段配套的介绍文案。如果按老办法，把这堆材料直接丢给一个智能体，让它“写篇长文”，产出通常很空。所以我先让场主做拆解。
场主的拆解结果是把整活拆成四个阶段：
- Research：整理该品牌技术特点、同类产品对比、场景化卖点，输出参考资料清单和核心观点提纲。
- Draft：基于研究笔记写初稿，要求控制篇幅在给定格式内。
- Review：自动检查引用完整性、内容结构、事实一致性，并打出一个评分。
- Release：通过人工确认后，格式化输出为最终可发布的 Markdown 文档。
这就是典型的龙虾场主式拆解方法：每个阶段都对应一个可验收的中间产物，而不是直接把最终目标砸给单个模型。拆解的过程看似多了几步，实际上是在为后面的失败恢复铺路。
3.2 四个阶段的排练记录
任务进入执行队列后，第一只龙虾是 researcher。我把主题、目标受众、主要卖点作为唯一输入投进任务信封，它回到自己的池子读取内部索引，调用搜索工具，跑了大概三分半钟，产出了一个 research_note.json，里面包含十几条来源链接和五个核心论点。
随后 drafter 被唤醒，它只能读取 research.json，不能读取最开始的原始主题。这里有个有意思的效果：因为输入是结构化的提纲，drafter 不会在开头重复叙述需求背景，而是直接进入内容组织。初稿生成后，reviewer 按规则跑了一遍引用完整性检查，发现了两个问题：有一段表述声称的出处和实际链接标题不一致，另外结构上缺少对比小节。初稿评分 0.84，低于 0.85 的阈值，任务被场主打回。
被打回时 drafter 并不是从头再来。它拿到的是 reviewer 的标注意见和原检查点引用，只对问题部分做修订。第二次提交评分 0.91，通过自动门禁，进入人工审批。
人工审批阶段由我在后台过目。我看了下敏感词、事实口径和表述风格，确认无误后点了通过。最后 formatter 拉取 approved_draft 检查点，渲染成最终的 Markdown 文件。整个流程十分钟左右，只有一次打回，没有一次完全重新生成。
3.3 执行日志里最值得盯住的几行
跑完任务后，我会习惯性翻一遍场主的审计日志。下面是我摘出的几行要点示范：
[farmer] audit task=T-20240513-001 stage=research status=pass duration=320s cost=0.21 [farmer] audit task=T-20240513-001 stage=draft status=hit_gate score=0.84 revert_to=checkpoint/research-v2 [worker:drafter] retry note=missing_source_fix task=T-20240513-001 checkpoint_ref=.../draft-v3 [farmer] audit task=T-20240513-001 stage=review status=pass score=0.91 [human] release approved by reviewer task=T-20240513-001看日志时重点不是“哪一步成功”，而是“status=hit_gate”的那一行。那行决定了成本，也反映了每个池子的质量。经常出现 hit_gate 说明上游产出质量不行，这时要去调上游的提示词和数据范围，而不是在下游反复重试。
还有 cost 字段。龙虾场主模式里每个阶段独立计费，日志会记录 token 消耗和费用。我习惯用这个字段做阶段成本对比，几乎每次都能发现 review 阶段的消耗被低估，因为要拉取检查点做全文校验。如果 review 成本占整体 40% 以上，就该考虑缩小评分范围，只对关键结构抽检。
4. 状态管理、失败恢复和那些坑
4.1 检查点：不把鸡蛋放在一个 Prompt 里
单 Agent 写长文的时候，最大的痛点是上下文长度有限，写到后面忘了前面。龙虾场主模式的解决办法是定期把状态固化成检查点，而不是让 Agent 在一段超长对话中死撑。
检查点文件不一定要存模型输出全文。我通常只存四类内容：
- 结构化数据字段，如引用链接、代码清单、关键结论
- 阶段产物元信息，包括生成时间、来源任务 ID、使用的模型名
- Schema 校验状态，标记是否通过门禁
- 异常信息，记录上一步打回的原因摘要
有了检查点之后的回滚逻辑就变成了：失败时只回到最近一个通过校验的检查点，把中间未验证的部分丢弃。比从零开始省成本，也比直接保留全部上下文干净。这和数据库的归档日志思想是一样的，本质上是放弃了自由文本的连续性，换来了可追溯性。
4.2 重试、冷却和死信队列的取舍
很多 Agent 框架把重试想得太简单：失败了，把原文再甩给模型一次。龙虾场主模式里我会设计重试流：
- 失败类型是门禁评分低：不能简单重试，必须携带 Reviewer 的打回原因，走修订版路径。
- 失败类型是外部服务超时：先做指数退避，等待时间按 1 秒、4 秒、16 秒递增，最多三次。
- 失败类型是 schema 校验失败：重试没有意义，直接进入死信队列等人工检查。
核心原则是重试要能区分哪类错误可以通过重试解决。外部资源抖动时重试有价值，模型输出不符合 JSON 结构时再试一百遍也还是不符合。不区分错误类型就统一重试，就是在浪费钱。
死信队列是场主模式里经常被忽略的部分。它像一个“问题任务收容所”，只有经过人工处理后才能重新投入队列。我见过有人把死信队列清空重启任务，中断几次后反而出现重复提交。正确做法是死信队列的每个任务都记录原始信封、错误信息、重试次数，人工看完再决定是修订、拆分还是直接弃用。
4.3 我踩过的坑和对应的规避方法
第一个坑是公共水池导致串味。最初我把多个任务交给同一个 drafter 智能体，它有一个长期会话，结果第二个任务里频繁出现第一个任务的名词。排查才知道它的上下文里未清空部分历史。后来我把池子彻底隔离，每个任务新建一个干净的上下文镜像，并且强制每个阶段结束后关闭会话。非常影响效率，但有效。
第二个坑是重试没有退避，碰到上游搜索服务抖动时挂了四五十次，直接拉爆调用账单。我加上了退避策略和最大重试次数，超过阈值就转人工。实际效果是故障期间消耗反而降低，因为大量失败请求不再重复发起。
第三个坑是人工审批节点的超时默认值。开箱配置里人工节点超时可能被定为“自动通过”，有一次凌晨任务反复触发，我没留意，审核节点直接放行了未经确认的内容。后来我把人工审批的超时策略改成“转派给备份审核员”和“挂起直到显式确认”，宁可让任务卡住也不自动放行。
这三个坑背后是一条通用规则：在编排层面，任何资源都要默认拒绝而不是默认放行。宁可任务排队，不能自动出错。
5. 把集群调到“能看着它跑”的状态
5.1 需要长期盯住的核心指标
跑过一段时间后会发现，龙虾场主模式的维护重点不是单次生成质量，而是集群的整体稳定性。我建了一张仪表盘，只关心五个指标：阶段时长、门禁通过率、重试率、检查点体积和单阶段成本占比。
这五个指标里门禁通过率最敏感。通过率低不是某个模型能力不足，而是职责边界或输入数据出了问题。检查点体积则能暴露上下文污染：体积突然涨大说明某个检查点里混入了不该有的自由文本，必须立刻看 schema 校验结果。
我按自己的情况做过一张异常对照表：
| 观察到的指标异常 | 可能的根因 | 第一反应 |
|---|---|---|
| 重试率高、门禁分低 | 上游产出质量不达标 | 缩小上游池子范围，补充输出约束 |
| 检查点体积快速膨胀 | 输出 schema 被破坏或上下文串味 | 检查池子隔离，限制检查点字段数 |
| 成本线性上涨但效果持平 | 拆解过碎、阶段太多 | 合并相邻阶段，减少提交次数 |
| 阶段经常超时 | 单阶段负载过大 | 拆分任务，或提高 pool 并发限制 |
5.2 快速定位问题的三个入口
线上排查时我会按顺序查三个地方。
第一是任务信封的状态。看任务卡在哪个 stage，pending 多久了。只查任务状态就能定位是不是调度卡死。第二是消息队列的堆积情况，主队列积压说明消费能力不足，死信队列快速增加说明门禁或重试设计有问题。第三是检查点文件的更新时间。如果某个阶段检查点超过时间窗口没有更新，而队列还在往前走，多半是那个智能体实例已经假死。
定位问题的核心是把时间戳和任务 ID 串起来。每条审计日志都带 task_id，每个检查点都带来源任务 ID，任何异常都能快速追踪到是哪一只“龙虾”在哪里“卡壳”。不要让任何中间产物变成匿名文本，追溯是场主模式比群聊模式强的重点。
5.3 什么时候不要用龙虾场主模式
这个模式虽然好用，但不是万能的。我总结了几条判断标准，摆在文章最后，因为你完全可以用同样的经验教训来知道何时停止。
如果整个任务只有两三个智能体、预期一步能完成，直接用链式或者单模型调用就行了，没必要上编排。如果有多个智能体在反复讨论、需要互相启发和否定，那群聊模式效率更高，别用流水线硬套。如果团队没有能力维护状态存储和死信队列，场主模式反而会把简单的事情变重。
我自己的一次切身体会发生在跑一个小型资料整理 Demo 时：本来只要一个智能体读十份 PDF 再汇总，我硬是拆成调研、汇总、审校三个阶段，结果审校阶段一直报格式问题，反而把简单需求搞得很疲惫。后来我给自己定了条硬性标准：阶段超过 6 个，才有拆分的必要；预计每个阶段的输出不会被后续阶段修改，才适合用检查点传递。
龙虾场主模式最好的使用位置是在“半自动化生产流水线”里，一个任务被拆成明确、可验收、可重复执行的阶段。它可以帮你把多 Agent 协作从混乱讨论变成可控的异步车间。如果你正准备上一套多智能体流程，我建议你先挑一个需求跑通，别急着铺大团队。先让场主站起来，再考虑要不要多建几个池子。
