📚 喵喵的笔记库

参考-Anthropic-Harness-Design-Long-Running-Apps

7分钟阅读

Harness Design for Long-Running Application Development

来源：https://www.anthropic.com/engineering/harness-design-long-running-apps 作者：Prithvi Rajasekaran (Anthropic Labs) 收录时间：2026-05-18

核心问题

如何让 Claude 在长时间自主编码中构建出真正可用的完整应用？

两个关键失败模式：

  1. 上下文失控 — 长任务中上下文窗口填满，模型失去连贯性；有些模型出现"上下文焦虑"（接近上下文限制时过早收尾）
  2. 自我评估偏差 — Agent 倾向于自信地赞美自己的工作，即使质量明显平庸

核心创新：GAN 启发的三 Agent 架构

从生成对抗网络（GAN）获得灵感，设计了 Planner → Generator → Evaluator 三 Agent 系统：

用户 1-4 句话
       ↓
  ┌─────────┐
  │ Planner  │ 扩展为完整产品 Spec（16 个功能，10 个 Sprint）
  └────┬────┘
       ↓
  ┌──────────┐    Sprint Contract    ┌───────────┐
  │ Generator │ ←─── 协商"完成"定义 ───→│ Evaluator  │
  │           │                       │ (Playwright)│
  │ 一个功能   │ ─── 实现结果 ──────→ │ 实际点击测试 │
  │ 一个功能地 │ ←── 评分+反馈 ────── │ 评分+详细批判│
  │ 做        │                       │            │
  └──────────┘                       └───────────┘

Planner Agent

  • 输入：1-4 句话的简单描述
  • 输出：完整产品 Spec
  • 关键设计：聚焦产品上下文和高层技术设计，不指定具体实现细节——避免 spec 中的错误级联到下游
  • 自动寻找机会在产品中编织 AI 功能

Generator Agent

  • 一次一个功能（Sprint 模式）
  • 技术栈：React + Vite + FastAPI + SQLite/PostgreSQL
  • 每个 Sprint 结束自评后交接给 Evaluator
  • 有 git 做版本控制

Evaluator Agent

  • 用 Playwright MCP 像真实用户一样点击运行中的应用
  • 测试 UI 功能、API 端点、数据库状态
  • 按 4 个标准评分：产品深度、功能完整性、视觉设计、代码质量
  • 任一标准低于硬阈值 → Sprint 失败，生成详细反馈

Sprint Contract 机制

Generator 和 Evaluator 在每个 Sprint 开始前协商"完成"定义：

  • Generator 提议：做什么 + 怎么验证成功
  • Evaluator 审查：确保 Generator 做的是正确的事
  • 双方迭代直到达成一致
  • 然后才开始写代码

Agent 间通过文件通信：一个 Agent 写文件，另一个读并回复。

关键实验结果

2D 复古游戏制作器

| Harness | 时长 | 成本 | 结果 | |---------|------|------|------| | Solo（无 Harness） | 20 分钟 | 200 | 真正可玩的游戏，完整的精灵编辑器、AI 集成、关卡导出 |

同一模型（Opus 4.5），同一 prompt，质量差距巨大。

Harness 版本的额外特性（Solo 完全没有）：

  • 精灵动画系统
  • 行为模板
  • 音效和音乐
  • AI 辅助精灵生成和关卡设计
  • 游戏导出 + 分享链接
  • 内置 Claude 集成

前端设计实验

四维评分标准：

  1. 设计质量（权重高）— 整体是否像统一设计而非零件拼凑？
  2. 原创性（权重高）— 有刻意创意选择，还是模板+AI 默认模式？
  3. 工艺 — 排版层次、间距一致性、色彩和谐、对比度
  4. 功能性 — 用户能否理解界面并完成任务？

用 few-shot 校准 Evaluator，确保评估与人类偏好对齐。5-15 次迭代，每次 Evaluator 用 Playwright 实际浏览页面后打分。

令人惊讶的创意飞跃： 在一个荷兰美术馆网站的设计中，第 9 次迭代产出了整洁的暗色主题页面——然后第 10 次完全推翻，重新构想为 3D 空间体验：CSS perspective 渲染的棋盘格地板，墙上挂着画作，通过门洞在展厅间导航。这种单次生成从未见过的创意跃迁。

关键设计决策

Context Reset vs Compaction

  • Compaction（压缩）：保留同一 Agent，压缩早期对话。保持连续性但不能消除上下文焦虑
  • Context Reset（重置）：清空上下文窗口，启动新 Agent + 结构化交接。干净但需要好的 handoff artifact
  • Sonnet 4.5 上下文焦虑严重 → Reset 必要
  • Opus 4.5 大幅改善了上下文焦虑 → 可以用 Compaction 替代 Reset，一次连续 session 完成

生成器的战略决策

每次评估后 Generator 选择：

  • 分数趋势好 → 继续细化当前方向
  • 方法不对 → 彻底转向完全不同的美学

"博物馆级"提示词效应

在评分标准中加入"最好的设计是博物馆级的"这类措辞，直接塑造了输出的视觉特征——提示词不仅引导评分，还影响了生成方向。

对 Harness Engineering 的启示

  1. 分离生成和评估比让 Agent 自评效果好得多
  2. Sprint Contract（事前协商"完成"定义）比事后检查更可靠
  3. Playwright 实际操作比静态截图评估更能发现真实 bug
  4. Planner 不指定实现细节是正确的——让 Agent 自己找路径
  5. 迭代不一定线性进步— 中间版本有时比最后的好
  6. 成本换质量：6 小时 9，但只有前者产出可用的产品

关系图谱