Anthropic：长期运行 Agent 应用的 Harness 设计
Anthropic 最新发布了一篇关于长期运行 Agent 应用 Harness 设计的深度技术文章，作者是 Prithvi Rajasekaran。文章分享了如何通过多 Agent 架构（生成器+评估器）来突破传统单 Agent 的能力天花板，实现复杂应用的自主构建。
核心问题：为什么简单实现不够？
传统的单 Agent 实现会遇到两个关键问题：
1. 上下文焦虑（Context Anxiety）
随着任务时间增长，模型会出现”上下文焦虑”——在接近上下文限制时提前结束工作。虽然上下文压缩（compaction）可以延长会话，但无法给 Agent 一个干净的 slate。解决方案是上下文重置（Context Reset）：完全清空上下文窗口，通过结构化交接（handoff）让新 Agent 接手。
2. 自我评估偏差
当要求 Agent 评估自己的工作质量时，它们往往过于乐观——即使质量明显 mediocre，也会自信地给予好评。这在主观任务（如设计）中尤为明显。
解决方案：分离生成与评估
借鉴 GAN（生成对抗网络）的思想，将生成器（generator）和评估器（evaluator）分离。虽然评估器也是 LLM，但调校一个独立的 skeptical evaluator 比让生成器自我批评要容易得多。
前端设计实验
作者首先在前端设计领域验证这个思路。Claude 默认倾向于安全、可预测的布局，技术可用但视觉平庸。
四项评分标准
为了让主观质量可量化，作者制定了四项评分标准：
| 标准 | 含义 |
|---|---|
| Design Quality | 设计是否像一个统一的整体，而非零件拼凑？色彩、排版、布局是否创造独特氛围？ |
| Originality | 是否有定制决策？还是模板布局、库默认值、AI 生成模式？ |
| Craft | 技术执行：排版层级、间距一致性、色彩和谐、对比度 |
| Functionality | 可用性：用户能否理解界面功能、找到主要操作、完成任务？ |
重点：Design Quality 和 Originality 权重更高，明确惩罚”AI slop”（紫色渐变+白卡片的典型 AI 生成模式）。
迭代循环
- 生成器创建 HTML/CSS/JS 前端
- 评估器通过 Playwright MCP 与页面交互、截图、评分
- 反馈回流给生成器进行下一轮迭代
- 运行 5-15 轮迭代，每轮 4 小时
惊人发现：在为一个荷兰艺术博物馆设计网站的第 10 轮迭代中，生成器完全推翻了之前的设计，重新想象为一个 3D 空间体验——CSS 透视渲染的方格地板、自由位置悬挂的艺术品、门洞导航而非滚动点击。这是单次生成从未见过的创意飞跃。
扩展到全栈开发
基于前端实验的经验，作者将其应用到全栈开发，构建了一个三 Agent 架构：
架构设计
| Agent | 角色 | 职责 |
|---|---|---|
| Planner | 规划器 | 将 1-4 句简单 prompt 扩展为完整产品 spec， ambitious 但避免过早指定技术细节 |
| Generator | 生成器 | 按 sprint 逐个实现功能，使用 React + Vite + FastAPI + SQLite/PostgreSQL 技术栈 |
| Evaluator | 评估器 | 通过 Playwright MCP 测试运行中的应用，评分并反馈 bug |
Sprint 契约
在每次 sprint 前，生成器和评估器协商”sprint 契约”：明确定义”完成”的标准和可测试的行为。这弥补了用户故事与可测试实现之间的鸿沟。
对比实验
Prompt：创建一个 2D 复古游戏制作器，包含关卡编辑器、精灵编辑器、实体行为和可玩测试模式。
| 方案 | 时长 | 成本 | 结果 |
|---|---|---|---|
| 单 Agent | 20 分钟 | $9 | 核心功能损坏，实体无法响应输入 |
| 完整 Harness | 6 小时 | $200 | 功能完整，包含 AI 辅助精灵生成、关卡设计、游戏导出 |
关键差异：
- 单 Agent 版本：布局浪费空间、工作流程僵化、核心游戏功能损坏
- Harness 版本：完整 viewport 利用、一致的视觉识别、AI 集成加速工作流、实际可玩的游戏
持续优化
移除 Sprint 结构
随着 Opus 4.6 发布（规划更仔细、更长任务保持、更好的代码审查和调试能力），作者尝试简化 harness：
- 移除 sprint 结构，让生成器连续运行 2 小时以上
- 评估器改为单次最终评估而非每 sprint 评估
- 保留 planner（防止生成器 under-scope）和 evaluator（捕获边缘 bug）
新实验：浏览器端 DAW（数字音频工作站）
- 运行 4 小时，$124
- 生成器连续运行 2 小时无需分解
- 评估器仍捕获关键缺陷：剪辑无法拖动、音频录制仅 stub、效果可视化不足
结论：评估器不是固定的是/否决策，而是取决于任务是否超出生成器独立可靠完成的边界。
核心启示
- 模型能力边界决定 harness 复杂度：随着模型改进，某些假设可能过时，值得定期 stress test
- 分解任务 + 专业化 Agent：复杂任务中，分解并应用专业化 Agent 能带来提升
- 新模型发布时重新评估 harness：剥离不再关键的组件，添加新组件实现更大能力
- 有趣 harness 组合的空间不会缩小：随着模型改进，空间会移动，AI 工程师的工作是不断找到下一个新颖组合
关键引用
“The space of interesting harness combinations doesn’t shrink as models improve. Instead, it moves, and the interesting work for AI engineers is to keep finding the next novel combination.”
“It is always good practice to experiment with the model you’re building against, read its traces on realistic problems, and tune its performance to achieve your desired outcomes.”
原文链接：https://www.anthropic.com/engineering/harness-design-long-running-apps
作者：Prithvi Rajasekaran (Anthropic Labs)