Claude动态工作流：让AI并行处理复杂任务的新能力

就在上周么, Claude Code它发布了一项全新的能力, 这项能力被称作动态工作流。

这项功能准许Claude依据特定任务、立刻编写定制化执行框架, 协调好多个子Agent、并行开展工作, 解决大规模、 high并行、对抗性任务当中的系统性失效问题。

近日, Anthropic 的工程师成员 Thariq, 发布了一篇篇幅较长的文章, 用以分享他一开始所拥有的工作流方面的经历体验以及内心的感悟想法。

我们对此进行了全文整理译述。

在深入到技术细节的前面, Thariq首先给出了一些示例提示, 以此来使得我们明白工作流的潜力:

动态工作流如何工作

动态工作流执行一个 JavaScript 文件, 这个文件里包含特殊函数, 这些函数能起到帮助生成的作用, 且能起到帮助协调子 Agent 的作用。

同一时间, 动态工作流之中还涵盖着标准 JavaScript 的功能选项, 像 JSON、Math 以及 Array 这些, 是用来处理数据的。

动态工作流能够决定一个Agent所使用的模型类型, 还能决定子Agent是否在独立的工作树中运行, 进而使得Claude可以选择所需的智能水平以及隔离方式。

若工作流出现中断情形, 像因用户进行操作或者终端退出所致, 在恢复会话步骤之时, 工作流能够从之前中止的断点该处接续展开执行。

为何使用动态工作流

执行任务时, 若我们运用默认Claude Code框架, 那它得于同一个上下文窗口里, 同步开展计划与执行行动。针对不少编程工作来说, 如此颇为有效, 然而在长时间持续运行、大规模并行作业或者高度结构的对抗任务当中, 有时候会出现状况。

造成这种情况的缘由是, Claude针对那些置身于单个上下文窗口里, 且需要历经越长运转时间方可完成的复杂任务, 越易于浮现出以下这好几种典型性质能够归为失败的模式:

可以通过为不同目标分配独立上下文窗口的Claude实例来创建工作流, 以此避免这些问题, 每个实例专注任务目标, 每个实例隔离任务目标。

动态与静态工作流的区别

或许你曾借助Claude Agent SDK、claude -p, 去创建静态工作流, 以此来协调多个Claude Code实例。

兼顾所有极端情况这种特征使得静态工作流往往更具通用性, Claude运用Opus 4.8构造的动态工作流, 可以促使Claude生成针对你特定用例定制的智能框架。

动态工作流的常用模式

你能够直接促使Claude去生成动态工作流, 或者借助触发词「ultracode」来保证Claude Code创建工作流。

能够明白动态工作流的那些经常会被使用的模式, 对于判别在什么时间去运用以及怎么样借助提示来引导Claude是有帮助的。

用例

迁移与重构

先将 Bun 从 Zig 进行重写, 而后是运用 workflows 把它重写成 Rust , 最终得以完成。

重点在于将任务分解成一系列能够逐步予以处理的小单元, 像例如调用点、失败测试、模块之类的。每一回修复都于独立的worktree当中派遣出一个子Agent去达成；随后紧接着再让另外一个Agent来开展对抗式审查, 在确认不存在问题之后再去进行合并。

若期望尽可能地并行, 且又不想将本机的资源用完, 那么能够明确地告知 Agent 不要去运行那些对于资源消耗极大的命令。

深度研究

我们于Claude Code当中发布了一项深度研究skill（/deep-research）, 此项深度研究skill所运用的是动态workflows。该深度研究skill, 是在特定的Claude Code里被发布的。它所采用的恰恰是动态workflows。

以具体的情况来讲, 它会开展网页搜索, 并且是并行地去做这件事, 接着抓取资料的来源之处, 之后针对其中所呈现的说法进行对抗式的验证, 最后将这些整合成为一份带有引用内容的研究报告。

然而, 此类研究并非单单局限于网页搜索范围。举例来说, 亦能够使Claude从Slack的上下文之中梳理出一份状态报告, 或者促使它深入细致地浏览代码库, 从而探查某个功能究竟是通过怎样的方式得以实现的。

