Claude Code · Dynamic Workflows · Multi-Agent Harness

Claude Code 动态工作流:让 Agent 自己为任务写 Harness

这篇博客讲的是 Claude Code 的一个关键跃迁:不再只是“主 Agent 分派几个子任务”,而是让 Claude 为复杂任务临时写一段 JavaScript 编排脚本,把任务拆成几十到上百个 subagents,并用可恢复、可保存、可复用的 workflow 运行。

原文:A harness for every task 作者:Thariq Shihipar / Sid Bidasaria 发布时间:2026-06-02 整理时间:2026-06-03

一句话理解

动态工作流把“怎么组织 Agent 干活”从对话上下文搬进脚本。脚本保存循环、分支、并行、裁判、验证和中间结果;Claude 主上下文只需要接收最终结论。

JSworkflow 是 Claude 写出的 JavaScript 编排脚本
100+适合几十到上百个 subagents 的任务规模
3主要解决懒惰停止、自我偏见、目标漂移三类失败模式

1. 核心结论

Dynamic workflows 是 Claude Code 的一种新型 Agent 编排能力。它让 Claude 根据任务临时生成一个 workflow script,由运行时在后台执行;脚本负责创建、协调、暂停、恢复、保存 subagents,并把复杂任务的中间状态留在脚本变量里。

不是更长提示词它不是把更多规则塞进主上下文,而是把调度逻辑写进可运行脚本。
不是普通并行它可以有分类器、裁判、验证器、循环终止条件和模型路由。
不是日常默认它更耗 token,适合复杂、高价值、长期、对抗性或大规模任务。

我的理解:这标志着 Coding Agent 从“会调用工具”进一步走向“会设计自己的运行时”。Claude 不只是做任务,而是先为任务设计一个临时组织结构,再让这个组织结构执行任务。

2. 为什么默认 Claude Code Harness 不够

默认 Claude Code 在很多常规编码任务上很有效,因为它能在一个上下文窗口里规划、读代码、修改、测试、迭代。但当任务变成长时间、多分支、大规模、强结构化或需要对抗验证时,单一上下文会出现明显退化。

失败模式通俗解释典型表现workflow 怎么缓解
Agentic laziness复杂任务没做完就提前宣布完成安全审查 50 项,只处理 35 项就收尾脚本显式保存任务列表、检查未完成项
Self-preferential bias模型更容易相信自己的判断让同一个 Agent 审自己写的报告,容易放过问题独立 verifier / refuter agent 对抗审查
Goal drift长对话和压缩后逐渐忘记初始约束边界条件、“不要做 X”等要求丢失脚本把目标、循环和停止条件固定下来
单上下文模式 Plan Execute 计划、执行、验证、中间结果都挤在同一个窗口 长任务容易压缩、漂移、提前收工 Dynamic Workflow JS Script Agent A Agent B Verifier 循环、分支、中间结果留在脚本变量里 主上下文只接收最终产物和摘要
图 1:核心差异不是“多几个 Agent”,而是“谁持有计划和中间状态”。

3. 机制拆解:动态工作流怎么跑

官方文档把 dynamic workflow 定义为一个 JavaScript script。Claude 为你的任务生成脚本;运行时在后台执行;脚本负责组织 subagents;你的主会话保持可响应。

用户请求 ↓ Claude 判断任务适合 workflow ↓ Claude 生成 JavaScript workflow script ↓ 用户批准计划 ↓ workflow runtime 后台执行 ↓ spawn / coordinate subagents ↓ 收集、验证、筛选、综合 ↓ 最终报告回到当前会话
模型与隔离可调workflow 可以决定用哪个模型,也可以让 subagent 在独立 worktree 中运行。
可暂停可恢复如果用户中断或退出终端,恢复会话后 workflow 可以继续。
后台进度可看通过 `/workflows` 可以查看阶段、agent 数量、token、耗时和每个 agent 的发现。
可保存可复用运行效果好的 workflow 可以保存到 `~/.claude/workflows`,也能通过 skill 分发。

文档还强调这是 research preview,需要 Claude Code v2.1.154 或更新版本;在 Pro 中需要从 `/config` 里开启 Dynamic workflows。

4. 它和 Subagents、Skills、Agent Teams 的区别

能力谁持有计划中间结果在哪里适合规模可复用的东西
SubagentsClaude 主会话逐轮决定Claude 上下文每轮少量委派worker 定义
SkillsClaude 按说明执行Claude 上下文与 subagents 类似技能说明和资源
Agent Teamslead agent 逐轮监督共享任务列表少数长跑 peer sessions团队定义
Workflows脚本持有 loop / branch / state脚本变量几十到上百个 agents编排脚本本身
我的理解:subagent 是“找一个人帮忙”;agent team 是“组一个小队”;workflow 是“写一个项目管理脚本,让脚本按规则不断派人、收结果、审结果”。

5. 六种常用动态工作流模式

Classify-and-act先由分类器判断任务类型,再路由到不同 agent 或输出策略。
Fan-out-and-synthesize把任务拆成许多小块并行处理,最后统一综合。
Adversarial verification每个输出都交给独立验证器按 rubric 挑错。
Generate-and-filter先大量生成,再去重、评分、过滤,只保留高质量结果。
Tournament多个 agent 用不同方法竞争,裁判两两比较直到选出赢家。
Loop until done任务量未知时循环派 agent,直到没有新发现或日志无错误。
Classifier Path A Path B Fan out Agent Agent Agent Synthesize Attempt Verifier Result
图 2:动态工作流的价值在于组合模式,而不是单个模式。

