ARTICLE · 1114319
Claude Code 动态工作流:AI 开始临场为自己造 Harness
Claude Code 上线了一个叫动态工作流(Dynamic Workflows)的新能力。它可以临场为自己写一套量身定制的多智能体系统(harness)**——自己拆任务、自己派活、自己开子智能体并行、自己安排"AI 审 AI",最后自己收拢结果。
Claude Code 默认的 harness 是为写代码设计的,但事实证明大量任务"长得就像编码任务",所以它顺手也能干很多别的活。不过总有一些任务,官方必须在其之上定制专门的 harness 才能发挥极致性能——比如深度研究、安全分析、智能体团队、代码审查。
这类定制能力被开放成了"动态工作流":你可以让 Claude 当场创建一个针对手头任务的专属 harness,还能保存下来、分享复用。
先提醒一句:动态工作流往往更费 token,最适合复杂、高价值的任务。
一、先看 8 个提示词,感受一下冲击力
在讲技术细节之前,先看官方给出的示例提示词:
"这个测试大约 50 次运行里会挂 1 次。搭一个工作流来复现它。复现出来所有问题之前,不要停。" "用工作流翻一遍我最近 50 个会话,挖掘我反复犯的同类错误,把高频项沉淀成 CLAUDE.md规则。""用工作流翻 Slack #incidents过去六个月的记录,找出那些反复出现、却始终没人提工单的根因。""拿我的商业计划书跑一个工作流,让不同的 agent 分别以投资人、客户和竞争对手的视角把它撕碎。" "这里有一文件夹 80 份简历,用工作流为后端岗位排序,并对前十名做二次复核。用 AskUserQuestion 工具面试我。" "我要给这个 CLI 工具起个名字。用工作流头脑风暴一堆候选,然后打一场锦标赛,选出前 3 名。" "用工作流把 User 模型在所有地方重命名为 Account。" "用工作流逐条核对这篇博客草稿里的每一个技术论断与代码库是否一致,我不想发布任何有错的内容。"
这里面一大半根本不是"写代码"的活:复盘会话、翻工单、审商业计划、筛简历、起名字。
动态工作流的能量,恰恰在非技术任务上经常更猛。
二、它是怎么运转的
动态工作流的本质,是执行一个 JavaScript 文件,里面有几个特殊函数,用来生成和协调子智能体(subagent)。三个积木:

动态工作流也需要外加 JSON、Math、Array 等标准 JS 函数用于处理数据。
两个值得划重点的能力:
1. 智能分级。 工作流可以决定每个 agent 用什么模型、要不要跑在独立的 worktree 里——等于让 Claude 自己按需选择"智力等级"和"隔离级别"。简单的分类用 Haiku,硬核的推理上 Opus,互不干扰还省钱。
2. 可恢复。 工作流被中断(比如你手动打断或关了终端),恢复会话后它能从断点继续跑。
三、为什么要"动态":静态的失效原因
用默认方式让 Claude Code 干活时,它在同一个上下文窗口里既要规划又要执行。日常编码没问题,但面对长时运行、大规模并行、高度结构化或对抗性的任务,就会崩。
上下文越长、任务越复杂,三种失败模式就越明显:
1. 智能体惰性(Agentic laziness)——干到一半就宣布完工。比如安全审查清单 50 项,处理完 35 项就举手说"做完了"。
2. 自我偏好(Self-preferential bias)——自己查自己,查了个寂寞。Claude 倾向于偏爱自己的产出,尤其是让它按评分标准给自己的结果当裁判时。
3. 目标漂移(Goal drift)——干着干着忘了初心。多轮对话后(尤其是上下文压缩后),对原始目标的忠诚度逐渐流失。每一次摘要都是有损压缩,边界条件、"不许做 X"这类约束,就这么被压丢了。
而工作流的解法非常"结构化":把任务分给多个拥有独立上下文窗口、目标单一且相互隔离的子智能体。惰性、偏见、漂移,从机制上被摁死。
四、动态 vs 静态:一次真正的范式转移
你可能之前就用 Claude Agent SDK 或 claude -p 搭过"静态工作流",协调多个 Claude Code 实例一起干活。但静态工作流要兼容所有边界情况,所以往往只能做得足够通用。
以"要不要把支付服务迁到新服务商"这个问题为例:

凭借 Claude Opus 4.8 和动态工作流,Claude 已经聪明到可以为自己量身定制 harness 了。
五、六种核心模式,背下来就能用
直接开口让 Claude 建工作流就行,也可以用触发词 ultracode 确保它一定走工作流。但建立一套心智模型,你才知道什么时候用、怎么用提示词去"掰"它。Claude 建工作流时,常用以下六种模式自由组合:

