动态工作流，是让 Claude 为一个任务写出调度程序，再由程序安排多个 Agent 分阶段完成工作。 主 Agent 负责理解目标、写程序和交付答案；程序负责派任务、传递中间结果、安排后续阶段。读材料、分析和核对，仍由参与执行的 Agent 完成。

这项能力属于 Claude Managed Agents——Anthropic 面向开发者提供的托管 Agent 服务。运行环境、会话和凭证由平台管理，开发者可以把它接入自己的应用。动态工作流目前已开放公开测试。

它主要提供五项能力：

• 按任务生成流程：主 Agent 为当前任务编写程序；程序可以根据前面的结果，决定后面做什么，也可以安排复查和重试。
• 分阶段并行处理：多份材料可以同时交给不同 Agent 阅读，完成后再进入汇总或核对阶段。
• 各自阅读，共用文件：每个 Agent 有独立的对话历史，同时可以访问会话中的共享文件，方便接续处理同一批材料。
• 在后台继续工作：程序在服务端运行，主 Agent 可以继续回答用户，或者结束当前轮次等待结果。
• 查看进度、控制支出：开发者可以查看阶段和执行线程的事件，并通过会话预算约束包括工作流在内的模型支出。

300 份合同，怎样从分头阅读变成一份答复

假设要从 300 份合同中找出带有“控制权变更条款”的合同。这类条款涉及公司控制权变化后的权利或义务，筛查时需要回到具体合同文字。

逐份阅读可以分头做，但最终要有人把结果接起来：哪些合同命中了，依据在哪里，哪些结果还需要核对。动态工作流把这部分协调工作交给程序。

主 Agent 接到目标后，写出一个包含“阅读合同”和“汇总核对”两个阶段的工作流。第一阶段，程序将不同合同分给阅读 Agent；每个 Agent 在自己的对话中处理材料，把结果返回给程序。

每个阅读 Agent 的对话历史保持独立，不会自动进入其他 Agent 的上下文；下一阶段需要的信息，由程序传入。与此同时，它们访问的是同一个沙箱里的文件，并共享会话凭证。独立的是阅读和工具对话的历史，文件工作空间仍是共享的。

例如，可以要求阅读 Agent 返回合同编号、条款原句和初筛判断，再由程序把这些结果交给复查 Agent。这样，复查阶段拿到的是为核对准备的信息，而不必重新接收所有阅读过程的对话。

接下来，程序把初筛结果交给第二阶段的 Agent，由它们核对和合并发现。还可以给合同任务设计一条返工规则：复查通过，就汇总结果；未通过，就重新读取相关材料，再交给复查 Agent；达到设定轮数仍有分歧，就退出并报告未解决的问题。程序根据返回的判断选择下一步，具体规则由这次任务生成的工作流决定。

这样，主 Agent 不需要在主对话里逐项收报告、再派出下一项任务。通常，工作流结束后，它会获得一个轮次读取汇总结果，再给用户答复。下面的合同演示展示了阅读、核对和交付的基本路径。

“动态”体现在流程会针对任务生成，后续安排也可以取决于前面的结果。用户不必事先为每份合同配置一个固定 Agent，但仍需要清楚交代目标、核对规则、失败后的处理方式和退出条件。

找 bug 的结果更好，究竟说明了什么

Anthropic 在一个 11.6 万行代码的代码库里植入了 70 个 bug，分别让单 Agent 和动态工作流各运行三次。

单 Agent 三次找出 14、15、27 个；动态工作流三次都找出 66 个。以 70 个植入 bug 为分母，前者的检出占比为 20.0%、21.4%、38.6%，后者均为 94.3%，每次仍有 4 个没有找到。

这组结果支持的判断是：在这项代码排查任务中，工作流找到了更多 bug，三次找到的数量也更稳定。它值得作为复杂排查的一种组织方式来尝试。

三次检出数量相同，并不代表找到的是同一批 bug。评估自己的代码审查任务时，除了找到多少，还要看遗漏和误报是否可以接受。

94.3% 是这次植入 bug 的检出占比。它不是所有代码审查的通用准确率，也没有包含误报情况。原帖没有给出相同预算下的对照、总 token 用量和耗时，判断它是否更划算，还需要在自己的任务上同时看结果、时间和费用。

哪些任务值得交给动态工作流

先看任务能否分开处理，再看结果能否合起来。数百份合同筛查、多模块代码排查、批量材料交叉核对，都有独立的处理部分，也需要最后汇总。只有一两份合同，或者每一步都依赖上一轮与用户的沟通，通常直接由主 Agent 处理更合适。

同样是多 Agent 协作，差别在于谁来决定下一步。动态工作流让程序推进；普通子 Agent 由主 Agent 派任务、读报告、再追问；Advisor 则给主 Agent 提建议，工作仍由主 Agent 做。

例如，批量阅读合同可以交给工作流；需要和某个专家反复讨论一份疑难合同时，普通子 Agent 的持续追问更方便。只是想在规划或最终检查时借助顾问模型判断，则可以使用 Advisor。三种方式可以一起配置。

普通子 Agent 的线程可以保留并继续发消息，委派只支持一层，一个会话最多同时保留 25 个子线程，闲置线程也计入。工作流里的线程不计入这 25 个，但不能向它们追加追问；服务端最晚在运行结束时归档这些线程，之后仍可查询它们的记录。

分完工，还要检查材料有没有真正处理完

自动协调解决了“下一步由谁安排”，并没有替用户定义什么算合格结果。对合同筛查而言，最终只收到一份命中名单还不够：每个结论需要能回到原句，没命中的合同也需要复查，没读成功的文件必须单独列出。

尤其要分清“未发现条款”和“没有读到合同”。前者是阅读后的判断，后者是任务尚未覆盖。把读取失败混进未命中清单，会让一份看起来完整的报告隐藏遗漏。

