Anthropic：关于Harness设计

这是一个应该让每个AI工程师感到不安的故事。

Anthropic的工程团队要求单个Claude实例构建一个复古游戏制作器。没有智能体Harness。没有编排。没有护栏。只是一个有能力的模型指向一个复杂任务。二十分钟后，花费9美元，他们得到了结果：损坏的输出。到处都是存根。不完整的特性。那种模型在你发现一半函数都是占位符注释之前宣布"完成"的代码。

模型并不困惑。它没有挣扎。它自信地报告成功。

现在这里是改变你对LLM编排看法的部分。

相同的模型。相同的任务。不同的架构。这次有一个结构化的Harness，围绕着问题包装了三个专门的智能体：规划器、生成器和评估器。六小时后，花费200美元，他们有了一个完全可用的复古游戏制作器，包含多种游戏类型，所有特性都正常工作，准备交付。

贵了二十二倍。长了十八倍。这是无法使用的垃圾和生产级软件之间的区别。

让这个想法沉淀一下。

9美元的运行并没有产生劣质软件。它产生了在任何有意义的层面上都不存在的软件。你无法交付它、修复它或从中学习。你花在阅读它自信的"完成"响应上的每一小时都是浪费的一小时。一旦你计算发现失败和重新开始的时间，9美元方法的实际成本不是9美元。它是9美元加上所有发现时间加上重启成本。

200美元的运行产生了可以交付的东西。将其与相同工作的开发人员时间进行比较。以任何合理的咨询费率，构建和测试一个多游戏应用程序需要多个开发人员日。Harness以200美元自主地花了六小时完成。那不是昂贵。那是高效。

这篇论文没有这样表述，但这些数字值得直言不讳：便宜的方法无限昂贵，因为它的输出价值为零。

1、为什么朴素智能体会失败

在单次智能体尝试复杂任务时，实际上出了什么问题？

该论文识别了两种基本的AI智能体失败模式。两者都是结构性的，而不是基于能力的。理解它们会改变你设计任何运行超过几个提示-响应周期的系统的方式。

1.1 上下文焦虑

第一种失败模式是Anthropic称之为"上下文焦虑"，一旦你看到它，你就无法忽视它。

想象一个学生参加三小时的考试。第一个小时，他们认真工作。彻底的答案，清晰的推理，展示他们的工作。但大约在两小时的时候，他们开始看时钟。剩余的问题堆积起来。他们的答案变得更短。在最后三十分钟，他们在草拟要点并跳过整个部分，试图在时间用完之前为每个问题写下一些东西。

LLM做完全相同的事情。随着上下文窗口填满，模型产生一种紧迫感。他们开始走捷径。完整实现变成存根。详细文档变成"TODO:稍后添加文档"。模型没有失去能力。它是对剩余上下文失去耐心，急于结束。

随着上下文窗口填满……（AI智能体形成）一种紧迫感。他们开始走捷径。完整实现变成存根。详细文档变成TODO：稍后添加文档。

这不是你可以通过更好的提示修复的bug。你可以告诉模型"不要急"，想怎么告诉都行。这种行为是结构性的。它源于模型与其自身上下文窗口的关系，并且随着任务变得更加复杂而恶化。像Sonnet 4.5这样的较小模型比Opus表现得更激烈，但即使是最有能力的模型在足够长的任务上也会表现出这种行为。

实际后果是残酷的。复杂应用最重要的部分——集成点、边缘情况、润色——往往在开发序列中排在最后。而"最后"正是上下文焦虑打击最猛烈的时候。

1.2 自我评估偏见

第二种失败模式更微妙，而且可以说更危险。

当你要求模型评估它刚刚产生的工作时，即使质量明显平庸，它也会自信地赞扬该工作。这不是模型在撒谎。而是模型看到它打算写的而不是它实际写的。使人类难以校对自己写作的相同认知捷径适用于评估自己代码的LLM。

