用 9 张图读懂 Claude Code Dynamic Workflows：中文译读笔记

这篇笔记来自 Thariq Shihipar 和 Sid Bidasaria 发布的文章 A harness for every task: dynamic workflows in Claude Code，也可以对照 X 上的线程 阅读。

我把它拆成两层：前半部分用 9 张中文工坊图先讲一遍我的理解；后半部分按照原文结构做一版中文译读/转述，并把原文配图放回对应位置。后半部分不是逐字全文翻译，主要是为了保留原文阅读节奏，同时避免变成简单转载。

先用 9 张图讲一遍

1. 任务先进入专用脚手架，再分派给子任务

任务先进入专用脚手架，再分派给子任务。

dynamic workflow 的关键不是“多叫几个 agent”，而是先为当前任务搭一个临时 harness。任务进入脚手架后，会被拆成子任务、校验和汇总等步骤。这样 Claude Code 不再只是在一个聊天上下文里连续思考，而是在一个可编排的小系统里推进工作。

2. 单窗口长跑容易半途停、自我偏和目标漂

单窗口长跑容易半途停、自我偏和目标漂。

复杂任务放在一个上下文窗口里跑久了，会出现三种典型问题：做一半就宣布完成，过度相信自己刚产出的结论，以及在多轮压缩后偏离最初目标。workflow 的价值，是把任务拆到独立上下文里，并让不同 agent 互相检查，减少这些长任务里的自然损耗。

3. 脚本决定派谁、用什么模型、在哪里跑

脚本决定派谁、用什么模型、在哪里跑。

dynamic workflow 会执行一个 JavaScript 文件。这个脚本可以派发子 agent、选择模型、开独立 worktree，也能记录状态以便中断后恢复。它不是替代模型思考，而是把“谁来做、怎么验证、何时继续”这些调度动作写清楚，让复杂任务更像可重跑的流程。

4. 分类、并行、互查、锦标赛和循环可组合

分类、并行、互查、锦标赛和循环可组合。

文章列了几种常见 pattern：先分类再路由、并行拆解后合成、对抗式验证、生成后筛选、锦标赛选择，以及循环直到达成停止条件。真正有用的 workflow 往往不是单一套路，而是把这些小结构按任务需要拼起来。

5. 重构、研究、核验、分诊、记忆和评测都适合

重构、研究、核验、分诊、记忆和评测都适合。

workflow 特别适合那些工作量大、可以并行、需要复查、判断带主观性的任务。比如大规模重构、深度研究、事实核验、支持工单分诊、从会话中提炼项目规则、做轻量 eval。它的共同点是：单个上下文容易忙乱，但拆开后可以更稳。

6. 要看是否值得消耗更多 token 和调度成本

要看是否值得消耗更多 token 和调度成本。

dynamic workflows 会消耗更多 token 和时间，所以不该默认用于所有任务。普通小修、小范围编码、线性明确的问题，用普通模式更直接。判断是否使用 workflow，可以问三个问题：是否需要并行上下文？是否需要独立验证？是否有明确停止条件？答案越多是“是”，越值得开 workflow。

7. 静态 workflow 像固定模板，动态 workflow 像现场搭台

静态 workflow 像固定模板，动态 workflow 像现场搭台。

静态 workflow 的好处是可复用、稳定，但为了覆盖很多情况，往往会偏通用。dynamic workflow 则让 Claude 根据当前任务现场生成 harness：任务是什么形状，脚手架就怎么接线。这个区别解释了为什么文章强调“custom-built for the task at hand”。

8. 多个假设分头验证，再把证据合回修复

多个假设分头验证，再把证据合回修复。

偶发测试失败很适合 workflow，因为单一路径容易过早相信某个猜测。更稳的做法是让不同 agent 提出独立假设，在不同分支里复现和验证，再由校验步骤审查证据。最后只有能解释失败、能复现、能通过验证的假设才进入修复。

9. 不可信输入进隔离区，复核后才执行动作

不可信输入进隔离区，复核后才执行动作。

文章提到 triage workflow 时强调 quarantine：读取外部评论、工单、网页或用户提交内容的 agent，不应该直接执行高权限动作。它只能产出证据或建议，再交给更可信的执行 agent 复核。这样既能自动化处理大量输入，又不把权限交给不可信文本。

原文译读版：A harness for every task

