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

## 核心洞察：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** | 完全清空上下文，结构化交接 | **干净状态，彻底解决** | > 对于 Claude Sonnet 4.5，Context Reset 是**必需**的——单纯 compaction 不足以支撑长任务。 **2. Self-Evaluation Bias（自我评估偏差）** 当要求 Agent 评估自己完成的工作时，它倾向于**过度乐观**——即使质量明显平庸，也会自信地赞扬。 这对主观任务（如设计）尤其致命：没有二元验证等价物（如软件测试），布局是否精致只能靠判断。 --- ## 二、前端设计：让主观质量可评分 ### GAN 启发的 Generator-Evaluator 架构 ``` ┌─────────────────┐ ┌─────────────────┐ │ Generator │ ──────→ │ Evaluator │ │ (生成设计) │ │ (评估设计) │ └─────────────────┘ ←────── └─────────────────┘ ↑ │ │ 反馈循环（5-15轮迭代） │ └─────────────────────────┘ ``` ### 四项评分标准 作者定义了将主观判断转化为可评分维度的框架： | 标准 | 定义 | 权重 | |------|------|------| | **Design Quality** | 设计是否像一个连贯的整体？颜色、排版、布局、图像是否结合形成独特的氛围和身份 | **高** | | **Originality** | 是否有定制决策的证据？人类设计师应能识别出刻意的创意选择 | **高** | | **Craft** | 技术执行：排版层级、间距一致性、色彩和谐、对比度 | 低 | | **Functionality** | 独立于美学的可用性：用户能否理解界面、找到主要操作、完成任务 | 低 | > **关键洞察**：Claude 默认在 Craft 和 Functionality 上表现良好，但在 Design Quality 和 Originality 上经常平庸。因此**加权设计质量和原创性**推动模型承担更大的美学风险。 ### 实际效果 通过 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