从 Claude Code 动态工作流看 Agent Harness 设计

Claude Code 最近推出了一个很值得关注的新能力Dynamic Workflows动态工作流。有了它Claude Code 就能动态地写出一套自己的多 Agent Harness。Claude 可以根据当前任务生成一段 JavaScript 工作流来调度多个子 Agent、分配上下文、选择模型、运行验证流程并把结果汇总回来。Claude Code 动态工作流的特点是让 Agent 不只是在一个对话里完成任务而是可以为当前任务临时搭出一套执行框架。当我们理解了这套执行框架也就能更好地理解 Agent Harness 是什么它到底在解决什么问题。Agent Harness 是什么我们先来解释一下 Harness。在 Claude 这篇文章里Harness 可以理解为一套“让 Agent 更有组织地干活”的执行框架。它负责决定任务怎么拆、Agent 怎么调用、上下文怎么隔离、结果怎么合并以及中断后怎么恢复。Claude Code 本身就有一套默认 Harness是这个编程 Agent 背后的执行框架。它主要面向编码任务负责组织 Claude Code 如何读取文件、理解项目、编辑代码、运行命令并根据执行结果继续调整。这套默认 Harness 已经能覆盖很多日常开发场景。但 Claude 官方表示有些任务为了达到更好的效果过去是要在 Claude Code 之上额外构建自定义 Harness比如 Research、安全分析、Agent Teams、Code Review 等。有了动态工作流Claude 现在就能动态生成这类 Harness让它更自然地处理复杂任务。以前开发者需要自己手写一套流程把多个 Claude Code 实例组织起来现在是 Claude Code 可以根据任务现场写一套工作流来组织自己。这就是动态工作流的核心功能。动态工作流的工作原理Dynamic Workflows 会先执行一个 JavaScript 文件。这个文件中有一些特殊函数可以用来创建和协调多个 subagent。它还支持标准 JavaScript 能力比如 JSON、Math、Array来处理结构化数据。图 1上图展示了工作流是如何通过 JavaScript 协调 subagent除此之外工作流还可以决定两件事每个子 Agent 用哪个模型以及要不要让它运行在独立的 worktree 里。这两个能力很重要模型选择会影响任务成本和执行效果。不是每个子任务都需要最强模型比如分类、清洗、初筛这类任务用更轻的模型可能就够了但如果任务需要理解复杂代码、做深入推理就可以交给更强的模型。worktree 解决的是隔离问题。在做大规模项目重构时不同子 Agent 可以在各自的 worktree 中进行修改互不干扰。最后再由另一个 Agent 统一审查、合并和验证。这里要注意一件事如果你的工作流被意外中断或者是终端退出。等你的 session 恢复之后工作流可以从中断位置继续执行。所以Dynamic Workflows 不只是一次问答式任务还能充当一个可恢复、可编排、可长期运行的执行流程。动态工作流的重要性上面也提过Claude Code 默认的 Harness 已经很好用足以覆盖很多日常编码任务。但它的计划和执行主要还是发生在同一个上下文窗口里。一旦任务变长、复杂化需要大规模并行和严格验证这种方式就容易暴露出一些问题。官方提到了下面这些典型失败场景第一个是Agentic laziness就是 Agent 在复杂、多步骤任务中出现“提前收尾”的情况。任务还没完全做完它就停止执行并声明已经完成了。Claude 提到过一个例子是安全审查中一共有 50 个问题它处理了 35 个就认为工作结束了。第二个是Self-preferential biasClaude 会倾向于偏好自己的结果尤其是你让它根据某个标准来验证、评判自己输出的时候。第三个是Goal drift任务执行时间越长Claude 对原始目标的保持能力越容易下降。特别是在上下文压缩之后每次总结都会带来信息损失一些边界条件、反例要求以及“不要做什么”的限制都可能会慢慢丢掉。上面这三个问题都和“一个上下文承担太多职责”有关。如果一个 Agent 既要规划、又要执行、还要验证、还得做总结它就很容易在长任务里失真。Dynamic Workflows 的做法是把任务拆给多个子 Agent让它们拥有独立上下文和更聚焦的目标。让一个 Agent 负责提出方案另一个 Agent 负责验证方案第三个 Agent 负责反驳前两个 Agent 的结论。这样一来验证过程就不完全依赖同一个上下文里的自我判断。这也是动态工作流对 Agent Harness 设计最有启发的地方复杂任务的可靠性不能只靠模型本身变强也要靠执行结构来保证。动态工作流 vs 静态工作流在 Dynamic Workflows 之前开发者也可以用 Claude Agent SDK或者 claude -p 指令去协调多个 Claude Code 实例做一套 Static workflow即静态工作流。由于静态工作流要提前考虑各种边界情况所以通常会写得比较通用。Dynamic Workflows 的思路会更灵活。Claude 可以根据当前任务生成一套更贴合任务本身的 Harness。动态工作流不是提前写死一个固定流程而是根据这次任务现场定制流程。图 2“静态工作流”和“动态工作流”的对比。这点很像从“固定流水线”走向“任务级编排”。不同任务需要的工作流结构并不一样。代码迁移可能会按模块、调用点、失败测试来拆分事实核查可能会先抽取声明再逐条查证最后合成报告排序任务则可能会采用两两比较、锦标赛或者先分桶再合并。所以Dynamic Workflows 强调的并不是某一套固定流程而是让执行框架跟着任务变化。放到 Agent Harness 设计里这一点很关键复杂任务需要的 Harness往往也应该是可调整、可定制的。典型工作流模式Claude 原文里总结了六种常见模式通过它们我们可以快速了解 Dynamic Workflows 到底能做什么。Classify-and-act先分类再行动这个模式会先让一个分类 Agent 判断任务属于哪一类再根据分类结果 classifier把任务交给不同 Agent或者进入不同的处理流程。流程末尾也可以再加一个分类器用来判断最终输出属于哪种类型。它适合处理任务结构复杂、类型不统一的场景。假如现在我们有一批工单有的是 Bug有的是产品反馈有的是使用问题咨询。这个工作流可以先完成分类再把不同类型的问题交给对应的 Agent 处理。Fanout-and-synthesize拆开并行最后汇总这个模式会把一个大任务拆成很多小步骤每个小步骤交给一个 Agent 处理最后再把所有结果合并。Claude 官方指出这种模式适合大量小步骤或者每一步都需要独立、干净上下文的任务。汇总阶段会等待所有 fan-out Agent 完成再把结构化输出合成一个结果。举个例子你要验证一篇文章里的 80 个技术说法可以先把所有待核查说法抽取出来再为每条说法启动一个子 Agent 分别查证最后统一生成核查报告。这里的关键不是“多开几个 Agent”而是把大任务拆成一组可以独立处理的小任务让每个 Agent 的上下文更干净。Adversarial verification对抗式验证这个模式会在一个 Agent 产出结果之后再启动另一个 Agent 按照既定标准进行验证甚至专门从反方向检查它的问题。它很适合代码审查、安全分析、事实核查、方案评估这类任务。举个例子一个 Agent 可以负责修复 Bug另一个 Agent 专门检查这次修改有没有引入新问题一个 Agent 负责给出技术判断另一个 Agent 则根据证据逐条核查、提出反驳。看得出来Claude 是在用对抗结构来降低自我偏见。让同一个 Agent 自己检查自己容易漏掉问题把验证者独立出来结果通常会更稳。Generate-and-filter生成再筛选这个模式会先生成一批候选结果再根据评分标准、验证流程或去重逻辑从中筛出质量更高的结果。比如起名字、写方案、列备选架构、生成测试用例都可以先多生成一些候选项再去掉重复、低质量或者不符合要求的结果。Tournament锦标赛式比较Tournament 模式会让多个 Agent 用不同思路解决同一个任务再通过两两比较让评审 Agent 选出更好的结果直到得到最终胜出方案。这个模式很适合主观性强、难以直接打分的问题。比如 CLI 工具命名、产品方案选择、架构路线比较。很多时候让模型绝对打分并不稳定但让它比较 A 和 B 哪个更好往往更容易得到可靠判断。Loop until done直到完成为止对于工作量不确定的任务工作流可以持续启动 Agent直到满足预设的停止条件。像是没有新的发现、日志里不再出现新的错误或者测试已经全部通过都可以是停止条件。这类模式适合调试、根因分析、持续分拣、反复验证等任务。它解决的是“提前写死执行轮次”不够可靠的问题。有些任务很难一开始就判断要跑几轮检查三轮可能还不够跑太多轮又会浪费资源。更合适的做法是先把停止条件定义清楚再让流程自己判断什么时候结束。动态工作流的使用场景这里给出六大动态工作流的使用场景迁移和重构大规模迁移和重构是 Dynamic Workflows 比较典型的使用场景。举个例子我们要把项目中 User 字段改名为 Account。这个任务表面上只是改名但在真实项目里可能会涉及调用点、测试、模块边界、文档、类型定义、迁移脚本等很多地方。像 Bun 从 Zig 重写到 Rust 时就用了 workflows。对于这类任务关键是把工作拆开有的子任务负责处理调用点有的负责修复失败测试有的负责检查具体模块。每个修复任务都可以交给一个子 Agent在独立的 worktree 里处理最后再由另一个 Agent 做审查、合并和验证。这也符合工程里的常识大规模重构最怕不同修改互相干扰。worktree 隔离、并行修复、统一审查可以让多个 Agent 更像一个临时组成的工程团队。深度研究Claude Code 里的 /deep-research skill 也用了 Dynamic Workflows。它会并行搜索网页、抓取来源、对说法进行对抗式验证最后合成一份带引用的报告。这个流程和人工研究很像先扩大搜索范围收集足够多的材料再核查信息质量排除不可靠的来源最后把验证后的信息汇总成报告。类似思路可以迁移到代码库研究里。像是让 Claude 研究一个项目里的鉴权模块如何工作它可以让不同 Agent 分别查看路由、中间件、数据库模型和测试文件最后再合成一份整体说明。深度验证如果你有一份报告需要检查里面的事实性说法是否可靠也可以生成一个 workflow 来完成验证。官方给出的思路是先让一个 Agent 找出报告里的所有待核查说法再为每条说法启动一个子 Agent 分别检查。必要时还可以再加一个验证 Agent专门来判断引用来源的质量是否足够高。图 10“抽取待核查说法 → 分别验证 → 再检查来源质量”的流程这个思路对技术文章也有参考价值。如果一篇文章中有很多判断像是某个工具支持什么能力某个模型有什么限制某种方案适合什么场景。单靠作者人工检查很容易漏掉细节。我们可以用 workflow 先把这些待核查说法抽出来再逐条验证可以减少文章里的事实硬伤。大规模排序Claude 原文还提到很多团队都会遇到需要排序的对象像是支持工单、Bug 列表、候选简历、需求池等。如果把 1000 行数据直接塞进一个 prompt让模型一次性排序质量很容易下降也可能超出上下文限制。更合适的做法是把排序过程拆开可以先让模型做两两比较或者先按优先级分组再分别排序和合并。记忆和规则遵守Claude 还提到一个很实用的做法如果你发现它总是漏掉某些规则哪怕已经写进 CLAUDE.md 里还是会忘就可以专门创建一个 workflow让每条规则都配一个 verifier agent 来检查。这个流程也可以反过来用从最近的 session 和 code review comment 里找出你反复纠正 Claude 的地方再把这些纠正聚类、验证最后沉淀回 CLAUDE.md。这个用法挺有意思。它把“人类反复纠错”变成了一套可以沉淀的规则更新流程。Agent 做完任务之后系统还能从人和 Agent 的互动历史里提取规则再反过来改善下一次执行。根因分析根因分析也很适合动态工作流。官方提到调试时最好提出多个独立假设再逐一验证。但如果只在一个上下文窗口里完成这件事Claude 可能会受到自我偏见影响过早相信某个判断。工作流可以用更结构化的方式来降低这个问题让不同 Agent 从不同证据出发提出假设比如一个看日志一个看文件一个看数据再让验证 Agent 和反驳 Agent 分别检查这些假设判断哪些更站得住脚。这不只适用于代码问题。像是销售额为什么下降、某条数据管道为什么失败、一次事故的真实原因是什么都可以用类似方法拆开分析。动态工作流的局限性Dynamic Workflows 很强但不适合所有任务。Claude 官方也提醒这项能力还很新而且会带来更多 token 消耗。改一个函数、补一个测试、修一个小 Bug普通 Claude Code 通常就够了。更适合使用 Dynamic Workflows 的是那些步骤多、要并行处理、交叉验证、容易遗漏或者单个上下文放不下的任务。所以工作流的价值不在于“多开几个 Agent”而在于降低复杂任务的不确定性。使用动态工作流的一些技巧Claude 原文最后给了一些使用建议。首先prompt 要尽量具体。你可以直接让 Claude 创建 workflow也可以使用触发词 ultracode 来确保 Claude Code 创建 workflow。但如果能提前说明任务结构、验证标准和停止条件效果会更好。其次workflow 可以和 /goal、/loop 结合使用。比如分拣、研究、验证这类需要反复执行的任务可以用 /loop 周期性运行再用 /goal 设置明确的完成条件。另外也可以在 prompt 里指定 token budget比如 “use 10k tokens”让 workflow 在预算内执行。最后workflow 还可以保存和分享。官方提到可以在 workflow 菜单里按 s 保存工作流也可以把它们 check in 到 ~/.claude/workflows或者通过 skill 分发。图 13workflow 可以被保存、复用和分发这也说明Dynamic Workflows 不只是一次性执行脚本。如果某个流程在团队里经常使用它也可以沉淀下来变成团队共享的 Agent 工作方式。从动态工作流看 Agent Harness 设计如果只看功能Dynamic Workflows 是 Claude Code 的一个新能力让 Claude 根据任务生成工作流调度多个子 Agent。但从 Agent 系统设计角度看它真正强调的是复杂任务不能只靠一个上下文一路做到底。任务需要拆分上下文需要隔离验证需要独立流程也要能在中断后恢复。不同子任务还可以选择不同模型和预算避免所有事情都挤在同一个执行路径里。这些设计放在 Claude Code 里是 Dynamic Workflows放到更大的 Agent 系统里其实就是 Agent Harness 要解决的问题。所以理解 Dynamic Workflows 的价值不只是看它能不能多开几个 Agent而是看它如何把复杂任务组织成一套更稳定的执行流程。这也是这篇文章里Agent Harness 最值得被单独拿出来讨论的原因。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】