想想当模型生成存根函数时会发生什么。模型"知道"该函数应该做什么。当它审查自己的输出时，它读取存根并在心理上填补空白。"哦，是的，那处理用户认证流程。"不，它没有。它是三行占位符代码。但生成器对其意思构建的心理模型泄漏到其评估中。

这产生了一个复合问题。每个错过问题的评估周期意味着下一个生成周期建立在一个有未检测错误的基础之上。在长时间运行的任务中，这些无声的失败累积起来，直到最终输出充满模型自己看不到的问题，即使直接询问也无法诚实地报告。

这里有一个Anthropic团队利用的重要不对称性。使模型可靠地自我批评非常困难。使单独的模型对别人的工作持怀疑态度要容易得多。对外部输出的怀疑是LLM比对自己输出的怀疑更自然的模式。这种不对称性是驱动整个智能体Harness架构的关键洞见。

2、每个Harness组件编码一个假设

在深入研究架构本身之前，有一个原则值得清楚地确立，因为它会改变你阅读后面所有内容的方式。

你添加到智能体Harness的每个组件都是关于特定模型限制的断言。

Anthropic的Harness设计论文——作为编码假设的脚手架

冲刺边界断言："这个模型无法在长上下文中保持质量。"外部评估器断言："这个模型无法客观判断自己的输出。"单独的规划器断言："这个模型无法在同一上下文中持有战略规划和战术执行而不使一个退化。"

这不是一个微妙的点。它是Harness设计的组织原则。

当你添加一个没有识别其解决的具体限制的组件时，你是在没有假设的情况下增加复杂性。当模型改进且限制缩小时，解决旧限制的组件变成死重。它们增加延迟、提高成本，并约束模型使用它现在拥有的能力。适用于Opus 4.5的Harness在应用于Opus 4.6时是积极有害的。

将你的Harness组件视为关于你模型的可证伪声明的动态列表。一些声明将被未来的模型发布证伪。其他将持续比你预期的更长时间。纪律在于知道哪个是哪个，并据此设计。

这个原则出现在论文的每个部分。规划器存在是因为"无计划地生成和执行"是一种已知的失败模式。冲刺存在于Opus 4.5时代是因为上下文管理是一种已知的限制。评估器存在是因为自我评估是一种已知的盲点。每个组件都有一个理由，每个理由最终都可能过期。

3、GAN启发的多智能体架构

如果你花时间在机器学习上，Anthropic选择的解决方案会感觉熟悉。它借用了生成对抗网络（将它们视为一个伪造者和一个侦探在军备竞赛中）的核心直觉：一个智能体创造，另一个智能体批评，它们之间的张力推动质量上升。

Anthropic的版本添加了第三个角色。GAN有两个角色（生成器和判别器），这个多智能体架构有三个：规划器、生成器和评估器。规划器的添加反映了GAN不需要处理的东西：软件开发在战术执行之前需要战略分解。

3.1 对GAN类比的诚实看法

GAN框架作为直觉是有用的。它不是一个精确的技术类比，值得明确说明它在哪里成立以及在哪里崩溃。

GAN在训练期间使用反向传播来更新两个网络。生成器和判别器根据彼此的输出字面调整它们的权重。LLM智能体不这样做。生成器不会以任何持久的方式从评估器学习。它在会话中纳入自然语言反馈，但它的权重不会改变。

GAN在训练期间同时运行两个网络，在紧密的反馈循环中。这里的智能体管道是顺序的：规划器传递给生成器，生成器传递给评估器，评估器将反馈发送回生成器。没有同时的共同进化。

GAN中的对抗动态在数学上是精确的。这里的生成器和评估器之间的"对抗"关系更像是在挑剔的校长监督下的彻底代码审查。评估器不是试图将生成器暴露为欺诈。它试图找到生成器遗漏的差距。

那么为什么要使用GAN类比？因为核心直觉转移得很清楚：将创造与判断分离，并在张力中运行它们，比将它们结合在单个过程中产生更好的输出。无论实现差异如何，那个洞见都是真实的。只是不要让这个类比导致你期望GAN式的收敛保证或训练动态。