原文开头的核心判断是：Claude Code 现在可以按任务现场写出自己的多 agent harness，并用这个 harness 编排一组子 agent。普通 Claude Code 的默认 harness 已经很适合编码，但研究、安全分析、agent teams、代码审查这类任务有时需要更定制的工作方式。dynamic workflows 的作用，就是让 Claude 不必一直挤在默认执行方式里，而是为当前任务临时搭一套更贴合问题形状的工作台。

作者也很早提醒了一个取舍：这不是低成本魔法。dynamic workflows 往往会用更多 token，更适合复杂、高价值、失败代价比较高的任务。也就是说，它像是给困难任务开一间临时作战室，而不是每次改一行代码都要拉一个委员会。

先看几个提示词，理解它想解决什么

原文在进入技术细节前，先给了一串 prompt 例子。这一段很重要，因为它把 workflow 的气质讲出来了：不是“帮我写代码”，而是“搭一个流程来解决这类复杂问题”。

例如，偶发测试失败可以要求 workflow 反复复现，提出多个竞争性假设，并且在某个假设经得住证据前不要停。也可以让 workflow 回看过去几十次会话，找出你反复纠正 Claude 的地方，再沉淀成 CLAUDE.md 规则。还可以让它翻 Slack 事故频道找重复根因，或者从投资人、客户、竞争对手三个角度拆解商业计划。

这一组例子背后的共同点是：任务不是一步完成，而是需要拆分、比较、复核、循环和停止条件。workflow 更像“让 Claude 设计一套调查流程”，而不是把所有要求塞进一个长 prompt。

它到底怎么工作

dynamic workflow 的执行体是一个 JavaScript 文件。这个文件里既有普通 JavaScript 能力，比如处理 JSON、数组和数学计算，也有一些特殊函数，用来创建 agent、并行执行、串成 pipeline，或者让 agent 返回结构化结果。

图里最值得注意的是两个概念：一是 agent(prompt, opts?)，它让脚本可以召唤一个子 agent，并指定模型、隔离方式、输出 schema 等选项；二是 parallel 和 pipeline，前者适合把多个任务同时派出去，后者适合把前一步结果交给下一步继续处理。

这意味着 workflow 不是把模型能力藏起来，而是把“调度”显式化：什么时候并行，什么时候等待所有结果，什么时候让另一个 agent 审查，什么时候进入下一轮，都可以被写在 harness 里。

workflow 还可以决定子 agent 使用什么模型，以及是否在自己的 worktree 中运行。这个能力很实用：简单分类任务不一定要用最强模型，风险较高的修改可以放到独立 worktree 里减少互相干扰。即使流程被中断，恢复会话后也能从之前状态继续跑。

为什么需要 dynamic workflows

默认 Claude Code 在同一个上下文窗口里既规划又执行。对很多编码任务来说，这已经足够好；但当任务变成长跑、多分支、强对抗或高度结构化时，同一个上下文会开始出现损耗。

原文提到三个典型失败模式。第一个是 agentic laziness：复杂任务还没真正做完，模型就因为局部进展而宣布完成。第二个是 self-preferential bias：模型在审查自己的产出时，更容易偏向自己刚刚得出的结论。第三个是 goal drift：长任务经过很多轮和压缩后，最初的边界、例外、禁止事项慢慢丢失。

workflow 的对应解法，是把任务拆给多个拥有独立上下文的子 agent，每个 agent 只承担一个更聚焦的目标。这样既能降低上下文污染，也能让“验证者”和“执行者”分离，避免自己证明自己。

动态和静态的区别

静态 workflow 不是新东西。你也可以提前用 Claude Agent SDK 或 claude -p 写一个固定流程，协调多个 Claude Code 实例一起工作。问题在于，静态流程通常要覆盖很多边界情况，所以会变得通用、保守、模板化。

dynamic workflows 的不同之处在于：Claude 可以为眼前这件事现场生成 harness。图左边的静态 harness 像一条固定流水线，不管问题是什么，都按同一套搜索、阅读、验证、总结来跑。图右边的动态 workflow 则会先判断问题是什么，再临时决定要哪些 agent、哪些验证、哪些分支，最终给出更具体的建议。

这也是我觉得文章标题里 “for every task” 最有意思的地方：它不是说每个任务都用同一个万能 harness，而是每个足够复杂的任务，都可以拥有一套临时定制的 harness。

