企业官网建设流程全解析

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 并返回结果。

一个典型的执行流程包括：

1. 把目标拆成可以独立执行的子任务；
2. 将子任务扇出给并行运行的智能体；
3. 按明确标准检查结果；
4. 对不合格或有争议的结果进行复核；
5. 等待必要任务完成后统一汇总；
6. 未满足停止条件时继续下一轮。

工作流中的并发有两种基本结构。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 的迁移，就是一个把任务切分、并行实现、对抗评审和测试驱动循环组合起来的例子。

用动态工作流重写 Bun

Jarred Sumner 使用动态工作流把 Bun 从 Zig 移植到 Rust。现有测试套件的通过率达到 99.8%，最终产出约 75 万行 Rust 代码，从首次提交到合并历时 11 天。

这不是“一次让 Claude 重写 Bun”，而是大约 50 个动态工作流连续运行。每个工作流都像一个工程循环：

while(task=todoList.pop()){result=implement(task)feedback=awaitPromise.all([review(result),review(result),])apply(feedback,result)}

它的核心不是智能体数量，而是把任务队列、实现、独立评审和修复循环分开。

1. 先建立迁移契约

大规模迁移之前，工作流先生成共享规则：

• PORTING.md：规定 Zig 的模式、类型和惯用写法如何映射到 Rust；
• LIFETIMES.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 tokens；
• 690M output tokens；
• 72B cached input reads；
• 按 API 价格估算约 16.5 万美元。

Claude Code 后续已经使用 Rust 移植版 Bun，Linux 上的启动速度约提升 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。
• 大规模分流：分类、去重、尝试处理，并将无法处理的项目升级给人工。
• 探索与评估：并行生成多个方向，再按统一标准筛选或进行淘汰赛。

对于读取不可信公开内容的工作流，信息收集与高权限操作应当隔离：负责读取外部内容的智能体只分析信息，真正采取行动的任务交给权限受控的智能体。

使用建议

一个有效的工作流请求，至少应该说明四件事：

1. 目标：最终要解决什么问题，而不是笼统地“研究一下”。
2. 验收标准：满足什么条件才算完成，例如测试通过、所有条目已处理，或每条论断都有来源。
3. 验证方式：是否需要独立评审者、竞争性假设或二次核查。
4. 资源边界：token 预算、并发数量、可运行的命令和权限范围。

动态不等于没有规则。预算、权限、验收条件和停止条件仍然应该明确；动态变化的是任务拆分与协调方式，而不是最终目标和安全边界。

工作流不只适用于大型任务。一次重要假设的快速对抗式评审，也可以只使用两三个智能体。但大多数常规编码任务并不需要一个五人评审团。

启用之前，可以先问三个问题：

1. 任务能否通过并行和上下文隔离获得明显收益？
2. 是否存在可以客观检查的验收标准？
3. 额外的 token、时间和计算成本是否值得？

如果任务规模小、结果容易验证，单个智能体通常更高效。如果任务能够切片、错误成本高，并且有编译器、测试、评分标准或可靠来源提供外部反馈，动态工作流才会真正发挥作用。

结语

动态工作流的价值，不是一次派出多少个智能体，而是为任务建立一套可拆分、可验证、可重试、可验收的执行结构。

Bun 的案例尤其说明了这一点：AI 提供了实现吞吐，但工程可信度仍来自迁移契约、独立评审、确定性工具、测试套件和人工监督。