为每个任务量身定制 Harness：Claude Code 中的动态工作流

source_url:“https://claude.com/blog/introducing-dynamic-workflows-in-claude-code”published_date: “2026-05-28”source_url:“https://claude.com/blog/a-harness-for-every-task-dynamic-workflows-in-claude-code”published_date: “2026-06-02”动态工作流的核心是 Claude Code 在接到任务后根据当前目标和约束生成一套专用 harness。它会把任务拆分给多个智能体并行处理检查各自的结果汇总结论并在未满足验收条件时继续迭代。传统的静态工作流需要提前定义流程并尽量覆盖可能出现的边界情况因此往往会变得越来越通用、越来越复杂。动态工作流把流程设计推迟到任务到来之后静态工作流人提前设计流程智能体按既定流程执行动态工作流人给出目标和约束智能体为当前任务生成并执行流程。这里的“动态”不是指执行过程没有规则而是任务拆分、协作方式和验证步骤会随任务变化。生成之后这些步骤仍会被写成可执行代码以支持并行、结构化交接、恢复和重复执行。Agent、Skill 与动态工作流分别解决不同层次的问题Agent把一个明确任务交给独立智能体Skill沉淀可复用的方法与领域知识由 Claude 根据上下文选择步骤动态工作流编排多个阶段和智能体定义如何拆分、协作、验证、汇总和重试。因此单个智能体能够完成时直接使用 Agent重点是复用经验时使用 Skill只有任务需要稳定的多阶段协作时才使用动态工作流。动态工作流适合规模大、耗时长、能够并行或者必须独立验证的任务例如跨代码库排查 bug、大规模迁移、深度研究、事实核查和批量排序。它通常会消耗更多 token不应该成为所有任务的默认选择。示例提示词下面几个例子可以帮助理解动态工作流适合解决什么问题「这个测试大概每跑 50 次会失败 1 次。搭一个工作流来复现它。针对这个竞态条件提出若干互相竞争的理论直到只剩一个能经受证据检验的理论。」「用一个工作流把我最近 50 次会话过一遍找出我反复在做的纠正并把其中稳定出现的部分变成CLAUDE.md规则。」「让不同智能体分别站在投资人、客户和竞争对手的视角审查这份商业计划书再综合出最值得处理的问题。」「这里有 80 份简历。先向我确认评分标准再完成排序并对前十名做二次核查。」「把博客草稿中的技术性论断逐条提取出来对照代码库核实不要发布未经验证的内容。」这些任务并非不能用 subagent 完成。动态工作流的提升在于它把多智能体协作变成一套可验收的批处理系统其中包含任务拆分、证据标准、独立反驳、汇总规则和失败重试。动态工作流如何运作在系统层面动态工作流并不是仅靠 Skill 的提示来暗示模型自由发挥而是宿主环境直接向 Agent 注册了一个专用的工作流工具例如workflow。模型在工具定义中看到完整的参数契约与语法指南在需要编排时生成一段受限的 JavaScript 脚本作为工具参数提交。这段脚本不是在原生 Node.js 或普通 JS 运行时中执行而是运行在宿主构建的隔离沙箱如vm上下文中。真正的多智能体能力来自宿主注入的一组非原生原语JavaScript 负责控制流利用循环、分支、数组与异步等待组织任务流程编排层本身不产生模型推理 token宿主注入编排原语提供agent()、parallel()、pipeline()、phase()、log()、budget等能力并对Date.now()、Math.random()等可能破坏可重现性的操作做确定性约束与静态检查子智能体承担实际执行每个agent()调用在独立上下文甚至隔离的 git worktree中启动一个新智能体由它真正读取代码、调用工具、消耗 token 并返回结果。一个典型的执行流程包括把目标拆成可以独立执行的子任务将子任务扇出给并行运行的智能体按明确标准检查结果对不合格或有争议的结果进行复核等待必要任务完成后统一汇总未满足停止条件时继续下一轮。工作流中的并发有两种基本结构。parallel()是屏障同时执行一批任务等全部完成后再继续适合全局汇总、去重和统一决策。pipeline()是流水线每个条目完成当前阶段后即可进入下一阶段不必等待其他条目适合逐文件执行“分析—修改—验证”。判断标准是下一步需要上一阶段的全部结果还是只需要当前条目自己的结果。不同阶段还可以通过 JSON Schema 传递结构化结果。运行时会检查输出是否符合 Schema并在不符合时要求修正使 findings、files、verdicts 等字段可以被下游稳定使用而不必依赖正则解析自然语言。Schema 相当于智能体之间的接口契约。如果执行中断恢复时会重放确定性的编排逻辑并复用已经完成的智能体结果因此随机数、当前时间等不应直接改变控制路径需要时应作为参数显式传入。为什么需要动态工作流默认的 Claude Code harness 要在同一个上下文窗口里完成规划、执行和检查。常规编码任务通常没有问题但长时间运行、大规模并行或高度对抗性的任务容易出现三种失效模式智能体惰性Agentic laziness复杂任务只完成了一部分智能体就宣布结束。例如安全评审有 50 个检查项却只处理了 35 个。自我偏好偏差Self-preferential bias同一个智能体既提出结论又验证结论容易维护自己的原有判断而不是主动寻找反例。目标漂移Goal drift交互轮数增加、上下文多次压缩后边界条件、验收标准和“不要做什么”等约束逐渐丢失。这些问题并非只有动态工作流才能缓解。任务清单和停止条件可以检查完成度独立 subagent 可以交叉验证目标文件、Skill 和 Hook 可以反复注入或强制检查约束。动态工作流的增量在于把这些机制组织成运行在对话之外的可执行流程它维护任务状态和依赖为子任务分配独立上下文在必要位置设置验证者并根据结构化结果决定接受、重试或继续执行。即使对话被压缩或执行中断编排状态仍可恢复。动态工作流通过独立上下文、显式任务列表、验证角色和停止条件把规划变成可以持续执行的程序而不是只存在于当前对话中的临时推理。六种常见模式分类并行动Classify-and-act先判断任务或输入属于哪一类再路由给不同的智能体或处理逻辑。分类器也可以放在末尾决定结果应该接受、重试、升级还是交给人工。扇出并综合Fan-out-and-synthesize把任务拆成许多独立部分为每部分运行一个智能体最后等待全部必要结果完成后统一综合。它适合按文件检查代码、按章节核查报告、按候选人评估简历或按数据源调查问题。对抗式验证Adversarial verification一个智能体生成结果另一个独立智能体假设它是错的主动寻找反例、遗漏和证据不足。它适合安全评审、事实核查、代码迁移和其他错误成本较高的任务。生成并筛选Generate-and-filter先生成一批候选再按评分标准验证、去重和筛选。生成与筛选相互独立适合命名、创意探索和方案设计。淘汰赛Tournament让多个智能体分别完成同一任务再通过两两比较逐步选出更好的结果。对于主观性较强的判断比较两个方案通常比给大量方案做绝对评分更稳定。循环直到完成Loop until done不预设固定轮数而是持续运行直到满足明确条件例如编译和测试全部通过、日志中不再出现目标错误、没有新的有效发现或所有条目都已处理。这些模式可以组合使用。Bun 从 Zig 到 Rust 的迁移就是一个把任务切分、并行实现、对抗评审和测试驱动循环组合起来的例子。用动态工作流重写 BunJarred Sumner 使用动态工作流把 Bun 从 Zig 移植到 Rust。现有测试套件的通过率达到 99.8%最终产出约 75 万行 Rust 代码从首次提交到合并历时 11 天。这不是“一次让 Claude 重写 Bun”而是大约 50 个动态工作流连续运行。每个工作流都像一个工程循环while(tasktodoList.pop()){resultimplement(task)feedbackawaitPromise.all([review(result),review(result),])apply(feedback,result)}它的核心不是智能体数量而是把任务队列、实现、独立评审和修复循环分开。1. 先建立迁移契约大规模迁移之前工作流先生成共享规则PORTING.md规定 Zig 的模式、类型和惯用写法如何映射到 RustLIFETIMES.tsv提前分析结构体字段应该对应怎样的 Rust lifetime。这些规则避免数十个智能体各自发明一套迁移方法让不同文件遵循同一组所有权、生命周期和类型约定。2. 按文件做机械迁移每个.zig文件对应生成一个.rs文件。目标不是立刻写出最优雅的 Rust而是先尽量保持原有行为先保语义再做 Rust 化的重构和优化。迁移本身已经引入了大量变量。如果同时改变行为、架构和语言风格出现问题后就很难定位原因。机械转换可以让旧实现、编译器和测试套件共同约束结果。3. 每个实现配独立评审典型分工是一个智能体实现两个或更多智能体负责对抗式评审。评审者不依赖实现者的推理只看代码差异和行为并被要求假设实现有错、主动寻找问题。这不是简单地“多看一遍代码”而是避免同一个上下文为自己的方案辩护。4. 用编译和测试驱动修复迁移结果进入持续修复循环修复 Rust 编译错误修复bun test、bun build等子命令并运行完整的 TypeScript 测试套件。TypeScript 测试与底层实现语言无关因此可以同时约束 Zig 版和 Rust 版。整个过程可以概括为旧 Zig 行为 PORTING.md LIFETIMES.tsv Rust 编译器 TypeScript 测试套件 对抗式评审 尽量等价的 Rust 实现Bun 适合这种工作流一个重要前提是旧实现和测试套件共同构成了“行为规格”。智能体不是凭空创造一个 runtime而是在一组可检查的约束下寻找等价实现。5. 修复过程而不只是修复结果如果 Claude 总是错翻某一种 Zig 模式做法不是手工修改散落在数百个文件中的所有实例而是修改PORTING.md、workflow prompt、生命周期映射或修复循环再重新生成或检查受影响的代码。这相当于从“修复一个 bug”上升到“修复产生这类 bug 的过程”。流程修正以后同类问题可以批量消除。6. 迁移后的优化基础迁移完成后一个通宵运行的工作流继续处理不必要的数据拷贝并为每项修改分别创建 PR供最终评审。动态工作流因此不只负责一次性转换也可以继续承担清理和优化。规模、成本与结果公开信息显示这次迁移包括约 50 个动态工作流11 天连续运行535,496 行 Zig 源代码约 75 万行 Rust 代码5.9B uncached input tokens690M output tokens72B cached input reads按 API 价格估算约 16.5 万美元。Claude Code 后续已经使用 Rust 移植版 BunLinux 上的启动速度约提升 10%。Jarred 在 Rewriting Bun in Rust 中介绍了这次迁移但没有公开完整的 workflow JavaScript 脚本。可以复用的是它的工作流结构和工程方法而不是一份可直接复跑的源码。Simon Willison 后来通过二进制字符串验证了 Claude Code 中存在 Rust 移植版 Bun 和对应的 Rust 源文件路径参见 Claude Code in Bun in Rust。这个案例没有证明什么Andrew Kelley 在 My Thoughts on the Bun Rust Rewrite 中提出了一个关键质疑测试套件通过不等于数十万行新代码已经得到充分评审如果原来的测试没有发现 Zig 实现中的问题同一套测试也不能自动证明 Rust 实现没有问题。所以Bun 案例不能简单理解成“AI 可以安全重写大型软件”。更准确的结论是AI 大幅提高了实现吞吐 但可信度来自迁移契约、独立评审、编译器、测试套件、人工监控和后续 rollout。动态工作流放大的是执行能力而不是自动消除工程风险。如果缺少稳定的行为规格、可靠的测试和明确的验收标准增加智能体只会更快地产生难以验证的代码。适合哪些场景动态工作流尤其适合以下任务迁移与重构按文件、模块、调用点或失败测试切分并行修改后独立评审。深度研究与验证并行检索不同来源逐条核查论断再综合带证据的结论。根因调查让不同智能体基于日志、代码、数据和近期变更提出竞争性假设再逐一验证。排序与分级对大量简历、工单、bug 或方案先分桶、比较和排序再复核靠前结果。记忆与规则提炼从历史会话和代码评审中找出反复出现的纠正验证后写入CLAUDE.md。大规模分流分类、去重、尝试处理并将无法处理的项目升级给人工。探索与评估并行生成多个方向再按统一标准筛选或进行淘汰赛。对于读取不可信公开内容的工作流信息收集与高权限操作应当隔离负责读取外部内容的智能体只分析信息真正采取行动的任务交给权限受控的智能体。使用建议一个有效的工作流请求至少应该说明四件事目标最终要解决什么问题而不是笼统地“研究一下”。验收标准满足什么条件才算完成例如测试通过、所有条目已处理或每条论断都有来源。验证方式是否需要独立评审者、竞争性假设或二次核查。资源边界token 预算、并发数量、可运行的命令和权限范围。动态不等于没有规则。预算、权限、验收条件和停止条件仍然应该明确动态变化的是任务拆分与协调方式而不是最终目标和安全边界。工作流不只适用于大型任务。一次重要假设的快速对抗式评审也可以只使用两三个智能体。但大多数常规编码任务并不需要一个五人评审团。启用之前可以先问三个问题任务能否通过并行和上下文隔离获得明显收益是否存在可以客观检查的验收标准额外的 token、时间和计算成本是否值得如果任务规模小、结果容易验证单个智能体通常更高效。如果任务能够切片、错误成本高并且有编译器、测试、评分标准或可靠来源提供外部反馈动态工作流才会真正发挥作用。结语动态工作流的价值不是一次派出多少个智能体而是为任务建立一套可拆分、可验证、可重试、可验收的执行结构。Bun 的案例尤其说明了这一点AI 提供了实现吞吐但工程可信度仍来自迁移契约、独立评审、确定性工具、测试套件和人工监督。