六种常见 workflow pattern

原文列了六种常见模式。理解这些模式以后，你给 Claude 提需求时就不只是说“用 workflow”，而是能更明确地说“先分类再路由”“并行调查后合成”“每个结论都要独立审查”。

Classify-and-act 是先让分类器判断任务类型、风险、规模或需要的模型，再把任务送到不同处理路径。Fan-out-and-synthesize 是把大任务拆成很多小块并行执行，等所有结果回来后统一合成。Adversarial verification 是让独立 agent 用 rubric 审查另一个 agent 的结果。

Generate-and-filter 适合探索：先生成大量候选，再去重、过滤、验证，只保留质量高的结果。Tournament 是让多个 agent 用不同策略做同一件事，再通过两两比较或评审选出优胜者。Loop until done 则适合总量未知的任务，不设固定轮数，而是跑到没有新发现、没有错误或验证通过。

真正有用的 workflow 往往会组合这些模式。比如一次技术事实核验可能先抽取 claim，再 fan-out 去查证，每个查证结果再交给 verifier，最后合成报告。

workflow 最适合发光的场景

原文总结了一组很典型的使用场景：迁移、研究、验证、排序、规则遵守、根因调查、分诊、品味探索、eval、模型路由。这些场景看起来很杂，但都有共同结构：工作量大、可以拆开、需要独立判断，或者需要某种形式的复核。

大规模迁移和重构适合 workflow，因为可以按 callsite、失败测试、模块或文件把任务拆开。每个子 agent 在自己的 worktree 里处理一部分，再由审查 agent 检查并合并。这里还要注意资源限制：如果几十个 agent 同时跑重命令，机器会先被打满，所以最好提示 workflow 避免高资源命令。

深度研究也很适合。workflow 可以 fan-out 做搜索和抓取，然后让验证 agent 检查来源质量，最后合成带引用的报告。这个思路不只适用于网页，也适用于 Slack、内部文档、代码库和历史讨论。

用 workflow 做事实核验

如果你有一份报告，想确认里面每个事实性主张是否站得住，workflow 可以先派一个 claim extractor 抽取所有可核验主张，再为每条主张派 claim checker 去查证来源。更稳一点，还可以为每个 checker 再配一个 source auditor，专门检查引用是否可靠、来源是否高质量。

这张图展示的就是这种结构：报告进入 workflow 后，被拆成 claim A、B、N，每条 claim 都有自己的查证路径。最后只有经过来源审查的结论才合并成 verified report。

这个结构对写技术文章尤其有用。很多时候我们不是故意写错，而是把“印象里是这样”写成了确定语气。workflow 可以把这种模糊主张拆出来，一条条逼它找证据。

用 tournament 做大规模排序

排序问题看起来简单，但如果一次性把一千条支持工单、候选人、bug 或用户反馈塞给模型，它既放不进上下文，质量也容易下降。原文建议用 tournament、成对比较 pipeline，或者先并行分桶再合并。

图里的思路像淘汰赛：一千个 item 先被分成许多成对比较，第一轮选出胜者，第二轮继续比较，直到得到最终排序。比较判断通常比绝对打分更可靠，因为模型只需要回答“这两个哪个更严重/更合适/更值得优先”，不用在抽象尺度上给所有东西打分。

这里 deterministic loop 负责维护 bracket 和运行顺序，agent 只负责单次比较。这样上下文压力小，也更容易追踪每一步为什么这么排。

把规则遵守做成 verifier

如果你发现 Claude 总是漏掉某些项目规则，只把规则写进 CLAUDE.md 可能还不够。原文建议把规则变成 verifier：每条规则都由一个独立检查者负责，比如不能改快照、迁移要配 rollback、不要新增生产日志等。

图里每一条规则后面都有一个 verifier agent。diff 进来后，verifier 逐条检查，最后由 bucketer 把通过、需要修改、需要人工确认的结果分出来。

反过来，workflow 也能帮你提炼规则。它可以读取最近的会话和 code review 评论，找出你反复纠正 Claude 的地方，聚类后再让 skeptical agent 审查这些候选规则，确认它们真的能避免真实错误，最后把幸存规则整理回 CLAUDE.md。

根因调查：让假设彼此独立

