claude code harness engineering 实战

Claude Code Harness Engineering 实战：我对 Anthropic 这篇官方博客的理解

原文：https://www.anthropic.com/engineering/harness-design-long-running-apps 发布时间：2026 年 3 月 24 日

这篇 Anthropic 官方文章，表面上在讲一个很具体的话题：怎么给 Claude 搭 harness，让它能连续几个小时构建完整应用。

但如果只把它理解成”又一个多 agent 工作流”，其实会错过它最有价值的部分。

我读完之后的核心判断：

Anthropic 真正想讲的不是某个固定的 harness 模板，而是一个更重要的工程原则：harness 不是神圣架构，是为当前模型能力边界量身定做的临时支架，而且必须持续做减法。

这和很多人理解的”给 agent 加更多脚手架就会更强”完全不是一回事。

一、这篇文章最重要的观点：不是多 agent，而是找到模型的失效边界

文章开头先讲了两个朴素但非常关键的失败模式。

第一个失败模式是长任务中的失真和跑偏。

模型在任务拉长、上下文变厚之后，会越来越容易失去整体一致性。Anthropic 在文中提到一个很形象的现象，叫 context anxiety。简单说就是，模型在接近自己感知中的上下文极限时，会开始焦虑，会提前收尾、假装完成、或者为了结束而结束。

这说明一个事实：

长时任务失败，原因往往不是模型不会做，而是模型在”持续工作”这件事上掉线。

第二个失败模式是自评失真。

模型一边产出，一边给自己打分，通常会过于宽容。尤其是设计这种主观任务，它特别容易说”已经很好了”，但人一眼就能看出只是一个安全、平庸、模板味很重的产物。即使到了可验证的软件任务里，这种自我宽容也依然存在，只是表现形式从”审美偏差”变成了”漏掉边角 bug 还觉得可以发布”。

所以文章真正的问题定义不是：

• 怎么让 Claude 更努力一点

而是：

• 当模型会在长任务里掉线时，怎么补偿
• 当模型会宽容地原谅自己时，怎么外部校正

harness 的价值就在这里——它是否精准补到了模型当前最容易失效的那几个点。

二、Anthropic 先拿”前端设计”试验，是因为主观任务最能暴露自评问题

我很喜欢这篇文章的一个写法：作者没有一上来就去堆全栈 agent，而是先从前端设计开始做实验。

背后的逻辑很清楚。设计任务没有像单元测试那样的硬 correctness signal，它最容易暴露模型”自己夸自己”的问题。所以如果能在设计任务里把 evaluator 调得更靠谱，这套机制更有可能迁移到软件构建任务里。

作者做了两件事：

1. 把”设计好不好”拆成可评分的标准
2. 把”生成”和”评分”拆成两个 agent

这两个动作看起来简单，实际非常关键。

因为很多人做 agent system 时，默认还是把”生产”和”判断”放在一个脑子里。Anthropic 这里的立场很明确：

与其让 generator 学会苛刻地批评自己，不如单独训练一个更怀疑、更挑剔的 evaluator。

逼一个模型一边创作一边保持自我否定，不如把这两件事交给两个各有专长的 agent。后者现实得多。

而且作者不是泛泛地说”评价设计”，而是把评分标准拆成了四类：

• 设计整体性
• 原创性
• 工艺与技术完成度
• 功能可用性

其中最值得注意的是权重分配。文章明确说，Claude 默认在 craft 和 functionality 上不算差，真正容易塌陷的是 design quality 和 originality。所以 evaluator 不是平均评分，而是有意识地惩罚模板味、组件库默认味、典型 AI slop 味。

Anthropic 在这里已经不只是做 QA 了，更像在做”品味编码”：

把原本只存在于人脑里的偏好，转成 agent 可执行的评分语言。

这是这篇文章非常值钱的部分。

三、这套设计真正迁移到全栈开发时，核心不是三 agent，而是三层职责分离

文章后半段把这套思路迁移到了完整应用开发。这里表面上是一个三 agent 结构：

• planner
• generator
• evaluator

但我认为更准确的理解不是”三个 agent 很厉害”，而是它把原来混在一起的三种职责硬拆开了：

1. Planner 负责扩写产品意图

用户只给一句到四句 prompt，不足以支撑多小时构建。planner 的作用不是写技术细节，而是把含糊的产品意图扩展成一个更完整的产品 spec。

这里有个很成熟的工程判断：planner 被要求不要过度规定实现细节。

为什么？因为在规划阶段就把细节定死，一旦定错了，错误会被整条流水线放大。相比之下，让 planner 主要负责产品目标、范围和高层设计，再把低层实现留给后续 agent 在执行时决策，风险反而更低。

Anthropic 对 planner 的定位不是”架构师一次定终局”，更像是”给出方向和验收空间”。

2. Generator 负责实现，但不是无限自由实现

generator 不是拿到大 spec 后一口气闷头做完，而是按 sprint 或后来的大轮次去推进。

