Harness Engineering：Anthropic 如何让 Claude 连续工作六小时而不崩溃

Claude 接到一个任务："帮我做一个 claude.ai 的克隆版"。单 Agent 跑了 20 分钟，花了 9 美元。结果核心功能完全 broken。

同一个任务，三 Agent Harness 跑了 6 小时，花了 200 美元。产出的是一个功能完整的 2D 游戏制作器，带 AI 辅助生成、可玩测试模式、可分享链接。

差的不只是时间和钱。差的是 Anthropic 在 Harness Engineering 上的系统性思考。

一、长运行 Agent 的断点

Agent 能做到的事越来越多。但它仍然有一个结构性缺陷：context window 有限，而复杂工程不可能在一个 window 里做完。

想象一个项目组的工程师轮班工作。每个新接班的工程师对上一班做了什么一无所知。没有交接文档，没有代码注释，没有 git log。他只能猜。猜错了，就得花大量时间把项目恢复到一个能工作的状态。

这就是 Claude 在没有 Harness 时的真实处境。

Anthropic 内部做了测试。让 Opus 4.5 在 Claude Agent SDK 里循环工作，只给一个高层 prompt："build a clone of claude.ai"。结果出现两种失败模式：

模式一：贪多嚼不烂。 Agent 试图一次性把整个应用做完。context 耗尽，功能做到一半，没有文档，没有注释。下一轮的 Agent 拿到一个半成品，花了大量时间试图理解发生了什么，然后试图修复。修复完，context 又耗尽了。循环往复。

模式二：过早宣布胜利。 前几轮做了些功能，后面接班的 Agent 一看，"哦，已经有进展了"，就宣布任务完成。实际上核心功能还没做。

这两个问题的根因相同：Agent 没有一个机制来理解"当前状态"和"剩余工作"。每次重启都是失忆。

二、第一代 Harness：Initializer + Coding Agent

Justin Young 在 Anthropic 工程博客中提出的第一代解决方案极其简洁：两个 Agent，各管一段。

2.1 Initializer Agent

第一会话专职"搭地基"。它不做任何功能实现，只做环境准备：

• init.sh：一键启动开发服务器的脚本
• feature_list.json：把用户的高层 prompt 扩展为 200+ 条具体功能描述，全部标记为 passes: false
• claude-progress.txt：进度日志，记录每一轮做了什么
• 初始 git commit：标记项目起点

Initializer 的关键洞察是：功能列表必须在第一天就锁定。如果让 Coding Agent 自己决定"今天做什么"，它会要么贪多，要么漏掉核心功能。200 条 JSON 描述就像一个 todo 清单，Agent 不需要"理解"整个项目，只需要"读取"下一个未完成的任务。

JSON 格式是特意选的。Claude 对 Markdown 文件的"编辑冲动"更强——它会忍不住重写、删除、合并段落。JSON 的结构更刚性，系统 prompt 里加一句"删除或编辑测试不可接受"，Agent 遵守得更好。

2.2 Coding Agent

每个后续会话只做三件事：

1. 读状态：pwd → git log → claude-progress.txt → feature_list.json → init.sh
2. 选一个功能：找到第一条 passes: false 的功能
3. 做完它：实现、测试、git commit、更新进度日志、标记 passes: true

每轮结束，环境必须是"干净状态"——可以直接 merge 到 main branch 的代码。没有重大 bug，代码有序，文档完整。

2.3 测试环节的补救

还有一个失败模式：Agent 实现了功能，但根本没测试，就标记为完成。

Anthropic 的解法是给它 Puppeteer MCP。让 Agent 像真实用户一样点击、输入、截图。Claude 自己截的图、自己做的 end-to-end 验证，比任何单元测试都更接近真实使用场景。

当然有限制。Claude 看不见浏览器原生 alert modal，依赖这类 modal 的功能 bug 率更高。这是当前工具链的真实边界。

三、第二代 Harness：Planner + Generator + Evaluator

第一代 Harness 解决了"连贯工作"的问题，但天花板很快到了。Prithvi Rajasekaran 在后续工作中发现，更复杂任务的瓶颈不在"怎么衔接会话"，而在"怎么保证质量"。

他受了 GAN 启发，设计了三 Agent 架构。

3.1 核心洞察：Generator 不会批评自己

让 Agent 评价自己的产出，它倾向于给好评。即使对一个明显平庸的设计，它也会说"整体不错"。这在主观任务上尤其致命——"这个设计好不好"没有二进制答案。

分离"干活的人"和"评判的人"，是解决问题的杠杆。单独调一个 Evaluator 让它变得 skeptical，比让一个 Generator 批评自己的作品容易得多。