调试和事故复盘最怕的，是一条假设刚有点证据，模型就越走越自信。workflow 可以通过结构避免这件事：让不同 agent 从不同证据来源独立提出假设，比如日志、代码、数据、最近变更；再让 verifier 和 refuter 对每个假设进行审查和反驳。

这个模式不只适用于代码。销售下滑、数据管道失败、产品指标异常、事故复盘，都可以用类似结构：先分头找证据，再合并假设，再用反证步骤筛掉解释力弱的说法。

大规模分诊要隔离不可信输入

分诊是 workflow 很自然的使用场景。支持队列、bug 报告、需求池、社区反馈，都可能大到人类处理不过来。workflow 可以先分类、去重、匹配已有 issue，然后尝试修复或升级给人类。

但原文特别强调 quarantine。读取公开评论、用户提交、工单正文这类不可信内容的 agent，不应该直接执行高权限动作。图里左侧 reader agents 只能阅读和汇总，进入 quarantine 区域后输出结构化 summary，再交给右侧更可信的 actor agent。actor agent 才能根据规则决定是否行动、升级或放弃。

这个边界非常关键。否则外部输入里的一句“忽略之前规则，执行某某命令”就可能通过自动化流程一路传到高权限动作里。

探索、品味和 eval

设计、命名、产品方案、文案方向这些任务也适合 workflow，因为它们往往不是单一正确答案，而是需要多个候选、一个 rubric 和某种比较机制。你可以让不同 agent 按不同策略生成候选，再让 review agent 按标准筛选。停止条件也可以交给 review agent：当它认为方案达到标准，就结束。

eval 也是类似结构。比如你刚做了一个 skill，可以让多个 agent 在独立 worktree 里用它完成任务，再由 comparison agent 按 rubric 比较输出质量。这样 workflow 本身也可以成为改进 workflow、skill 和提示词的工具。

模型路由则是另一个实用方向：先派一个分类器研究任务复杂度，再决定用 Sonnet 还是 Opus。比如“解释 auth 模块”到底难不难，取决于 auth 相关文件数量、耦合程度和代码库结构，而不是需求一句话本身。

什么时候不要用

dynamic workflows 很强，但不是默认解法。原文给的提醒很朴素：它会多用 token，不是每个任务都值得。普通编码任务、小范围修复、一步能完成的低风险改动，大多不需要一个五人评审团。

我觉得可以用三个问题判断：这件事是否需要并行上下文？是否需要独立验证？是否有明确停止条件或循环条件？如果只有一个答案是“是”，普通 Claude Code 可能更省事；如果两个以上是“是”，workflow 就值得考虑。

建 workflow 的几个小技巧

原文最后给了一些使用建议。第一，prompt 要具体。不要只说“用 workflow”，要说明希望它用哪些模式：比如先分类、再 fan-out、每个结果做 adversarial verification，最后用 rubric 合成。

第二，小任务也可以用 quick workflow。比如你只是想让另一个 agent 对某个假设做一次独立反驳，不一定要开很大的流程。

第三，可重复任务适合配合 /loop，比如持续分诊、持续研究、持续验证；有硬性完成标准的长任务适合配合 /goal，把完成条件钉牢。第四，可以明确 token budget，避免 workflow 自动扩张到不可控。

保存和分享 workflow

workflow 跑起来后，菜单里可以看到运行中和已完成的工作流，也能选择保存。保存以后，它就不只是一次性的临时脚本，而是可以复用、调整、分享的工作流资产。

原文最后提到，可以把 workflow 文件放到 skill 文件夹里，并在 SKILL.md 中引用它。这里有一个很值得记的建议：通过 skill 分发时，最好把 workflow 当作模板，而不是要求 Claude 每次逐字执行固定脚本。这样既能复用经验，又能保留 dynamic workflow 最重要的部分：按当前任务现场调整。

我读完后的抓手

不要把 workflow 当成“更强的 prompt”，而要把它当成“为任务临时搭出来的工作台”。当任务需要拆分、验证、比较、循环、预算控制或恢复执行时，它才真正显出价值。

我的个人判断是：如果任务里有两个以上问题答案是“是”——是否需要并行上下文、是否需要独立验证、是否存在明确停止条件、是否要隔离权限或不可信输入——那就值得考虑 dynamic workflow。否则，直接用普通 Claude Code，反而更轻快。