如果你想让 Agent 在你睡觉时持续完成复杂任务，harness 设计的质量直接决定成败。Anthropic 工程师 Prithvi Rajasekaran 在三月份发表的 Harness design for long-running application development 是一篇难得的实战复盘，完整记录了他们如何一步步把 Claude 从能跑推到能交付。

两个核心问题

在进入架构设计之前，文章先指出了长时自主 Agent 任务中最普遍的两个失败模式：

Context anxiety：模型在接近上下文窗口上限时，会倾向于提前收尾，即使任务远未完成。Sonnet 4.5 这个问题尤为明显。

Self-evaluation 偏差：Agent 评估自己产出时，系统性地给出高于实际质量的评分——这在设计这类主观任务上最为突出，但即使在有客观评判标准的编程任务上也无法完全消除。

GAN 风格的三 Agent 架构

解决方案的灵感来自 GAN（生成对抗网络）：不让生成者同时当评判者，而是分离成两个独立角色。

完整架构包含三个 Agent：

Planner：接收 1-4 句的产品描述，输出完整的产品 spec。要求它保持野心，聚焦产品上下文而非技术实现细节——因为 spec 里的错误会级联到下游实现。

Generator：每次做一个 Sprint，从 spec 里取一个功能实现。用 React + Vite + FastAPI + PostgreSQL 技术栈，每个 Sprint 结束自评后再交给 QA。

Evaluator：使用 Playwright MCP 实际操作运行中的应用——点击按钮、调用 API、检查数据库状态——然后对照 Sprint contract 里的每一项测试标准打分。任何一个指标低于硬阈值，Sprint 判定失败，Generator 收到详细反馈。

Generator 和 Evaluator 在每个 Sprint 开始前会协商一份Sprint contract：双方对齐完成的定义和验证方式，之后 Generator 按约实现，Evaluator 按约验收。

实测结果：6 小时 vs 20 分钟

第一个测试任务是做一个 2D 复古游戏制作工具。

Harness时长成本
Solo（单 Agent）20 分钟
完整 Harness6 小时00

成本相差 22 倍，但质量差距是肉眼可见的。Solo 版本的 Entity 渲染逻辑有断裂，核心游戏功能根本无法运行。Harness 版本交付了一个完整应用：精灵编辑器、关卡编辑器、内置 Claude 集成，甚至还有 AI 辅助生成功能。

Evaluator 在 Sprint 3 就发现了 27 个具体问题，比如矩形填充工具只在拖拽起点/终点放置瓦片，而非填充整个区域这类细节 bug。

新模型发布后，harness 需要重新审视

进入 V2 阶段时，Opus 4.6 发布了。4.6 在长上下文检索和代码调试能力上有显著提升，团队得以去掉 Sprint 结构，把 Evaluator 从每 Sprint 评分改为最终单次评估。

这一步说明了一个重要原则：harness 里的每个组件都对应模型当前能力的某个短板。模型变强了，这个短板可能就消失了，组件就成了多余开销。但同时，更强的模型也意味着你可以设计更复杂的 harness 来完成之前不可能完成的任务。

用 V2 harness 生成一个浏览器内完整 DAW（数字音频工作站），4 小时 / 24，仍需 3 轮迭代。Generator 会在非核心功能上偷懒——比如音频录制只是 stub，EQ 可视化只是滑动条而非真实曲线——这些都需要 Evaluator 抓回来。

关键结论

  • Context reset（清空重置）vs Compaction（压缩）：Compaction 保留连续性但不能解决 context anxiety；reset 提供干净 slate，但需要高质量的 handoff artifact 来传递状态
  • 分离 Evaluator 是关键杠杆：让 Generator 自己评判自己永远做不到客观，分离后才可调优
  • Evaluator 的有效性取决于任务难度：模型强到能可靠完成的任务，Evaluator 就是多余开销；在能力边界上的任务，Evaluator 价值最大
  • Harness 需要随模型迭代而重构：不是越来越简单，是越来越精准