Harness 设计是实现智能体编码前沿性能的关键。本文介绍了Anhtropic如何推动 Claude 在前端设计和长期自主软件开发方面更进一步。有两个相互关联的问题：让 AI Agent 生成高质量的前端设计。让它无需人工干预就能构建完整的应用程序。这项工作源于我们早期在前端设计技能和长期运行编码智能体框架上的努力。当时，我和同事们能够通过提示工程和 harness 设计将 Claude 的性能提升到远高于基准线的水平——但两者最终都遇到了瓶颈。瓶颈有哪些？工程瓶颈——上下文窗口我们之前已经证明，harness 设计对长期运行的智能体编码的有效性有着重大影响。在早期的一个实验中，我们使用了一个初始化智能体将产品规格说明分解为任务列表，以及一个编码智能体逐个功能地实现这些任务，然后移交工件以跨会话传递上下文。更广泛的开发者社区也得出了类似的见解，像“Ralph Wiggum”方法这样的方法使用钩子或脚本来让智能体保持持续迭代循环。但有些问题仍然存在。对于更复杂的任务，智能体仍然容易随着时间的推移而偏离正轨。在分解这个问题时，我们观察到了智能体在执行这类任务时的两种常见失效模式。随着上下文窗口填满，模型往往会在冗长的任务上失去连贯性（请参阅我们关于上下文工程的文章）。一些模型还表现出“上下文焦虑”，即当它们接近自己认为的上下文限制时，会开始过早地结束工作。上下文重置——完全清空上下文窗口并启动一个全新的智能体，同时结合一个结构化的移交过程，该过程携带前一个智能体的状态和后续步骤——解决了这两个问题。这与压缩（compaction）不同，压缩会就地总结对话的前面部分，以便同一个智能体可以在缩短的历史记录上继续运行。虽然压缩保持了连续性，但它没有给智能体一个全新的开始，这意味着上下文焦虑可能仍然存在。重置提供了一个全新的开始，但代价是移交工件需要有足够的状态，以便下一个智能体能够顺利地接续工作。仅靠压缩不足以实现强大的长任务性能，因此上下文重置成为 harness 设计中必不可少的一环。这解决了核心问题，但增加了每次 harness 运行时的编排复杂性、令牌开销和延迟。读者可以翻看笔者之前的Harness在KCD演讲可视化相关的实战。在实战中，每个任务笔者都采用了全新的上下文窗口，连接在文章末尾。建立客观指标的必要性——自视过高我们之前未提及的第二个问题是自我评估。当要求评估自己生成的作品时，智能体往往会自信地赞美这些作品——即使在一个人类观察者看来，其质量明显平庸。这个问题在主观性任务（如设计）中尤为突出，因为这类任务没有像可验证的软件测试那样的二元检查。“一个布局是精致还是普通”是一个主观判断，而智能体在评价自己的作品时总是偏向于给出正面评价。然而，即使在那些结果可验证的任务上，智能体有时也会表现出糟糕的判断力，这阻碍了它们完成任务时的表现。将执行工作的智能体与评判工作的智能体分开，被证明是解决这个问题的有力手段。但分离本身并不能立即消除那种宽容倾向；评估器仍然是一个倾向于对 LLM 生成的输出持宽容态度的 LLM。然而，将一个独立的评估器调教得具有批判性，比让生成器批判自己的作品要容易得多。一旦存在这种外部反馈，生成器就有了可以据此进行迭代的具体依据。词与词的权重关系在同一个大模型内部是一致的，如果不切换权重分布，更换大模型的话。且不说切换只是从一个权重换到另一个权重，类似两个三观不合的人吵架，根本吵不到点上。我们确实需要一个客观的方法来指导模型让它知道什么是好的，也就是设计约束。突破瓶颈为了突破瓶颈，我们需要为任务设计