Dynamic Workflows（动态工作流）

Dynamic Workflows（动态工作流） 是 Anthropic Claude Code 语境中的一个新兴产品能力。根据当前材料，它指 Claude 基于用户给出的复杂目标，先生成一段可执行、可阅读、可复跑的编排脚本，再交给 Workflow Runtime 调度多个 subagent 协同完成任务。

它不是简单的“多叫几个子 Agent”，而是把复杂任务从主会话里的临时推理，提升为 Runtime 中可运行、可追踪、可验证的任务编排。这个方向与 Loop Engineering（循环工程）和 Harness Engineering（驾驭工程）高度相关：前者关注目标驱动的闭环，后者提供执行、权限、状态、验证和治理基础设施。

核心链路

Dynamic Workflows 的运行链路可以概括为：

用户用自然语言提出一个复杂目标，并给出范围、约束和验收标准
Claude 判断任务复杂度，生成 Workflow Script
Workflow Runtime 接管脚本执行，调度多个 subagent
各类 subagent 并行或串行完成扫描、研究、编码、测试、审查、修复等子任务
系统通过交叉检查、对抗验证或独立 review 收敛结果
主会话返回最终结论、证据和执行记录

关键变化是：主 Agent 不再把所有执行细节都塞进不断膨胀的上下文，而是先把任务转化为外部可执行计划。Runtime 再负责状态管理、并发控制、失败处理、日志记录和结果汇总。

与普通 subagent 的区别

形态	核心机制	主要问题
Subagent	主 Agent 临时分派一个或几个子任务	中间结果容易回流到主上下文，规模有限
Multi-Agent	多个角色协作完成任务	如果缺少调度机制，容易各说各话
Agent Team	预设固定团队角色	团队结构和流程通常提前写死
Dynamic Workflows	按目标动态生成脚本和团队结构，由 Runtime 执行	成本、可控性和目标定义要求更高

因此，Dynamic Workflows 的重点不是“Agent 数量更多”，而是流程生成、状态管理、验证收敛三件事被工程化了。

适用任务

Dynamic Workflows 更适合复杂、长程、需要多角色协同的任务：

大规模代码审计，例如扫描一批 API 路由是否缺少认证或权限校验
代码迁移、批量重构、跨模块一致性修复
多源调研、证据汇总、交叉验证
企业业务分析，例如选址、风控、供应链优化、城市治理方案生成
需要先设计流程、再执行流程、最后复核结果的 ToB 场景

它不适合低价值、低复杂度、成本敏感或目标无法清楚定义的任务。简单任务直接让单个 AI Agent（智能体）执行更便宜，也更容易审查。

动态编排系统的五层能力

如果把 Dynamic Workflows 从具体产品功能抽象为一种通用 Agent 系统形态，它不能只是一个聊天入口，也不能只是预设流程模板的集合。更完整的动态编排系统至少需要五层能力：

层级	职责
目标理解层	识别用户要的结果、数据、工具、约束和交付物，必要时追问澄清
流程编排层	生成 Workflow Plan：阶段、角色、工具调用、输入输出、并行关系、验证节点、失败策略
Runtime 执行层	调度任务、管理状态、控制权限、记录日志、处理异常、汇总结果
验证收敛层	检查数据完整性、工具调用成功率、证据链、Agent 结果冲突和高风险人工确认
经验沉淀层	将成功流程、可复用模板、Agent 配置、评估规则、工具链组合和失败经验沉淀为系统资产

这五层分别解决“动态适配”和“持续复用”：动态生成流程让系统能适配不同目标，经验沉淀让系统不必每次从零开始。

与循环工程的关系

Dynamic Workflows 可以看作 Loop Engineering（循环工程）在复杂任务上的一种产品化形态：

Loop Engineering 强调目标、验证、状态和自动化闭环
Dynamic Workflows 强调先生成可执行脚本，再由 Runtime 组织多 Agent 执行
两者都要求把目标写成可验证的完成条件，而不是依赖 Agent 自称完成

区别在于，循环工程更像方法论；Dynamic Workflows 更像某个 Agent 产品把这套方法论内置进执行系统后的具体能力。

在 proactive loop 中，Dynamic Workflows 通常承担“把一个持续到来的任务拆成多 Agent 流程”的角色：/schedule 负责触发，/goal 负责停止条件，workflow runtime 负责编排 triage、修复、review 和通知。它适合 bug 报告、issue 分诊、依赖升级这类输入持续变化但验收标准可以写清楚的工作；如果验收标准模糊，动态工作流只会把不确定性放大到更多 Agent 上。

Headless 模式与 Fan-out：横向扩展

动态工作流的轻量形态是用 claude -p 非交互模式把 Claude 集成进自动化流水线，再通过 shell 循环做横向扩展（fan-out）。这不需要 Runtime 基础设施，但共享同一个思路：把一个复杂目标分解为独立子任务，并行或批量执行。

# 生成需要迁移的文件列表
find src -name "*.py" > files.txt

# Fan-out：每个文件独立调用 claude -p
for file in $(cat files.txt); do
  claude -p "Migrate $file from React to Vue. Return OK or FAIL." \
    --allowedTools "Edit,Bash(git commit *)"
done

使用 --allowedTools 在无人值守运行时限制操作范围；--permission-mode auto 让分类器模型自动拦截高风险操作。

实践模式：先在 2–3 个文件上验证 prompt 的正确性，再对全量文件运行。--output-format json 或 stream-json 可将结果接入其他处理流程。

Fan-out 解决了传统单 Agent 对大型代码库的规模瓶颈——2,000 个文件的迁移任务，由单个 Agent 顺序执行可能需要数小时，fan-out 后可并行处理，总时间约等于最慢单文件的处理时间。

Writer/Reviewer 多会话模式

多个并行 Claude 会话可以在不依赖 Runtime 基础设施的情况下实现质量分离：Writer 会话负责实现，Reviewer 会话在独立新鲜上下文里审查 diff。

sequenceDiagram
    participant W as Session A（Writer）
    participant R as Session B（Reviewer）
    W->>W: 实现限流中间件
    W->>R: diff 完成，请求 review
    R->>R: 在新鲜上下文审查\n查找边缘情况、竞态条件
    R->>W: review 反馈
    W->>W: 按反馈修复

Reviewer 不带"自己写过这段代码"的偏见，对 diff 的评估完全基于代码本身，而不是产生这段代码的推理过程。这是 Evaluator-Optimizer（评估器-优化器）模式在 Claude Code 并行会话上的具体实例。

同样的分离也可以用于测试驱动开发：Session A 只写测试，Session B 只写让测试通过的代码——两者互不看到对方的实现。

可靠性边界

Dynamic Workflows 的风险来自三个方面：

成本高：多 Agent 并行、交叉验证、长程执行会消耗更多 token、时间和工具调用额度
可控性要求高：需要权限控制、审计日志、状态恢复、人工确认和回滚机制
任务定义要求高：目标、范围、约束、输入数据和验收标准越模糊，动态生成的流程越容易偏离真实业务目标

企业落地时，Dynamic Workflows 必须建立在 Agent Sandbox（Agent 沙箱）、Agent Memory（Agent 记忆）、Evals（评估）和权限治理之上。否则它很容易退化成一段复杂 prompt：看起来像编排，实际上没有可靠的执行边界。