深度验证

另一方面, 若你手头持有一份报告, 且期望将其中所引用的每一项事实陈述以及该陈述的来源逐个进行核查, 那么你能够构建起一套工作流, 先是由一个智能体承担起识别全部事实陈述的任务, 接着派生出一个子智能体, 针对每一项陈述展开详尽的核查。除此之外, 你还能够引入一个验证智能体, 专门针对负责溯源的子智能体进行复核, 以此来保证其所引用的来源具备高质量。

排序

你或许会存在一批条目, 打算依据某种定性的标准去进行排序, 并且这个标准恰恰是Claude Code较为专长判断的。比如说, 将支持工单按照bug的严重程度来予以排序。

但要是你打算于一个prompt之中一次性去处理1000多行, 那么质量极易下降, 并且上下文也容纳不下。更为理想化的做法是开展一场「锦标赛」: 构建一条由两两进行比较的Agent所组成的流水线。相较于直接打绝对分, 两两比较一般而言更为可靠。

或可先进行并行分桶排序, 而后将结果予以合并。每次之比较交由一独立 Agent 来达成 , 具确定性的循环负责主持整个比赛括号, 实处上下文里留存的, 唯当下正执行之顺序而已。

记忆与规则遵循

要是你察觉到存在一组规则, 哪怕是写进了 CLAUDE.md 里，Claude 却依旧常常会出现漏掉或者执行得不太好的情况, 那么就能够专门去做一个工作流, 将这些规则罗列出来, 使得验证 Agent 一条一条地进行检查。其中每条规则都对应着一个验证 Agent。

并且, 另外去构建一个有着怀疑者角度的子 Agent, 专款进行复查考察这些诸多的规则是不是合理, 是不是真的与目标达成对齐统一, 如此这般能够降低太多误报情况的出现。

也这般成立: 于最近参与的互动交流以及代码审评反馈之中, 你居然能够挖掘出众多你再三予以纠正的疑难状况；接着促使多个 Agent 以并行的方式展开分门别类的梳理汇总事宜；随后针对每一条备选规则, 去施行那种呈现对抗态势的验证举措, 讲真, 就类似这般追问情形: 在那个特定时刻, 这一条规则切实能成功免除一宗确凿无疑会产生的失误状况吗? 末期阶段, 将通过验证检验的那些诸条规则再次予以提炼, 并最终归结至 《 CLAUDE.md》文档文件上面呢。

根因调查

调试最为有效的办法, 一般来讲是先给出几个彼此独立的假设, 然后逐个进行验证。然而要是仅仅依靠一个上下文窗口, Claude极易陷入某种“自我偏好”: 越去看就越会坚信自己一开始的判断。

这一点能够从结构方面通过工作流予以避免, 工作流能够使得多个 Agent 依据相互隔离的证据各自提出假设, 像一个 Agent 仅仅查看日志, 一个专门只看文件, 另一个仅专注于看数据, 随后各个假设交由一组验证者与反驳者拿去检验。

这样的办法并非仅仅对代码适用, 销售场景同样能够运用, 像是剖析 3 月销售额下滑的缘由；数据工程领域也能够运用, 好比排查某条数据管道失败的缘故。任何需要开展复盘、探寻根因的问题, 均能够借助类似的工作流予以回应。

大规模工单分拣

每一个团队都会遭遇支持工单队列、Bug 报告或者别的积压下来的任务, 这些任务单单依靠人工是万万处理不完的。分流工作流可以针对每一个有待办理的事项予以分类, 和已经追踪的条目做去重比对进而明确有没有重复, 并依据情况采取对应的行动。这些行动也许涵盖尝试直接把问题修复好之后提交, 或者是把它往上移交转着交给人工用户去处理。