3.2 三个角色

规划器读取一个简短的提示，通常只有一到四句话，并将其扩展成结构化的规范。它将工作分解成离散的任务，定义成功标准，并创建其他智能体遵循的路线图。关键是，规划器在自己的上下文中运行。它不忙于实现细节。它的整个认知预算都用于战略分解。

DAW实验中的规划器阶段成本0.46美元，耗时4.7分钟。在计算术语中几乎不算什么。但价值是巨大的：它给生成器一个清晰、结构化的计划而不是模糊的提示，并给评估器具体的评分标准。

生成器接收来自规划器的任务并构建。它的上下文完全用于实现。它不担心整体架构是否有意义（规划器处理了）或输出是否符合质量标准（评估器会检查）。这种关注点分离让生成器将其完整的上下文窗口集中在困难的部分：编写可工作的代码。

评估器是架构真正新颖的地方。它不只是读取生成器的代码。它运行应用程序。使用Playwright MCP（一个作为模型上下文协议服务器暴露的浏览器自动化工具），评估器启动构建的应用程序，点击UI，填写表单，检查控制台错误，截屏，并根据规划器的标准评分输出。

这与代码审查根本不同。代码审查可能会查看React组件并说"是的，这渲染了一个表单"。评估器实际上打开表单，输入数据，点击提交，并检查响应是否有意义。它捕获在代码中看起来不错但在实践中失败的运行时bug、视觉故障和损坏的导航流程。

3.3 反馈循环

交互模式是这样的：

1. 规划器创建任务列表并定义评估标准
2. 生成器完成任务，构建特性
3. 评估器根据标准测试实时应用程序
4. 如果任何标准失败，评估器向生成器发送具体的结构化反馈
5. 生成器根据该反馈进行修订
6. 步骤3到5重复，直到所有标准通过

这个循环是质量的引擎。每次迭代都收紧输出。因为评估器是一个有自己上下文的单独智能体，它不会继承困扰试图判断自己工作的生成器的自我评估偏见。

3.4 评估器的秘密武器：实时应用测试

评估器值得更仔细地看，因为它代表了智能体Harness架构中最实用的新颖元素。

大多数多智能体系统在代码级别评估。读取生成的代码，检查明显问题，也许运行linter或类型检查器。这捕获语法错误和简单的逻辑错误，但它错过了只在运行时出现的整个类别的bug。

Anthropic的Harness中的评估器使用Playwright MCP与应用程序交互，就像真实用户会做的那样。它打开浏览器，导航到正在运行的应用程序，并执行真实交互。点击这个按钮。填写这个表单。向下滚动。检查布局是否正确。查找控制台错误。验证导航流程是否有意义。

对于前端设计案例研究，评估器根据形成冲刺合同的四个标准评分：

1. 设计质量：视觉吸引力、布局连贯性、排版、情绪和身份
2. 原创性：定制设计决策与通用AI生成模式的对比（明确惩罚论文称之为"AI slop"的东西）
3. 工艺：排版细节、间距、色彩和谐、微交互、对润色的关注
4. 功能性：它真的有用吗？没有损坏的链接，没有控制台错误，没有死胡同导航

每个标准独立评分，所有四个必须通过才能推进冲刺。这很重要。一个美观但有损坏导航的设计失败。一个功能正常但有通用千篇一律样式的应用程序失败。多维评估防止生成器以牺牲其他维度为代价优化一个维度。

荷兰博物馆案例研究是这个评估循环产生的结果最生动的例子。生成器的第一次尝试是一个标准的深色主题落地页。能干但不引人注目。评估器在原创性上反击。生成器修订。评估器在工艺上反击。生成器再次修订。到第10次迭代时，网站已经演变成一个空间体验：一个带有CSS透视渲染的方格地板的3D房间，带有基于门口的展厅间导航。

没有单次生成会产生那个。它产生于"构建某物"和"这不够好"之间的对抗张力。

4、案例研究：复古游戏制作器

