核心洞察：Harness 设计的工程实践
这是一篇来自 Anthropic 官方博客的深度工程文章，作者 Prithvi Rajasekaran 分享了他们在长运行应用开发中设计 Harness 的实践经验。文章涵盖了从设计质量评估到全栈代码生成的完整方法论。
| 属性 | 内容 |
|---|---|
| 作者 | Prithvi Rajasekaran (Anthropic Labs Team) |
| 来源 | Anthropic 官方工程博客 |
| 核心架构 | Generator-Evaluator 多 Agent 系统（GAN 启发） |
| 关键创新 | Sprint Contract、Context Reset、主观质量可评估化 |
一、为什么简单实现会失败
两个核心问题
1. Context Anxiety（上下文焦虑）
模型在上下文窗口填满时会失去连贯性，甚至提前结束工作。这与 Anthropic 之前在 context engineering 文章中的观察一致。
| 解决方案 | 原理 | 效果 |
|---|---|---|
| Compaction | 原地总结早期对话 | 保留连续性，但焦虑仍在 |
| Context Reset | 完全清空上下文，结构化交接 | 干净状态，彻底解决 |
2. Self-Evaluation Bias（自我评估偏差）
当要求 Agent 评估自己完成的工作时，它倾向于过度乐观——即使质量明显平庸，也会自信地赞扬。
这对主观任务（如设计）尤其致命：没有二元验证等价物（如软件测试），布局是否精致只能靠判断。
---
二、前端设计：让主观质量可评分
GAN 启发的 Generator-Evaluator 架构
┌─────────────────┐ ┌─────────────────┐
│ Generator │ ──────→ │ Evaluator │
│ (生成设计) │ │ (评估设计) │
└─────────────────┘ ←────── └─────────────────┘
↑ │
│ 反馈循环（5-15轮迭代） │
└─────────────────────────┘
四项评分标准
作者定义了将主观判断转化为可评分维度的框架：
| 标准 | 定义 | 权重 |
|---|---|---|
| Design Quality | 设计是否像一个连贯的整体？颜色、排版、布局、图像是否结合形成独特的氛围和身份 | 高 |
| Originality | 是否有定制决策的证据？人类设计师应能识别出刻意的创意选择 | 高 |
| Craft | 技术执行：排版层级、间距一致性、色彩和谐、对比度 | 低 |
| Functionality | 独立于美学的可用性：用户能否理解界面、找到主要操作、完成任务 | 低 |
实际效果
通过 5-15 轮迭代：
- 评估器通过 Playwright MCP 与实时页面交互
- 每次迭代通常推动生成器走向更独特的方向
- 一个显著案例：荷兰艺术博物馆网站从传统落地页演变为 3D 空间体验（CSS 透视渲染的棋盘地板、墙面艺术作品、门户导航）
三、扩展到全栈开发：三 Agent 架构
架构演进
| 版本 | 模型 | 架构 | 时长 | 成本 |
|---|---|---|---|---|
| V1 | Opus 4.5 | Initializer + Coding Agent + Context Reset | 6 hr | $200 |
| V2 | Opus 4.6 | Planner + Generator + Evaluator（连续会话） | 3.8 hr | $125 |
三 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）
| 属性 | 内容 |
|---|---|
| 时长 | 20 min |
| 成本 | $9 |
| 问题 | |
| 布局 | 浪费空间，固定高度面板留下大部分视口为空 |
| 工作流 | 僵化，无 UI 引导用户先创建精灵和实体 |
| 核心缺陷 | 游戏核心功能损坏：实体显示但无输入响应 |
| 根因 | 实体定义与游戏运行时之间的连接损坏 |
Full Harness（三 Agent）
| 属性 | 内容 |
|---|---|
| 时长 | 6 hr |
| 成本 | $200 |
| 优势 | |
| 功能丰富度 | 额外包含：精灵动画系统、行为模板、音效、AI 辅助精灵生成器、关卡设计师、游戏导出 |
| 视觉设计 | 使用完整视口、合理面板尺寸、一致的视觉识别 |
| AI 集成 | 内置 Claude 集成，通过提示生成游戏各部分 |
| 核心功能 | 游戏模式可运行：实体可移动、可玩 |
评估器发现的典型问题
| Contract 标准 | 评估器发现 | ||
|---|---|---|---|
| 矩形填充工具允许点击-拖动用选定图块填充矩形区域 | FAIL — 工具只在拖动起点/终点放置图块，而非填充区域。fillRectangle 函数存在但未在 mouseUp 时正确触发 | ||
| 用户可选择并删除已放置的实体生成点 | FAIL — 删除键处理程序需要 selection 和 selectedEntityId 同时设置，但点击实体只设置 selectedEntityId。条件应为 selection \ | \ | (selectedEntityId && activeLayer === 'entity') |
| 用户可通过 API 重新排序动画帧 | FAIL — PUT /frames/reorder 路由定义在 /{frame_id} 路由之后。FastAPI 将 'reorder' 匹配为 frame_id 整数并返回 422 |
五、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 结构：
| 变化 | 原因 |
|---|---|
| 移除 Sprint | 4.6 原生处理能力更强，无需分解 |
| 保留 Planner | 防止生成器 underscope（从原始提示开始构建而不先规格化） |
| 保留 Evaluator | 对于超出生成器可靠能力的任务，评估器仍提供真实价值 |
| 单 Pass QA | 移至运行结束时，而非每 Sprint |
DAW 案例（简化后 Harness）
> "使用 Web Audio API 在浏览器中构建功能齐全的 DAW（数字音频工作站）"
| 阶段 | 时长 | 成本 |
|---|---|---|
| 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 |
| 总计 | 3 hr 50 min | $124.70 |
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 的启示
| 实践 | OpenClaw 应用 |
|---|---|
| Context Reset | 现有上下文压缩可结合更激进的 Reset 策略 |
| Generator-Evaluator | Skill 系统可引入评估 Agent 进行质量把关 |
| Sprint Contract | 复杂任务可拆分为带验收标准的 Sprint |
| Build to Delete | 随着模型改进，定期审视并简化 Harness |
| Playwright MCP | Evaluator 可通过浏览器自动化测试 Web 应用 |
原文链接
https://www.anthropic.com/engineering/harness-design-long-running-apps
#Harness设计 #Anthropic #Agent工程 #多Agent系统 #BuildToDelete #SprintContract