译：每个任务都有自己的执行框架：Claude Code 中的动态工作流
上周，我们在 Claude Code 中发布了动态工作流。现在，Claude 可以即时编写自己的 harness，也就是根据当前任务量身定制的执行框架。
默认的 Claude Code harness 是为编程任务构建的，但它其实也适用于很多其他类型的任务。因为事实证明，很多任务在形态上都很像编程任务。不过，有些任务类型如果想达到最佳表现，就需要在 Claude Code 之上构建自定义 harness，比如研究、安全分析、智能体团队，或者代码审查。
工作流允许你在 Claude Code 之上动态创建 harness，让 Claude 能够更原生地解决这些问题。你也可以把这些工作流分享给别人，或者重复使用。
在这篇文章中，我会介绍自己对工作流的一些早期使用经验和体会，帮助你更好地发挥它的能力。请注意，相关最佳实践仍在发展中：动态工作流通常会消耗更多 token，因此更适合复杂、高价值的任务。
示例提示词
在进入技术细节之前，我想先给出几个示例提示词，帮助你理解工作流可以做什么：
“这个测试大概每 50 次会失败 1 次。设置一个工作流来复现它。提出几个关于竞态问题的竞争性理论，在证据只支持其中一个理论之前不要停止。”
“使用一个工作流，回顾我最近 50 次会话，挖掘我反复纠正 Claude 的地方，并把这些高频问题整理成 CLAUDE.md 规则。”
“使用一个工作流，查看过去 6 个月 Slack 里的 #incidents 频道，找出那些反复出现但没人创建 ticket 的根因。”
“拿我的商业计划书跑一个工作流，让不同智能体分别从投资人、客户和竞争对手的角度猛烈挑刺。”
“这里有一个包含 80 份简历的文件夹。使用一个工作流，根据后端岗位要求对它们进行排序，并对前 10 名进行二次检查。你可以用 AskUserQuestion 工具采访我，以确定评分标准。”
“我需要给这个 CLI 工具起个名字。使用一个工作流头脑风暴出一批候选名字，然后用锦标赛方式选出前 3 个。”
“使用一个工作流，把我们的 User 模型在所有地方重命名为 Account。”
“检查我的博客草稿，并使用一个工作流根据代码库验证里面的每一条技术声明。我不想发布任何错误内容。”
动态工作流是如何工作的
动态工作流会执行一个 JavaScript 文件，这个文件里有一些特殊函数，用来创建和协调子智能体：
动态工作流也包含标准 JavaScript 函数，比如 JSON、Math 和 Array，用来帮助处理数据。
特别值得注意的是，动态工作流可以决定某个智能体使用哪个模型，也可以决定子智能体是否运行在自己的 worktree 中。这让 Claude 可以根据任务需要选择合适的智能水平和隔离程度。
如果工作流被打断，比如用户主动中断，或者退出了终端，那么恢复会话后，工作流可以从之前中断的位置继续执行。
为什么需要动态工作流
当你让默认的 Claude Code harness 执行一个任务时，它需要在同一个上下文窗口中同时完成规划和执行。对于很多编程任务来说，这种方式非常有效。但对于长时间运行、大规模并行、高度结构化，或者带有对抗性质的任务来说，它可能会出现问题。
原因是：Claude 在单一上下文窗口中处理复杂任务的时间越长，就越容易受到几类特定失败模式的影响：
- 智能体式偷懒：Claude 在完成复杂、多步骤任务之前就提前停止，并在只取得部分进展后宣称任务已经完成。例如，在一次安全审查中，本来有 50 个问题需要处理，但它只处理了 35 个就结束了。
- 自我偏好偏差：Claude 倾向于更相信自己的结果或发现，尤其是在你要求它按照某个评分标准验证或评判这些结果时。
- 目标漂移：经过很多轮对话后，尤其是在上下文压缩之后，Claude 会逐渐丢失对最初目标的精确理解。每次总结都会损失信息，像边界条件要求或者“不要做 X”这样的限制，很容易在过程中丢失。
创建工作流可以通过编排多个独立的 Claude 子智能体来对抗这些问题。每个子智能体都有自己的上下文窗口，并且有更聚焦、更隔离的目标。
动态工作流 vs 静态工作流
你以前可能已经使用 Claude Agent SDK 或者 claude -p 创建过静态工作流，用来协调多个 Claude Code 实例一起工作。
但是，因为静态工作流需要处理所有边界情况，所以它们通常会更通用。现在，借助 Claude Opus 4.8 和动态工作流，Claude 已经足够智能，可以为你的具体使用场景编写一个量身定制的 harness。
使用动态工作流时的有用模式
你可以直接让 Claude 创建一个动态工作流，也可以使用触发词 “ultracode”，确保 Claude Code 会创建一个工作流。
不过，如果你能建立一个关于动态工作流如何运作的心智模型，就会更清楚什么时候该使用它，以及如何通过提示词引导 Claude。
在构建工作流时，Claude 可能会使用并组合以下几种常见模式：
分类并执行
使用一个分类器智能体来判断任务类型，然后根据任务类型路由到不同的智能体或行为。也可以在流程结束时使用分类器来判断输出结果。
扇出并综合
把一个任务拆分成许多更小的步骤，让每个步骤由一个智能体处理，然后再综合这些结果。
这种模式特别适合步骤数量很多的任务，或者每个步骤都适合拥有一个干净独立的上下文窗口的场景。这样可以避免不同步骤之间互相干扰，或者上下文交叉污染。
综合步骤是一个屏障：它会等待所有扇出的智能体完成，然后把它们的结构化输出合并成一个最终结果。
对抗式验证
对于每个创建出来的智能体，再创建一个独立的智能体，根据评分标准或判断准则，对前者的输出进行对抗式验证。
生成并过滤
围绕某个主题生成一批想法，然后根据评分标准或验证结果进行筛选，去除重复项，最后只返回质量最高、经过测试的想法。
锦标赛
不是把工作拆开，而是让多个智能体在同一个任务上竞争。
创建 N 个智能体，让它们分别使用不同方法尝试完成同一个任务。然后通过提示词或模型，让一个裁判智能体以两两比较的方式评判结果，直到选出最终胜者。
循环直到完成
对于工作量未知的任务，不使用固定次数的处理流程，而是不断创建智能体，直到满足停止条件为止，比如没有新的发现，或者日志里不再出现错误。
使用场景
你可以更有创造性地思考什么时候、以及如何让 Claude Code 创建动态工作流。我发现，工作流有时在非技术任务中甚至更有用。
迁移和重构
Bun 就是使用工作流从 Zig 重写为 Rust 的。你可以在 Jarred 的 X 线程中了解更多细节。
关键在于把任务拆分成一系列需要处理的步骤，比如调用点、失败测试、模块等。为每个修复任务启动一个子智能体，并让它在一个 worktree 中完成修复；然后再让另一个智能体进行对抗式审查，最后合并结果。
你可以考虑告诉智能体不要使用资源消耗很大的命令，这样你就可以尽可能提高并行度，同时避免耗尽本机资源。
深度研究
我们在 Claude Code 中发布了一个深度研究 skill，也就是 /deep-research，它使用了动态工作流。具体来说，它会扇出多个网页搜索、获取来源、对其中的声明进行对抗式验证，并综合生成一份带引用的报告。
不过，这种研究并不只适用于网页搜索。比如，你也可以让 Claude 根据 Slack 中的上下文编写状态报告，或者让它深入探索代码库，研究某个功能是如何工作的。
深度验证
另一方面，如果你有一份报告，并希望检查和溯源其中引用的每一条事实声明，那么可以生成一个工作流：先让一个智能体识别所有事实声明，然后为每一条声明启动一个子智能体进行详细检查。
你还可以再设置一个验证智能体，用来检查负责溯源的子智能体，确保它引用的来源质量足够高。
排序
你可能会有一组项目，希望按照某种定性指标进行排序，而你认为 Claude Code 擅长评估这种指标。例如：按照 bug 严重程度给支持工单排序。
但如果你试图在一个提示词里对 1000 多行数据排序，质量会下降，而且上下文也装不下。
更好的方式是运行一个锦标赛，或者建立一个由成对比较智能体组成的流水线。成对比较通常比绝对打分更可靠。也可以并行进行分桶排名，然后再合并结果。
每一次比较都由一个独立智能体完成，因此确定性的循环负责维护整个竞赛表，而上下文中只需要保留当前运行顺序。
记忆和规则遵循
如果你发现 Claude 经常漏掉或难以遵守某些规则，即使你已经把它们写进 CLAUDE.md 文件中，也可以创建一个工作流，把这些规则列出来，并让验证智能体逐条检查。每条规则对应一个验证智能体。
创建一个“怀疑者人格”的子智能体来审查这些规则，也能帮助避免产生太多误报。
反过来也可以：挖掘你最近的会话和代码审查评论，找出你反复做出的纠正；再用并行智能体对它们进行聚类；对每个候选规则进行对抗式验证，比如判断“这条规则是否真的能防止一个真实错误”；最后把通过验证的规则提炼回 CLAUDE.md。
根因调查
调试最有效的方式，是提出几个相互独立的假设，然后分别验证它们。但如果只使用一个上下文窗口，Claude 可能会陷入自我偏好偏差。
工作流可以从结构上避免这个问题：它可以启动多个智能体，让它们基于彼此独立的证据来源生成假设。例如，分别为日志、文件和数据启动不同智能体。之后，每个假设都可以接受一组验证者和反驳者的审查。
这并不只适用于代码。工作流也可以用于销售分析，比如“为什么 3 月销售额下降了？”；也可以用于数据工程，比如“为什么这个 pipeline 失败了？”；或者用于任何事后复盘场景。
大规模分诊
每个团队都会有支持队列、bug 报告，或者其他无法完全由人工处理的积压任务。
一个分诊工作流会对每个项目进行分类，与已经追踪的内容进行去重，然后采取行动。这可能意味着尝试修复问题，也可能意味着升级给人工用户处理。
分诊工作流中的一个有用模式是“隔离区”。它会禁止那些读取不可信公共内容的智能体执行高权限操作。真正的高权限操作，则由负责基于信息采取行动的智能体来执行。
你可以把分诊工作流和 /loop 搭配起来，让 Claude 持续执行这类任务。
探索和品味
当你需要探索某个解决方案的不同方向时，工作流会很有用。尤其是在设计、命名这类带有审美判断的任务中，如果再配合评分标准，效果会更好。
你可以让 Claude 探索一批解决方案，然后给审查智能体一套判断“好方案”的评分标准。当审查智能体认为已经满足标准时，任务就完成了。
这些方案也可以根据评分标准，通过锦标赛方式进行排序或筛选。
评测
你可以为某些特定任务运行轻量级评测：启动多个独立智能体，让它们在各自的 worktree 中完成任务，然后再启动比较智能体，根据评分标准比较和打分这些具体输出。
例如，你可以用这种方式评估并改进自己创建的某个 skill，看它是否符合特定标准。
模型和智能路由
你可以创建一个针对自己任务调优过的分类器智能体，由它决定应该使用哪个模型。
当你的任务需要大量工具调用，并且在真正执行之前需要做一些研究时，这种方式尤其有用，因为前期研究可以帮助识别最适合当前任务的模型。
例如，对于“解释 auth 模块如何工作”这个任务，最适合的模型取决于 auth 模块包含多少文件，以及整个代码库的结构。分类器智能体可以先做这项研究，然后根据预期复杂度把任务路由给 Sonnet 或 Opus。
什么时候不该使用动态工作流
工作流仍然是一个新功能。虽然在许多使用场景中，它能带来远超常规方式的结果，但并不是每个任务都需要它，而且它最终可能会消耗显著更多 token。
最好用创造性的方式使用工作流，把 Claude Code 推向你以前没有尝试过的方向。对于普通编程任务，可以先问自己：它真的需要更多计算资源吗？
例如，大多数传统编程任务并不需要一个由 5 个审查者组成的评审小组。
构建动态工作流的建议
提示词
针对动态工作流，使用更详细的提示词，并明确采用前面提到的具体技巧，通常能得到最好的结果。
工作流并不只适用于大型任务。你也可以提示模型使用一个“快速工作流”。例如，你可以创建一个快速的对抗式审查流程，用来检查某个假设。
结合 /goal 和 /loop
当你使用可以重复执行的工作流时，比如分诊、研究或验证，可以把它们和 /loop 搭配起来，让它们按固定间隔运行；同时使用 /goal 设置一个硬性的完成要求。
Token 使用预算
你可以为动态工作流设置明确的 token 使用预算，限制某个任务最多消耗多少 token。
例如，你可以在提示词中写：“use 10k tokens”，这样就会设置一个上限。
保存和分享动态工作流
你可以在工作流菜单中按下 “s” 来保存工作流。你可以把它们提交到 ~/.claude/workflows，也可以通过 skill 分发。
如果想通过 skill 分享工作流，可以把 JavaScript 工作流文件放进 skill 文件夹中，并在 SKILL.MD 中引用它们。
为了提高灵活性，你可能会希望提示 Claude：把 skill 中的工作流看作一个模板，而不是一段必须逐字执行的脚本。
一个新的探索起点
工作流是扩展 Claude Code 的一种很有帮助的新方式。我鼓励你把它们看作一个起点，用来探索使用 Claude 完成任务的新方法。关于如何最好地使用它们，还有很多东西值得发现。欢迎告诉我你的发现。
本文作者是 Thariq Shihipar 和 Sid Bidasaria，他们是 Anthropic 负责 Claude Code 的技术团队成员。