该论文最引人注目的证据是复古游戏制作器任务的对比。

4.1 单独尝试

单个Claude实例，没有编排，没有评估Harness。只有模型和一个提示。

• 成本：9美元
• 时间：20分钟
• 结果：损坏

单独智能体开始很强。早期函数实现良好，代码干净。但随着任务变得更加复杂，经典的上下文焦虑模式出现了。特性开始被存根出去。"完整"函数变成占位符注释。集成点被完全跳过。到模型宣布完成时，应用程序的很大一部分无法运行。

模型认为它已经完成工作。这是自我评估偏见在起作用。模型有一个盲点。它的上下文中有完整游戏制作器的心理模型，即使实际代码充满差距。它自信地报告成功，因为从它自己的上下文内部，成功看起来是合理的。

4.2 Harness尝试

相同任务，通过完整的规划器/生成器/评估器管道运行。

• 成本：200美元
• 时间：6小时
• 结果：完全可用的复古游戏制作器，包含多种游戏类型

规划器将游戏制作器分解成离散的特性。生成器构建每个特性。评估器通过实际运行游戏来测试每个：点击菜单，验证游戏逻辑是否工作，检查精灵是否正确渲染。当评估器发现存根或损坏的特性时，这些问题带着具体反馈返回给生成器。

4.3 数字实际意味着什么

9美元对200美元的比较听起来像是简单的成本权衡。它不是。它是零价值和真实价值之间的比较。

9美元的尝试产生了损坏的软件。你无法交付它。你无法挽救它。存根和差距如此普遍，修复它们的成本超过重新开始。如果你花一小时评估输出，那小时有负价值：你现在知道你浪费了它，你仍然必须重启。加上发现时间、上下文切换成本和重启本身，"便宜"的方法不是9美元。它是9美元加上失败造成的任何损害。

200美元的尝试产生了可以交付的东西。重要的比较不是9美元对200美元。它是：交付价值的成本是多少？对于单独智能体，每单位工作软件的成本是无限的，因为没有工作软件。对于Harness，它是200美元一个已交付的应用程序。

5、案例研究：Opus 4.6的DAW

数字音频工作站实验很重要，因为它用更新的、更有能力的模型测试智能体Harness架构。

Opus 4.6（大约2026年2月发布）相比Opus 4.5带来了显著改进：1M token上下文窗口（从200K增加），128K最大输出（从64K翻倍），以及在智能体基准测试上显著更好的性能。如果Harness架构只是在补偿弱模型能力，Opus 4.6应该使它变得不必要。

它没有。

• 成本：124.70美元
• 时间：3小时50分钟
• 结果：带有AI作曲功能的可用DAW

成本分解讲述了一个有趣的故事。规划器成本0.46美元，耗时4.7分钟。实际上免费。构建阶段在约3小时20分钟内消耗了约113.85美元。评估和质量保证轮次增加了约10到11美元，耗时约25分钟。

即使有了Opus 4.6的改进，评估器仍然发现了真正的问题。生成器标记为"完整"的存根。生成器自我评估忽略的缺失特性。单独看起来正常但连接时失败的组件之间的集成bug。

这是重要的验证。Harness不是弱模型的拐杖。它解决了单智能体生成的结构性限制，这种限制随着模型变得更有能力而持续存在。生成器无法客观评估自己的工作。这不是一个会随着规模缩小的能力差距。它是生成如何运作的基本特征，并且没有随着规模或改进训练而消失的迹象。

6、Harness进化：作为假设的脚手架

这是论文中在智力上最有趣的部分，也是将它与典型的"这是我们的架构"博客文章区分开来的部分。

应用前面确立的原则：每个Harness组件编码一个关于模型限制的假设。随着模型改进和假设被证伪，相应的组件应该被移除，而不是保留。

这是违反直觉的。大多数工程文化默认"如果有效，就保留它"。但在智能体AI中，保留解决已经解决的限制的脚手架会损害性能。它增加延迟、提高成本，并约束模型使用它现在拥有的能力。

