Anthropic动态工作流详解：适用场景与避坑指南

一个开发者烧掉20亿Token的教训

一位开发者尝试复现Anthropic的动态工作流（Dynamic Workflows），结果消耗了20亿个Token。Token是大语言模型计费的基本单位，大致相当于一个英文单词的3/4或一个中文汉字。20亿Token意味着大约处理了15亿个英文单词的文本量——相当于约5000本标准长度的书籍。幸运的是他用的是DeepSeek而非Opus 4.8，否则账单将是天文数字。以DeepSeek的API定价（约每百万输入Token 0.27美元）计算，20亿Token的成本约为数百美元；而如果使用Claude Opus 4.8（每百万输入Token 15美元、输出Token 75美元），同样的Token消耗可能产生数万甚至数十万美元的账单。这个案例揭示了一个核心问题：动态工作流并非万能工具，盲目使用只会烧钱而得不到任何收益。

本文将深入解析动态工作流的本质、它与现有Agent模式的区别，以及最关键的——什么场景该用，什么场景绝对不该用。

从单Agent到动态工作流：计划存储在哪里？

理解动态工作流，首先要理解一个核心问题：谁持有计划（plan）？

单Agent模式

在Claude Code的单Agent模式下，模型可以读取文件、查看工具结果，所有信息都在同一个上下文窗口中。上下文窗口（Context Window）是大语言模型在单次推理中能够"看到"和处理的最大文本长度，本质上是模型的短期工作记忆——所有的对话历史、系统提示、工具调用结果都必须装进这个窗口中。当前主流模型的上下文窗口从128K到200K Token不等（Claude的上下文窗口为200K Token）。在单Agent模式下，它的计划、决策和执行都发生在这个窗口内。当任务复杂度超出单个上下文窗口的容量时，信息就会被截断或遗忘，这正是需要多Agent架构的根本原因。

Sub-Agent模式

Anthropic引入了子Agent原语：一个编排器（Orchestrator）将任务分解为子任务，分配给各个子Agent，每个子Agent拥有独立的上下文窗口。编排器模式借鉴了微服务架构中的编排思想——在传统软件工程中，编排器负责协调多个服务的调用顺序和数据传递；在AI Agent领域，编排器是一个"管理者"角色的LLM实例，它将复杂任务分解后分配给专门的子Agent执行，然后汇总结果。这种模式类似于MapReduce的思想——先分（Map），再合（Reduce）。Anthropic并非唯一采用此模式的公司，OpenAI的Swarm框架、LangChain的LangGraph等也实现了类似的多Agent编排能力。

计划仍然存在于编排器的上下文中。但问题是，子Agent之间互不通信，可能出现重复劳动。

Agent Teams模式

为解决子Agent间的协调问题，Anthropic推出了Agent Teams——协调式Agent会话。主编排器创建一个共享任务列表，各Agent从中领取任务并能相互通信。计划变成了共享任务列表，但本质上仍在模型的上下文窗口中。

动态工作流的本质突破

动态工作流的革命性在于：计划不再存储在任何Agent的上下文窗口中，而是一段真实的JavaScript脚本代码。Claude会生成一个完整的脚本，包含编排器、子任务分配、独立验证器和修复器。运行时在后台执行这个脚本，结果存储在脚本变量中，而非Claude的上下文窗口。

这意味着计划变成了一个可版本化、可审查的工件（artifact），你可以直接阅读和理解整个执行流程。这一设计的深层意义在于：传统Agent模式中，计划是"隐式"的——它散布在模型的注意力权重和上下文记忆中，人类无法直接审查；而动态工作流将计划"外化"为可读代码，使得整个执行逻辑变得透明、可调试、可复现。

动态工作流的核心机制

脚本结构与基本原语

动态工作流生成的脚本包含几个基本原语：

• Agent：单个执行单元
• Parallel：并行扇出，将文件列表映射到多个Agent
• Pipeline：串行流水线
• Workflow：完整的工作流定义

脚本的结构清晰可读：初始元数据 → 分阶段标记 → 并行Agent分配 → 结构化输出返回。这些原语的设计借鉴了工作流编排领域的成熟概念，如Apache Airflow中的DAG（有向无环图）任务编排、CI/CD管道中的阶段和步骤定义，使得熟悉DevOps的开发者能够快速理解和调整工作流结构。

实现-验证-修复循环（对抗性验证）

动态工作流最特别的设计是**对抗性验证（Adversarial Verification）**循环：

1. 实现Agent：执行具体任务
2. 验证Agent：拥有独立上下文窗口，专门寻找实现中的漏洞
3. 修复Agent：根据验证结果进行修复

每个环节的Agent都有独立的上下文窗口，共享的仅是任务相关信息。这种设计的灵感来源于多个领域：在博弈论中，这类似于"红队/蓝队"对抗演练；在机器学习中，这与生成对抗网络（GAN）的思想异曲同工——一个网络生成，另一个网络判别。更直接的类比是软件工程中的代码审查（Code Review）实践：编写代码的人和审查代码的人应该是不同的人，因为编写者容易陷入"确认偏差"（Confirmation Bias），即倾向于寻找支持自己方案正确的证据，而忽略潜在问题。通过给验证Agent一个完全独立的上下文窗口，它不会"记得"实现过程中的妥协和假设，从而能更客观地发现缺陷。

并发限制

