Claude Code 推出 Dynamic Workflows： 从「一个 agent 干到底」升级到「agent 自己当项目经理 + 调度层」，标杆案例是 Bun Zig → Rust 迁移！

让 Claude Code 根据任务现场生成编排脚本，在单次会话里启动 数十到数百个并行 subagent，并在结果交付前做 独立验证。把原本需要多轮人工规划、分阶段推进的大型工程任务，压缩成 可端到端自动跑完的长任务。 https：//claude.com/blog/introducing-dynamic-workflows-in-claude-code

Dynamic Workflows 解决什么问题？ · 上下文窗口有限：拆子任务，并行 fan-out · 单视角易漏检/误判：多 agent 独立探索 + 对抗性 refute · 长任务易中断丢失：进度持久化，断点续跑 · 对话上下文被协调信息污染：协调逻辑在对话外执行，主线程保持单一结论

工作机制（技术逻辑） 用户 prompt ↓ Claude 动态规划（非固定 pipeline） ↓ 拆分子任务 → 并行 subagents（数十~数百） ↓ 独立产出 → 验证/对抗审查 → 收敛迭代 ↓ 汇总为单一协调结果 → 交付用户

几个值得注意的设计点： · 动态编排：脚本由 Claude 现场写，不是固定 workflow DSL；任务形态变化时更灵活，但也更难预测 token 消耗。 · 对抗式收敛：不只「多 agent 投票」，还有 agent 专门 反驳 其他 agent 的结论，迭代到答案稳定--类似 ensemble + red team。 · 长时运行：官方称可持续 数小时到数天；协调在会话外，避免对话 token 被中间状态撑爆。 · 首次触发需确认：第一次启动 workflow 时会展示即将执行的内容，用户确认后才跑--成本与范围的可控闸门。

和 Claude Code 现有能力的关系 明确把它放在 「单个 subagent」和「完整 agent team（需人工搭建）」之间： · 单个 subagent：轻量、快，但 scope 有限 · 完整 agent team：灵活、可见，但搭建成本高 · Dynamic Workflows：Claude 自动决定是否启用、如何编排，用户只需提需求或开 ultracode

这是 agent 编排层的 productization--把多 agent 协作从「高级用户自建」变成「模型自决策调用」。

标杆案例：Bun Zig → Rust 迁移 Jarred Sumner 用 dynamic workflows 完成 Bun 从 Zig 到 Rust 的移植（尚未 production）： · ~75 万行 Rust · 99.8% 现有测试通过 · 首 commit 到 merge：11 天

流程示意： · 一个 workflow：为 Zig 代码中每个 struct field 映射正确的 Rust lifetime · 下一个 workflow：并行 port 每个 .zig → .rs，每文件配 2 个 reviewer · Fix loop：驱动 build + test 直到全绿 · 后续 overnight workflow：优化不必要的数据拷贝，每个改动单独开 PR

这说明 workflow 不只用于「读/审」，也用于 大规模写 + 验证 + 修复闭环--接近小型软件工厂的运作方式。