# Anthropic: Harness design for long-running application development

Status: captured-for-positioning  
Type: engineering blog / industry signal, not a paper  
Published: 2026-03-24  
Captured: 2026-06-24  
Language: 英文原文，中文详解；保留常用英文术语。  

## Source

- Title: Harness design for long-running application development
- Author: Prithvi Rajasekaran, Anthropic Labs
- Source: Anthropic Engineering Blog
- Original link: https://www.anthropic.com/engineering/harness-design-long-running-apps
- X announcement: https://x.com/AnthropicAI/status/2036481033621623056
- Standalone local page: `index.html`
- X / public discussion notes: `x-discussion.md`

> Copyright note: user asked for an exact full translation. Because this note is part of a public survey/dashboard, this file preserves the article's structure and details through a high-fidelity Chinese explanation rather than a word-for-word full translation. Key terms and short source phrases are kept in English where useful.

## 先放我们的观点和启发

这篇文章非常重要，因为它把我们正在讨论的几个关键词放到同一个工程结构里：

```text
long-running application development
  -> planner / generator / evaluator
  -> sprint contract
  -> Playwright-driven QA
  -> observable app behavior
  -> iterative code revision
  -> harness simplification as models improve
```

它不是直接讲 multimodal verification，但它实际上给出了一个强相关的外壳：模型不只是写代码，而是在一个 harness 里长期工作；验证不是模型“自我感觉不错”，而是由独立 evaluator 通过真实运行界面、点击、截图、检查 API 和数据库状态来给出反馈。

这和我们的愿景非常贴近：multimodal verification 不是一个单独打分器，而是让 agent 在既有系统基础上继续推进开发的闭环组件。

## 和我们相关的部分

1. **Harness 是模型外的工程系统。** 文章的核心不是“Claude 更会写代码”，而是 planner、generator、evaluator、context management、artifact handoff、QA criteria 这些外部结构共同决定长程任务质量。这支持我们的 framing：agentic coding 的能力来自 `model + harness + environment + verification`，不能只看模型本身。

2. **独立 evaluator 比 self-review 更关键。** Anthropic 明确观察到模型评估自己产物时会偏乐观，尤其是前端设计和复杂 app QA。把 generator 和 evaluator 分离，让 evaluator 通过 Playwright MCP 操作 live page，再给出结构化 critique，是我们 multimodal verification loop 的近邻形态。

3. **Sprint contract 把 vague goal 变成可验证目标。** 文章里 generator 和 evaluator 在每个 sprint 前协商 “done” 的定义，再由 evaluator 检查具体行为。这对我们很重要：多模态 verifier 不应该只说“好/不好”，而应该绑定可观察 evidence、失败位置、预期行为和下一步修复建议。

## 这篇文章在讲什么

Anthropic 这篇工程博客讨论两个互相关联的问题：

1. 让 Claude 做出更高质量、更有审美判断的 frontend design。
2. 让 Claude 在没有人类持续介入的情况下构建完整应用。

作者的工作来自此前两个方向：`frontend design skill` 和 `long-running coding agent harness`。这些早期工作通过 prompt engineering 和 harness design 已经把 Claude 推到 baseline 以上，但后来遇到上限。为突破上限，作者借鉴 GAN 的思路，设计了 generator 和 evaluator 分离的多智能体结构。

文章的主线可以压缩成一句话：

```text
如果任务足够长、足够主观、足够产品化，就不能只让一个 agent 写完再自评；需要外部 harness 把规划、生成、验证、反馈、继续推进组织起来。
```

## 逐节详解

### 1. 为什么 naive implementation 不够

文章先解释长程 agentic coding 为什么容易失败。

第一类问题是长任务里的 coherence 下降。随着 context window 被填满，模型容易忘记先前决策、偏离任务，或者出现 `context anxiety`：模型接近它以为的上下文限制时，会提前收尾，像是在任务还没有真正完成前急着结束。

Anthropic 早期 harness 使用 `context reset` 解决这个问题：完全清空当前上下文，启动一个新 agent，再通过结构化 handoff artifact 把上一个 agent 的状态和下一步传过去。文章特别区分了 `reset` 和 `compaction`：

