OpenClaw 多智能体博客流水线优化实战：4.5h→15min

起源：4.5 小时的噩梦

2026 年 7 月，我搭建了一套 OpenClaw 多智能体博客流水线。愿景很美好。一条命令触发，AI 就能自动完成写稿、编辑、SEO、配图、审核、发布。但第一天跑完，计时器告诉我一个残酷的数字——4 小时 32 分钟。

这不是流水线，这是慢炖锅。

问题出在哪？[[openclaw-multi-agent-intro|OpenClaw 多智能体系统入门]]中的 DAG 编排器（云天枢）卡在"顾问咨询"模式、子 Agent 被 Gateway 重启杀死、模型上下文爆炸、ComfyUI 镜像排队死锁——每个环节都在拖后腿。

诊断：为什么慢？

模型选型陷阱

云天枢的默认模型是 stepfun/step-router-v1，这个模型有强烈的"输出咨询格式"倾向。每次 spawn 子 Agent 之前，它会输出一长串 [Advisor consultation #1] 占位文本，而不是直接执行工具调用。这导致：

• 每次 spawn 前有 1-3 分钟的无意义输出
• 用户需要手动发送"？“来打断它
• 整个 DAG 的执行节奏被彻底打乱

Gateway 重启的连锁灾难

每次修改配置都需要重启 Gateway，而 Gateway 重启会杀死所有正在运行的子 Agent。在优化过程中，我们重启了至少 10 次 Gateway，每次重启都意味着：

• 正在运行的 kb-writer 被中断
• 已完成的步骤需要重新执行
• 用户需要重新触发流程

子 Agent 的短生命周期

OpenClaw 的 subagent 模型是"spawn → execute → complete”，每个子 Agent 都是短生命周期的。云天枢作为编排器，需要在一个 session 中持续运行整个 DAG，但实际上一旦它 spawn 了子 Agent 并 sessions_yield，它自己就结束了——DAG 后半段没人管。

第一轮优化：止血

模型换血

最直接的优化：把云天枢的模型从 stepfun/step-router-v1 换成 longcat/LongCat-2.0。LongCat-2.0 没有 advisor consultation 倾向，收到 spawn 指令就直接执行，每次节省 1-3 分钟无意义输出。

# openclaw.json 中修改 agent 配置
"agents-orchestrator": {
  "model": "longcat/LongCat-2.0",  // 替换 stepfun/step-router-v1
  ...
}

移除"祸根" Skill

排查发现，self-improving-agent skill 是导致 advisor consultation 的元凶之一。这个 skill 的指令让模型在不确定时输出咨询格式。移除后，模型行为变得干净利落。

SOUL.md 强化指令

给云天枢的 SOUL.md 加上最高优先级指令：

## 工具调用规则（最高优先级）
- **你是编排者，不是咨询顾问**：spawn 子 agent 后必须 sessions_yield 等待 auto-announce
- **直接输出纯 JSON tool_call**，不要输出 XML 包裹
- **不要输出 advisor consultation**
- **直接执行**：不要输出咨询/建议格式
- **持久协调**：DAG 执行期间你必须持续运行

第二轮优化：架构升级

从"子 Agent 托管"到"顶层编排"

意识到 OpenClaw 的 subagent 模型不适合"持久协调者"后，参考 [[dag-workflow-optimization|DAG 工作流编排与超时治理]] 的经验，我们改变了架构模式：

旧模式：云天枢（子 Agent）编排整个 DAG → 被 Gateway 重启杀死 → 失败

新模式：顶层 Agent（LongCat-2.0）直接编排，逐步 spawn 各步骤，每次 sessions_yield 等待完成

顶层 Agent (LongCat-2.0)
  ├── Phase 1: spawn kb-writer → 写草稿 → 等待完成
  ├── Phase 2: spawn editor + SEO 并行 → 等待两者完成
  ├── Phase 3: spawn kb-writer 改稿 → 等待完成
  ├── Phase 4: HITL 暂停等待用户确认
  ├── Phase 5: spawn design 生图 → 等待完成
  └── Phase 6: HITL 暂停等待用户确认 → 发布

上下文压缩

每次 HITL 暂停点，用户确认时看到的上下文已经膨胀到数万 token。更多上下文工程技术可参考 [[context-window-management|上下文工程与 Token 压缩]]。解决方案：

• HITL 输出压缩：只展示当前步骤的结果摘要，不展示完整上下文
• 关键信息提取：使用 grep/head 提取关键行，而不是全文输出
• 结构化报告：每次 HITL 输出 {status, 完成步骤, 下一步, 亮点, 问题} 五段式报告

ComfyUI 并发锁

生图阶段需要调用 ComfyUI API，但 ComfyUI 的 GPU 同时只能处理一个请求。并发请求会导致死锁和超时。更多细节见 [[comfyui-api-integration|ComfyUI API 集成与并发控制]]。解决方案：

• 在 ComfyUI 调用前加互斥锁
• 锁超时设为 5 分钟
• 失败后自动重试，最多 3 次

Crash Recovery 断点恢复

最严重的痛点是：一旦中间某个环节失败，整个 DAG 要重头开始。解决方案：

• 步骤状态持久化：每完成一步，将状态写入 JSON 文件
• 断点检测：启动时检查是否有未完成的 DAG
• 自动恢复：从断点继续，而不是从头开始

// /tmp/pipeline_state.json
{
  "dag_id": "blog-pipeline-20260802",
  "steps": {
    "phase1_kb_writer": {"status": "completed", "output": "xxx"},
    "phase2_editor": {"status": "completed", "output": "xxx"},
    "phase2_seo": {"status": "failed", "error": "timeout"},
    "phase3_kb_writer_revision": {"status": "pending"}
  },
  "resume_from": "phase2_seo"
}

成果：15 分钟，18 倍提速

经过两轮优化，真实数据如下：

经验总结

1. 模型选择是第一步：DAG 编排器需要一个不"胡思乱想"的模型，LongCat-2.0 比 step-router-v1 更适合做编排
2. 顶层编排 > 子 Agent 编排：在 OpenClaw 的架构下，持久协调者必须在顶层 Agent 层面实现
3. Gateway 重启是杀手：尽可能减少重启次数，配置改完确认无误后再重启
4. 断点恢复是必备功能：任何超过 5 分钟的流程都应该有断点恢复机制
5. HITL 要压缩，不要倾倒：每次暂停给用户看的是摘要，不是全部上下文。关于 HITL 设计模式可参考 [[hitl-design-patterns|HITL 人工审核设计模式]]

参考来源

• OpenClaw 官方文档
• OpenClaw Gateway 配置参考
• OpenClaw 多 Agent 编排指南