6.1 从Opus 4.5到Opus 4.6的变化

冲刺被移除。使用Opus 4.5时，生成器需要刚性的冲刺边界。工作被分解成小块，每个之间有强制的上下文重置。这是必要的，因为Opus 4.5的200K上下文窗口在复杂任务上很快填满，触发上下文焦虑。Opus 4.6的1M上下文窗口和自动压缩使这变得不必要。生成器可以在连续会话中工作，在内部处理上下文管理。假设"这个模型无法在长上下文中保持质量"被证伪。冲刺脚手架被移除。

规划变得灵活。使用Opus 4.5时，规划器需要创建高度详细、刚性的任务序列。如果情况变化，生成器无法适应。使用Opus 4.6时，规划器可以更像向导而不是独裁者那样运作。生成器可以在实施过程中做出战术决策而不失去战略线索。假设"这个模型无法在执行期间适应计划"被部分证伪。刚性度被调低。

评估器持续存在。这是关键发现。即使Opus 4.6在各方面都有改进，外部评估仍然是必不可少的。模型仍然无法可靠地评估自己的工作。自我评估偏见没有随着模型能力而改善。假设"这个模型无法客观判断自己的输出"仍未被证伪。评估器保留。

6.2 为移除而设计

这个分析指向一个具体的设计实践：构建你的Harness组件以便它们可以被关闭。

如果你今天添加冲刺边界，使它们可配置。如果你添加刚性规划，使刚性成为参数而不是常数。如果你添加冗余验证步骤，将它们隔离以便可以被绕过。

当下一个模型发布带着改进的能力到来时，你想通过改变配置值来简化你的Harness，而不是重写你的架构。编码假设的组件应该像假设本身一样模块化。

6.3 一个值得认真对待的反驳

并非所有人都同意更多的Harness复杂性总是更好。苏黎世联邦理工学院的一项研究（arXiv:2602.11988）发现，智能体系统的LLM生成配置文件实际上损害了性能，同时将token成本增加了20%或更多。人工编写的配置仅显示约4%的改进。该研究的启示：脚手架有收益递减，设计不良的脚手架比根本没有更糟。

这并不与Anthropic的发现相矛盾。论文中描述的Harness是围绕特定的、经过验证的失败模式精心设计的，每个都有清晰的假设。但它对每当出问题就添加更多智能体的本能是有用的检查。价值来自用有针对性的组件解决特定的结构性限制。没有明确标准的复杂性增加产生开销而没有收益。

纪律不是"添加Harness组件"。而是"识别特定的失败模式，假设解决它的组件，衡量它是否有帮助，并准备在模型改进超过它时移除它"。

7、工程师今天的实用要点

Anthropic的Harness设计论文——Harness工程的实用要点

如果你现在正在构建智能体系统，以下是你可以从这篇论文中获得的。

7.1 首先构建评估器

如果你只构建一个Harness组件，构建外部评估。这是你能做的最高杠杆干预。

你不需要完整的规划器/生成器/评估器管道就能从中受益。即使是一个简单的设置，一个模型生成，另一个模型审查，也能提供显著的质量改进。关键约束是分离上下文。评估智能体必须与生成智能体不共享上下文。如果它们共享对话，评估器继承生成器的假设和偏见。单独的过程，单独的上下文，单独的系统提示。

对于任何质量重要的任务，将生成与评估分开。这个单一的结构决策解决了论文中最持久的失败模式。

7.2 在干净的上下文中运行规划

即使在更简单的设置中，在执行开始前在不同的上下文中运行规划阶段也有帮助。规划器不需要是一个完整的智能体。它可以是一个单独的提示，接收你的需求并输出结构化的任务列表。价值来自于在执行上下文填满实现细节之前进行战略思考。

规划输出也给你的评估器一些具体可评分的东西。没有计划，评估退化为"这看起来好吗？"有计划，评估变成"这符合标准1、2和3吗？"这种具体性是使评估循环有用而不是循环的原因。