- `compaction` 是把前文压缩进同一会话，让同一个 agent 继续工作；
- `reset` 是让新 agent 从干净上下文开始，只读取 handoff artifact。

在 Sonnet 4.5 上，作者认为 compaction 不足以解决 context anxiety，所以 reset 成了必要结构。但 reset 也带来 orchestration complexity、token overhead 和 latency。

第二类问题是 self-evaluation。模型评估自己刚产出的作品时，经常会自信地夸奖，即便人类明显能看出质量普通。前端设计这种主观任务尤其明显，因为它不像单元测试那样有二元正确答案。文章的关键判断是：把“做事的 agent”和“评判的 agent”分开，是解决这个问题的强杠杆。

### 2. 前端设计：把主观质量变得可评分

作者先在 frontend design 上实验，因为这里 self-evaluation 偏乐观最明显。如果不做干预，Claude 往往会生成安全、可用但没有辨识度的页面。

Anthropic 设计了四类评分标准，并同时给 generator 和 evaluator：

- `Design quality`: 页面是否像一个整体，颜色、字体、布局、图像和细节是否形成明确情绪和身份。
- `Originality`: 是否有定制化决策，还是模板、库默认组件和典型 AI 生成风格。
- `Craft`: 技术执行是否扎实，比如字体层级、间距、色彩协调、对比度。
- `Functionality`: 不看审美时，用户是否能理解界面、找到主操作并完成任务。

作者强调前两项：design quality 和 originality。原因是 Claude 默认已经比较擅长 craft 和 functionality，但常常在 design/originality 上显得平淡。评分标准会显式惩罚 generic AI slop，比如未经修改的 stock components、白色卡片上的紫色渐变等。

Evaluator 使用 few-shot examples 做校准，保证分数和作者偏好对齐，减少迭代中的 score drift。

实现上，generator 根据用户 prompt 生成 HTML/CSS/JS 前端；evaluator 拿到 Playwright MCP，可以直接打开 live page、点击、截图、观察实现，然后按四个标准打分并写详细 critique。反馈再交回 generator，进入下一轮。

文章里每个 generation 通常跑 5 到 15 轮；因为 evaluator 真的在浏览器里操作页面，而不是只看静态截图，整个循环会消耗真实 wall-clock time，最长跑到约 4 小时。

这里最值得我们保留的不是“前端变漂亮了”，而是这个 loop 的形状：

```text
generate frontend
  -> render live page
  -> evaluator interacts through browser
  -> scores + critique
  -> generator refines or pivots
  -> repeat
```

这基本就是我们想要的 multimodal verification loop，只是 Anthropic 用它先优化 design taste。

### 3. 前端实验的现象

文章报告了几个有意思的现象：

- 分数整体会随迭代提高，但不是完全线性。
- 有时中间版本比最后版本更让作者喜欢。
- 随着 evaluator 反馈，generator 往往会做更复杂、更冒险的实现。
- 评分 criteria 的措辞会直接影响最终风格。例如强调 “museum quality” 会把设计推向某种特定审美收敛。
- 即便第一轮还没有收到 evaluator feedback，评分标准本身也能让输出避开 generic defaults。

文章举了一个荷兰艺术博物馆网站的例子：第九轮生成了精致的深色 landing page；第十轮突然 pivot，变成一个 CSS perspective 的 3D room，有棋盘地面、墙上悬挂作品、通过 doorway 在 gallery rooms 之间导航。作者把它视为单次生成不太容易出现的 creative leap。

这个例子对我们有启发：verification 不只是在纠错，也可能通过有方向的 critique 推动模型跳出局部最优。

### 4. 扩展到 full-stack coding

有了前端实验后，作者把 generator-evaluator pattern 用到 full-stack development。这里 evaluator 类似软件开发生命周期里的 code review 和 QA。

早期 long-running harness 已经有 initializer agent、coding agent，以及 context resets。到了 Opus 4.5，作者认为 `context anxiety` 大幅减轻，于是这次 harness 可以去掉 reset，让 agents 在一个连续会话里运行，依靠 Claude Agent SDK 的 automatic compaction 处理上下文增长。

文章里的 full-stack harness 是三智能体：

