动态工作流让模型即时编写自己的多 Agent 执行逻辑。但比功能本身更值得想清楚的是：编排中，哪些流程该写死，哪些该动态生成？
你让 AI 助手去复现一个偶发 bug，它查了日志、跑了测试、看了代码，然后在同一个对话窗口里同时规划下一步和执行当前步骤。跑了几十次之后，它可能提前宣布"已修复"，其实根本没跑完。
这不是假设。在单个上下文窗口里同时规划和执行，模型会遇到三类典型问题：做到一半就停（惰性），偏好自己之前的结论（自我偏差），以及在多轮对话后逐渐丢失原始目标（漂移）。
动态工作流（dynamic workflow）是一种应对方式——模型不再依赖固定框架，而是针对当前任务即时编写一套多 Agent 编排逻辑：拆分步骤、调度独立的子 Agent、编排验证流程。这个功能由 Anthropic 团队在 2026 年 5 月随 Claude Code 发布，执行载体是一个 JavaScript 文件，通过特殊函数生成和协调子 Agent。
但比"怎么用"更重要的问题是：编排中，哪些流程该写死，哪些该动态生成？
隔离解决三类问题，但底层是两种原因
前面提到的三类失败——惰性、自我偏差、目标漂移——直觉上都可以归因于"上下文太长"。但仔细看，隔离解决的其实是两种完全不同的问题。
上下文隔离解决惰性和漂移。根源在模型架构层面：上下文越长，每个 token 分到的注意力预算越薄；加上中间的上下文压缩必然有损——每一次摘要都是有损的，边界情况的需求或"不要做 X"之类的约束细节可能丢失。这是结构性问题，把单窗口做得更强治标不治本，只能拆短。动态工作流为每个子 Agent 分配独立的上下文窗口和聚焦目标，正是这个逻辑。
身份隔离解决自我偏差。定义很精确：模型"倾向于偏好自己之前的结果或发现，尤其是在被要求按照评分标准进行验证或判断时"。根源不是长度，而是"运动员兼裁判"——模型在生成一个结论的过程中积累了大量推理上下文，再让它自己验证，认知结构没变，决策就不会变。缩短上下文也救不了。
这就是为什么"对抗性验证"被单独列为一种编排模式：对每个生成的 Agent，运行一个独立的 Agent 按评分标准验证其输出。验证者和生成者不共享推理轨迹，这是身份隔离，不是上下文隔离。
区分这两种原因决定了你在编排中选择哪种策略：上下文问题靠拆分解决，身份问题靠对抗解决。
传统代码管流程，Agent 管判断
动态工作流的执行载体是一个 JavaScript 文件，其中包含少量特殊函数用于生成和协调子 Agent，其余都是标准 JavaScript——JSON、Math、Array。这个技术选择不是偶然的。
架构的核心原则是：传统代码管流程控制，Agent 管单次判断。
循环、分支、赛程表、扇出屏障、重试逻辑——这些要求可靠、可恢复、可审计的部分用传统代码写。单次判断、生成、比较这些需要智能但上下文干净、目标单一的任务，交给子 Agent。
一个特性正好印证了这一点：如果工作流被中断（比如用户主动退出终端），恢复会话后工作流将从中断处继续执行。这之所以能做到，正是因为流程控制是传统代码，中间状态可以被持久化。如果把编排逻辑也交给模型，"中断恢复"就变成了另一个需要智能判断的问题。
把要求确定性的编排交给模型是错配。模型擅长的是在干净的上下文中做高质量的单次判断，不擅长在长链路中维护状态一致性。
工作流还可以决定子 Agent 使用哪个模型以及是否在独立的 worktree 中运行。这意味着编排层可以按任务复杂度路由到不同智能级别的模型——比如用轻量模型做分类路由，用高级模型做复杂判断。这个"模型路由"本身也是传统代码在做决策。
三种核心编排模式
原文列出了六种编排模式，但深入理解其中三种就够建立心智模型：
1. 扇出-综合（把大任务拆小）
把任务拆成多个小步骤，每个步骤一个 Agent，最后综合结果。综合步骤是一个屏障——等所有扇出 Agent 完成，再合并结构化输出。典型例子是深度研究：扇出网络搜索、获取信息源、对抗性验证声明，综合生成带引用的报告。
2. 对抗性验证（让结果更可靠）
对每个生成 Agent 的输出，运行独立 Agent 按评分标准验证。人类做评审受社交压力影响，而编排中你可以直接下令："你的任务是推翻这个结论，除非证据压倒性地支持它。"这是有罪推定式的验证，把证伪主义搬进了 Agent 编排。
一个关键判断：比较判断比绝对评分更可靠。让 Agent 做成对比较（A 和 B 谁更好），远胜于让它打绝对分——绝对分缺乏锚点，跨样本不一致；成对比较只需局部判断，确定性高得多。
3. 循环直至完成（处理不确定性）
对工作量不确定的任务，循环生成 Agent 直到满足停止条件，而不是固定次数的遍历。典型例子是："这个测试偶发失败，形成多个竞争假说，不要停下来直到有一个假说经受住了证据检验。"
这三种模式在实际任务中经常组合使用。大规模代码迁移就是典型：先拆（把迁移分解为调用点、失败测试、模块等步骤）→ 每个步骤扇出一个子 Agent 在独立 worktree 中执行修复 → 再对抗性审查 → 最后合并。
哪些流程该写死，哪些该动态生成
动态工作流消耗更多 token，最适合复杂的、高价值任务。对于常规任务，应该先问一句："这真的需要多 Agent 编排吗？大多数传统任务不需要 5 个评审者的评审团。"
但 token 成本不是唯一的衡量维度。更根本的问题是：这个任务的哪些部分该写死，哪些可以动态生成？
判断标准只有一个：这个部分的价值是"省事"还是"一致性"？
只图省事的部分——重写无风险、逻辑简单、可以随时重新生成——会随着模型变强而被动态生成逐步替代。现写成本越低，固化的门槛就越高。今天值得预制的编排逻辑，明天模型可能几句话就能写得更好。
必须一致的部分——需要每次完全相同、已验证、可审计、团队共享、合规——不会被替代。它的价值恰恰在"写死"本身，而写死排斥动态化。
模型评测是典型的"必须一致"场景。它的灵魂是可比较性和可复现性——必须固定同一套评分标准、同一套比较协议、同一套聚合算法，否则跨时间的分数互不可比，全是噪音。所以评测工作流应该版本化、当代码审查、纳入持续集成。模型再强也不该让它动态化评测流程，价值恰在"每次一样"。
更微妙的是，过程和产物可以分别判断。一个例子：用 Agent 动态探索一个新模型的输出特征，发现它总是漏掉某个维度。这个发现值得写成固定规则加进评测标准里——因为一旦确认某个维度重要，它就应该成为每次评测的必检项，保证跨模型的可比性。但下次换新模型，你还是会重新跑一遍探索，因为新模型可能漏掉的是另一个维度，而哪些维度会漏，恰恰是你无法提前预知的。探索路径可以动态生成，探索结论应该固化为标准。
算力的边际价值取决于信息密度
我用动态工作流调研一个刚上线一周、公开证据高度集中于单一案例的新功能，调度了近百个子 Agent、消耗数百万 token，最终发现可挖掘的真实样本本就稀薄。信息密度低的任务，普通会话加几次定向搜索就能达到相近结论。
动态工作流的价值在"单 Agent 难以胜任"的高价值复杂任务。一个真实案例是 Bun 的代码重写。Bun 是一个用 Zig 语言编写的 JavaScript 运行时，以极致的启动速度著称。2026 年他们决定把约 96 万行 Zig 重写为 Rust（PR #30412：6755 commits、2188 个文件、新增约 75 万行 Rust），核心移植约 6 天，99.8% 既有测试通过，目前已合入 canary 分支但尚未进入生产环境。
这个任务之所以需要动态工作流，是因为它同时踩中了三个条件。第一，信息极度分散——2188 个文件需要逐一处理，没有任何一个上下文窗口能装下全部信息。第二，每个文件的改写都需要独立验证——Bun 团队为每个文件配了两名审查者做对抗式审查，尝试推翻对方结论，推不翻才算通过。第三，容错率极低——运行时级别的代码重写，错误代价远超普通重构。
三个条件叠加，单个 Agent 在单一窗口中根本不可能完成：上下文装不下，验证会自我偏差，且没有中断恢复能力。动态工作流正好逐一对应——扇出拆文件、对抗性验证保正确、传统代码控制流保证中断可恢复。
算力的边际价值取决于可挖掘信息的密度，而非任务听起来多大。
编排框架的核心问题从来不是"能不能动态"，而是"什么该写死"——能被动态生成替代的部分终将消亡，不能被替代的部分才是架构的核心。
词语注释
- 动态工作流：模型在运行时即时编写的多智能体编排逻辑，而非预先固定的流程
- 子智能体：在独立上下文中运行的子任务执行者，与主智能体不共享推理过程
- 上下文压缩：对话过长时对历史内容做摘要以节省空间，但摘要是"有损"的，细节会丢失
- 对抗性验证：让独立的验证者以"有罪推定"的方式尝试推翻结论，推不翻才算通过
- 确定性代码：编排中用传统编程语言（非 AI）实现的控制流部分，保证可靠和可恢复
- 独立工作目录（worktree）：独立的代码工作目录，让子智能体可以并行修改代码而不互相冲突