1. 先分类,再行动(Classify-and-act)先用一个分类器 agent 判断任务类型,再路由给不同的 agent 或行为。也可以反过来,在末端用分类器决定输出。
2. 扇出再综合(Fan-out-and-synthesize)把任务拆成大量小步骤,每步一个 agent,最后统一综合。步骤多、或者每步都需要干净的独立上下文(避免交叉污染)时特别好用。综合步骤是一道屏障:等所有 agent 全部完工,再把结构化产出合并成一份结果。
3. 对抗性验证(Adversarial verification)每派一个干活的 agent,就再派一个独立的 agent,按评分标准对它的产出进行对抗性审查。
4. 生成再筛选(Generate-and-filter)先生成一批想法,再按评分标准或实际验证来筛选,去重,只留下经过检验的高质量想法。
5. 锦标赛(Tournament)不分活,让 agent 抢活:开 N 个 agent 用不同思路攻克同一个任务,再由裁判 agent 两两对决式打分,直到决出冠军。
6. 循环到收工(Loop until done)工作量未知的任务,不设固定轮数,而是循环生成 agent 直到满足停止条件(没有新发现、日志里不再报错)。
六、实用场景
1. 迁移与重构
Bun(去年claude收购的那个公司) 就是用工作流从 Zig 重写为 Rust 的。(详见 Bun 作者 Jarred Sumner 的推文线程,以及官方"AI 代码迁移"实践——已经跑通了百万行级代码库的迁移。)
关键打法:把任务拆成可独立操作的单位(调用点、失败的测试、模块),每个修复在独立 worktree 里开一个子智能体去改,再让另一个 agent 对抗性审查,最后合并。一个小技巧:告诉 agent 别用资源密集型命令,这样能最大化并行而不榨干你的机器。
2. 深度研究
官方在 Claude Code 里发布了 /deep-research 技能,底层就是动态工作流:分发搜索、抓取来源、对抗性核实论断、综合成一份带引用的报告。
研究来源不止于websearch:让 Claude 从 Slack 里汇编状态报告,或在代码库里深挖一个功能的实现原理,都是同一套打法。
3. 深度核查
手里有份报告,想逐条核实每个事实论断?让一个 agent 先识别全部事实论断,然后每条论断派一个子智能体细查,还可以再派"信源审计员"核查每个来源本身的质量。

4. 大规模排序

给 1000+ 条工单按严重程度排序?一次性塞进一个 prompt,质量会掉,上下文也塞不下。解法:打锦标赛、跑两两比较的流水线(比较判断比绝对打分更可靠)、或分桶并行排序再归并。每次比较都是独立 agent,循环本身只保存"赛程表",不需要把 1000 条全装进一个上下文。
5. 记忆与规则遵循
总有几条规则 Claude 老是违反,写进 CLAUDE.md 也没用?那就建一个"一规则一核查员"的工作流,每条规则由一个独立核查员 agent 检查,再配一个"怀疑论者"人设的子智能体复查标记,把误报压下去。
反向玩法也成立:挖掘近期会话和 code review 里你反复给出的纠正,用并行 agent 聚类,再对抗性验证每个候选规则——"这条规则真能防住一次真实错误吗"——幸存者沉淀进 CLAUDE.md。
6. 根因调查
调试的最佳姿势是多个独立假设分别验证,但在单一上下文里,Claude 会有自我偏好。工作流从结构上杜绝这一点:分别基于日志、文件、数据,让不同 agent 各自生成假设,每个假设再面对一个"验证者 + 反驳者"评审团。
这不止是代码的事:销售(为什么三月销量掉了?)、数据工程(管道为什么挂了?)、任何复盘,都适用。
7. 大规模分诊
每个团队都有处理不完的 backlog:工单、bug、用户反馈。分诊工作流对每条做分类、去重、然后行动(尝试修复,或升级给人类)。
这里有个关键安全模式——隔离区(Quarantine):接触不可信公开内容的 agent 一律禁止高权限操作;高权限操作只由"行动"agent 执行,而且它只看到前者的摘要。配合 /loop,可以 7×24 小时持续运转。
8. 探索与品味
设计、命名这类主观任务,让 Claude 探索一堆方案,给审查 agent 一份"什么是好方案"的评分标准,达标才算完成;也可以用锦标赛按标准排出名次。
9. 轻量评测
在 worktree 里开独立 agent 跑任务,再开比较 agent 按评分标准打分。比如评估并持续打磨你自己创建的 skill。
10. 模型与智力路由
让一个分类器 agent 先侦察、再决定用哪个模型。比如"解释 auth 模块的工作原理"——最佳模型取决于 auth 模块有多少文件、代码库长什么样。分类器调研后,再路由到 Sonnet 或 Opus。
七、什么时候千万别用
工作流还很新,不是每个任务都需要,而且可能显著更费 token。日常编码时先问自己:这活真需要更多算力吗?大多数传统编码任务,不需要 5 个审查员的评审团。
架构判断同理:选多智能体还是单智能体,逻辑是一样的——并行与专业化,必须挣得过它的协调成本。
八、四个进阶技巧
1. 提示要具体。 把上面这些模式直接写进提示词,效果最好。另外工作流不是只干大事——可以要求"快跑一个小工作流",比如对一个假设做一次快速对抗审查。
2. 组合 /goal 和 /loop。 可重复的工作流(分诊、研究、核查)配 /loop 定时执行,配 /goal 设硬性完成条件。
3. 设 token 预算。 直接在提示词里说"1 万 token 以内",就会设上限。

4. 保存与分享。 在工作流面板按 s 即可保存;存入 ~/.claude/workflows,或者通过 skill 分发——把工作流 JS 文件放进 skill 文件夹,在 SKILL.md 里引用即可。官方建议让 Claude 把这些工作流当作"模板"而非逐字执行的脚本。

官方面板长这样:review-changes 跑了 14 个 agent、48.2 万 token、6 分 12 秒;deep-research 跑了 22 个 agent、110 万 token、11 分 3 秒。真·大力出奇迹。
结语
官方在文末说得克制又真诚:把工作流当作扩展 Claude Code 的新起点,用它去探索以前没试过的用法——最好的用法,还没被发现。多智能体系统最难的一环从来不是模型,而是编排。当编排本身也被自动化,剩下的瓶颈,只剩你的想象力。