重点不在”分阶段”本身。每个阶段都只处理一个足够明确、仍然可控的工作块——Anthropic 用任务切片来控制 coherence loss。

为了让模型在长时间构建时，始终能把注意力压在局部闭环里。

3. Evaluator 负责把”看起来像完成”变成”真的通过验收”

这是最重要的一层。

Anthropic 的 evaluator 不是只看代码 diff，也不是只跑一遍 smoke test。它会用 Playwright MCP 真正操作运行中的应用，检查 UI、API 和数据库状态，再根据明确标准打分。任何一个维度低于阈值，这轮就算失败，generator 必须继续返工。

agent coding 最常见的幻觉，不是不会写，而是会写出”看起来很完整”的半成品。没有 evaluator，这种东西极容易漏过去。

四、我认为全文最有启发的设计，不是 evaluator 本身，而是 sprint contract

如果只看 headline，很多人会把注意力都放在 planner/generator/evaluator 三角结构上。

但我读完后觉得，文中最有实战价值的设计，可能反而是 sprint contract。

它的本质是：在每轮编码开始前，generator 和 evaluator 先约定这轮到底要交付什么，以及如何验证”完成”。

这个动作非常像成熟团队里的：

• implementation contract
• testable acceptance criteria
• story-level done definition

为什么它重要？因为 planner 输出的是高层 spec，本来就故意不写死技术细节。如果中间没有这层 contract，generator 很容易”自己理解一个版本的 done”，而 evaluator 又拿”另一个版本的 done”去检查，最后两边各说各话。

sprint contract 的作用，就是把这种模糊地带变成可测试、可对齐、可回放的中间工件。

高层 spec 负责留出创造空间，中层 contract 负责把创造空间收束成可验证目标。

这其实是一种很漂亮的分层。

五、Anthropic 对”上下文重置”和”上下文压缩”的处理，说明 harness 设计必须跟着模型代际变化

文章里还有一个特别值得记住的点：他们并没有把旧 harness 当作真理。

早期版本里，Claude Sonnet 4.5 在长任务中 context anxiety 很明显，所以 Anthropic 发现，单靠 compaction 不够，必须做 context reset。也就是彻底清空上下文，重新起一个 agent，再用结构化交接工件把状态传过去。

这一步很重：

• 编排更复杂
• token 开销更大
• 时延更长

但在当时是必要的。

后来换到 Opus 4.5，再到 Opus 4.6，模型自身在长时任务保持性上的能力变强，这个支架的必要性就下降了。于是 Anthropic 开始拆掉旧结构，去验证：

• sprint 还需要吗
• evaluator 还要不要每轮都上
• planner 还是不是 load-bearing

这让我印象深刻。好的 harness 不是越复杂越好，而是刚好补足当前模型缺口的最小复杂度。

模型一旦变强，旧 harness 里原本必要的部分，就可能立刻变成纯开销。

作者后来强调，应该一项项移除部件，看性能怎么变，而不是凭感觉保留所有”看起来专业”的组件。总结成一句话：harness 是假体，不是器官。负担件要识别出来，随模型代际变化会迁移，简化本身也是核心工作。

六、Anthropic 这篇文章比很多 agent 文章更诚实，因为它一直在算”值不值”

文里给了两个非常直白的数字对比。

第一个实验，solo 大概 20 分钟、9 美元；full harness 大概 6 小时、200 美元。

第二个更新后的 harness，依然接近 4 小时、124 美元。

harness 很贵。 Anthropic 没有回避这个事实。

这也是为什么我觉得这篇文章很值得看。它没有把多 agent 包装成一个无脑收益的通用答案，而是不断回到一个更工程化的问题：

这部分 scaffold 带来的质量提升，是否真的值得它的时间、token 和编排复杂度？

文章里关于 evaluator 的判断也很到位：它不是固定的 yes/no 组件。只有当任务落在”模型单独做不稳，但加评估又能补上”的那个区域里，evaluator 才真正值钱。换句话说，evaluator 的价值是相对于当前模型边界的相对价值。这个判断能防止团队把 harness 设计成一种宗教。

七、如果把这篇文章翻译成 Claude Code 实战语言，我会提炼成 6 条

如果不讨论 Anthropic 内部实验，只站在 Claude Code 或通用 coding agent 的实战角度，我会把这篇文章压缩成下面 6 条经验。

1. 不要迷信单 agent 长跑

模型能做复杂事，不代表它能长时间稳定地做复杂事。 一旦任务跨小时、跨模块、跨状态，最先坏掉的往往不是能力，而是一致性。

2. 生成和评估最好分脑子

自评宽容几乎是默认现象。 执行 agent 和评审 agent 分开，是比”要求同一个 agent 更严格一点”更有效的杠杆。

3. 高层 spec 不要过度写死实现

