收录：2026-06-24 · 原文发布：2026-03-24 · 类型：Engineering blog / industry signal

Anthropic Harness Design：长程应用开发的外壳设计

这篇文章讲的不是一个更会写代码的单点模型，而是如何用 planner / generator / evaluator、sprint contract、Playwright QA 和长程 harness，把模型推向完整应用构建。

harness design long-running agents planner / generator / evaluator sprint contract Playwright QA multimodal verification

本页是按原文结构整理的高保真中文详解。另有一份全文 1:1 复刻 + 中英对照页：bilingual.html（左右双栏、逐段对照，可切 EN / 中文 / 对照三视图）。常用术语保留英文。

先放观点和启发

这篇文章最重要的地方，是把“做代码”提升成“有外壳的长程软件过程”：模型要规划、生成、运行、被独立 QA、收到反馈，再继续修改。我们的 multimodal verification 可以被理解成这个 evaluator / QA 角色的多模态版本。

和我们相关的部分

Harness 是模型外的工程系统。 长程 coding 的效果来自 model、tool、context、artifact、evaluator 和 orchestration 的组合，不是单点代码生成能力。
独立 evaluator 是闭环核心。 Anthropic 明确指出 self-review 容易偏乐观；用 Playwright 操作 live app 的 evaluator 才能把 UI、行为、API、数据库状态转成可执行反馈。
Sprint contract 把目标变成 verification target。 Generator 和 evaluator 先协商 done 的定义，再实现和测试。这对应我们需要的 verifier schema：failure、evidence、expected、actual、location、suggested fix、uncertainty。

文章结构详解

1. Naive 实现为什么不够 长任务会失去 coherence，模型还会有 context anxiety。早期 harness 用 context reset 和 structured handoff 让新 agent 接手；同时 self-evaluation 过于宽松，需要把做事和评判分离。

2. 前端设计如何被评分 Anthropic 用 design quality、originality、craft、functionality 四类标准，并更重视前两项，避免 Claude 生成安全但普通的模板化页面。

3. Generator-evaluator loop Generator 生成 HTML/CSS/JS；evaluator 通过 Playwright MCP 打开页面、点击、截图、观察，再打分和写 critique。每次 generation 跑 5 到 15 轮，最长约 4 小时。

4. Full-stack 三智能体 Planner 把短 prompt 扩成 product spec；Generator 按 feature/sprint 实现；Evaluator 像用户一样测试 UI、API 和 database state，低于阈值就让 sprint fail。

5. Retro game maker 对比 Solo run 20 分钟、约 $9，核心 game play 坏了；full harness 6 小时、约 $200，规划成 16 features / 10 sprints，最后可玩但仍有 rough edges。

6. DAW 更新版 harness 移除 sprint construct 后，Opus 4.6 builder 连续运行 2 小时以上；整体约 3 小时 50 分、$124.70。QA 仍抓到 display-only、stub、缺少交互深度等问题。

关键机制

Context reset vs compaction

Compaction 是压缩历史后让同一个 agent 继续；context reset 是清空上下文，用 handoff artifact 让新 agent 接手。前者保留连续性，后者减少 context anxiety，但要求 handoff 足够结构化。

Rubric 影响输出性格

前端实验里，rubric 不只是评分表，也在 shaping output。强调 design quality 和 originality，会让 generator 更愿意做审美冒险；某些措辞甚至会导致风格收敛。

QA agent 需要被训练得 skeptical

Anthropic 观察到 out-of-box QA 会找到 bug 后又说服自己“问题不大”，或者只测表层路径。作者通过读 evaluator logs、找人类判断和模型判断不一致的地方，反复调 QA prompt。

组件是否 load-bearing 会随模型移动

文章的一个重要工程原则是：harness 的每个 component 都编码了“模型自己做不到什么”的假设。新模型到来后，要重新检查哪些组件还必要，哪些已经变成 overhead。

对我们项目的直接启发

Verifier 要独立。 不要只靠 generator 自评；至少要有单独 evaluator role 和明确的 skeptical criteria。
Verifier 要看运行后的 artifact。 Playwright live page 是最低可行形式；我们进一步加入 screenshot、video frame、DOM、logs、API/database state。
Verifier 输出要可执行。 不是“页面不好看”，而是具体 evidence、失败位置、预期/实际差异和下一步 patch 方向。
验证也要记忆化。 如果 verifier 发现过某类视觉/行为失败，下一轮 agent 应该能读到并避免重复。
实验要记录成本。 这类 loop 质量提升明显，但 token、时间、quota 都是真实约束。

X / 评论区记录

X 原帖公开搜索结果显示有 315 replies；直接抓取 X 和 lightbrd 镜像时遇到访问限制。已在 x-discussion.md 中记录可验证的 X 元信息、搜索片段，以及同一 Anthropic 发布在 LinkedIn 上可公开读取的评论主题。

评论区主题集中在：generator/evaluator 分离、TDD/acceptance criteria 类比、context anxiety、decision authority、trajectory drift、Playwright/browser QA、成本和 quota exhaustion、persistent memory、dynamic skills。

可转化实验问题

同一 UI/应用任务上，self-review、text-only evaluator、Playwright evaluator、multimodal evaluator 的改进幅度分别是多少？
有无 sprint contract，会不会影响 verifier feedback 的具体性和下一轮修复成功率？
Verifier 看 screenshot、DOM、logs、API/database state 的不同组合时，发现的 bug 类型有何差异？
模型变强后，multimodal verifier 在哪些任务上仍然是 load-bearing component？