7.3 知道你的Harness编码了哪些假设

对于你的智能体Harness中的每个组件，写下它背后的假设。"冲刺边界：假设模型在N个token上下文后退化。""冗余验证：假设模型在第一次传递时错过边缘情况。""刚性规划：假设模型无法在执行期间适应。"

这迫使你清晰，并为每个模型发布创建审查清单。当新模型出来时，检查你的假设列表。新模型证伪了哪些假设？移除相应的组件。哪些仍然成立？保留它们。这个实践防止你的Harness积累曾经有道理的脚手架。

7.4 多维度评估

前端案例研究中的四标准框架——设计质量、原创性、工艺和功能性——是一个模板，不是特定于前端的工具。

原则是：定义独立的质量维度并要求所有维度通过。这防止生成器以牺牲其他维度为代价优化最简单的维度。如果视觉质量是唯一被评估的东西，模型自然会产生视觉上令人印象深刻但损坏的软件。

对于后端工作，你的四个标准可能是正确性、性能、错误处理和API设计质量。对于数据管道：准确性、延迟、弹性和可观察性覆盖。具体标准会改变。多维度评估的原则与独立通过/失败阈值保持不变。

7.5 诚实地为自主工作定价

200美元的六小时Harness运行并不昂贵。但它也不是9美元。为可靠的自主工作的实际成本做预算，而不是单个提示的成本。

在实践中，这意味着习惯于迭代成本。每个发现问题并将生成器送回修复的评估循环都会增加token、时间和金钱。这种开销不是浪费。它是产生工作软件的机制。具有零评估循环的自主任务要么非常幸运，要么产生了尚未被测试的东西。

对于规划目的：假设Harness质量结果的成本大约是天真的单次尝试的10到25倍。随着模型改进，这个倍数可能会缩小。它不会消失。

7.6 主动管理上下文

无论是通过上下文重置（Opus 4.5方法）还是自动压缩（Opus 4.6方法），主动管理上下文窗口使用对于长时间运行的任务都是必不可少的。

不要假设模型会处理它。监控上下文使用。当上下文填满时有一个策略。对于没有自动压缩的模型，计划明确的重置点。对于有更大上下文窗口的模型，在移除重置逻辑之前，测试你的任务长度是否仍然出现上下文焦虑。

上下文窗口更大并不意味着问题消失了。它意味着阈值移动了。知道你的模型和你的任务复杂度的阈值在哪里。

7.7 信任的架构

放大到足够远，Harness设计论文实际上是关于信任边界。

你可以在哪里信任模型？你可以信任它生成代码、遵循计划并纳入特定反馈。这些是模型在定义的约束内运作并产生被外部验证的输出的任务。

你可以在哪里不能信任模型？你不能信任它判断自己的工作。你不能信任它在上下文填满时保持质量。你不能信任它诚实地报告它何时走了捷径。模型不会故意对你撒谎。但它会告诉你存根完成了，因为从它的上下文内部，存根看起来完成了。

智能体Harness在这些信任限制周围绘制边界。评估器存在是因为你不能信任自我评估。规划器存在是因为战略和战术思考争夺上下文空间。冲刺边界，在需要时，存在是因为上下文焦虑悄悄地降低质量。

随着模型改进，信任边界扩展，Harness简化。Opus 4.6在上下文管理上赢得了足够的信任，以至于冲刺可以被移除。未来的模型可能在自我评估上赢得足够的信任，以至于外部评估简化。但基于目前的轨迹，生成器不应该给自己作业打分的原则看起来会持续一段时间。

对于今天构建智能体系统的工程师，这里是核心要点：你的脚手架是临时的，但你的评估策略不是。

你添加的每个组件都是关于当前一代模型不能可靠地做什么的声明。追踪这些声明。针对每个新模型发布测试它们。移除不再适用的。保留仍然成立的。

原文链接: The $9 Disaster: What Anthropic's Harness Design Paper Teaches Us About Building Autonomous AI

汇智网翻译整理，转载请标明出处