- `Planner`: 把 1 到 4 句的简单 prompt 扩展为完整 product spec。它被要求在 scope 上 ambitious，但聚焦产品上下文和高层技术设计，不要提前写太细的技术实现。
- `Generator`: 按 sprint 工作，一次实现一个 feature。技术栈是 React、Vite、FastAPI、SQLite，后来切到 PostgreSQL。每个 sprint 结束前 generator 先 self-evaluate，再交给 QA。
- `Evaluator`: 用 Playwright MCP 像用户一样点击 running application，测试 UI feature、API endpoint、database state，再按照 product depth、functionality、visual design、code quality 等标准评分。

每个 criterion 有 hard threshold；只要有一个低于阈值，sprint 就失败，generator 会收到详细反馈。

### 5. Sprint contract

文章里非常重要的结构是 `sprint contract`。

在每个 sprint 开始前，generator 和 evaluator 会先协商这个 chunk 的 “done” 是什么。原因是 product spec 故意保持高层，不想提前把实现细节规定死。Generator 先提出要做什么、怎么验证；evaluator 审核这个 proposal，确保它确实在做正确的事。双方迭代直到达成一致。

Communication 通过文件完成：一个 agent 写文件，另一个 agent 读取并回应，可能在同一文件里回复，也可能写新文件。然后 generator 按约定 contract 实现，再交给 QA。

这正好对应我们想做的 verifier schema：

```text
intent / spec
  -> contract / observable criteria
  -> implementation
  -> rendered or executed evidence
  -> evaluator feedback
  -> next revision
```

### 6. Retro video game maker 实验

作者用 Claude Opus 4.5 做了一个对比：同一个 prompt 让 solo agent 和 full harness 都构建一个 2D retro game maker。

Prompt 是要求构建一个 2D retro game maker，包含 level editor、sprite editor、entity behaviors 和 playable test mode。

结果成本和耗时差异很大：

| Harness | Duration | Cost |
| --- | ---: | ---: |
| Solo | 20 min | $9 |
| Full harness | 6 hr | $200 |

Full harness 贵了 20 倍以上，但质量差异也明显。

Solo run 一开始看起来符合预期，但实际点击后出现问题：布局浪费空间，workflow 刚性，UI 没有引导用户先创建 sprites/entities，最重要的是 game play 是坏的。实体出现在屏幕上，但没有响应输入。看代码后发现 entity definitions 和 runtime 之间的 wiring 断了。

Full harness 从同一句 prompt 出发，planner 扩成 16 个 features，分布在 10 个 sprints。除了核心 editor 和 play mode，还包括 sprite animation system、behavior templates、sound effects/music、AI-assisted sprite generator、AI level designer、shareable links 等。

Full harness 的应用更 polished：canvas 使用整个 viewport，面板尺寸更合理，视觉身份更统一。workflow 仍然有一些 clunkiness，比如仍然没有很好引导用户先创建 sprites/entities，但核心 play mode 可用：作者能移动 entity 并玩起来。物理效果仍有粗糙边界，比如角色跳到平台上会重叠，但核心功能工作了。

### 7. Evaluator 抓到的具体问题

文章强调 evaluator 的价值不在抽象评价，而在具体、可操作的 bug finding。每个 sprint 它会按 contract 的 test criteria 走一遍，通过 Playwright 操作应用，记录和预期行为不一致的地方。文章提到 Sprint 3 单独就有 27 个 level editor criteria。

文章举了几类 evaluator 发现的问题：

- Rectangle fill tool 没有真正填充拖出的矩形区域，只在起点/终点放 tile。
- Delete key handler 的条件导致选中的 entity spawn point 无法删除。
- FastAPI route 顺序错误，导致 `/frames/reorder` 被当成 `/{frame_id}` 匹配，返回 422。

这几个例子很值得保留，因为它们横跨 visual interaction、frontend state、backend routing。Multimodal/software verifier 不应该只看截图，还需要把 UI 行为、代码位置、API response、database state 合起来判断。

### 8. QA agent 不是天生好用

作者特别指出：Claude out of the box 不是一个好的 QA agent。早期运行里，它会找到真实问题，然后自己说服自己这些问题不严重，最后批准工作；它也容易只做浅层测试，漏掉边界情况。

