梦行志OpenClaw 多智能体博客流水线：从 Skill 到 DAG 的演进
OpenClaw 多智能体博客生产流水线的设计思路、关键决策与落地实现
多智能体博客流水线架构设计：从 Skill 到 DAG 的演进
当你的博客系统从 2 个 Agent 扩展到 5 个，线性流程出现并行需求，你就站在了一个分岔路口：继续在 SKILL.md 里硬编码编排逻辑，还是切换到真正的编排引擎？
oklife.me 的博客生产一直依赖 blog-writer skill[[08-运维体系/2026-07-02-2115-博客自动化生产流水线|博客自动化生产流水线]]。这个 skill 检测到"写博客"触发词时，直接调用 kb-writer 写文章，再委托 design-yuntianguang 生成封面图和插图。在只有 2 个 Agent、线性执行时，这个模式足够简单。
但随着需求扩展——加入质检（云天月）、SEO 优化（marketing-seo-specialist）、图片提示词优化（design-image-prompt-engineer）——硬编码在 SKILL.md 中的编排逻辑开始暴露致命缺陷：
| 问题 | 说明 |
|---|---|
| 无并行 | skill 是线性的，质检和 SEO 不能同时跑 |
| 无状态记忆 | skill 不知道上次哪个 SEO 建议有效 |
| 无分支逻辑 | 质检不通过时 skill 不知道怎么回退 |
| 无法学习 | 每次"写博客"都像第一次，不积累经验 |
| 硬编码痛苦 | 5 个 agent 的调用全写在 SKILL.md 里，改一处要全改 |
关联阅读：[[2026-07-28-2200-openclaw-blog-writer-skill-fix-complete-review|旧 blog-writer 修复回顾]]
核心矛盾：当 Agent 数量从 2 增加到 5，且有并行需求和分支逻辑时，skill 直调模式已经扛不住了。
这个阈值是 2026-07-03 讨论中得出的：≤2-3 个 Agent 线性流程 → skill 直调；≥4-5 个 Agent 有分支逻辑 → orchestrator 有价值。
11 个关键设计决策
整个架构设计过程中，我们做出了 11 个关键决策，每个都直接影响最终方案。
1. 编排引擎：复用云天枢，不新建
云天枢（agents-orchestrator）已经有完整的 YAML DAG 引擎 v2.0，支持 Wave 并行排序、变量插值、条件执行、人工审批节点、循环迭代、断点续跑、反馈返工。没必要从零建编排引擎。
2. 云天月不可复用，新建云天辰
云月（editor-yuntianyue）是完全为南明小说量身定制的网文责编。她的质检维度——历史虚无主义、色情低俗、暴力过度、角色一致性、爽点密度——与博客质检完全不重叠。强行复用需要重写整个 SOUL.md，等于新建。
3. SEO Agent：复用 marketing-seo-specialist
三个 SEO Agent 对比后，marketing-seo-specialist 胜出——它有最全面的页面 SEO 优化清单和白帽方法论。Baidu specialist 过度聚焦百度生态，而 oklife.me 面向全球搜索。WebMCP specialist 是 AI Agent 方向，并非传统 SEO。
4. 图片质量：插入提示词工程师
生图质量差的根因是提示词太泛（“抽象科技风+深蓝色调”）。design-image-prompt-engineer 能输出精确到光线方向、镜头焦段、构图法则的专业提示词。插入到云天光之前作为独立步骤。
5. 分类路由：只分两路
| 分类 | 关键词匹配（≥3 个） | 发布目录 |
|---|---|---|
| Code Art Studio | OpenClaw/AI/Docker/Hugo/配置/排障/部署/代码/Python/API 等 | code-art-studio/ |
| Digital Asset | 其他所有主题 | digital-asset/ |
6. 发布脚本拆分
保留现有 publish-technical.mjs，新建 publish-digital-asset.mjs。职责单一，互不干扰。已有 8 篇 Digital Asset 文章不迁移图片路径。
关联阅读：[[08-运维体系/2026-07-03-1239-publish-technical-script-dual-source-upgrade|发布脚本双源升级]]
7. blog-writer skill 保留不动
新建 blog-pipeline skill 作为触发器，路由到云天枢执行。blog-writer skill 不做任何修改，保持向后兼容。
8. HITL 门控：两个审批节点
- HITL 1：改稿确认（24 小时超时默认通过）——进入配图前
- HITL 2：终稿确认（48 小时超时默认通过）——发布前
9. 幻觉检测：kb-writer 自检
不新建独立 Agent，由 kb-writer 在 revision 阶段做模式匹配（提取命令/参数/版本号与原文比对）。
10. 互链已内置
kb-writer 的 C-Step 3 已经有完整的"插入文章互链"流程（扫描 vault 找相关文章，插入"关联阅读"段落）。不需要单独的互链步骤。
11. 去AI味：humanizer skill 覆盖
kb-writer 已多次调用 humanizer skill 去除 AI 味。云天辰只做博客特有维度（合规+品牌+可读性），不去重复 humanizer 的工作。
新架构全景
用户在任意 Agent 会话中说"写博客"
↓
blog-pipeline skill（触发器 + 分类路由器）
↓
┌─────────────────────────────────────────────────────┐
│ 云天枢 Agent（编排引擎） │
│ ┌───────────────────────────────────────────────┐ │
│ │ Phase 1: kb-writer → 写草稿 + 互链 │ │
│ │ ↓ │ │
│ │ Phase 2: 云天辰(质检) ∥ SEO专家(SEO优化) │ │
│ │ ↓ │ │
│ │ Phase 3: kb-writer → 改稿 + SEO元数据 + 幻觉检测│ │
│ │ ↓ │ │
│ │ ┌── HITL 门控 1: 改稿确认 ──────────────────┐ │ │
│ │ │ 对比展示 + 通过/驳回 24h超时默认通过 │ │ │
│ │ └───────────────────────────────────────────┘ │ │
│ │ ↓ │ │
│ │ Phase 3.5: design-image-prompt-engineer │ │
│ │ Phase 4: design-yuntianguang → 生图 │ │
│ │ Phase 4.2: 质量校验 → 不合格回退重试(最多2次) │ │
│ │ ↓ │ │
│ │ ┌── HITL 门控 2: 终稿确认 ──────────────────┐ │ │
│ │ │ 完整文章+配图 通过/驳回 48h超时默认通过 │ │ │
│ │ └───────────────────────────────────────────┘ │ │
│ │ ↓ │ │
│ │ Phase 5: 发布脚本 → Hugo 构建 → Cloudflare │ │
│ └───────────────────────────────────────────────┘ │
│ 全程: 上下文摘要压缩 + Trace 日志 │
└─────────────────────────────────────────────────────┘云天枢 DAG 引擎：被低估的基础设施
这次设计中最大的发现是：云天枢已经有完整成型的 YAML DAG 引擎 v2.0，而且已经实际运行过多个 workflow。
核心能力一览：
| 能力 | 说明 | 状态 |
|---|---|---|
| YAML DAG 定义 | 步骤/依赖/并行/变量插值 | ✅ 完整 |
| Wave 并行排序 | 自动分层，同 Wave 内并行执行 | ✅ 完整 |
| 条件执行 | condition 字段控制步骤是否执行 | ✅ 完整 |
| 人工审批节点 | type: approval，暂停等用户确认 | ✅ 完整 |
| 循环迭代 | loop 字段控制重试（max_iterations + exit_condition） | ✅ 完整 |
| 断点续跑 | –resume –from 从任意步骤续跑 | ✅ 完整 |
| 反馈返工 | –feedback 增量修改 + 下游重跑 | ✅ 完整 |
| Skill 注入 | 指定 step 注入方法论 Skill | ✅ 完整 |
| 变量插值 | {{variable}} 跨步骤传递 | ✅ 完整 |
| 产出归档 | 自动保存到 workflow-runs/ | ✅ 完整 |
这些能力全部被 blog-post.yaml DAG 利用，不需要额外开发。
Agent 角色定义
云天枢（agents-orchestrator）— 编排引擎
- 职责：路由 + 编排 + 质检，不执行
- 位置：流水线的中央协调者
- 已有 268 个代理的健康档案
kb-writer（知识归档员）— 写作 + 改稿 + 发布
- 职责：写草稿、改稿、幻觉检测、执行发布
- 能力：互链（C-Step 3 内置）、humanizer 去 AI 味
云天辰（editor-blog-yuntianchen）— 博客质检
- 职责：合规检测、品牌调性、可读性
- 不负责：去 AI 味（humanizer 覆盖）、互链（kb-writer 覆盖）
- 新建原因：云天月完全是网文定向，无法复用
design-image-prompt-engineer — 提示词优化
- 职责：将泛提示词转化为摄影级精确提示词
- 能力：4 大模板（人像/产品/风光/时尚）+ 4 平台特化（MJ/DALL-E/SD/Flux）
design-yuntianguang（视觉设计师）— 配图生成
- 职责：封面图 + 文内插图生成 + 质量校验
- 工具链：ComfyUI（Z-Image-Turbo / Ideogram 4.0）→ agnes-image → step-image 降级
7 个隐藏真相
在设计过程中，我们发现了 7 个之前不知道的"真相"，它们直接影响了架构设计：
隐藏真相 1：kb-writer 已有互链能力
C-Step 3 已包含完整互链流程，不需要单独步骤。
隐藏真相 2：kb-writer 已有 humanizer 去 AI 味
日志显示已多次调用 humanizer skill。
隐藏真相 3：云天枢已有 SEO 方法论 Skill
skills/seo-content-structure.md 已存在，可直接注入。
隐藏真相 4：run-workflow.sh 是真正的执行引擎
不只是文件生成，还做 Wave 分析、拓扑排序、变量插值。
隐藏真相 5：云天月是完全网文定向的
SOUL.md 专为《我在南明做监国》定制，与博客质检完全不重叠。
隐藏真相 6：marketing-seo-specialist 是最佳 SEO 选择
有最全面的页面 SEO 优化清单。
隐藏真相 7：LoveIt 主题没有内置相关文章
互链完全靠 kb-writer 手动插入，进一步确认了其价值。
总结：复用现有基础设施，不重复造轮子
这次架构设计的核心思路是：复用现有基础设施，不重复造轮子。
云天枢的 YAML DAG 引擎、compose.md 意图路由、SOP.md 编排手册、kb-writer 的互链和 humanizer 能力、design-image-prompt-engineer 的摄影提示词框架——这些已有的能力加在一起，使得整个流水线的设计变得水到渠成。
关键数字：
- 7 步 DAG 流程（含 2 个 HITL 门控 + 1 个重试循环）
- 5 个专职 Agent（kb-writer、云天辰、marketing-seo-specialist、design-image-prompt-engineer、design-yuntianguang）
- 11 个关键决策（从分类路由到幻觉检测）
- 7 个隐藏真相（云天月的不可复用性、kb-writer 的互链能力等）
- 19 个文件变更（12 新建 + 7 修改）
下一步是端到端测试——用一篇真实的博客文章跑完整条流水线，验证每个步骤是否如预期工作。
参考来源
–全文完–
“技术终归是工具，而我们一次次认真把问题理顺，守住的其实不只是页面样式和代码输出，还有那一点不愿被混乱打败的心气，是每一个深夜仍愿点灯前行的人。”
转载请注明来自https://oklife.me。