6. 使用场景:哪些任务最适合

场景为什么适合 workflow推荐模式
大迁移 / 大重构可按 callsite、模块、失败测试切分,并让独立 agent 在 worktree 中修复fan-out + adversarial review
深度研究不同搜索方向并行,来源之间互相核验,最后生成引用报告fan-out + cross-check + synthesize
事实核查先抽取所有 factual claims,再逐条验证来源质量claim extraction + verifier agents
大规模排序1000+ 条 ticket 或候选项难以放进一个上下文pairwise tournament / bucket-rank
规则遵守CLAUDE.md 中的规则可能仍被遗漏,可以一条规则一个 verifierrule-specific verification
根因调查多个独立假设避免单 Agent 过早相信自己的解释hypothesis agents + refuters
大规模 triage支持队列、bug reports、公开内容需要分类、去重、升级或尝试修复classify + quarantine + loop
命名 / 设计 / 品味探索需要多个方案、rubric、评审和锦标赛generate-and-filter + tournament
轻量 eval可以让多个 worktree 中的 agent 输出,再由比较 agent 打分parallel eval + judge
模型路由先评估任务复杂度,再选择 Sonnet / Opus 等模型classifier + model routing
非技术任务也很适合 博客反复强调,动态工作流不只用于写代码。业务计划评审、招聘排序、事故复盘、销售下滑分析、研究报告核查,这些都可以被拆成并行、验证、综合的结构。

7. 怎么开始用

最简单的方式是直接在 prompt 里要求 Claude 使用 workflow。官方也提到可以使用触发词 ultracode 来确保 Claude Code 创建工作流。文档进一步说明,/effort ultracode 会把高推理努力与自动 workflow 编排结合起来,让 Claude 为有实质复杂度的任务自动规划 workflow。

示例思路: ultracode: audit every API endpoint under src/routes for missing auth checks use a workflow to verify every technical claim in this report against source files run a quick workflow: generate three competing hypotheses for this flaky test, then have verifier agents check each one against logs and code
操作作用
/deep-research内置 workflow,对问题做多角度搜索、交叉验证并生成引用报告
/workflows查看运行中和已完成的 workflows,进入进度视图
/loop用于重复执行研究、triage、验证等 workflow
/goal设置硬完成条件,避免任务只做一部分就收尾
~/.claude/workflows保存工作流脚本,复用为命令

如果要通过 skill 分发,做法是把 JavaScript workflow 文件放到 skill 目录,并在 SKILL.md 中引用。我的建议是把 workflow 当成模板而不是死脚本,这样 Claude 可以按当前任务调整。

8. 成本、边界和安全

什么时候不该用

如果只是常规编码任务,一个主 Agent 加少量 subagents 就够了。动态工作流会显著增加 token 使用和等待时间,不应该为了“显得高级”而给每个任务配评审团。

不适合小改动、单文件修复、明确 bug、低价值任务、需要马上返回的任务。
适合高价值、复杂、多分支、长期、需要独立验证、需要可复用编排的任务。

安全点:Quarantine

博客在大规模 triage 场景里提到一个重要模式:读取不可信公开内容的 agents 不应拥有高权限动作能力;真正执行动作的 agents 应该被隔离出来。这个思路非常重要,因为 prompt injection、恶意 issue、恶意网页、恶意日志都可能影响 agent 行为。

风险建议
公开内容提示注入读取者与执行者隔离;读取者只输出结构化摘要
并行命令过载提示 workflow 避免重型命令,限制并发和资源消耗
token 失控在 prompt 里设预算,例如限定 10k token
错误合并每个 worktree 变更都经独立 verifier 审查后再合并
规则误报让 skeptic persona 审查规则本身,避免 verifier 过度严格

9. 我反复阅读后的关键笔记

9.1 Harness 是 Agent 能力的乘法器

模型能力本身很重要,但复杂任务的成败越来越取决于 harness:怎么拆任务,怎么保留状态,怎么验证,怎么防止偏见,怎么处理失败和重试。Dynamic workflows 是 Anthropic 把 harness 生成能力交给 Claude 的尝试。

9.2 这是“代码即组织结构”

静态 prompt 像规章制度,subagent 像临时外包,agent team 像小团队;workflow 更像一段可执行的组织流程。它把任务组织方式变成代码,所以可以暂停、恢复、复用、审查和分享。

9.3 最值得复制的是验证思维

无论是否使用 Claude Code,文章里的 adversarial verification、tournament、claim-by-claim checking、quarantine 都是高质量 Agent 系统的通用设计模式。它们解决的是“模型会自信但不一定可靠”的根问题。

9.4 这会改变团队使用 Agent 的方式

过去团队沉淀的是提示词、CLAUDE.md、skills;以后还会沉淀 workflow:安全审查 workflow、事故复盘 workflow、招聘筛选 workflow、迁移 workflow、代码审核 workflow。工作流会变成团队的可执行 SOP。

9.5 未来竞争点

我认为下一阶段 Coding Agent 的竞争不只是模型速度和代码质量,而是:谁能自动生成更好的 harness,谁能让 harness 可观测、可审计、可复用、可治理。Dynamic workflows 正是朝这个方向走。

10. 资料来源

说明:本文为中文学习笔记和工程化解读,重点基于官方博客和 Claude Code 文档重写、解释和可视化;其中“我的理解/建议”属于基于材料的分析推断。