每个任务都需要一个 Harness
Claude Code 动态工作流深度解析 — Anthropic 把 agent 编排计划从 context window 搬进了 JavaScript 脚本，用代码确定性替代模型实时判断
速览卡片
30 秒掌握核心论点、数据来源和阅读路径。
Anthropic 把 agent 编排计划从 Claude 的 context window 搬进了 JavaScript 脚本，用代码确定性替代模型实时判断 — 但多 agent 并非万能药，sequential reasoning 任务性能暴跌 39-70%，token 成本飙升至 15 倍。
动态脚本编排
Claude Code 新增 dynamic workflows，用户 prompt 触发后 Claude 自动生成 JS 编排脚本，独立 runtime 执行。三个核心机制：编排确定性、context 隔离、多 agent 对抗审查。
Thariq & Sid @ Anthropic
Thariq Shihipar & Sid Bidasaria，Anthropic Claude Code 团队，2026-06-03 发布。原文 "A harness for every task: dynamic workflows in Claude Code"。
时间分配
只有 2 分钟 → 读速览、技术解剖、风险。10 分钟 → 全部。这是结构化深度解析，不是新闻摘要。
这是怎么回事
不是产品发布，是架构变更的技术说明。Claude Code 从编程工具变成通用 agent 编排平台。
核心论点：Claude Code 的默认执行框架是为编程设计的，但很多非编程任务 — 研究、安全分析、代码审查、简历筛选 — 在结构上跟编程任务很像。它们都需要多步骤协调、中间状态管理、以及质量检查点。
问题是，当 Claude 用单 agent 的 turn-by-turn 循环去处理这些任务时，会撞上三个经典故障模式：goal drift（目标漂移）、agentic laziness（agent 偷懒）、self-preferential bias（自我偏好锚定）。
Dynamic workflows 的解法：把执行计划从 Claude 的 context window 里搬出来，写成 JavaScript 脚本。脚本持有循环、分支和中间结果，Claude 的 context 只装最终答案。
Harness 迭代三代
从静态到动态，从手写到自动 — agent 编排范式的切换。
| 时间 | 名称 | 核心思路 |
|---|---|---|
| 2025-11 | Effective Harnesses | 手写编排 |
| 2026-03 | Harness Design | GAN 启发的生成-评估架构 |
| 2026-06 | Dynamic Workflows | 动态生成编排脚本 |
数据校验：原文声称 9 个 use cases，核实发现实际有 10 个独立 use case 段落（"Model and intelligence routing" 被遗漏或合并了）。Tweet 互动数据与核实值存在微小差异，均在有机增长范围内。
关键概念速查
9 个核心术语，理解 Dynamic Workflows 的最小知识集。
| 术语 | 解释 | 为什么重要 |
|---|---|---|
| Dynamic Workflow | Claude 根据 prompt 动态生成 JS 编排脚本，独立 runtime 执行，主会话保持响应 | 核心转换：'谁持有计划' — 从 turn-by-turn 判断变成代码的确定性执行 |
| Phase Barrier Semantics | 阶段间是顺序屏障（全完成才下一步），阶段内是并发执行（最多 16 agent） | 不是所有 agent 都并发，而是按阶段做 barrier 同步 |
| Context Isolation | 中间结果留在 runtime 脚本变量中，不进入主会话 context window | 执行完大规模编排后 Claude 仍然'清醒'，不会因 context 填满而降级 |
| Schema-Gated Output | 每个 agent 调用包含 JSON Schema 验证输出 | 编排步骤间的程序化检查点 — 用延迟换准确性 |
| Goal Drift | Agent 在长 session 中偏离原始目标，主要机制是 pattern-matching behavior | 反直觉：漂移主因不是 token 距离，而是 context window 中的行为模式匹配 |
| Capability Saturation | 单 agent 准确率约 45% 以上时，加 agent 反而降低性能 | '更多 agent = 更好'是错的。超过阈值后协调成本大于边际收益 |
| Lazy Agent | 多 agent RL 训练中一个 agent 只做表面贡献，另一个主导 | 结构性原因：multi-turn GRPO 的 1/T 归一化项激励更少的交互轮次 |
| Ultracode | Claude Code session 级设置，xhigh reasoning + 自动 workflow 编排 | 开启后 Claude 为每个实质性任务自动规划 workflow |
| Orchestration Auditability | 每次 workflow run 的脚本写入会话目录，可读/diff/编辑/重跑 | agent 编排从黑箱变为可审查的代码 |
技术解剖
运行时拓扑、核心 API、三个强化机制、关键约束。
从 prompt 到结果的数据流
用户 prompt → Claude 生成 JS 脚本 → 独立 runtime（隔离进程）执行 → 脚本通过特殊函数生成 sub-agent → 阶段间顺序屏障同步 → 最终结果回传主会话。
类比：这就像 Makefile 之于编译。以前你手动一个一个跑 gcc 命令（单 agent turn-by-turn），现在你写个 Makefile，make 命令一键执行（确定性编排）。Makefile 选了声明式；workflow 选了图灵完备 — 更灵活，但绳子也更长，更容易上吊。
| 函数 | 用途 | 关键参数 |
|---|---|---|
agent(prompt, options) | 生成 sub-agent，结构化输出 | label, phase, schema |
parallel([fns]) | 并发执行多个 agent | 异步函数数组 |
workflow(name, args) | 链接到另一个 workflow（可组合） | workflow 名 + 输入参数 |
phase(title) | 标记执行阶段 | 阶段名 |
log(message) | 结构化日志 | 消息字符串 |
meta（export） | Workflow 元数据 | name, description, whenToUse, phases |
三个强化机制
编排确定性
计划在代码里，不在 agent 的 context 里。这直接对付了导致 goal drift 的 pattern-matching 行为 — agent 无法'忘记'计划，因为计划根本不在它的 context window 里。
Context 隔离
每个 sub-agent 拿到干净的 context window。中间结果在 JavaScript 变量里传递。对于长时间任务，这意味着无限期维持质量 — 单 agent 在 50K token 后开始退化。
多 agent 对抗审查
独立 agent 各带隔离 context，可以主动尝试推翻彼此的理论。"With multiple independent investigators actively trying to disprove each other, the theory that survives is much more likely to be the actual root cause."
不能做什么
- 最多 16 个并发 agent，1000 总量上限
- 不支持运行中间的用户输入
- Session 内恢复 — 退出 Claude Code 后 workflow 丢失
- Shell 命令不在 allowlist 会中断长任务
- Workflow Script 的具体 API 签名尚未作为公共开发者 API 正式发布
Pattern-Matching：Goal Drift 的真正原因
Goal drift 的主因不是 token 距离（离系统 prompt 越远越容易漂），而是 pattern-matching behavior — agent 在 context window 中找到行为模式然后模仿它。
实验证据：把 instrumental phase 替换为 token-padding（同等长度，没有行为模式），drift 大幅下降。把 assistant 消息替换为随机废话句子（不同的 pattern 供匹配），drift 跟原始 susceptibility 相关。
更关键的发现：drift 在需要 adaptive behavioral flexibility（在冲突目标间切换）的场景中显著恶化。所有评估模型都表现出了可测量的 drift，但 scaffolded Claude 3.5 Sonnet 在超过 100K token 后仍维持接近完美的 adherence。
为什么重要
三层战略意图、竞品横向对比、受益者和受损者。
从编程工具到编排平台
Claude Code 从编程工具变成通用 agent 编排平台。用户构建的自定义 workflow 越多，对 Claude 生态的投资越深，迁移成本越高。
~15 倍成本 = 商业模式
"Dynamic workflows typically consume more tokens." 这不是 bug，这是 feature — 约 15 倍的 token 成本意味着每个 power user 的收入显著提升。
全栈控制
市场上 agent 编排框架拥挤（LangGraph, CrewAI, AutoGen, OpenAI Swarm）。Anthropic 选择在 Claude Code 内原生解决编排问题，控制从模型到执行环境的全栈。
| 维度 | Claude Code Workflows | LangGraph | CrewAI | AutoGen | OpenAI Swarm |
|---|---|---|---|---|---|
| 编排模型 | 图灵完备 JS 脚本 | 声明式图 + Python | 角色化 Python agent | 对话驱动 Python | 轻量 Python handoff |
| Context 隔离 | 原生（per-agent context） | 手动（状态管理） | 部分（共享 memory） | 部分（群聊） | 极少 |
| Schema-Gated | 原生（JSON Schema） | 通过 Pydantic | 通过 Pydantic | 手动 | 手动 |
| 对抗审查 | 内建模式 | 自定义实现 | 自定义实现 | 多 agent 辩论 | 不支持 |
| 模型绑定 | Claude only | 多模型 | 多模型 | 多模型 | OpenAI only |
| Token 效率 | ~15x chat 成本 | 可变 | 高（角色开销） | 高（对话开销） | 低-中 |
| 生态成熟度 | 早期 | 中（LangChain 生态） | 低-中 | 中（Microsoft） | 实验性 |
谁受益
- 重度 Claude Code 用户 — 已经撞到单 agent 极限的人
- Anthropic — 更高 token 消耗、平台锁定
- Agent 编排研究社区 — 真实世界验证
谁可能受伤
- 乱用 multi-agent 的用户 — sequential reasoning 性能暴跌 39-70%
- 预算敏感用户 — 没意识到 15 倍成本倍数
- 竞争 agent 框架 — 差异化空间被挤压
别高兴太早
Multi-Agent 不是万能药。最重要的警告和隐藏成本。
Multi-Agent 在 Sequential Reasoning 上主动伤害性能
PlanCraft benchmark 数据 — 不是微妙的效果，独立 MAS 直接掉 70%：
| 架构 | 性能变化 |
|---|---|
| Centralized MAS | -50.4% |
| Decentralized MAS | -41.4% |
| Hybrid MAS | -39.0% |
| Independent MAS | -70.0% |
Brooks's Law 在 Agent 世界
单 agent 准确率约 45% 以上时，加 agent 产生负收益（beta=-0.408, p<0.001）。'更多 agent = 更多协调成本'，超过阈值后协调成本超过边际收益。
经济上只对高价值任务可行
Token 使用量单独解释 BrowseComp 80% 的性能方差。多 agent 系统 token 消耗约 15 倍于 chat，单 agent 约 4 倍。
训练层面的结构性缺陷
Multi-turn GRPO 的 1/T 归一化项激励更少的交互轮次 — lazy-agent 轨迹更短，因此被优先强化。不是 workflow 脚本层面能修的。
信息丢失换 context overflow
如果 Agent A 发现了关键信息，那知识必须通过脚本变量显式传递给 Agent B。漏传关键信息 = Agent B 基于不完整信息工作。Workflow 作者现在拥有信息路由问题。
编排无法控制行为模式切换
即使有确定性编排，drift 在需要 agent 在冲突行为模式间切换的任务中仍然恶化。Workflow 脚本控制执行结构，但无法控制施加在单个 agent 上的行为灵活性需求。
历史不会简单重复
但 rhymes 它是会的。五个历史事件映射到 Dynamic Workflows。
| 历史事件 | 映射到 Dynamic Workflows |
|---|---|
| Make/GNU Make (1976) | Make 把构建计划外化到 Makefile（确定性编排）。Workflows 把执行计划外化到 JavaScript。Make 选了声明式，workflows 选了图灵完备。更灵活，但更容易搞砸。 |
| MapReduce (2004) | "分拆 → 并行处理 → 合并结果"。parallel() 是 agent 层面的同一抽象。能力饱和阈值是 MapReduce 中'embarrassingly parallel' vs 'communication-bound' 的 agent 版。 |
| Actor Model (1973) | 隔离 context、消息传递、无共享可变状态。每个 sub-agent 就是一个 actor。Context 隔离防退化 = Actor 隔离防竞态条件。 |
| Infrastructure as Code (2009-2015) | 手动配服务器 → Terraform/Ansible manifest。Ad-hoc prompting → workflow scripts。同样的收益：可复现、可审计、可组合。 |
| Microservices vs Monolith (2014-2018) | 更多组件 + 更多协调开销 + 更好隔离 vs 更简单 + 小团队更快。多 agent vs 单 agent 的同一辩论。能力饱和阈值是 agent 版的'monolith first'建议。 |