可以在交代任务时加入下面这样的核对要求。它是针对合同场景拟制的指令示例：

用动态工作流筛查 contracts/ 中的全部合同，查找控制权变更条款。
初筛按合同分工；发现条款时摘录原句并注明章节或页码，未发现时明确记录。
第二轮独立复查所有合同，包括初筛未命中的合同；两轮分歧重新比对后裁定。
读取失败、超时的文件单独列入未覆盖清单，不能记作未命中。
最终列出已覆盖数量、命中及依据、复查后未发现条款的合同、未覆盖文件及原因。
将本次运行时间上限设为 1 小时。

这些要求为生成流程提供了核对标准。最终还要检查工作流是否落实了它们，特别是覆盖数量和失败清单。

界面显示 completed，只说明工作流程序正常结束。如果程序遇到某份文件读取失败后选择跳过，运行仍可能显示这个状态。要判断任务是否完成，需要看结果和各个执行线程的错误记录，不能只看阶段结束或整个程序结束的事件。

查错时，阶段事件帮助了解流程推进到哪里，执行线程的消息和工具记录则帮助查明哪些材料读取失败。主事件流会汇总运行、阶段和线程状态；详细的阅读与工具消息在各线程自己的事件流中。两类记录需要对照查看，接口没有直接把每条线程对应到某个阶段的字段。

客户端默认看不到工作流代码、启动和管理它的内部调用，也看不到每个 Agent 返回给程序的中间值。若想检查实际的分工与返工规则，可以等工作流结束、主会话空闲后，要求主 Agent 逐字输出启动时使用的程序，并说明不要再启动新工作流。

后台运行时，怎样控制规模和费用

每个参与执行的 Agent 都会消耗 token。增加分工和复查轮次也会增加用量，所以起步时适合先选一个范围明确的任务，观察产出和消耗，再逐步增加复杂度。

“单次最多 1,000 个 Agent”说的是整个运行期间累计启动的数量，并不是 1,000 个同时开工。目前一个工作流最多同时有 64 个工作线程，多出来的任务排队等待；64 是当前服务端配置，可能调整。累计申请超过 1,000 个 Agent，会结束运行；失败任务的服务端重试可能产生新线程，所以最终线程数也可能超过 1,000。

同一会话默认最多同时有 10 个尚未结束的工作流，暂停的也占名额。每个运行默认最多持续 24 小时，可以设置更短时限；预算暂停、等待客户端处理工具请求，都不会让这个时钟停下来。

预算暂停，不代表费用会精确停在某个数

会话预算按模型标价计算支出，覆盖主 Agent 和工作流的模型请求。达到上限后，工作流会暂停，但已经发出的模型请求会执行完，因此最终消耗可能超过预算。

预算要在创建会话时设置；当时没有设置，之后不能补加。已经设置的预算可以调整或移除。提高或移除预算，可能让因预算耗尽而暂停的工作流继续运行；若它同时因用户中断等原因暂停，则不保证恢复。

结束主对话，不等于停止后台工作

客户端的 user.interrupt 会打断主 Agent 当前轮次，却不会终止工作流；后台任务可能继续，也可能暂停。需要关停时，应要求主 Agent 停止工作流，并确认运行结束事件的结果是 stopped，再归档会话。仍有未结束的工作流时，归档请求可能被拒绝。

主 Agent 读取结束结果也有自己的时机：预算耗尽或主线程等待客户端应答时，这个轮次会推迟；用户中断后，它可能不会自动读取结果，需要再发消息让它读取或继续。

预算耗尽的会话不能直接接收新的用户消息，需要先提高或移除预算，才能发送停止要求。这一步也可能恢复后台运行，因此“补预算”和“停止任务”是两个不同操作。

如果任务会修改文件或调用外部工具，还要考虑重试：同一个子任务可能重新执行。工具应能识别重复请求，避免重复操作造成额外改动。

开发者入口：先允许工作流，再交代任务

在 Agent 定义中，将 multiagent.type 设为 multiagent_20261001，即可配置这套协作能力。这个类型默认启用工作流、普通子 Agent 和内联 Agent，Advisor 默认关闭。开发者在用户消息或系统提示词中交代何时使用工作流，由主 Agent 决定是否启动；无需额外调用一个启动工作流的 API。

会话在创建时复制当时的 Agent 配置，之后修改 Agent 定义，不会更新已经存在的会话。修改配置后，可以创建新会话使用更新后的设置。

启用工作流，再交代任务

配置示例

执行角色有两种来源：可以使用事先创建的 Agent，分别指定它们的模型、提示词和工具；也可以让主 Agent 或工作流临时定义内联 Agent，为当前子任务编写提示词。内联 Agent 继承主 Agent 的模型，工具、MCP 和 Skills 取自主 Agent 能力的子集。预定义 Agent 的两个配置列表分别最多容纳 20 个不同角色，版本在创建或更新配置时锁定。

如果使用 Advisor，还需要符合主模型与顾问模型的配对要求。它通过临时线程提供建议，不能作为普通子 Agent 持续追问。

在 Claude Code 会话中，可以使用官方引导命令开始配置 bug-hunter 模板：

/claude-api managed-agents-onboard bug-hunter

也可以访问控制台快速起步模板。先用一个小范围任务确认分工、核对和支出，再扩大到整批材料。

接入进度显示时，事件流重连只会收到新事件，漏掉的记录需要分页读取历史事件来补齐；目前没有单独列出所有工作流运行的端点。如果执行线程发来自定义工具调用或权限确认请求，客户端应及时应答，因为其他线程可能仍在工作。会话停在 requires_action 时，要先处理等待中的工具请求，才能正常发送新的用户消息。