Harness design for long-running application development
这是一篇 Anthropic 关于长时运行应用开发 harness 的工程文章。文章的核心不是“又做了一个多 agent 系统”，而是更具体地讨论：在前沿 agentic coding 里，什么样的 harness 设计能让模型在多小时的前端设计和全栈应用开发中持续产出高质量结果。作者给出的答案是，把任务拆成明确角色，并用规划、外部评估和结构化交接来抑制模型在长任务中的常见失效模式。
- 文章把此前两条线索合并了起来：一条是前端设计中的主观质量评估，另一条是长时运行 coding agent 的上下文与交接问题。
- 作者先在前端设计上验证了一个 GAN 风格思路：把生成和评分拆开。
generator负责生成界面，evaluator负责通过 Playwright 实际操作页面，再按design quality / originality / craft / functionality四个维度评分和批评。 - 这个分离之所以重要，是因为模型在自评自己产出时往往过度宽松，尤其在设计这类主观任务上会“自我表扬”。让独立 evaluator 持怀疑态度，反而更容易调出来。
- 然后作者把这个结构迁移到长时运行应用开发，形成
planner / generator / evaluator三角色架构：planner把一句话 prompt 展开成产品 spec，generator按 feature 或 sprint 实现，evaluator用 Playwright 与验收标准做 QA。 - 文章对
context reset和compaction做了清晰区分：compaction 只是压缩历史，能保连续性；reset 是直接换一个新 agent 并通过交接 artifact 传状态，能更彻底缓解 context anxiety，但会增加编排成本。 - 在早期 harness 中，Sonnet 4.5 的 context anxiety 明显到 compaction 不够用，所以 reset 很关键；到了 Opus 4.6，模型长时稳定性提高，很多任务上可以把 reset 去掉，改成单一连续 session 加自动 compaction。
- 文章最有价值的工程结论之一是：harness 组件不是越多越好。每加一个 planner、evaluator、sprint 结构，都意味着你在弥补某种模型短板；新模型来了，就应该重新验证哪些组件还 load-bearing，哪些已经成了纯开销。
- 在具体实验中，完整 harness 用一句话 prompt 做出了比单 agent 更完整、更有产品感的浏览器 DAW 和复古游戏制作器，但成本和时长也显著上升，例如 DAW 版本约
3 hr 50 min、$124.70。 - 即使如此，文章也承认 evaluator 仍有明显上限，尤其在音乐听感、微妙交互和深层嵌套 feature 上，模型 QA 还远未穷尽人类的验收能力。
ℹ️ Conflict:
- 更复杂的 harness 能明显提升上限，但也会带来额外编排成本、延迟和 token 开销；并不是所有任务都值得上 planner 和 evaluator。
- evaluator 不是固定必选项。文章明确指出：当任务已经落到当前模型的稳定能力边界以内时，evaluator 可能只是额外负担；只有任务接近或超出模型稳态能力时，它才真正显著增益。
- Anthropic, “Harness design for long-running application development”, 原文摘录：[llm-wiki/raw/anthropic/Harness design for long-running application development](/raw/anthropic/Harness design for long-running application development.md)