先给出几个核心判断：在大型AI编程任务中，长期存在一个根本性矛盾——任务规模越大，对话上下文就越臃肿，模型也越容易“偏离方向”。当单次对话需要处理数十万行代码的迁移或审计任务时，中间结果层层叠加，最终要么上下文窗口溢出，要么模型彻底丢失目标。
Claude Opus 4.8随Claude Code推出的Dynamic Workflows（动态工作流），正是为破解这一痛点而设计。该功能在开发者社区引发广泛关注，其架构设计值得深入剖析。
核心架构：将计划移出上下文
动态工作流与传统对话式编程的本质区别在于——谁掌控计划。从根本上说，问题出在“计划”由谁承载。在传统对话式编程中，所有中间结果都被塞进主会话上下文，逐步撑大窗口，最终让模型不堪重负；而动态工作流则将计划写入JavaScript脚本，中间结果存放在脚本变量中，主会话仅保留最终答案。这样一来，上下文保持轻量，且不易偏离目标。
更关键的是并行能力。传统方式采用线性推进，无法实现大规模并行；而动态工作流可以做到1个编排器+数百个并行子Agent，分支处理复杂任务。容错方面也显著提升——传统方式一旦中断就需从头开始，而动态工作流的进度持续保存，在同会话中可从断点恢复。标杆案例充分验证了其威力：75万行代码库移植（Bun从Zig到Rust），仅用11天完成。
两大技术支柱
动态工作流并非一个独立的API层级，而是Opus 4.8中两个已有组件协同配合的结果。
第一是xhigh effort级别。Anthropic为长周期编程任务专门调优的思考强度，单次响应可消耗数百万Token预算，支持运行超过30分钟的任务。它为编排器提供了规划大规模任务所需的推理深度。
第二是会话中途系统消息（Mid-conversation System Messages）。这是Messages API的关键变革。此前系统提示词固定在会话开头；现在可在消息数组中间插入系统条目，在任务中途注入新指令或权限。正是这一机制，让编排器可以在运行开始后动态获得启动子Agent的权限，而无需事前协商。
工作流如何运行
当用户触发一个工作流任务时，Claude会执行以下步骤：
- 动态生成编排脚本：根据任务描述现场编写JavaScript脚本，将任务拆解为独立单元。
- 扇出并行子Agent：脚本调度数十至数百个子Agent并行执行，每个Agent负责一个任务切片。
- 对抗性验证：部分Agent专门负责“反驳”前者的发现，通过多角度交叉验证确保结果可靠性。
- 汇总交付：结果流式传回并合并到主会话，用户收到的是经过验证的最终报告。
成本与使用建议
- 适用场景：代码库级重构、大规模测试矩阵、多角度研究比较。
- 回避场景：狭窄的顺序任务——每一步依赖上一步时，并行子Agent无法带来价值。
- 成本控制：数百个xhigh子Agent意味着数百万Token消耗。建议严格限定子Agent范围，在子任务允许时使用较低effort级别，并缓存共享上下文。
常见问答FAQ
Q1：动态工作流和普通对话式编程到底有什么区别？
普通对话中，Claude逐轮决策，所有中间结果都进入上下文窗口；工作流则将编排逻辑移入代码脚本，由脚本协调数百个子Agent并行处理，主会话只保留最终答案，从根本上解决了上下文膨胀问题。
Q2：如何在Claude Code中开启动态工作流？
在effort菜单中选择ultracode模式即可。它会设置xhigh effort，并通过会话中途系统消息授予生成并行子Agent的权限。Pro用户需在/config中手动启用。
Q3：跑一次动态工作流大概多少钱？
成本较高。一个启动200个子Agent的工作流，总Token消耗可达数百万。建议先在小范围任务上测试，评估支出后再扩展到全量。