动态工作流
大任务的 agent 编排模式：主 agent 临场编写 orchestration 脚本，把任务拆成子任务扇出给数十到数百个并行 subagent，每个结果先过独立验证、再被对抗 agent 攻击，迭代到答案收敛才折叠成单一答案交给用户。由 Claude Code 的 dynamic workflows 产品化（2026-05 GA，见 Claude Code - Dynamic Workflows）：“按季度规划的工作变成按天交付。” 它落在本库 多 Agent 系统 概念的适用范围内——后者是该模式的方法论上游（何时该用、怎么拆、verification subagent，见 Anthropic - Building Multi-Agent Systems）。
机制
- 动态规划：orchestration 脚本按当次 prompt 现写现跑，不是固定模板；
- 并行扇出：subagent 各自从独立角度解决子任务；
- 验证闸门：每个结果被独立检查，另有对抗 agent 专门试图推翻发现——只有活下来的进报告；
- 收敛：跑到答案收敛为止，这是”单遍跑不出来的结果”的来源。
工程性质：面向长时工作（可到小时/天级）；进度随跑随存、中断续跑；协调状态放在对话之外，任务再大计划不漂移。代价是 token 消耗远超普通 session，官方建议先从 scoped task 起步；首次触发需人工确认。
编排脚本与 runtime（官方文档）
脚本 = 纯 JavaScript + top-level await，禁 import；五个 runtime 注入原语：agent(prompt, opts?)（起一个 subagent；opts 可带 schema——JSON Schema 结构化输出——与 label——进度视图标签；被中止/不可恢复错误时 resolve null，官方 audit-routes 示例见 raw 快照）、parallel()（一批同时跑、等全部）、pipeline()（列表每项跑一个，保留 null，故惯用 .filter(Boolean)）、phase()（进度视图分组标题）、log()（进度视图消息）；保存的 workflow 经全局 args 读参数。Runtime 约束：脚本自身无 fs/shell（“Agents read, write, and run commands. The script coordinates the agents”）；Date.now()/Math.random()/无参 new Date() 直接 throw（保证重放确定性，时间戳经 args 传入）；并发上限 16、单次 parallel/pipeline 最多 4096 项、每 run 1000 agents；共享 prompt-cache 前缀的 agent 错峰 ≤5s 启动；每 run 脚本落盘 ~/.claude/projects/<session>/，可 diff、可改后重发。
收敛判定：没有统一谓词，按任务临场选定
官方文档未定义统一的”答案收敛”判定；停止条件写在每次生成的脚本里，按任务从四种模式选：① checker（跑到通过或停止进展）② 发现枯竭（新轮无新发现）③ 投票 + 交叉核查（/deep-research：claims 投票、未存活者过滤）④ 对抗幸存（无人能推翻）。兜底：1000 agents/run 硬上限，>25 agents 或预计 >1.5M tokens 触发 Large workflow 警告（仅提示不拦截）。架构层面拆解见 Dynamic Workflow 架构拆解。
适用形状
- 全库审计：bug 猎杀、profiler 引导的性能审计、安全审计（auth 检查、输入校验、不安全模式）——发现先验证，报告只留真问题；
- 大型迁移：框架替换、API 弃用、语言移植，跨数千文件端到端；
- 高代价决策的加倍检查：独立多尝试 + 对抗攻击，答案错误成本高时用。
规模证据：Bun 的 Zig→Rust 移植
约 75 万行 Rust、99.8% 测试通过、首 commit 到 merge 11 天。分阶段：workflow 1 为 Zig 代码库每个 struct field 映射正确的 Rust lifetime → workflow 2 每文件行为等价移植（数百 agent 并行 + 每文件双 reviewer）→ fix loop 把 build 与测试跑干净 → 落地后隔夜 workflow 清理不必要数据拷贝、每处开 PR。尚未上生产。
与 Agent Fleet 管理 的对照
fleet 管理的是 always-on 运营 bot 群（岗位描述、静默原则、人工闸门），动态工作流是单任务一次性 swarm：生命周期一个 session，产出即解散。fleet 的”solo 优先、无监督 crew 错误率放大 17 倍”与此不矛盾——那是没有验证兜底的常驻协作；动态工作流把并行性关进”独立验证 + 对抗审查”的闸门，人只见收敛后的结果。共同的底座判断一致：并行/委派的产出必须过一道结构化的检查，才能到人面前。
与 Agent 状态分层 的呼应
“协调发生在对话之外、进度持久化、中断续跑”= 把编排与进度当 work 态对待：发起它的对话（workspace 性质）可以断，work 态跨中断存活。