因此 evaluator prompt 也需要调参。作者的 tuning loop 是读 evaluator logs，找出它的判断和人类判断不一致的地方，再更新 QA prompt。多轮迭代后，evaluator 才达到作者认为合理的评分方式。

但即便如此，harness output 仍有 QA 局限：小布局问题、交互不直觉、深层嵌套功能里的未发现 bug 仍会存在。这说明 verification headroom 还很大。

这点对我们尤其关键：我们不能假设“有一个 VLM/LLM verifier 就够了”。Verifier 也需要 benchmark、calibration、failure taxonomy 和 prompt/harness tuning。

### 9. 迭代 harness：组件是否 load-bearing

第一版 harness 有效果，但笨重、慢、贵。下一步是简化 harness，同时不牺牲性能。

文章给出一个非常好的工程原则：harness 的每个 component 都编码了一个假设，即模型自己做不到什么；这些假设需要 stress test，因为它们可能错，也会随着模型进步而过期。

作者先尝试大幅简化，但发现无法复现原始性能，也很难判断哪些组件真正 load-bearing。于是改成更 methodical 的做法：一次移除一个组件，看最终结果变化。

这对我们之后实验很重要：multimodal verifier 也要做 ablation。比如：

- 有 verifier vs 无 verifier；
- verifier 看 screenshot vs 看 DOM+截图；
- verifier 只评分 vs 给 actionable feedback；
- verifier 在每个小步后检查 vs 只在 end-to-end 后检查。

### 10. 移除 sprint construct

随着 Opus 4.6 发布，作者有理由相信模型需要更少 scaffold。文章提到 Opus 4.6 更会 plan、更能持续 agentic tasks、更可靠地在大代码库中运行，并且 code review/debugging 能力更好。

作者先移除了 sprint construct。Sprint 原本帮助模型把工作切块，但 4.6 可能可以原生处理更长任务。Planner 和 evaluator 仍保留，因为它们价值明显：

- 没有 planner，generator 容易 under-scope；
- evaluator 在任务位于模型能力边界之外时仍能发现关键问题。

一个重要结论是：evaluator 不是固定 yes/no 的选择。它是否值得取决于任务相对当前模型能力边界的位置。如果任务在模型 solo 能力范围内，evaluator 可能是 overhead；如果任务在边界外，evaluator 仍有明显收益。

### 11. Updated harness: browser DAW

作者用更新后的 harness 生成一个浏览器里的 Digital Audio Workstation（DAW），prompt 是用 Web Audio API 构建一个功能完整的 DAW。

这次仍然很长很贵，总计约 3 小时 50 分钟，token cost 约 $124.70。文章列出阶段：

| Agent / Phase | Duration | Cost |
| --- | ---: | ---: |
| Planner | 4.7 min | $0.46 |
| Build Round 1 | 2 hr 7 min | $71.08 |
| QA Round 1 | 8.8 min | $3.24 |
| Build Round 2 | 1 hr 2 min | $36.89 |
| QA Round 2 | 6.8 min | $3.09 |
| Build Round 3 | 10.9 min | $5.88 |
| QA Round 3 | 9.6 min | $4.06 |
| Total V2 Harness | 3 hr 50 min | $124.70 |

这里有个关键信号：builder 在没有 sprint decomposition 的情况下连续运行超过 2 小时仍保持 coherence。这说明新模型确实降低了 scaffold 需求。

但 QA 仍然抓到真实 gap。第一轮 QA 指出 app 看起来很好，AI agent 和 backend 也不错，但一些 DAW 核心功能只是 display-only，比如 timeline clips 不能拖动、缺少 synth knobs/drum pads、缺少 EQ curves/compressor meters。第二轮 QA 又指出 audio recording 仍是 stub、clip resize/split 未实现、effect visualizations 只是 numeric sliders。

最终 app 离专业 DAW 很远，Claude 也不能真的听音乐，所以 musical taste 的 QA loop 比较弱。但 app 已经有 arrangement view、mixer、transport，作者能通过 prompt 让 agent 设置 tempo/key、写 melody、加 drum track、调 mixer levels、加 reverb，完成一个短 song snippet。

