目录

OpenClaw 多智能体博客流水线:修复 advisor consultation 与模型统一实战

当 LLM 模型内置行为覆盖你的指令:从 step-router-v1 到 LongCat-2.0 的迁移全记录

起源:文章发布了,但流水线还是坏的

2026 年 8 月 2 日凌晨 4:20,我发布了第一篇文章《OpenClaw 多智能体博客流水线:从 4.5 小时到 15 分钟的优化实战》。但那只是"跑了第一次实测"的结果——流水线本身千疮百孔。从 4:20 到 13:44,我花了 9 个半小时修复这些系统性问题。本文完整记录修复全过程。

修复时间线示意图,从4:20到13:44的9小时修复过程,标注关键故障节点和修复里程碑

第一轮诊断:advisor consultation 幽灵

症状:云天枢(agents-orchestrator)spawn kb-writer 后,不等待返回就结束。更严重的是,它的输出变成占位文本:

[Advisor consultation #1]
[Advisor review]

Now I'll execute Phase 1: writing. Let me spawn kb-writer...

它输出了 [Advisor consultation #1] 占位文本,然后没有真正执行 tool_call。子 Agent 没有被 spawn,流水线卡死。

根因:step-router-v1 模型(云天枢的默认模型)内置了 advisor consultation 行为模式。当 agent 配置了 self-improving-agent skill 时,模型会在每次工具调用前输出咨询文本,然后……经常"忘记"执行实际的 tool_call。这是模型级行为,不是配置能解决的。

  1. 尝试修复 1:移除 self-improving-agent skill

    • 结果:云天枢停止输出 advisor consultation ✅
    • 但 editor-blog-yuntianchen 也需要这个 skill 来执行质检 → 恢复后加规则"执行时跳过 advisor"
  2. 尝试修复 2:在 SOUL.md 和 AGENTS.md 反复加"不要输出 advisor"指令

    • 结果:被模型无视 ❌ — 模型级行为,提示词压不住
  3. 最终修复:把所有 agent 的模型从 step-router-v1 改为 LongCat-2.0。


第二轮诊断:DAG 执行模式崩溃

症状:云天枢 spawn kb-writer 后立即返回,不做 sessions_yield 等待。子 Agent 还没跑完,编排者已经退出了。

根因:OpenClaw 的 subagent 模型是"短生命周期"——agent 执行完第一步就结束。DAG 需要"持久协调者"跨越多个 spawn→yield→resume 循环,但 subagent 做不到。

云天枢的失败时间线

10:31  我 spawn 云天枢
10:33  云天枢 spawn kb-writer → 立即返回(没等)
10:35  我手动 spawn kb-writer(发现云天枢已经结束了)
10:40  kb-writer 完成
10:42  我手动 spawn design-image-prompt-engineer
...

每次 Gateway 重启(今天发生了 6 次),所有正在运行的 subagent 都会被杀死,已经在跑的 DAG 全部丢失。

架构迁移

旧模式:我 → spawn 云天枢 → 云天枢 spawn 子 agent(失败)
新模式:我 → 直接 spawn 子 agent → sessions_yield 等待 → 一步
          → 全部完成后汇报结果

云天枢保留 DAG 定义(blog-post.yaml)和意图路由(compose.md),但执行者从"子 Agent 编排"改为"顶层编排"。blog-pipeline SKILL.md 嵌入 DAG 执行逻辑,用户的当前 agent 直接执行。

架构对比图,左边是旧架构(云天枢作为编排者→子Agent),右边是新架构(当前agent直接编排DAG→多个子Agent),标注两种模式的差异

第三轮诊断:Obsidian 与 Hugo 顺序颠倒

症状:kb-writer 把文章直接写入 Hugo 内容目录,Obsidian 没有同步。一旦改稿,Hugo 和 Obsidian 两个版本就漂移了。

根因:kb-writer 的 AGENTS.md 没有明确指定"Obsidian 优先"的工作流,默认写到了 Hugo 路径。

修复:在 kb-writer TOOLS.md 和 AGENTS.md 加入"博客发布流程铁律":

顺序:Obsidian → 审核 → 配图 → 审核 → 复制到 Hugo → git push

禁止:在 HITL 1 之前写入 Hugo
禁止:跳过 Obsidian 直接写入 Hugo

同时修改 design-yuntianguang AGENTS.md,加入"博客配图流程铁律"——读取 Obsidian 文章 → 生成图片 → 替换 Obsidian 中的 [ILLUSTRATION:] 标记 → 不碰 Hugo。


模型统一:消除 advisor consultation 的根本修复

将 5 个 DAG 相关 Agent 统一到 LongCat-2.0:

Agent旧模型新模型修复效果
agents-orchestrator(云天枢)step-router-v1LongCat-2.0不再输出 advisor consultation
marketing-seo-specialiststep-router-v1LongCat-2.0不再输出 advisor consultation
design-image-prompt-engineerstep-router-v1LongCat-2.0不再输出 advisor consultation
design-yuntianguang(云天光)step-router-v1LongCat-2.0不再输出 advisor consultation
editor-blog-yuntianchen(云天辰)LongCat-2.0LongCat-2.0 ✅已修复
kb-writerdeepseek-v4-flashdeepseek-v4-flash ✅不受影响

关键认知:模型决定行为上限,配置只能在下限内调整。当模型内置了 advisor consultation 模式,你写再多"不要输出 advisor"也压不住。


并发锁:OpenClaw + opencode 共享 ComfyUI

问题:OpenClaw 和 opencode 都调用 run_workflow.py 生图,同时运行会冲突。ComfyUI 单实例同时处理两个请求,导致图片生成失败。

为什么用文件锁? 文件锁(fcntl.flock)是最轻量的跨进程互斥方案——无需额外依赖、不依赖网络、进程崩溃自动释放。替代方案包括:Redis 分布式锁(需要 Redis 服务)、端口检测(竞态窗口大)、systemd 锁服务(太重)。对于本机双进程场景,文件锁是性价比最高的选择。

修复:在 run_workflow.pygenerate_book_cover.py 入口加文件锁:

import fcntl
lock_fd = open("/tmp/comfyui.lock", "w")
fcntl.flock(lock_fd, fcntl.LOCK_EX)  # 阻塞等待
# ... 生图 ...
fcntl.flock(lock_fd, fcntl.LOCK_UN)
并发锁示意图,OpenClaw和opencode两个进程争夺ComfyUI资源,文件锁机制确保只有一个进程能访问

工具调用规则:避免 advisor consultation 扩散

所有 DAG 相关 Agent 的 SOUL.md 和 AGENTS.md 统一加入"工具调用规则":

## ⚠️ 工具调用规则(最高优先级)
- 直接执行,不要输出 advisor consultation 或其他非标准格式
- 只输出纯 JSON tool_call
- 不要输出 XML 包裹(如 `<tool_call>` 标签)

涉及文件:agents-orchestrator/AGENTS.md、design-yuntianguang/AGENTS.md、marketing-seo-specialist/AGENTS.md、design-image-prompt-engineer/AGENTS.md、editor-blog-yuntianchen/SOUL.md。


HITL 门控:从"假阻塞"到"真阻塞"

问题:HITL 门控设了 5 分钟超时 + auto_pass,等于自动通过,根本没有人工审核环节。

修复

  • 超时从 5 分钟改为 30 分钟
  • 超时行为从 auto_pass 改为 pause_and_notify
  • 编排者 sessions_send 通知用户,sessions_yield 等待回复
  • 用户超过 30 分钟不回复 → 暂停流水线,不自动继续

上下文压缩:减少 Phase 3 token 浪费

问题:Phase 3 改稿时,把全文 + SEO 报告 + QC 报告全塞给 kb-writer,光传上下文就消耗大量 token。

修复:DAG 加入 context_compression 配置:

context_compression:
  enabled: true
  rules:
    - from: seo_data
      keep: [推荐标题, Meta Description, Slug, 长尾关键词, 内链建议]
      drop: [优化逻辑, 排序依据, 竞争度分析]
      max_tokens: 300

只保留 Phase 3 真正需要的决策数据,丢弃冗长的分析过程,减少 50-60% 的 token 消耗。


Crash Recovery:断点续传

问题:Gateway 重启或中间错误导致整个流水线从头开始。

修复:Phase 1 完成后,将中间产物(Obsidian 文章路径、slug、word_count)保存到 /tmp/blog_pipeline_state.json。后续 Phase 启动时先检查该文件,如果已有成果则跳过已完成的 Phase。


最终架构(2026-08-02 13:37)

任意会话说"写博客"
    ↓
触发 blog-pipeline skill
    ↓
分类 → 准备 frontmatter
    ↓
当前 agent 直接执行 DAG:
    Phase 1: spawn kb-writer → Obsidian → sessions_yield
    Phase 2: spawn editor + SEO → sessions_yield
    Phase 3: spawn kb-writer 改稿 → sessions_yield
    HITL 1: 暂停等用户确认
    Phase 3.5: spawn design-image-prompt-engineer → sessions_yield
    Phase 4: spawn design-yuntianguang 生图 → 替换 ILLUSTRATION → sessions_yield
    HITL 2: 暂停等用户确认
    Phase 5: cp Obsidian → Hugo → git push

云天枢的角色从"执行者"变为"定义者":

  • ✅ DAG 定义(blog-post.yaml)
  • ✅ 意图路由(compose.md)
  • ❌ 不再作为执行者(subagent 模型限制)
最终架构图,展示从用户会话到Obsidian再到Hugo的完整发布流程,标注各Phase的Agent名称和职责

修复统计

指标数值
修复时长9 小时 24 分钟(4:20 - 13:44)
修改文件数12 个
Gateway 重启次数6 次
成功发布文章1 篇
修复 Agent 模型数5 个
新增并发锁2 处(run_workflow.py + generate_book_cover.py)
修复 HITL 门控2 处(Phase 4 前 + publish 前)

待修复

  • [P1] editor-blog-yuntianchen 仍需验证 LongCat-2.0 下的质检质量
  • [P1] publish-technical.mjs 脚本路径已修正但未验证
  • [P0] 整个 DAG 端到端自动化仍需更多集成测试
  • [P0] ComfyUI 服务稳定性(今天多次不可用,需排查原因)
  • [P2] 碎图清理:临时图片文件需要定期清理机制

参考来源