Claude Code Dynamic Workflows
工程级深度解读
不只是"AI 编排工具"——这是一个把 LLM 调用从思考空间搬到脚本运行时的架构转换。 本文从运行时模型、代码级 API、手搓版对比、选型决策框架到社区真实数据，完整拆解。
第一层：它到底是什么，在哪跑
不是"AI 自己编排自己"，而是一个 JS 运行时执行编排脚本，LLM 只在 agent() 调用时被唤醒。
2026 年 5 月 28 日，Anthropic 为 Claude Code 引入 Dynamic Workflows。核心变化：Claude 不再在上下文窗口里逐轮决定是否委派 subagent——它改为动态编写一段 JavaScript 编排脚本，交给内置运行时执行。
这段脚本是普通的 JS 代码，有变量、循环、条件分支。编排逻辑从此脱离 LLM 的上下文窗口，存储在脚本变量中，理论上可无限扩展。LLM 只在脚本调用 agent() 时被唤起。
有些问题对单个 agent 的一次执行来说太大了——跨越整个服务的 bug 搜索、涉及数百个文件的迁移、一个你想从每个角度压力测试的计划。
Some problems are too big for one pass by a single agent, especially in complex, legacy codebases. Dynamic workflows can handle all of these end-to-end.
| 维度 | Subagent（旧） | Skills | Dynamic Workflow（新） |
|---|---|---|---|
| 谁在协调 | Claude 逐轮对话决定 | Claude 遵循指令 | JS 编排脚本，运行时执行 |
| 中间状态 | 存在 Claude 上下文窗口 | 同 subagent | 存在脚本变量/文件 |
| 规模 | 每轮几个 | 同 subagent | 每次运行数十到数百个 agent |
| 上限 | 受上下文窗口限制 | 同 subagent | 16 并发，1,000 agent/工作流 |
| 中断恢复 | 重置当前轮次 | 重新开始 | 同一会话内可恢复 |
| 可复用 | 无 | 保存为 skill 文件 | 保存为 .claude/workflows/ 命令 |
| 对话影响 | 占用主对话上下文 | 同 subagent | 隔离运行，对话保持可用 |
| 权限 | 继承会话模式 | 同会话 | 子 agent 始终 acceptEdits，自动批准文件编辑 |
第二层：运行时模型
JS 运行时是指挥官，LLM 是士兵。脚本定义"谁做什么、什么时候做"，LLM 只在 agent() 调用时被唤起执行具体任务。
JS 运行时（编排器）
脚本拥有完整的 JS 执行环境：变量、循环、条件、错误处理。编排逻辑是确定性的代码——不是 LLM 的模糊决策。这意味着你可以用 try/catch 处理失败、用 Promise.all 控制并发、用变量追踪进度。
关键约束：脚本自身没有文件系统或 shell 访问权限。所有 I/O 操作都由 agent 执行。脚本的职责纯粹是协调。
LLM Agent（工作者）
每个 agent() 调用创建一个独立的 Claude 实例。它继承项目的工具白名单（acceptEdits 模式），拥有自己的上下文窗口，执行脚本分配的具体任务。
关键特性：agent 之间互不感知。它们只看到脚本传入的 prompt 和返回的结果。这避免了共享上下文污染，但也意味着 agent 之间无法直接通信。
阶段屏障语义——最容易被误解的区分
Workflow 的编排有两个关键语义，搞混会导致对"脚本到底怎么执行"的根本误解：
阶段间 = 顺序屏障（Sequential Barrier）：阶段 1 的所有 agent 完成后，阶段 2 才开始。这意味着阶段是一个同步点——前一个阶段的结果可以作为下一个阶段的输入。
阶段内 = 并发执行（Concurrent Execution）：同一阶段内的 agent 同时运行，互不等待。最多 16 个 agent 并发，超出排队。结果是"一批一起做完，再做下一批"。
陷阱：如果两个任务之间没有数据依赖，应该放在同一阶段并行执行。如果有依赖关系（任务 B 需要任务 A 的结果），必须放在不同阶段，让 A 先完成再启动 B。把无依赖的任务分到不同阶段 = 浪费时间；把有依赖的任务放在同一阶段 = 拿不到中间结果。
图灵完备 vs DAG：脚本是图灵完备的（可以有 while 循环、条件分支），但单次执行轨迹隐含 DAG 结构——节点是 agent 调用，边是数据依赖。循环多次的轨迹是 DAG 的多次展开。这不是设计限制，而是"阶段屏障 + 无共享状态"的必然结果。
数据流模型
┌─────────────────────────────────────────────────────────┐
│ 用户 Prompt │
│ "扫描整个代码库找安全漏洞" │
└─────────────────┬───────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────┐
│ Claude（规划器） │
│ 分析任务 → 编写 JS 编排脚本 │
│ 输出：script.js（含任务分解 + agent prompt 模板） │
└─────────────────┬───────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────┐
│ JS 运行时（后台执行） │
│ │
│ const files = glob("**/*.ts"); │
│ const chunks = split(files, 16); // 16 并发 │
│ │
│ const results = await Promise.all( │
│ chunks.map(chunk => │
│ agent(`审查这些文件的安全漏洞: ${chunk}`) │
│ ) │
│ ); │
│ │
│ // 对抗性审查 │
│ const verified = await Promise.all( │
│ results.map(r => │
│ agent(`挑战这个安全发现，试图推翻它: ${r}`) │
│ ) │
│ ); │
│ │
│ // 合并收敛 │
│ const final = await agent( │
│ `合并并去重这些安全发现: ${verified}` │
│ ); │
└─────────────────┬───────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────┐
│ 最终报告 → 返回用户对话 │
└─────────────────────────────────────────────────────────┘
注意：上面的数据流图基于 Anthropic 官方文档描述推断。文档确认了核心模型："The script holds the loop, the branching, and the intermediate results itself"——脚本掌握循环、分支和中间结果，是图灵完备的。但具体 API（agent() 的参数签名、返回值格式）未公开，真实脚本可能包含未文档化的内部原语。
第三层：核心架构拆解
六大阶段 + 两个内置模式 + TUI 进度面板。完整组件表、职责、数据流。
执行生命周期：六个阶段
1. Plan（动态规划）
Claude 根据 prompt 分析任务结构，决定如何分解、需要多少 agent、依赖关系。输出是一段 JS 脚本。
2. Fan-out（并行展开）
脚本执行，任务拆分为子任务分发给并行 agent。最多 16 个同时运行，超出排队。
3. Check（独立验证）
结果在合并前被独立检查。对抗性 agent 试图推翻发现。这是"自检收敛"的关键。
4. Fold-in（合并收敛）
验证后的结果合并为单一回答。去重、排序、格式化。
5. Checkpoint（断点续跑）
进度实时保存。中断后已完成的 agent 返回缓存结果，只重新运行未完成部分。
6. Save（可复用）
成功的 workflow 可保存到 .claude/workflows/（项目级）或 ~/.claude/workflows/（个人级），变为 / 自动补全命令。
组件职责表
| 组件 | 职责 | 数据流 |
|---|---|---|
| Planner LLM | 解析用户 prompt，生成编排脚本 | Prompt → JS Script |
| JS Runtime | 执行编排脚本，管理 agent 生命周期 | 调度 agent() 调用 |
| Agent Pool | 维护最多 16 个并行 Claude 实例 | 接收 prompt → 返回结果 |
| Checkpoint Store | 持久化每个 agent 的完成状态和结果 | 写入缓存 → 恢复时读取 |
| TUI Progress | 终端 UI 展示阶段/agent 进度 | 读取 runtime 状态 |
| Workflow Store | .claude/workflows/ 文件系统 | 保存/加载脚本文件 |
TUI 进度面板快捷键
浏览进度
↑/↓ 箭头键：在阶段之间导航
Enter：展开选中阶段的 agent 列表
Ctrl+C：退出进度视图（workflow 继续运行）
运行时操作
p：暂停/恢复整个 workflow
x：停止 workflow
r：重启单个失败的 agent
s：保存当前脚本为可复用命令
Ultracode 模式
Ultracode 不是模型，不是 effort level——是 Claude Code 的一个设置开关。它做了两件事：
- 向模型发送 xhigh 推理强度（等同于手动
/think的最高级别） - 让 Claude 自动判断每个任务是否值得启动 workflow（而不是用户手动触发）
触发方式：/effort ultracode（仅限 Opus 4.7 和 4.8）
限制：仅当次会话有效，新会话自动重置。Token 消耗极高。
第四层：代码级细节
脚本长什么样？有哪些 API？跟"Building Effective Agents"的理论框架如何映射？
关键事实：官方文档未公开脚本级 API。agent()、pipeline()、parallel()、phase()、log()、workflow()、args() 是内部运行时原语——Claude 在生成 workflow 脚本时使用它们，但它们不是开发者可调用的公共 API。文档原话："A dynamic workflow is a JavaScript script that orchestrates subagents at scale." Claude 写脚本，用户不手写。
市面上有些文章将这些内部函数当作公共 API 详细解读参数和返回值——这是不准确的。下文的脚本示例基于官方文档描述的行为推断，并非精确的 API 参考。
Workflow 脚本结构（推断模型）
// 基于 Anthropic 文档描述推断的脚本结构 // 真实语法可能包含未公开的元数据声明 // 阶段 1：扫描（推断行为） // 脚本将任务拆分为子任务 // 每个子任务通过 agent() 分配给独立 Claude 实例 // 阶段内最多 16 个 agent 并发执行 // 阶段 = 自然屏障：所有 agent 完成后才进入下一阶段 // 阶段 2：对抗性验证（文档确认的模式） // 独立 agent 审查阶段 1 的每个发现 // 试图推翻或确认结论 // "It can have independent agents // adversarially review each other's findings" // 阶段 3：合并收敛 // 验证后的结果合并为单一回答 // 中间结果存储在脚本变量中 // "Intermediate results stay in script variables // instead of landing in Claude's context"
// 文档确认的关键行为： // 1. 脚本拥有循环、分支和中间结果 // "The script holds the loop, the branching, // and the intermediate results itself" // → 脚本是图灵完备的（可写循环） // → 但执行轨迹隐含 DAG 结构 // （阶段=顺序屏障，阶段内=并发） // 2. Agent 隔离性 // - 每个 agent = 独立 Claude Code 会话 // - 拥有自己的上下文窗口 // - agent 之间互不感知 // 3. 权限模型（文档确认） // - 子 agent 始终 acceptEdits 模式 // - 继承会话工具白名单 // - Shell/web/MCP 不在白名单的工具 // 仍会触发权限提示 // 4. Checkpoint 机制（文档确认） // - 每个 agent 完成后结果被缓存 // - 恢复时：已完成的返回缓存结果 // - 缓存是会话范围的（内存中） // - 退出 Claude Code = 缓存丢失，从头来 // 5. 编排脚本无 I/O（文档确认） // "No direct filesystem or shell access // from the workflow itself" // Agent 负责读写和运行命令
触发与禁用
四种启动路径
1. 在 prompt 中包含 "workflow" 关键词（按 alt+w 可忽略）
2. /effort ultracode（Opus 4.7/4.8，Claude 自动判断是否启动 workflow）
3. 运行保存的命令：内置 /deep-research 或自定义 /<name>
4. 在 CLI、桌面应用、IDE 扩展、claude -p、Agent SDK 中均可用
三种关闭路径
1. /config 界面切换
2. ~/.claude/settings.json 中设置 "disableWorkflows": true
3. 环境变量 CLAUDE_CODE_DISABLE_WORKFLOWS=1
保存与复用
在 /workflows 进度视图中按 s 保存脚本。保存位置：
- 项目级：
.claude/workflows/——与仓库共享，所有人可用 - 个人级：
~/.claude/workflows/——跨项目可用，仅自己
命名冲突：如果项目级和个人级同名，项目级优先运行。
每次运行确认：显示 workflow 名称、计划阶段、token 消耗警告。可选"运行""不再询问""查看脚本""拒绝"。
与 Anthropic "Building Effective Agents" 框架的映射
Anthropic 在 Building Effective Agents 中定义了五类 workflow 模式和一类 agent 模式：
| 理论模式 | 定义 | Dynamic Workflow 对应 |
|---|---|---|
| Prompt Chaining | 顺序步骤，每步处理前一步输出 | ✅ 脚本中顺序 agent() 调用 |
| Routing | 分类输入，分派到专门处理 | ✅ 脚本中 switch/if 分支 |
| Parallelization | 任务分区并发，或多选方案 | ✅ Promise.all(agent(...)) |
| Orchestrator-Worker | 中心 LLM 动态分解+委派 | ✅ Planner LLM + agent pool |
| Evaluator-Optimizer | 一个生成、一个评估的循环 | ✅ 对抗性审查模式 |
| Autonomous Agent | LLM 在循环中自主决策 | ⚠️ 每个 subagent 内部是自主 agent，但编排层是确定性代码 |
关键洞察：Dynamic Workflow 把 Anthropic 理论框架中的五种 workflow 模式全部在代码中实现了。编排层是确定性的 JS 代码（不是 LLM 决策），执行层每个 agent 内部才是自主循环。这是"workflow 的可预测性"和"agent 的灵活性"的精确结合。
第五层：DIY 对比——没有 Workflow 之前怎么做的
把 claude -p 和 shell 脚本组合起来，手动实现类似效果。差距在哪？
手动方案：Shell + claude -p
#!/bin/bash
# 手动编排 claude -p 实现并行安全审计
# 1. 获取文件列表
files=$(find src -name "*.ts" | sort)
total=$(echo "$files" | wc -l)
chunk_size=$((total / 4))
# 2. 拆分文件到 4 个 chunk
split -l $chunk_size <(echo "$files") /tmp/chunk_
# 3. 并行运行 4 个 claude -p（每个处理一个 chunk）
for chunk in /tmp/chunk_*; do
(
cat "$chunk" | xargs cat | \
claude -p \
--output-format json \
--allowedTools "Read,Glob,Grep" \
"审查以下代码的安全漏洞。输出 JSON 格式：[{file, line, severity, description}]"
) &
done
# 4. 等待所有并行任务完成
wait
# 5. 手动合并结果
echo "[合并所有 chunk 的结果...]"
# 6. 对抗性审查？需要另写脚本...
# 7. 断点续跑？没有，中断了从头来
# 8. 保存复用？把脚本放进 .bashrc
逐项对比
| 维度 | Shell + claude -p | Dynamic Workflow |
|---|---|---|
| 并行管理 | 手动 & + wait，需要自己控制并发数 | 内置线程池，自动管理 16 并发上限 |
| 任务分解 | 手动拆文件、写 prompt 模板 | Claude 自动分析任务结构并生成脚本 |
| 对抗性验证 | 需要另写脚本，多跑一轮 claude -p | 内置，脚本中一行 agent() 调用 |
| 断点续跑 | 无。中断 = 从头来 | 同一会话内可恢复，已完成 agent 缓存结果 |
| 进度可视化 | 无，或者自己写 log | TUI 面板，实时显示每个 agent 状态 |
| 结果合并 | 手动处理 JSON/文本拼接 | 脚本变量传递，合并 agent 负责 |
| 可复用性 | 脚本文件手动管理 | 保存为 /command，自动补全 |
| 上下文隔离 | 每个 claude -p 是独立进程（✅） | 每个 agent 有独立上下文（✅） |
| 权限管理 | --allowedTools 手动指定 | 继承会话配置 + acceptEdits 自动 |
| Token 消耗可见性 | claude -p 输出 token 计数 | 汇总显示，但内部不可控 |
| 规模上限 | 取决于机器内存和 API 限速 | 硬限制 16 并发 / 1,000 agent |
| 适用场景 | 简单并行，一次性任务 | 复杂编排，多阶段验证，可复用 |
结论：对于"把文件拆 4 份并行跑一遍 claude -p"这种简单场景，shell 脚本够用。但当你需要多阶段编排 + 对抗性验证 + 断点续跑 + 可复用时，手搓的成本远超直接用 Dynamic Workflow。差距不在单个维度，而在整合度。
第六层：选型决策框架
什么时候用 Workflow，什么时候不用，什么时候考虑替代方案。
适合用 Dynamic Workflow 的场景
- 全代码库扫描——安全审计、dead code 检测、性能热点搜索，需要覆盖数百个文件
- 大规模迁移——框架升级、API 废弃替换、语言移植，涉及数百个文件批量修改
- 高置信度任务——关键代码审查、安全评估，需要"双重检查"甚至"对抗性验证"
- 可复用的团队流程——标准化 CI/CD 检查、代码规范审查、依赖升级策略
- 多信源调研——/deep-research 内置 workflow 的应用场景
不适合用的场景
- 单文件编辑——一个文件的修改用普通 Claude Code 就够了，启动 workflow 是浪费 token
- 需要频繁人工确认的任务——workflow 运行期间无用户输入，不能中途停下来问你"这样行吗"
- 对 token 成本敏感——10-100 个 agent × 每个独立上下文 = "substantially more tokens"
- 需要跨会话持久化——断点续跑只在同一会话内有效，退出 Claude Code 就从头来
- 简单并行就能搞定的——shell + claude -p 4 个并行就够的任务，不需要 workflow 的复杂度
替代方案对比
| 方案 | 适用规模 | 编排方式 | 适合谁 |
|---|---|---|---|
| Dynamic Workflow | 10-1000 agent | JS 脚本自动生成 | Claude Code Max 用户，大型任务 |
| claude -p + Shell | 2-10 并行 | 手动 Shell 脚本 | 简单并行，一次性任务 |
| Codex Goals | 1 agent 循环 | 自主迭代循环 | 单一大型任务的持续迭代 |
| n8n/Dify/Coze | 可视化节点 | 拖拽式工作流 | 非开发者，确定性编排 |
| Claude Agent SDK | 自定义 | Python/TS 代码 | 需要完全控制编排逻辑的开发者 |
诚实限制与已知问题
不是所有闪闪发光的都是金子。社区真实反馈 + 已知 bug。
产品级限制
- 16 并发上限——受 CPU 核心限制，多核机器才能跑满
- 1,000 agent/工作流——超大规模任务需要手动分批
- 同会话恢复——退出 Claude Code = 从头来，不能跨会话
- Token 消耗——Anthropic 自己说"substantially more tokens"，Max 用户都触发过上限
- Opus only——Ultracode 仅限 Opus 4.7/4.8
- 脚本无 I/O——编排脚本不能直接读写文件或执行 shell
真实世界问题
- Issue #9553——复杂多步 workflow 灾难性故障：JSON 解析错误、状态管理崩溃、跨 agent 通信失败，21 次迭代尝试后被禁用
- "Prompt 过长"错误——子 agent 在接收长 prompt 时频繁失败
- Thinking block 修改错误——阻止 workflow 启动
- "Slop debt"问题——LLM 添加代码债，让 LLM 清理 LLM 的后果——社区报告质量不佳
- 合并冲突率 3.1%——极端场景 109 波次的文件修改冲突
我的限制因素不是 Claude 能多快地自我推送代码。而是 Claude 是否能正确完成任务。
My limiting factor is not how fast Claude can self-push code. It's whether Claude can get it right.
— HN 社区评论，item?id=48311705
Token 消耗真实数据：有用户报告"第一次因为 workflow 达到了 Claude Max 限制。大约 90 个 agent 运行来审查一个相当小的包"。在 DeepSeek Flash 上进行大规模移植估算的 token 消耗约 20 亿（成本约 $20）。Claude API 定价更高——大规模 workflow 一次可能消耗 $50-$100 的 token。
旗舰案例：Bun Zig→Rust 移植
人类历史上最大规模的 AI 辅助代码库移植。但创造者自己说"很可能被丢掉"。
四阶段工作流
Phase A-1: 生命周期映射
Workflow 为 Zig 代码库中每个结构体字段映射 Rust 生命周期。这是一个极其精确的任务——每个字段的借用关系都需要正确标注。
Phase A-2: 逐文件移植
数百个 agent 并行工作。每个 .zig 文件移植为行为相同的 .rs 文件。每个文件两个审查者——一个做移植，一个做验证。
修复循环
Workflow 反复驱动构建和测试套件直到干净。失败 → 修复 → 重新测试的循环完全自动化。
优化扫描
合并后的夜间 workflow 扫描不必要的数据拷贝，进一步优化性能。
这段代码被完全丢弃的可能性非常高。我很好奇一个可工作的版本会是什么样子。
The probability that this code is thrown away entirely is very high. I was curious what a working version would look like.
— Jarred Sumner，Bun 创始人
这个案例的双面性
正面：证明了 Dynamic Workflow 在极端规模下的可行性。750K 行 × 11 天 × 99.8% 测试通过 = AI 辅助编程的里程碑。
反面：GitHub 上被标记为"AI slop"。Rust 开发者批评其包含"20 年来最糟糕的编码恐怖"，"毫无意义的'源文本一致性测试'是职业生涯中见过的最糟糕例子"。Jarred 自己说"很可能被丢掉"——能力 ≠ 判断力。
技术细节：未使用 async Rust；保持相同架构、相同数据结构；编译器辅助捕获和防止内存错误。
衍生项目：有用户基于 Bun repo 中的 workflow 文件创建了开源仿制品 AgentLoom，指向 DeepSeek Flash。
竞品格局与 Codex Goals 对比
不只是"谁有 multi-agent"。关键是编排方式、自主程度、适用场景的差异。
| 产品 | 编排方式 | 规模 | 最大差异 | 适合场景 |
|---|---|---|---|---|
| Claude Code Dynamic Workflows | JS 脚本自动生成+执行 | 10-1000 agent | 编排外置 + 对抗性验证 + 断点续跑 + 可复用命令 | 大规模代码库操作，多阶段验证 |
| OpenAI Codex Goals | 持久自主循环（plan→act→test→review→iterate） | 1 agent 长时间循环 | 跨会话持久化；"软停止"边界；自我评估和总结 | 单一大型任务的持续迭代，"设了就走" |
| GitHub Copilot Agent Mode | 单 agent + 工具调用 + MCP | 单 agent | 最深 IDE 集成；可从任务创建 PR；异步编码 | IDE 内日常编码，PR 创建 |
| Cursor | 多文件编辑，本质单 agent | 单 agent | 编辑器集成体验最好；human-in-the-loop 工作流 | 代码补全和编辑器内交互 |
| Google Jules | 云端异步 agent（Gemini 2.5 Pro） | 任务池架构 | 克隆 repo 到云 VM；完全异步；生成 PR | 提交 GitHub issue 后台处理 |
| Windsurf Cascade | 持久单 agent，多步推理链 | 单 agent | 上下文感知的结对编程 | 编辑器内交互式开发 |
| n8n / Dify / Coze | 可视化拖拽工作流 | 节点图 | 确定性编排 + 代码节点；无自主 agent | 非开发者，固定流程自动化 |
Codex Goals vs Dynamic Workflows：架构哲学对比
持久自主循环
模型：1 个 agent 在 loop 里持续工作——plan → act → test → review → iterate——直到目标可验证完成。
持久性：跨会话存活。设了之后可以走开，18 小时后回来发现 14/18 功能已发货。
"软停止"：不是硬性停止边界，而是在合适的时机自我暂停和总结。
适用：单一大型任务（"把这个 Java 游戏移植到 C#"）的长时间自主执行。
结构化多 agent 编排
模型：JS 脚本协调 10-1000 个 agent，每个 agent 做一小块工作，结果在脚本中汇聚。
持久性：仅同一会话内。退出 Claude Code = 从头来。
"硬结构"：编排脚本是确定性代码，不是自主循环。每个 agent 做什么由脚本预先定义。
适用：需要并行处理 + 对抗性验证 + 多阶段协调的复杂任务。
一句话总结：Codex Goals 是"一个很能干的人不间断地做一个大项目"，Dynamic Workflows 是"一个项目经理指挥 100 个专家并行工作"。前者适合深度迭代，后者适合广度扫描。它们解决的是不同维度的问题。
Anthropic 内部实战数据
Claude Code 团队成员 Boris 在 HN 上分享的真实使用数据。
Workflow 用来优化自身
Anthropic 内部用 Dynamic Workflow 自主实施了 20+ 项优化，将 Claude Code 的 token 使用量减少约 15%。具体项目：
- 将 tree-sitter、color-diff、yoga-layout 等 WASM/Rust 模块移植到 TypeScript，CPU 和内存使用提升 2-10 倍
- 将基于正则表达式的 bash 静态分析迁移到 tree-sitter，误报权限提示减少 45%
- Claude Agent SDK 启动时间减少 61%
- 发货 69 个代码简化 PR，删除超过 10,000 行代码
Claude Code 里程碑
Dynamic Workflows 发布同期，Anthropic 宣布：
- Claude Code 达到 $10 亿运行收入率（公开 6 个月后）
- 收购 Bun（Bun 保持开源和 MIT 许可）
- Bun 每月下载量超过 700 万，GitHub 82,000 星
- Opus 4.8 发布："允许已编写的代码缺陷不被注意的可能性降低了约 四倍"
这些数字说明 Dynamic Workflow 不是实验品——它是 Claude Code 从"编码助手"升级为"工程编排平台"的核心能力。
苏格拉底对话
从具体场景出发，追问到问题的本质。
老师：Dynamic Workflows 的核心创新是什么？
学生：并行 agent 数量从几个变成几百个。
老师：数量只是表象。真正的创新是编排逻辑从 Claude 的上下文窗口移到了脚本里。这意味着什么？
学生：上下文窗口不再是瓶颈了？
老师：对。但更深层的是——AI 的协调能力不再受限于它自己的"思考空间"。以前 Claude 就像一个将军，所有战略都在脑子里，脑子满了就打不了更大的仗。现在它把战略写成了作战计划书，交给执行引擎去跑。将军的脑子被解放了。
学生：那对抗性审查呢？这是 Anthropic 文档里反复强调的。
老师：这是最被低估的部分。传统 CI/CD 是"跑测试，过了就合"。对抗性审查是"让一个 agent 专门找另一个 agent 的茬"。这跟学术界的 peer review 是同一个模式——AI 编码第一次有了内建的科学验证机制。但要注意：对抗的有效性取决于对抗者的能力。如果对抗者自己也是 Claude，可能存在系统性盲点。
学生：Codex Goals 的"持久自主循环"跟 Workflow 的"结构化编排"哪个更好？
老师：这就像问"锤子和螺丝刀哪个更好"——它们解决不同维度的问题。Codex Goals 是深度：一个 agent 不间断迭代，适合"把一个大项目做到完成"。Workflow 是广度：100 个 agent 并行扫描，适合"把 1000 个文件都检查一遍"。真正的杀手是能把两者结合——但今天的工具还不能。
学生：Bun 那个案例，750K 行 Rust，Jarred 自己说"很可能被丢掉"……
老师：这说明能力 ≠ 判断力。Dynamic Workflows 给了你 750K 行 Rust，但它没有告诉你"该不该做这个移植"。最大的浪费不是 token，是用 AI 做了一个本来就不该做的事。这跟"AI Psychosis"是一个硬币的两面——工具能力在指数增长，判断力没有。
学生：最后一个问题——社区有人说"我的限制因素不是速度，是质量"。这说明什么？
老师：说明 DSP（Deterministic Scripting Paradigm）的价值。编排脚本是确定性代码——你读脚本就知道会做什么。但 agent 内部的执行仍然是不确定的。对抗性审查试图缓解这个问题，但它不能替代人类的判断。工具的极限不在于它能做多少，在于你能信任多少。
个性化洞察
基于你的身份和工作场景，这些是最切合的发现。
从 dead code 扫描开始体验 Workflow
Max 计划默认开启 Dynamic Workflows。建议从小任务开始：对你的项目做一次全代码库 dead code 扫描。感受 token 消耗曲线后再扩大到安全审计或大规模迁移。保存成功的 workflow 复用——这是核心价值。
对抗性审查 = 自动化测试的新维度
对抗性审查模式对 QA 来说是革命性的。用它做全代码库安全扫描、输入验证审计、死代码检测，比手动 code review 覆盖率高一个数量级。但记住：对抗者的能力边界就是审查的边界。它不能替代安全专家，但能做"第一遍粗筛"。
Anthropic 的 multi-agent 编排答案
Dynamic Workflow 是 Anthropic 对"如何编排多 agent"的回答。不是 CrewAI 那种框架定义角色，而是 AI 自己动态生成编排脚本。如果你在做 AI 产品，这提供了一个范式参考：确定性编排 + 模糊执行 的混合模式。
Codex Goals vs Dynamic Workflow 实战对比
你的 translate-analyze skill 已经在用 3 个并行 subagent。可以写一篇"Codex Goals vs Dynamic Workflows：两种 AI 编排哲学的对比"，从你的实际使用经验出发——这是原创内容，目前市面上没有深度对比。
$1B ARR + 收购 Bun = Anthropic 加速
Claude Code 公开 6 个月达到 $10 亿运行收入率。Anthropic 一周两弹（Dynamic Workflows + Zero Trust），从"编码助手"升级为"工程编排平台"。对 Cursor、Copilot 形成直接压力。Bun 收购意味着 Anthropic 正在吃掉 AI 开发工具链的上游。
选一个项目做全项目 workflow 扫描
建议流程：安全审计 → 依赖升级 → 死代码清理。每个保存为可复用 workflow。积累 3-5 个后，你就有了自己的"AI 工程工具箱"——可以分享到 GitHub 作为开源项目。