这对我们还有一个额外启发：如果目标是音频/视频/视觉/交互质量，verifier 的 modality 能力决定上限。Claude 不能听，所以对音乐品味的 QA 弱；同理，如果 verifier 只看 DOM，不看 screenshot/video，它就很难发现视觉和动态行为问题。

### 12. What comes next

文章最后的判断是：随着模型变强，某些 scaffold 会变得不重要；但模型越强，也越能支撑更复杂的 harness，去完成 baseline 做不到的任务。

值得保留的实践建议：

- 在真实任务上观察 model traces。
- 根据想要的结果调 harness。
- 复杂任务有时可以通过 decomposition 和 specialized agents 获得 headroom。
- 新模型出现时，需要重新检查 harness，删掉不再 load-bearing 的组件，并加入此前不可能的新组件。

作者的结论是：有趣的 harness combination 不会随着模型进步而消失，而是会移动。AI engineer 的工作是继续找到下一组有效组合。

## 对我们项目的启发

### 1. Multimodal verifier 应该是 independent evaluator

不要只让 generator 自己看截图再夸自己。我们需要一个独立的 evaluator role，最好有明确 skeptical instruction、failure taxonomy、rubric 和 evidence requirements。

### 2. Verification target 需要 contract 化

文章里的 sprint contract 是从 high-level product spec 到 testable criteria 的桥。我们也需要把 screenshot/reference/video/user intent 变成可验证目标，而不是让 verifier 直接“凭感觉”评价。

### 3. Playwright-style observation 是近邻基线

Anthropic 的 evaluator 通过 Playwright MCP 操作 live app。我们的 multimodal verification 可以从这个近邻基线出发，再加入 screenshot/video/frame/DOM/log/API/database 等 evidence。

### 4. Verifier 本身也需要迭代

文章里 QA agent 早期会过度宽容、浅测、批准有 bug 的产物。我们的 verifier 也可能有同样问题：打分漂移、偏袒生成结果、忽视边界状态、无法给出 actionable fix。需要把 verifier tuning 作为研究对象，而不是一次性 prompt。

### 5. 成本是实验设计的一部分

6 小时 / $200 和 3 小时 50 分 / $124.70 的例子说明，long-running harness 的质量提升伴随真实成本。我们的 benchmark 需要同时记录质量、耗时、token cost、iteration count 和 human intervention。

## 可转化为实验的问题

1. 在同一个前端/网页复刻任务上，single agent self-review、text-only evaluator、Playwright evaluator、multimodal evaluator 的改进幅度分别是多少？
2. Sprint contract 是否能提升 verifier feedback 的可执行性？比如让 verifier 输出 `failure / evidence / expected / actual / location / suggested fix / uncertainty`。
3. 对已有系统继续开发时，何时需要每步验证，何时只需要 milestone 验证？
4. Verifier 看到源码会不会更容易找 bug，还是会被实现细节误导？截图、DOM、logs、API traces 应该如何组合？
5. 在模型变强后，哪些 harness component 不再 load-bearing？Multimodal verifier 是否仍然在视觉/行为边界任务上保留收益？
6. 对音频、动画、视频、PDF、chart、UI 这些不同 artifact，verifier 的 modality 缺口分别是什么？

## Evidence Strength

| Claim | Evidence | Strength | Relevance |
| --- | --- | --- | --- |
| 长程 app development 需要 harness，而不只是单个模型生成。 | Anthropic 工程博客给出 planner/generator/evaluator、sprint contract、Playwright QA、多小时 runs。 | medium | high |
| 独立 evaluator 能明显改善 subjective design 和 full-stack QA。 | 文章报告 frontend 5-15 轮迭代、retro game maker solo vs full harness 对比、DAW QA 多轮抓 gap。 | medium | high |
| Evaluator 本身需要 tuning 和校准。 | 文章明确说 out-of-box QA 会过宽、浅测，需要读 logs 后调 prompt。 | medium | high |
| Multimodal verification 可作为 evaluator 的下一步形态。 | 这是从 Playwright/browser QA 和我们项目目标推出的研究假设。 | hypothesis | high |

## 相关文件

- Standalone page: `index.html`
- X / public discussion: `x-discussion.md`
- Board page: `../../../notes-blogs.html`