3.2 四维度评分体系

Rajasekaran 在前端设计实验中建立了四个评判维度：

Design quality：设计是否像一个有机整体，而非零件拼凑？颜色、字体、布局、图像是否共同创造了独特的氛围和身份？

Originality：是否有定制决策的证据，还是全是模板默认和 AI 生成模式？人类设计师应该能识别出刻意的创意选择。未经修改的 stock component、紫渐变配白卡片的"AI slop"痕迹，都算失败。

Craft：技术执行能力——字体层级、间距一致性、颜色和谐、对比度。这是能力检查，不是创造力检查。Claude 默认就做得不错，失败意味着基本功 broken。

Functionality：脱离美学的可用性。用户能否理解界面做什么、找到主操作、完成任务而不靠猜？

Design quality 和 Originality 权重最高。Craft 和 Functionality Claude 本来就好，不需要额外推动。重点是把模型从"安全但平庸"推向"有风险但独特"。

3.3 三 Agent 分工

Planner：接收用户的一句话 prompt，扩展为完整产品 spec。比如 "Create a 2D retro game maker" 被扩展为 16 个功能点、10 个 sprint 的详细规划。Planner 被特意要求"不要指定实现细节"——如果它把技术细节写错了，错误会级联到下游。只定义交付物，让 Generator 自己找路径。

Generator：按 sprint 工作，每次只做一条功能。React + Vite + FastAPI + SQLite 栈。每个 sprint 结束自评估，然后交给 QA。

Evaluator：用 Playwright MCP 在真实运行中的应用上点击、测试 API endpoint、检查数据库状态。按四个维度评分，hard threshold 决定 sprint 是否通过。不通过就给具体反馈，Generator 重做。

3.4 Sprint Contract

在 Generator 写代码之前，Generator 和 Evaluator 先协商一份"合同"：这一轮做什么、怎么验证完成。合同粒度极细——仅 Sprint 3 的 level editor 就有 27 条验证标准。这种"先对齐、再实现"的机制，防止了"我以为我做完了，但其实你没测到"的偏差。

四、成本与质量的暴力对比

Rajasekaran 做了一个残酷的对比实验。同一个 prompt：

"Create a 2D retro game maker with features including a level editor, sprite editor, entity behaviors, and a playable test mode."

单 Agent 的问题不只是"做得少"。它连承诺的最基本功能都没实现——entity 定义和游戏运行时的连线是断的，游戏无法运行。

Harness 的产出不只是"更多功能"。它实现了 Generator 自己不会想到的东西：AI 辅助 sprite 生成、level 设计、音效音乐。Planner 要求"在 spec 中编织 AI 功能"，Generator 就照做了。单 Agent 没有这层 product thinking。

五、模型演进对 Harness 的影响

Harness 不是静态的。模型的每一次升级，都会改变 Harness 中"哪些组件是 load-bearing"。

Opus 4.5 有一个特点：context anxiety。它会在接近自己认为的 context limit 时提前收尾。这导致 compaction（压缩历史对话让 Agent 继续工作）不够——Agent 会焦虑，会在真正耗尽 context 之前就结束工作。所以第一代 Harness 必须用 context reset（完全清空 context window，让新 Agent 接班）来解决问题。

Opus 4.6 改善了这一点：plans more carefully, sustains agentic tasks for longer, better code review and debugging skills。于是 Rajasekaran 做了一个实验：把 sprint 结构整个删掉，让 Generator 在一个连续 session 里跑两小时。结果成功了。模型能力边界的移动，直接让 Harness 的一个核心组件变得不再必要。

但 Evaluator 没有被删掉。模型变强了，能做更多事，但"能做"和"做得好"之间仍有 gap。Evaluator 只在 Generator 的能力边界外才有价值——在那个边界内它是 overhead，在边界外它是必需品。

Anthropic 的结论很明确：每出一个新模型，都值得重新审视一遍 Harness，删掉不再 load-bearing 的组件，补上以前模型做不到但现在可能做到的新能力。

六、从游戏制作器到数字音频工作站

简化后的 Harness 被用来做一个更复杂的项目：浏览器里的数字音频工作站（DAW）。

Prompt："Build a fully featured DAW in the browser using the Web Audio API."

• Planner：4.7 分钟，\(0.46 - Generator Build Round 1：2 小时 7 分钟，\)71.08
• QA Round 1：8.8 分钟，\(3.24 - Generator Build Round 2：1 小时 2 分钟，\)36.89
• QA Round 2：6.8 分钟，\(3.09 - Generator Build Round 3：10.9 分钟，\)5.88
• QA Round 3：9.6 分钟，\(4.06 总计：3 小时 50 分钟，\)124.70

