Claude Code 动态工作流：让 AI 自己写 Harness，这事靠谱吗

核心结论（一句话）

Claude Code 的动态工作流（Dynamic Workflows） 把”搭建 Harness”这件事也交给 Claude 自己——不再需要预先写好调度脚本，Claude 看任务后自己写确定性 JS 脚本来调度独立子 Agent；适合”不知道最优拆分方式”的探索性任务，但对已有经验的任务静态工作流仍更可控。

分类提炼

知识节点

关联图谱

上游（基于 / 来自）

下游（应用于 / 验证于）

同级（横向 / 并列）

正文要点

单 Agent 的三大退化模式

Claude Code 默认模式是单 Agent 一个上下文窗口搞定规划和执行，大多数编程任务这就够用。但有些场景单 Agent 怎么优化都跑不好——三个已知的退化模式：

  1. 偷懒：让它做一轮安全审查，50 个检查项查到 20 个就宣布完成（长上下文行为退化）
  2. 自我偏爱：让它评判自己产出，天然倾向给好评
  3. 目标漂移：上下文压缩是有损的，每压缩一次，原始需求的边缘条件、约束细节丢一点

这三个问题不是模型能力问题，是单上下文窗口同时承担规划和执行带来的架构局限。

Dynamic Workflows 工作原理

用独立的子 Agent 各自占一个干净的上下文窗口，每个子 Agent 只干一件事，由确定性的 JavaScript 脚本调度它们的执行顺序和依赖关系。

核心区别：

维度 静态工作流 动态工作流
调度脚本 提前写好，考虑各种边界 Claude 看任务后自己写
适用 已知拆分方式的任务 探索性任务
稳定性 可控 灵活但需要 Prompt 引导

六种调度模式

  1. 分类路由：一个分类 Agent 判断任务类型，分发给不同处理 Agent
  2. 扇出合并（最常用）：拆成很多小步，每步一个独立 Agent，最后合并
  3. 对抗验证：每个生成 Agent 配独立验证 Agent 专门挑毛病
  4. 生成过滤：先大量生成，再按标准筛选去重
  5. 锦标赛模式：N 个 Agent 不同策略做同一件事，两两淘汰留赢家
  6. 循环到完成：不设固定轮次，跑满足停止条件

这些模式可组合：先扇出，每个分支内部做对抗验证，合并时再跑一轮锦标赛。

实际应用场景

场景 模式 关键价值
大规模迁移和重构 扇出 + 对抗验证 Bun Zig→Rust 重写；每个修改点一个独立 Agent，天然避免交叉污染
深度验证 分类 + 扇出 提取文章里的事实性声明，每个声明派 Agent 核实，验证信息源是否可靠
排序 锦标赛 按 Bug 严重程度排 1000 条工单；比较判断比绝对评分可靠
规则遵守 分类 + 验证 CLAUDE.md 规则一条 Agent 验证一条；反向扫日志提炼新规则
根因分析 扇出 + 对抗 不锁定单一假设，分别从日志/文件/数据生成假设，每个假设面对验证者和反驳者
大规模分流 分类 + 隔离区 工单队列分类、去重、自动修复；读不可信内容的 Agent 不可执行高权限操作

什么时候不需要工作流

动态工作流消耗的 token 显著更多，适合复杂、高价值的任务。

判断标准：

用法和技巧

1
2
3
4
5
6
7
8
9
10
11
12

# 两种开启方式
ultracode  # 触发词
# 或在 Prompt 里要求 "用工作流做这件事"

# 配合 /loop 定期执行
/loop "用工作流扫最近 50 个 session..."

# 配合 /goal 硬性完成条件
/goal "不找到根因不许停"

# 限制 token 消耗
"用 10k token 解决"  # 大概一两轮对话

Prompt 模板示例：

保存工作流：按 s 可保存脚本到 ~/.claude/workflows，或通过 Skill 分发给团队。

表格：六种调度模式对比

模式 核心思想 适用场景 关键风险
分类路由 任务类型分发 异构任务批处理 分类器本身的准确性
扇出合并 拆小步并行 大规模可拆解任务 合并 Agent 的归纳能力
对抗验证 配独立验证 需要质量保证的生成 验证 Agent 也要强
生成过滤 大量生成+筛选 创意/方案探索 筛选标准的可定义性
锦标赛 两两淘汰 排序/评选 N 较大时 token 成本
循环到完成 跑到满足 开放式目标 难以停止 / token 爆炸

我的理解

适合关联的主题