对分流工作流而言, 「隔离」（Quarantine）属于一种极为实用的模式, 其核心做法这是禁止那负责读取非受信公共内容的智能体去执行高权限操作, 相反专门负责基于信息来采取行动的智能体才会执行这些高权限操作, 把分流工作流跟 /loop 指令一同使用, 就能让 Claude 持续不断地自动执行此类任务。

探索与品味判断

在探寻针对某一解决办法的各异实现途径之际, 工作流程显得格外有用, 尤其是当任务关联主观“品味”评判, 像设计工作或者命名工作之类, 且需依照一套既定标准, 也就是Rubric来展开评估之时。

尝试让 Claude 去探索, 探索并生成这么一系列潜在的解决方案, 之后指派一个「评审智能体」。为这个「评审智能体」提供一套明确的评估标准, 用这套评估标准去界定什么才是「优质」的解决方案。当这个评审智能体判定某一个方案已经完全符合既定的标准的时候, 这个任务就宣告完成了。另外, 还能够依据这套评估标准, 借助「锦标赛」式的比拼机制, 对各类解决方案进行排序或者最终筛选。

评估

你能够针对特定任务去运行那种轻量级的评估流程, 先是于独立的「工作树」（Worktree）里衍生出一组智能体用以执行任务, 接着又衍生出一组「对比智能体」, 按照既定的评估标准, 针对前面那组智能体所生成的具体输出结果展开比对以及评分。比如说, 你能够借助这一机制, 依照特定的评估标准, 对你所创建的某项Skill进行评估, 并且在这个基础之上予以迭代优化。

模型与智能路由

你能够打造一个针对你的任务有着独特调优的「分类智能体」, 这个「分类智能体」会管决定该去调用哪一个基础模型来开展任务。当你的任务牵扯到好多工具调用的时候, 这样的机制特别实用～这是经由在正式执行任务以前做预先分析和调研, 这个分类智能体能够精确辨认出最适配当前任务的基础模型呢。

比如说, 对于「解释认证模块（Auth module）的工作原理」这个任务而言, 并非简单地固定着最佳基础模型的选择, 而是由该认证模块当中所包含的文件数量, 以及整个代码库的整体结构形态来决定。在这样的情况下, 分类智能体能够承担起这项预先进行分析的职责, 并且依据对于任务预期复杂度的判断, 智行般地将任务路由到 Sonnet 或者 Opus 等不同的基础模型那里去进行处理。

何时不宜使用动态工作流

一项相对较新的功能是「工作流」。它在许多应用场景下能带来显著成效, 让事情更容易做, 然而并非每一项任务都得依靠它；要是滥用「工作流」, Token 资源消耗可能远超想象。

充分挖掘 Claude Code 的潜能的最佳实践策略是发挥创意并以一种前所未有的方式灵活运用工作流, 对于常规的编程任务要自问世问这项任务是否真的有必要投入额外的计算资源来运行工作流, 比如大多数传统的编码任务并不需要由五名审阅者组成的评审小组。

构建动态工作流的技巧 提示词设计

对于动态工作流而言, 要是运用我们上文详细叙述的特定的技巧去编写详尽的提示词, 往往能够获取最佳的效果。

工作流并非专门限定于大型任务才适用, 你能够借助提示词指令, 促使模型去完成一种被叫做「快速工作流」的流程, 例如你能够迅速搭建一个用以对付特定假设展开「对抗性审查」的一类工作流。

结合使用 /goal 与 /loop 指令

假如你有那种需要去开展可重复进行的工作流的情况, 拿任务分流来说, 或者是资料调研, 还有信息核实之类的, 此时建议配合着使用 /loop 指令, 目的是达成周期性执行的效果, 并且还要结合 /goal 指令, 以此来设定清晰明确的任务完成方面的硬性指标。

Token 使用预算

你能够针对动态工作流去设定明晰的Token使用预算, 借由这个来限制单项任务所耗费的Token数量。还能够在提示词里直接指定预算额度, 就像输入这种——「use 10k tokens」（使用10k Token）, 如此系统就会自动设定对应的上限。

标签： Claude动态工作流 AI并行处理 复杂任务 工作流执行 智能路由