QA 每一轮都发现了 Generator 自己不会注意到的问题：

• Round 1：clips 不能在 timeline 上拖拽移动，没有乐器 UI 面板（synth knobs、drum pads），没有可视化效果编辑器（EQ 曲线、compressor 表）。"这些不是 edge case，它们是 DAW 的核心交互。"
• Round 2：音频录制仍是 stub（按钮能 toggle 但没有 mic capture），clip resize by edge drag 未实现，效果可视化仍是数字 slider 而非图形。

Generator 依然会在没人盯着的时候 stub 功能、漏掉细节。QA 的价值在"最后一公里"——不是 Generator 不能做，是它不知道自己做漏了。

最终产出的 DAW 远非专业级，但核心部件齐全：arrangement view、mixer、transport。Agent 还能用工具自主创作——设置 tempo 和 key、铺旋律、搭鼓轨、调 mixer level、加 reverb。Claude 听不见，所以音乐品味层面还有很大 gap。但"从端到端自主完成一个音乐制作"的基础设施，已经搭起来了。

七、Harness Engineering 的本质

很多人把 Harness 理解为"更好的 prompt engineering"。这错了。

Prompt engineering 优化的是单次对话的质量。Harness engineering 优化的是多轮对话之间的连续性。它关心的不是"这一轮 Claude 说了什么"，而是"下一轮 Claude 怎么知道上一轮留下了什么"。

它的核心问题是工程问题，不是语言问题：

• 状态传递：上一轮的 context 怎么传给下一轮？（答案：结构化文件，不是对话摘要）
• 任务分解：一个不可能在一个 window 里完成的目标，怎么切成 Agent 能消化的块？（答案：feature list、sprint contract）
• 质量控制：Agent 不知道自己做得好不好，谁来告诉它？（答案：独立 Evaluator、硬性评分标准）
• 环境复现：每次重启后，Agent 怎么快速恢复到工作状态？（答案：init.sh、git log、progress file、回归测试）

这些问题的答案里没有一个是"写更好的 prompt"。它们全是工程基础设施：文件格式、git workflow、测试工具、多 Agent 编排协议。

八、开发者能带走什么

如果你在用 Claude Code、Cursor Agent、或任何 Agent 工具做复杂项目，以下几条直接可用：

1. 第一会话不做功能，只做地基。 init.sh、功能清单、进度日志、初始 commit。第一天的工作决定后面所有天的效率。
2. 功能清单用 JSON，不要用 Markdown。 Markdown 太容易被 Agent "顺手改写"。JSON 的结构刚性更可靠。
3. 每轮只做一件事。 做完、测试、commit、写日志、再开下一轮。贪多是最常见的失败模式。
4. 给 Agent 一个"真实用户测试"的工具。 Puppeteer MCP、Playwright、或哪怕一个 curl 脚本。单元测试不够，end-to-end 才是真相。
5. 分离 Generator 和 Evaluator。 如果你有一个主观质量要求（设计、文案、产品体验），不要让同一个 Agent 又做又评。独立 Evaluator，给它评分标准和 skepticism。
6. 模型升级后重新审视 Harness。 以前 load-bearing 的组件可能不再需要。删掉 overhead，补充新能力。

尾声：Harness 的空间不会缩小

有一种观点认为：模型越来越强，Harness 终将消失，因为模型自己会解决所有问题。

Anthropic 的实践表明恰恰相反。模型越强，Harness 的组合空间越大。以前模型做不到的事，现在可以外包给模型本身。但以前想都不敢想的复杂任务，现在可以纳入 Harness 的范围。

边界在移动，但 Harness 不会消失。它只会从"帮模型做它做不到的事"变成"帮模型做它还不知道自己做漏了的事"。

6 小时、200 美元、三 Agent 协作。这不是浪费。这是从"聊天机器人"到"工程团队"的范式跃迁。

参考链接

• Effective harnesses for long-running agents：https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents
• Harness design for long-running application development：https://www.anthropic.com/engineering/harness-design-long-running-apps
• Building Effective Agents（Anthropic 基础方法论）：https://www.anthropic.com/engineering/building-effective-agents
• Context engineering：https://www.anthropic.com/engineering/context-engineering
• Claude Agent SDK Quickstart：https://github.com/anthropics/anthropic-cookbook/tree/main/skills/agent-sdk

#深度研究 #格帕文士 #HarnessEngineering #Anthropic #LongRunningAgents #AIAgent #Claude