Harness Design for Long-Running Application Development（长时应用开发的 Harness 设计）
- 原文标题
- Harness Design for Long-Running Application Development（长时应用开发的 Harness 设计）
- 原文链接
- https://www.anthropic.com/engineering/harness-design-long-running-apps
- 作者
- Prithvi Rajasekaran（Anthropic Labs）
- 发布日期
- 2026-03-24
🎯 一句话
长时任务的根本矛盾是：任务比上下文窗口长。⭐ 解法都围绕一件事：把状态外置到上下文之外，让每一轮都能从外部恢复。
通过借鉴生成对抗网络（GAN）思想的多 Agent harness 架构，可以显著提升 Claude 在复杂长周期任务上的表现。关键在于：把任务执行与结果评估分离，并引入中间规划阶段，从而在主观领域（如前端设计）和客观领域（如全栈开发）都获得更高质量的产出。
要解决的核心问题
上下文管理问题
长时间运行的 Agent 有两种主要失败模式：
- 上下文窗口退化： 随着对话历史填满上下文窗口，模型逐渐失去连贯性。
- 上下文焦虑（Context Anxiety）： 模型感知到接近 token 上限时，会过早草率收尾。
解决方案是「上下文重置」——清空对话历史，在全新的 Agent 会话之间传递结构化产物（artifacts），而不是仅依赖上下文内的摘要。
自我评估盲区
模型评估自己的工作时存在系统性的正面偏差，在主观任务上尤其明显。把生成与评估分离，远比试图让生成者自我批判更有效。
实验一：前端设计
目标： 提升 Claude 生成有美学水准、有原创性的 Web 界面的能力。
架构： 受 GAN 启发的双 Agent 结构： - 生成器 Agent： 编写 HTML/CSS/JavaScript 界面 - 评估器 Agent： 按四项具体标准打分： 1. 设计质量（整体协调、氛围、独特的视觉身份） 2. 原创性（自主的设计决策 vs 模板化默认样式） 3. 工艺（排版、间距、色彩和谐） 4. 功能性（可用性和任务完成度）
关键发现： 「这个设计是否符合我们的优秀设计原则？」是可回答的问题，而「这个设计美吗？」不是。把模糊的审美判断转化为具体可衡量的标准，评估才能稳定进行。
评估器通过 Playwright MCP 与真实页面交互，截图并研究实现后再打分。每轮生成经过 5–15 次迭代逐步打磨。一个典型例子：一个博物馆网站最初生成了平庸的深色主题设计，在第十次迭代时被推翻，改为使用 CSS perspective 渲染的 3D 空间画廊漫游体验。
实验二：全栈应用开发
架构演进： 三 Agent 系统：
1. 规划 Agent（Planner）
- 把 1–4 句话的简短需求扩展成详细的产品规格
- 侧重范围界定和高层技术方向，而非细粒度实现细节
- 在规格中融入 AI 功能的机会点
2. 生成 Agent（Generator）
- 以 Sprint 为单位迭代实现功能
- 技术栈：React、Vite、FastAPI、SQLite/PostgreSQL
- 交给 QA 前先自我检查
- 用 Git 管理版本
3. 评估 Agent（Evaluator）
- 通过 Playwright MCP 测试运行中的应用，模拟真实用户行为
- 实现前先协商「Sprint 契约」——共同定义成功标准
- 按发现的 bug 和多维质量标准打分
- 提供详细反馈供生成器迭代
通信协议： Agent 之间通过文件交换信息，在写代码之前先建立明确的「何为完成」契约。
具体案例
复古游戏制作器（Retro Video Game Maker）
- 单 Agent 方案（20 分钟，$9）： 玩法机制损坏、流程僵硬、布局问题、实体输入处理不可用
- 完整 harness（6 小时，$200）： 覆盖 10 个 Sprint 的 16 项功能规格、视觉风格统一的精致 UI、可用的精灵编辑器、游戏可正常游玩，并集成了 Claude 驱动的精灵/关卡生成功能
浏览器数字音频工作站（DAW）
- 提示词： 「用 Web Audio API 在浏览器里构建一个功能完整的 DAW」
- 结果： 具备编排视图、混音台、走带控制和 Agent 自动作曲能力的完整浏览器音乐制作程序
- 成本： 3 小时 50 分钟，$124.70
DAW 案例展示了评估器反馈的价值——它抓住了「时间轴上的片段无法拖动」「录音功能还只是桩代码」这类生成器自己会忽略的实质性缺口。
迭代精简与模型演进
- 作者采用「有条不紊地移除组件」而非推倒重来的策略。核心认识：harness 中的每个组件都编码了一个「模型自己做不到某事」的假设，这些假设会随模型进步而过时。
- Opus 4.6 到来后，规划、长上下文推理和调试能力的提升使部分脚手架不再必要。对 Opus 4.5 必不可少的 Sprint 级任务分解，对 Opus 4.6 反而成了多余开销。
- 关键结论：「有用的 harness 设计空间不会随模型进步而缩小，而是会移动。」
- 评估器的价值取决于任务复杂度相对模型能力的位置：模型能可靠完成的任务上，评估器是无谓开销；在能力边界上的任务中，评估器仍提供必要的验证和反馈。
经验与结论
- 专业化分工驱动性能： 针对规划、生成、评估分别优化的 Agent，优于一体化方案。
- 具体标准使主观改进成为可能： 把模糊判断转化为可衡量的设计原则。
- 生成/评估分离消除自评偏差： 外部评估器远比自我打分客观。
- 结构化交接支撑长时任务： 基于文件的通信和显式契约让多会话工作不发生上下文崩塌。
- harness 调优需要实证依据： 阅读 Agent 日志、度量具体提示词选择的影响，是优化的必经之路。
前瞻建议
- 大量实验以理解模型的失败模式
- 用专门化 Agent 处理任务的不同侧面
- 新模型版本发布时重新审视 harness，移除不再必要的组件
- 认识到模型进步是移动（而非消除）需要脚手架的边界
- 接受「再好的系统也仍有改进空间」——没有 harness 是完成态
✅ 检查点
- 长时任务的根本矛盾是什么？
- 「状态外置」具体外置什么？
- 为什么说「可恢复」比「不出错」更重要？
👀 答案
- ⭐ 任务需要的信息量超过了上下文窗口。一个跑几小时、几百步的任务，不可能把所有中间过程都留在上下文里。
- ①进度和待办（做到哪了、还剩什么）②已经确定的结论和决策（避免反复推翻）③产出物本身（写进文件而不是留在对话里）④遇到过的坑（否则会重复踩）。⭐ 关键是这些都要写到文件或外部存储，且格式要便于下一轮读回。
- 因为长任务里出错是必然的——工具超时、模型走偏、外部服务变更，跑几百步不可能一次不出错。⭐ 所以设计目标不该是「不出错」，而是「出错后能从最近的检查点继续」。能恢复，长度就不再是问题；不能恢复，一次失败就要从头再来。
🛑 可以停在这里
⚡ 走神救援
⭐长时任务的根本矛盾：任务需要的信息量超过了上下文窗口——跑几小时几百步的任务不可能把所有中间过程留在上下文里。⭐解法都围绕「状态外置」，外置四样：进度和待办、已确定的结论和决策（避免反复推翻）、产出物本身（写文件而非留在对话里）、遇到过的坑（否则重复踩）；关键是写到文件或外部存储，且格式便于下一轮读回。⭐⭐「可恢复」比「不出错」更重要：长任务里出错是必然的（工具超时、模型走偏、外部服务变更），设计目标该是「出错后能从最近的检查点继续」——能恢复，长度就不再是问题；不能恢复，一次失败就要从头再来。