虽然动态工作流支持大规模并行，但存在硬性限制：最多16个并发Agent，单次运行总计最多1000个Agent。这些限制既有技术原因（API速率限制、计算资源调度），也有成本控制的考量。16个并发Agent意味着在峰值时可能同时进行16次独立的LLM推理调用，每个调用都消耗独立的Token配额，成本呈线性增长。

动态工作流适用场景判断：三个关键问题

这是本文最重要的部分。一个简单的决策树可以帮你判断是否应该使用动态工作流：

决策树

1. 是否存在客观的评判标准（Objective Oracle）？ 即是否有单元测试、可验证的奖励信号，或明确的通过/失败条件？
2. 是否需要大规模并行扇出？ 需要数百个Agent同时处理？
3. 是否需要运行中的动态调整？

如果第一个问题的答案是"否"，直接放弃动态工作流。如果不需要大规模并行，用单Agent或Sub-Agent就够了。如果不需要动态调整，用/goal模式即可。

"客观评判标准"（Objective Oracle）这个概念在强化学习领域有深厚的理论根基。在强化学习中，奖励函数（Reward Function）定义了什么是"好"的行为——如果奖励函数设计不当，Agent就会产生"奖励黑客"（Reward Hacking）行为，找到技术上满足指标但实际上毫无意义的捷径。同样的道理适用于动态工作流：如果没有明确的、可程序化验证的成功标准（如单元测试通过率、类型检查通过、API响应码正确等），验证Agent就无法有效判断实现Agent的输出质量，整个验证-修复循环就变成了两个模型之间毫无根据的"互相猜测"，白白消耗Token。

适合使用动态工作流的场景

• 代码迁移：如Bun从Zig迁移到Rust（Anthropic官方案例），因为有近乎完美的测试覆盖率
• 大规模Bug修复或安全扫描：有明确的通过/失败标准
• 数百个文件的批量处理：需要并行能力
• 深度研究：多个来源可以交叉验证

不适合使用动态工作流的场景

• 创意或主观输出：如写10个不同版本的网站文案——模型不知道"好"长什么样
• 小范围、明确的代码修改：杀鸡用牛刀
• 没有自动化正确性标准的任务：没有Ground Truth，验证环节形同虚设
• 评估自己过往技能：这是一个真实的反面案例

核心原则：没有可验证的成功标准，动态工作流就是在烧钱。

实战演示：MLX到Transformers的模型迁移

作者用自己开发的应用Quorum（一个本地化的会议转录和总结工具）做了实战演示。任务是将所有模型从MLX Swift迁移到Transformers。

MLX是Apple专门为其自研芯片（M系列）优化的机器学习框架，设计理念类似于PyTorch但针对Apple Silicon的统一内存架构做了深度优化。MLX Swift是其Swift语言绑定，允许iOS/macOS开发者直接在应用中运行机器学习模型。Transformers则是Hugging Face推出的开源库，是当前最广泛使用的预训练模型推理和微调框架，支持几乎所有主流模型架构。从MLX迁移到Transformers意味着从Apple生态专用方案切换到更通用的跨平台方案，这类迁移涉及模型加载方式、推理管线、内存管理等多个层面的代码重写，是动态工作流的理想应用场景——因为每个文件的迁移都可以通过编译和测试来客观验证。

启动方式

有两种方式激活动态工作流：

• 在提示词中直接包含"workflows"关键词
• 将effort设置为"ultra code"级别

执行过程

1. Claude首先分析现有代码库，特别是MLX实现部分
2. 提出澄清问题（人在回路环节），确认执行方案
3. 展示将要执行的脚本，并警告Token消耗
4. 确认后，自动决定分4个阶段、约12个子Agent执行

人在回路（Human-in-the-Loop, HITL）是AI系统设计中的重要安全模式，指在自动化流程的关键决策点引入人类审核和确认环节。在动态工作流中，HITL体现在两个关键时刻：一是执行前的方案确认（Claude展示即将执行的脚本并警告Token消耗），二是执行中的澄清问题。这种设计平衡了自动化效率和人类控制权——完全自主的Agent可能在错误方向上消耗大量资源（正如文章开头20亿Token的案例），而过度的人工干预又会抵消自动化的优势。Anthropic在其Agent设计指南中一直强调"渐进式自主"原则，即随着信任度的建立逐步减少人工干预。

执行监控与结果

在Workflows面板中可以实时查看：

• 当前所处阶段（设计→实现→测试）
• 各子Agent的状态和Token消耗
• 使用的模型（本例中选择了Opus 4.8）
• 工具调用次数

最终结果：实现完成，测试通过，总计消耗约75万Token。应用的转录功能正常工作，但仍需在实际会议中进一步验证。值得注意的是，75万Token与文章开头提到的20亿Token形成了鲜明对比——前者是有明确验证标准的合理使用，后者是缺乏客观评判标准的盲目消耗，两者的Token效率相差近3000倍。

三句话总结动态工作流

1. 代码即计划（Code, Not Context）：计划存储在脚本中，而非Agent的上下文窗口
2. 必须有可度量的目标：没有客观评判标准，动态工作流毫无意义
3. 谨慎使用：强大的能力伴随着巨大的成本

动态工作流是Anthropic Agent架构演进中的重要一步，但它不是银弹。在决定使用之前，先问自己：我的任务有没有一个明确的、可自动验证的成功标准？如果答案是否定的，请老老实实用单Agent或Sub-Agent模式——你的钱包会感谢你的。