Claude Opus 4.8 为 Claude Code 带来了一个重磅功能：Dynamic Workflows。在一个会话中，编排智能体 (orchestrating agent) 可以启动数百个并行子代理来处理大型、分支任务：跨数十个文件的重构、运行庞大的测试矩阵，或者同时探索多个解决方案路径。在终端中看，这简直像魔法一样。而在底层，它是两个具体组件协同工作的结果。
本指南将拆解 Dynamic Workflows 的实际工作原理、何时使用它们，以及如何通过原始 API 构建相同的编排模式。关于模型本身，请参阅 what is Claude Opus 4.8。关于智能体架构背景，我们的 Claude Code agent harness breakdown 是配套读物。
AI Coding 交流群
如果你也在用 AI 写代码，或者正在研究 Cursor、Claude Code 这些工具，欢迎加入以下交流群。群里平时会聊一些 AI 编程的实际用法、开发工作流，还有各种新工具和新玩法。
Dynamic Workflows 到底是什么
在 Claude Code 中，Dynamic Workflows 在 effort 菜单中以名为 ultracode 的模式呈现。这里值得理解的一点是：ultracode 并不是一个新的 API effort 级别。它是 Opus 4.8 中已经存在的两项功能的组合：
xhigheffort 级别- 会话中途系统消息 (Mid-conversation system messages)
结合在一起，这两者赋予了编排智能体规划大型任务的推理深度，以及在任务展开时启动工作代理 (worker agents) 的持续权限。这就是全部秘诀。其他一切都是 Claude Code 的内部封装。
要素 1：xhigh effort
effort 参数 控制 Opus 4.8 在一次响应（包括工具调用）中消耗多少 token。xhigh 是 Anthropic 推荐用于长周期编程和智能体工作的级别；它专门为运行时间超过 30 分钟、token 预算达数百万次的任务而调优。
对于 Dynamic Workflow 来说，这种深度至关重要，因为编排器必须进行真正的规划：将任务分解为独立的单元，决定生成多少个工作代理，并合并它们的结果。较低的 effort 级别会缩小工作范围并减少工具调用，这与编排器的需求背道而驰。运行 xhigh 时，请设置较大的 max_tokens（64K 是一个合理的起点），以便模型有足够的空间进行思考和协调。
要素 2：会话中途系统消息 (Mid-conversation system messages)
这是新的 Messages API 功能，使整个流程成为可能。在 Opus 4.8 之前，系统提示词 (system prompt) 位于会话开始处且保持固定。现在，你可以在 messages 数组的中间放置一个系统条目，在任务中途注入新的指令或权限。
正是这一点赋予了编排器在会话开始后启动多智能体工作流的持续权限，而不是预先进行协商。Anthropic 在 mid-conversation system messages 中记录了这一机制。这是一个微小的 API 变化，却带来了巨大的影响：智能体现在可以根据它们在运行过程中的发现来获取新的能力。
在 Claude Code 中开启
在 Claude Code 中，Dynamic Workflows 隐藏在 effort 菜单的 ultracode 选项之后。选择它会设置 xhigh effort，并通过会话中途系统消息授予该会话生成并行子代理的权限。从那时起，你只需描述一个大型任务，让编排器将其分发出去。
以下几件事会自动发生：
- Claude 规划任务并决定如何拆分
- 它并行启动工作代理，每个代理负责任务的一个切片
- 结果流式传回并合并到主会话中
如果你已经通过计划设置了 Claude Code，我们的 Claude Agent SDK with Claude plan setup guide 涵盖了相关的配置。
何时使用 Dynamic Workflows（以及何时不使用）
Dynamic Workflows 在广泛的、可并行的工作中表现出色：
- 同时在许多文件中重构某种模式
- 生成并运行大型测试矩阵
- 并行探索多种实现方法，然后进行比较
- 大规模代码库分析，每个工作代理负责一个模块
对于狭窄的、顺序的任务，它们并不是合适的工具。为单文件更改生成数百个子代理会白白消耗 token，且当每一步都依赖于上一步时，并行工作代理也无济于事。成本是真实存在的：数百个 xhigh 子代理意味着数百万个 token。请务必使模式与工作的形态相匹配。
通过 API 构建相同的功能
你不需要 Claude Code 也能构建编排。原始 Messages API 提供了相同的两个要素，Anthropic 在 build an orchestration mode 中提供了一个现成的示例。其形态如下：
- 以
xhigheffort 运行编排器调用来规划任务 - 使用会话中途系统消息授予编排器分派工作代理的权限
- 并行分发 (Fan out) 工作代理调用，每个调用负责一个工作单元
- 收集结果并将其反馈给编排器进行合并
import anthropic
client = anthropic.Anthropic()
orchestrator = client.messages.create(
model="claude-opus-4-8",
max_tokens=64000,
output_config={"effort": "xhigh"},
thinking={"type": "adaptive"},
messages=[
{"role": "user", "content": "Plan a refactor of the auth module across all 14 services."},
],
)
每个工作代理都是一个可以并发运行的独立 Messages 调用，由于其任务较窄，通常可以使用较低的 effort 级别。如果你正在权衡这与 Anthropic 托管的智能体基础设施，managed agents vs Agent SDK 指南列出了其中的权衡。
成本与控制
并行子代理会迅速成倍增加 token 支出。一个启动 200 个工作代理的 Dynamic Workflow，如果每个代理在 xhigh 下消耗数万个 token，将耗费不菲。以下三个习惯可以保持成本可控：
- 严格限制工作代理范围，并在子任务允许的情况下以
medium或loweffort 运行它们 - 限制每个工作代理的
max_tokens，防止失控的智能体耗尽你的预算 - 缓存共享上下文，这样重复的系统提示词就不会在每个工作代理上按全额计费
Opus 4.8 pricing breakdown 详细计算了 effort 级别和缓存的成本。简而言之：编排功能强大，但账单随智能体数量扩展，因此请将并行化视为一种深思熟虑的选择。
使用 Apifox 测试你的编排
当你通过 API 构建编排时，最难调试的部分是分发 (fan-out)：工作代理是否获得了正确的范围上下文？它们的响应格式是否符合合并步骤的预期？你的会话中途系统消息是否正确送达？你肯定不想在 200 次真实的工作代理调用后才发现 bug。
Apifox 允许你孤立地测试这些组件：
- 保存编排器请求，并在分派任何内容之前检查规划的任务分解
- Mock 工作代理端点，这样你就可以在不花费 token 进行数百次真实调用的情况下，测试分发和合并逻辑
- 在工作代理响应格式上添加断言，以便在 payload 偏离时及时报错
- 以不同的
effort级别重放单个工作代理调用，以优化每个代理的成本
下载 Apifox，针对 https://api.anthropic.com/v1/messages 构建编排器和工作代理请求，并首先在 mock 上验证循环。Opus 4.8 API guide 提供了可供开始的基础请求。一旦逻辑在 mock 上稳定，即可切换到实时端点。
FAQ
什么是 Claude Code 中的 Dynamic Workflows？ 这是一项允许一个会话启动数百个并行子代理来处理大型、分支任务的功能。它由 Opus 4.8 上的 xhigh effort 加上会话中途系统消息驱动。
ultracode 是一个单独的 effort 级别吗？ 不是。Ultracode 是 Claude Code 对 xhigh effort 配合启动多智能体工作流持续权限的称呼。API 的 effort 级别仍然是 low、medium、high、xhigh 和 max。
什么是会话中途系统消息 (mid-conversation system messages)？ 这是 Opus 4.8 中 Messages API 的一项变化，允许你在会话中途放置系统条目，在任务中途注入新的指令或权限。它是编排器在运行开始后生成工作代理的关键。
我可以在不使用 Claude Code 的情况下构建 Dynamic Workflows 吗？ 可以。在原始 Messages API 上使用 xhigh effort 加上会话中途系统消息即可。Anthropic 在其文档中发布了一个完整的编排示例。
Dynamic Workflows 成本高吗？ 可能会很高。数百个 xhigh 子代理加起来可能达到数百万个 token。请严格限制工作代理的范围，尽可能降低它们的 effort 级别，并缓存共享上下文以控制支出。
什么时候应该避免使用 Dynamic Workflows？ 在处理狭窄或严格顺序的任务时。当每一步都依赖于前一步时，并行工作代理不会带来任何价值，并且会在小型任务上浪费 token。
开发必备：API 全流程管理神器 Apifox
介绍完上文的内容，我想额外介绍一个对开发者同样重要的效率工具 —— Apifox。作为一个集 API 文档、调试、设计、测试、Mock、自动化测试于一体的工具，Apifox 是目前提升研发效率的首选。
如果你正在开发项目，不妨试试其极其友好的界面设计，它完全兼容 Postman 和 Swagger 数据格式，导入数据非常方便，，即使是新手也能很快上手，点击这里即可注册使用。
值得一提的是，除了个人和常规团队使用，针对有高安全合规要求、或需要在内网环境协作的企业，Apifox 还提供了深度定制的私有化部署方案。
获取专属报价与部署方案
详细的私有化部署系统架构与安全白皮书
针对您公司规模的专属报价单
免费的 1v1 专属产品演示 (Demo) 机会