前期细节写太满，错了会整链传染。 高层 spec 更适合定义目标、范围、产品深度和验收方向，而不是提前决定所有实现细节。

4. 中层 contract 很关键

spec 和代码之间，最好有一层”这轮到底交什么、怎么验”的工件。 没有这层，agent 很容易把”做了一些东西”误当成”完成了目标”。

5. Playwright 这类真实交互式 QA 很值钱

只看代码和日志，不足以判断产品真的可用。 很多 bug 只有在”像用户一样点一遍”时才会暴露。

6. 持续问自己：这个支架还负重吗

不要把旧 harness 神化。 每一次模型升级，都值得重新做一遍负重测试，看看哪些组件已经可以删掉。

八、用 Claude Code 写代码时，这些观点怎么落地

前面六条是经验压缩。展开说说我自己在用 Claude Code 编码时，从这篇文章里实际拿到了什么。

别在一个超长 session 里闷头干活

文章说的 context anxiety，在 Claude Code 里一样存在。

一个 session 改了几十文件、上下文堆了几万行之后，模型会开始”提前收尾”——代码写得越来越安全、越来越模板化，最后给你一个”看起来完成”的东西。你可能觉得”还没做完呢”，但它已经觉得”可以交差了”。

我的做法：大任务主动拆 session。改完一个模块，提交，开新 session 接着干。/compact 有用但不是万能的，compaction 之后模型丢失细节的风险依然存在。

写和审分开

文章反复强调的核心观点。在 Claude Code 里，这意味着：不要让同一个对话既写代码又验收代码。

写完一个 feature，开一个新 session 做审查，或者用 /review 类命令单独过一遍。自己写自己审，一定会放过自己——这一点已经被 Anthropic 的实验反复验证了。

给任务下 contract，别只给方向

“帮我重构认证模块” — 这种 prompt 太模糊，模型会自己定义 done 的标准，然后自己验收自己。

改成：“帮我重构认证模块，重构完成后：登录流程能跑通、单元测试全部通过、不引入新的 warning”。这就是 sprint contract。明确交付物，明确验收标准。

Claude Code 的 Task 工具天然适合干这件事。创建任务时写清楚 acceptance criteria，完成时对照检查，比口头说”做得差不多了”靠谱得多。

用真实运行验证，别只看 diff

文章里 evaluator 用 Playwright 真的去操作应用。映射到 Claude Code：改完代码后，让它跑测试、让它启动服务、让它 curl 接口验证返回值。别停留在”代码改好了”这一步。

代码 diff 通过了不代表功能正确。很多 bug 只有在”像用户一样点一遍”时才会暴露。这个判断在文章里和我的实际经验里完全一致。

定期质疑你的 workflow

这是文章里我最认同的一点。你半年前为 Claude Code 设计的 prompt template、hooks、workflow，现在还必要吗？模型升了几代之后，很多东西可能已经从”必要支架”变成了”纯开销”。

文章原话：harness 是假体，不是器官。该扔就扔。

我在实际用 Claude Code 的过程中确实经历过这种事。早期觉得必要的某些 CLAUDE.md 规则、某些 hooks，随着模型能力提升，变成了限制而不是帮助。定期清理一遍，看看哪些已经可以删掉，这个动作本身就有价值。

九、和 OpenAI 那篇 Harness Engineering 文章相比，Anthropic 这篇更强调”弹性脚手架”

如果把这篇文章和 OpenAI 那篇关于 Codex 的 harness engineering 放在一起看，差异其实很有意思。

OpenAI 那篇更强调：

• repo 作为唯一记忆系统
• 架构边界和 lint 约束
• agent-readable codebase
• 持续反熵和后台清理

Anthropic 这篇更强调：

• 模型在哪些点上会失效
• 用什么 agent 分工和工件来补这个缺口
• 当模型能力变了，哪些 harness 组件应该拆掉

所以在我看来，两篇文章关注的是同一个大问题的两个层面：

• OpenAI 更像在讲 系统级工程环境
• Anthropic 更像在讲 运行时 harness 编排

前者偏”把工作场域设计好”，后者偏”在当前模型边界上怎么搭临时支架”。

两者并不冲突，反而是互补的。

十、我对这篇文章的最终理解

如果只用一句话总结：

它不是在教你搭一个固定的三 agent 模板，而是在教你如何把 harness 设计成一个可实验、可替换、可删减的能力放大器。

几个核心原则：

• 先找模型真正会失败的点
• 用最少的结构去补这些点
• 把执行、判断、规划适度拆开
• 用中间工件做状态对齐
• 用真实运行时验证替代纸面完成感
• 随模型升级不断做减法

我觉得这篇文章很”工程”，而不只是”AI demo 复盘”。它最打动我的地方，不是他们做出了一个几小时自动跑的系统，而是他们始终在问：

这个组件为什么存在？ 它现在还必要吗？ 模型如果变强了，它是不是该被删掉？

这才是 harness engineering 真正成熟的样子。