看到Anthropic新推出的Dynamic Workflows，我非常兴奋。
因为它和我想做的ToB行业场景动态编排平台，在底层思想上是高度一致的：
不是提前编排好流程，也不是Agent即兴拆解，而是基于一个确定的业务目标，先由AI动态生成场景编排脚本，并组织一支Agent团队协同完成任务。
当前只是Claude Code的一个Research Preview功能，但它正在引领Agent走向新形态：动态工作流编排系统。
Agent变成FDE，基于目标，编排任务、调度团队、管理状态、验证结果。
本文将从如下5个维度进行分享：
-
Dynamic Workflows到底是什么
-
Dynamic Workflows的架构与原理解析
-
Agent形态演进与各自适用场景
-
Dynamic Workflows的价值与启发
-
将Dynamic Workflows思想落地企业项目
一、Dynamic Workflows到底是什么？
Anthropic官方对Dynamic Workflows的描述很直接：
Dynamic workflows orchestrate many subagents from a script Claude writes and you can rerun.
可以理解为：Claude根据用户目标生成一段可执行的工作流脚本，由Runtime调度多个subagent执行，并在后台完成复杂任务。
这个概念听起来并不复杂，甚至有人会说：
这不就是多个subagent一起干活吗？
如果你把Dynamic Workflows理解成更强的subagent，就低估它了。
虽然现在Claude Code、Codex这类Coding Agent已经很强大了，但是Dynamic Workflows真正要解决的是：如何将足够复杂的任务工程化。
Anthropic 给了一个很典型的触发动态工作流的示例：
使用ultracode模式，审计 src/routes/ 目录下所有 API 接口，检查是否存在缺少认证或权限校验的问题。
ultracode模式会自动判断这个任务适不适合启动Dynamic Workflows。
有什么区别呢？
普通模式下，你需要明确地告诉Claude创建一个工作流审计这个项目权限。
而开启ultracode后，Claude会自己判断这个任务是否复杂？如何拆分？如何验证？是否需要启动Dynamic Workflows?
由此可见，ultracode模式（启动Dynamic Workflow）适合复杂任务，希望Claude尽可能认真规划、拆解、验证。
Claude不是在上下文里边想边调度，而是先生成一份orchestration script（编排脚本），再交给专门的Workflow Runtime去执行。
也就是说，Claude不再把所有执行细节都塞进自己的“脑子”里，而是先写出一份“作战计划”，然后由Runtime负责调度、执行、记录和验证。
所以，Dynamic Workflows不是让Agent一次完成复杂任务，而是把复杂任务的执行方式，从临时推理，升级为Runtime中可运行、可追踪、可复用、可验证的编排脚本。
这是它与普通subagent协作最大的不同。
二、Dynamic Workflows的架构与原理
理解Dynamic Workflows，关键不是看它调用了多少个Agent，而是看它如何把一个复杂目标，转化为一套可执行、可追踪、可验证的动态编排过程。
其核心链路可以概括为：用户提出目标 → Claude生成编排脚本 → Runtime调度执行 → 多Agent并行协作 → 验证复核 → 返回最终结果。
如图所示，Dynamic Workflows的运行链路有4个关键节点：
-
用户用自然语言提出一个复杂目标，并给出必要的范围和约束。
-
Claude理解任务、判断复杂度，并生成一段可执行的Workflow Script，将任务拆解、执行顺序、并行策略和验证规则写入脚本。
-
脚本生成后，Workflow Runtime接管执行过程，负责调度多个Subagents、管理中间状态、控制并发，并记录每个阶段的执行结果。不同Subagents会分别承担扫描、研究、编码、测试、审查、修复等子任务。
-
系统通过对抗验证 / 交叉检查对多个Agent的结果进行复核，过滤误报、补充证据，并将收敛后的最终结果返回主会话。
这是一套从目标理解、脚本生成、runtime调度、多agent协作，到验收收敛的完整机制。
三、Agent形态演进与适用场景
如果把几种常见Agent形态放在一起看，差异对比会更清楚。
Workflow
固定流程。人提前设计好节点、分支和规则，系统按流程执行。
流程稳定、可控，适合业务规则固定的场景，缺点是灵活性不足，复杂场景流程编排非常复杂。
Subagent
临时分工。主Agent根据当前任务临时派出一个或几个子Agent去查资料、读代码、写模块。
优点是简单灵活；缺点是规模有限，中间结果仍然容易回到主上下文。
Multi-Agent
多人协作。多个Agent可以扮演不同角色，比如产品、研发、测试、评审等。
优点是视角更丰富；缺点是如果没有清晰的调度机制，很容易变成多个Agent各说各话。
Agent Team
固定团队。系统提前配置好一组角色，比如Planner、Coder、Reviewer、Tester，由它们协作完成任务。
它比普通Multi-Agent更工程化，但团队结构通常是预设的。
Dynamic Workflows
根据任务目标动态生成流程，动态组织Agent，并交给Runtime执行。核心是动态生成流程、运行时状态管理、验证收敛机制。
适合复杂工程任务、大规模扫描、迁移和审计。
四、Dynamic Workflows的价值与启发
当前大多数Agent产品，本质上仍然是「主Agent + 工具 + 上下文」的模式。
用户提出需求后，Agent在对话中拆解任务、调用工具、汇总结果。这个模式在单点任务里很好用，但当任务变得复杂、流程变得不确定、结果需要验证时，就会暴露出组织能力不足的问题。
Dynamic Workflows是目标驱动的动态编排，复杂任务不应该只依赖一个Agent在上下文里连续推理，而应该被转化为一套可运行、可追踪、可复用、可验证的动态流程。
动态流程编排的价值，主要体现在三个方面：
流程可复用
Dynamic Workflows生成可阅读、可保存、可复跑的Workflow Script，让复杂任务编排从一次性对话，变成可沉淀的流程资产。
执行可管理
任务拆解、并行执行、状态记录、失败处理和结果汇总都交给Runtime管理，不再完全依赖主会话上下文，复杂任务因此更稳定、可控、可审计。
结果可验证
将结果复核与交叉检查写入流程，让Agent输出不只是看起来合理，而是经过复核和收敛。
这三点对设计企业Agent非常有参考价值的。
对于ToB行业落地来说，比如物流、文旅、城市治理、零售选址、本地生活这些复杂场景里，客户的业务目标往往是相对明确的，但实现路径并不固定。
如果依赖传统Workflow固定编排，当流程越复杂，分支越多，维护成本越高。
Dynamic Workflows提供的是另一种思路：不再穷举所有流程，而是让AI根据业务目标生成可沉淀的合适流程。
比如客户说：我要做一个分析城市哪里适合开新能源补能站的Agent。
这个需求背后的流程涉及：POI数据检索、车流分析、路网与可达性计算、竞品站点分布、地块成本、选址评分模型、方案报告生成...
如果是人类解决方案专家针对这个场景的Agent设计会思考如下问题：
Dynamic Workflows就相当于这里的人类专家，基于复杂场景的目标任务，先编写可执行脚本、设计Runtime、组建执行团队...
Agent从会干活，走向会组织一群人干活。当然，Dynamic Workflows 并不是万能解。它至少有三个明显局限：成本高、可控性机制要求高、任务定义要求高。因此，如果任务简单或对成本极度敏感的低价值任务，就不适合使用Dynamic Workflows。
此外，在使用Dynamic Workflows时需要用户能明确目标、约束、范围、验收标准，对于企业项目落地来说需要配套权限控制、执行审计、人工确认和回滚机制。
五、如何设计一个动态Agent编排平台
如何把Dynamic Workflows思想迁移到企业项目落地，设计一个动态编排平台呢？
我认为至少需要五层能力：目标理解、流程编排、Runtime 执行、验证收敛、经验沉淀。
1. 目标理解层
用户先用自然语言描述业务目标，系统自动识别用户想要什么结果、需要哪些数据和工具、有哪些约束，以及最终交付物是什么，需求可以与用户进行澄清与确认。
2. 流程编排层
AI根据目标生成Workflow Plan，包括阶段划分、Agent分工、工具调用、输入输出、并行/串行关系、验证节点和失败处理策略。
流程不是人提前配置，而是由 AI 动态生成。
3. Runtime执行层
Runtime负责任务调度、状态管理、权限控制、日志记录、异常恢复和结果汇总。
Runtime的设计非常重要，如果没有Runtime，动态编排很容易退化成一段复杂Prompt。
4. 验证收敛层
企业场景不能只靠模型自信输出结果，必须有验证机制。
验证数据是否完整、工具调用是否成功、结论是否有证据、多个Agent结果是否冲突，以及高风险建议是否需要人工确认。
5. 经验沉淀层
每次Workflow执行完成后，都应该沉淀为可复用流程、行业模板、评估规则、Agent 配置、工具链组合、成功案例和失败经验。
这也是ToB平台商业化的关键：动态生成解决“个性化”，经验沉淀解决“规模化”。
未来真正有价值的ToB Agent平台，不只是一个聊天入口，也不是一堆固定流程模板，而是一套从目标理解、动态编排、Runtime执行、结果验证到经验沉淀的完整闭环。