OpenClaw 多智能体博客流水线 v3.0：破解 3 层 Subagent 嵌套限制的 2 层 DAG 架构演进

开篇：一次"修不好"的架构重构

2026 年 8 月 2 日，我花了整整一天时间，试图修复 [[OpenClaw 多智能体博客流水线：从 4.5 小时到 15 分钟的优化实战|OpenClaw 多智能体博客流水线]]的一个"小问题"——结果发现，这个问题的根因不是代码 bug，而是架构层面的先天限制。

问题表象：云天枢（云天枢）作为编排者调用 kb-writer，kb-writer 再调用 design-yuntianguang 生成配图——但 design-yuntianguang 在执行过程中反复出现 advisor consultation 问题，导致整个流水线卡死。

根因：当 subagent 嵌套达到 3 层时，OpenClaw 的底层机制会在某一层触发"模型内置行为覆盖指令"的现象，导致 agent 不按指令执行，而是自行"咨询"或"反问"用户。

1. Advisor Consultation 问题：step-router-v1 的"暗黑模式"

通常来说，AI agent 的指令遵循顺序是：系统指令 > 用户指令 > 模型默认行为。但在 OpenClaw 的底层实现中，step-router-v1 模型内置了一个"咨询路由"行为——当 agent 无法确定下一步操作时，它会自动向用户发起询问。

这个行为在 1-2 层嵌套时几乎不会触发，[[多智能体博客流水线架构设计：从 Skill 到 DAG 的演进|架构设计文档]]中也有类似观察——因为上下文足够清晰。但当嵌套达到第 3 层时，subagent 的上下文压缩导致模型丢失了部分指令信息，于是触发了这个内置的"咨询"行为。

关键发现：这不是 bug，而是 step-router-v1 模型的特性——它被设计为"宁可多问，也不乱做"。但问题是，在 3 层嵌套的背景下，第 3 层 agent 问的问题，不会传到第 1 层的用户那里，而是卡在中间层，造成死锁。

2. 3 层嵌套限制：OpenClaw 的物理天花板

经过反复测试，我确认了 OpenClaw 的一个硬性限制：

Subagent 嵌套深度：最多 2 层可靠，第 3 层开始出现不可预测行为。

这并不是 OpenClaw 的 bug，而是其架构设计决定的。OpenClaw 的 subagent 机制基于子进程通信，每层嵌套都需要复制上下文信息。当嵌套达到 3 层时：

1. 上下文压缩：中间层 agent 的上下文被压缩，丢失关键指令
2. 响应路由异常：第 3 层 agent 的响应可能错误路由到第 1 层
3. 模型行为覆盖：step-router-v1 在上下文不完整时触发内置"咨询"行为
4. 边际效用递减：第 3 层 agent 的产出质量显著下降，不如直接调用

3. 云天枢的"降级"：从编排者退回定义者

这是这次重构中最"痛苦"但也最关键的决策。

[[多智能体博客流水线架构设计：从 Skill 到 DAG 的演进|最初的架构]]（v2.0）：

云天枢（编排者）
  ├── kb-writer（写博客）
  │     └── design-yuntianguang（配图）← 3 层嵌套，出问题
  └── 其他任务

云天枢在这里扮演**编排者（Orchestrator）**的角色——它直接调用 kb-writer，kb-writer 再调用 design-yuntianguang。但 3 层嵌套的限制让这个架构无法稳定运行。

重构后的架构（v3.0）：

云天枢（定义者）
  ├── 定义任务结构和参数
  ├── 生成 frontmatter 和指令
  └── 交给外层 DAG 执行
       
DAG 执行层（2 层调用）
  ├── step 1: kb-writer（写博客 + 写入 Obsidian）
  └── step 2: design-yuntianguang（配图 + 替换标记）

云天枢从"我亲自编排"退回到"我定义结构，让 DAG 执行"。这不是功能降级，而是职责聚焦——云天枢现在的核心价值在于任务定义（写什么、怎么写、用什么风格），而不是执行调度（谁先谁后、怎么传参）。

4. 模型统一：全链路 agnes-2.5-flash

在排查过程中，我还发现了一个隐蔽的问题：不同 agent 使用了不同的模型。

• kb-writer 默认使用 deepseek-v4-flash
• design-yuntianguang 使用 agnes-2.5-flash
• 云天枢使用 claude-sonnet-4

不同模型之间的响应风格差异导致 [[kb-writer 实现与部署 - 操作手册|kb-writer]] 生成的 frontmatter 格式，design-yuntianguang 解析起来总是出错。

解决方案：全链路统一为 agnes-2.5-flash。这个模型虽然不如 claude-sonnet-4 强，但胜在行为一致性好——同一个模型处理同一类任务，输出格式稳定，跨 agent 传递数据时不会出现"格式爆炸"。

5. DAG v3.0 最终方案

关于 DAG 执行模式的更多细节，可参考 [[OpenClaw 博客自动化生产流水线：从会话内容到一键发布|博客自动化生产流水线]]。

经过一天迭代，最终敲定的架构如下：

核心更改

执行流程

云天枢（定义任务 → 生成 frontmatter → 传给 DAG）
  │
  DAG 执行层（2 层深度）
  ├── step 1: kb-writer（写博客 → 写入 Obsidian）
  ├── step 2: design-yuntianguang（配图 → 替换标记）
  └── step 3: 结果汇总（HITL 审核）

关键规则

• Obsidian 优先：所有草稿、改稿、配图标记替换都在 Obsidian 中完成，审核通过后才复制到 Hugo
• HITL 双审核：写完后审一次，配图后审一次，两次通过才发布
• 不会主动生图：kb-writer 不直接调用生图工具，生图是 design-yuntianguang 的唯一职责
• 路径跟随：博客文章必须写入与源文件相同的目录，不默认写回到写作目录

经验总结

这次重构给了一个深刻的教训：架构设计不能脱离底层限制。OpenClaw 的 subagent 嵌套限制是物理天花板，不是 bug，设计时就要考虑进去。

三个核心教训：

1. 嵌套深度是硬约束：设计多 agent 协作时，一开始就要按 2 层嵌套来规划，不要试图堆叠 3 层
2. 模型统一是刚需：跨 agent 数据传递时，模型不一致会导致格式爆炸，全链路统一模型是最简单的解决方案
3. 角色聚焦优于角色全能：云天枢从编排者退回定义者，不是退步，而是找到了更适合自己的定位

关联阅读

• [[多智能体博客流水线架构设计：从 Skill 到 DAG 的演进]]
• [[OpenClaw 多智能体博客流水线：从 4.5 小时到 15 分钟的优化实战]]

参考来源

• OpenClaw 官方文档
• OpenClaw GitHub 仓库