Anthropic 官方实践：长运行应用开发的 Harness 设计之道

核心洞察：Harness 设计的工程实践

这是一篇来自 Anthropic 官方博客的深度工程文章，作者 Prithvi Rajasekaran 分享了他们在长运行应用开发中设计 Harness 的实践经验。文章涵盖了从设计质量评估到全栈代码生成的完整方法论。

一、为什么简单实现会失败

两个核心问题

1. Context Anxiety（上下文焦虑）

模型在上下文窗口填满时会失去连贯性，甚至提前结束工作。这与 Anthropic 之前在 context engineering 文章中的观察一致。

对于 Claude Sonnet 4.5，Context Reset 是必需的——单纯 compaction 不足以支撑长任务。

2. Self-Evaluation Bias（自我评估偏差）

当要求 Agent 评估自己完成的工作时，它倾向于过度乐观——即使质量明显平庸，也会自信地赞扬。

这对主观任务（如设计）尤其致命：没有二元验证等价物（如软件测试），布局是否精致只能靠判断。

二、前端设计：让主观质量可评分

GAN 启发的 Generator-Evaluator 架构

┌─────────────────┐         ┌─────────────────┐
│   Generator     │ ──────→ │   Evaluator     │
│  (生成设计)      │         │  (评估设计)      │
└─────────────────┘ ←────── └─────────────────┘
         ↑                         │
         │    反馈循环（5-15轮迭代）    │
         └─────────────────────────┘

四项评分标准

作者定义了将主观判断转化为可评分维度的框架：

关键洞察：Claude 默认在 Craft 和 Functionality 上表现良好，但在 Design Quality 和 Originality 上经常平庸。因此加权设计质量和原创性推动模型承担更大的美学风险。

实际效果

通过 5-15 轮迭代：

• 评估器通过 Playwright MCP 与实时页面交互
• 每次迭代通常推动生成器走向更独特的方向
• 一个显著案例：荷兰艺术博物馆网站从传统落地页演变为 3D 空间体验（CSS 透视渲染的棋盘地板、墙面艺术作品、门户导航）

三、扩展到全栈开发：三 Agent 架构

架构演进

三 Agent 分工

┌─────────────────────────────────────────────────────────────────┐
│                     三 Agent 系统架构                            │
├─────────────────────────────────────────────────────────────────┤
│                                                                  │
│  ┌─────────────┐                                                │
│  │   Planner   │  将 1-4 句提示扩展为完整产品规格                   │
│  │  (规划者)    │  • 保持高水平技术设计                            │
│  │             │  • 避免过早指定细节（防止级联错误）                │
│  └──────┬──────┘                                                │
│         │ 输出：16 功能规格 + 视觉设计语言                        │
│         ▼                                                       │
│  ┌─────────────┐                                                │
│  │  Generator  │  分 Sprint 实现功能                              │
│  │  (生成器)    │  • 技术栈：React + Vite + FastAPI + SQLite      │
│  │             │  • 每 Sprint 结束自我评估                        │
│  │             │  • 使用 Git 版本控制                            │
│  └──────┬──────┘                                                │
│         │ 输出：可运行代码 + Sprint 成果                           │
│         ▼                                                       │
│  ┌─────────────┐                                                │
│  │  Evaluator  │  通过 Playwright 测试运行中的应用                 │
│  │  (评估器)    │  • 测试 UI 功能、API 端点、数据库状态             │
│  │             │  • 每项标准有硬阈值，未通过则 Sprint 失败         │
│  └─────────────┘                                                │
│                                                                  │
│  关键机制：Sprint Contract（Sprint 合约）                         │
│  - 编码前，Generator 和 Evaluator 协商"完成"的定义                │
│  - Generator 提议：构建内容和验证方式                             │
│  - Evaluator 审查：确保构建正确的内容                             │
│  - 迭代直到达成一致                                               │
│                                                                  │
└─────────────────────────────────────────────────────────────────┘

Sprint Contract 机制

这是桥接用户故事和可测试实现的关键步骤：

用户提示："创建一个 2D 复古游戏制作器"
    │
    ▼
Planner → 16 功能规格（跨 10 个 Sprint）
    │
    ▼
Sprint N: Generator & Evaluator 协商 Contract
    │
    ├─ Generator: "我将构建 X，通过 Y 验证"
    ├─ Evaluator: "审查后同意/要求修改"
    │
    ▼
Generator 构建 → Evaluator QA → 通过/反馈

四、案例对比：Solo vs Full Harness

测试任务

"创建一个具有关卡编辑器、精灵编辑器、实体行为和可玩测试模式的 2D 复古游戏制作器"

Solo 运行（单 Agent）

评估器发现的典型问题

五、Harness 的持续演化：Build to Delete

核心哲学

"Every component in a harness encodes an assumption about what the model can't do on its own, and those assumptions are worth stress testing."

Build to Delete：Harness 的复杂度应随模型能力提升而递减。

Opus 4.6 的简化

当 Opus 4.6 发布时（具备更好的规划、长上下文检索、代码审查和调试能力），作者移除了 Sprint 结构：

DAW 案例（简化后 Harness）

"使用 Web Audio API 在浏览器中构建功能齐全的 DAW（数字音频工作站）"

QA 仍发现的真实缺陷

即使经过简化，QA 仍捕获了关键问题：

第一轮反馈：

"主要失败点是功能完整性——虽然应用看起来令人印象深刻且 AI 集成运行良好，但几个核心 DAW 功能仅是显示而无交互深度：片段无法在时间轴上拖动/移动，没有乐器 UI 面板（合成器旋钮、鼓垫），也没有视觉效果编辑器（EQ 曲线、压缩器仪表）。"

第二轮反馈：

"剩余缺陷：音频录制仍是 stub-only（按钮切换但无麦克风捕获）；片段边缘拖动调整大小和片段分割未实现；效果可视化是数字滑块而非图形化（无 EQ 曲线）。"

关键洞察：生成器在独立工作时仍然容易遗漏细节或 stub 功能，QA 在捕获这些最后一公里问题方面继续增加价值。

六、核心经验总结

1. Context Reset > Compaction

对于容易上下文焦虑的模型（如 Sonnet 4.5），完全重置上下文比原地总结更有效。

2. Generator-Evaluator 分离是强杠杆

• 单独的评估器可以调优为怀疑者
• 比让生成器批评自己的工作更容易
• 提供具体迭代目标

3. 主观质量可评估化

通过明确定义标准（设计质量、原创性、工艺、功能），将"这个设计好吗？"转化为可评分的维度。

4. Sprint Contract 桥接抽象与实现

在编码前协商"完成"的定义，防止：

• 规格过高导致的级联错误
• 实现偏离用户意图

5. Build to Delete

Harness 组件编码了关于模型不能做什么的假设。随着模型改进，这些假设应被验证并剥离。

6. Evaluator 的价值边界

评估器不是固定的是/否决策——当任务超出当前模型可靠能力边界时，它值得成本。

对 OpenClaw 的启示

原文链接

https://www.anthropic.com/engineering/harness-design-long-running-apps

#Harness设计 #Anthropic #Agent工程 #多Agent系统 #BuildToDelete #SprintContract