OpenAI Anthropic Harness 之争：更强模型，相反的工程押注

OpenAI 的工程师重新点燃了与 Anthropic 一场影响深远的争论：更强的 AI 模型应当需要更轻量的 harness，但高难度任务依然会从更严密的监督中受益。

这场 OpenAI Anthropic harness 之争，并不只是关于提示词或界面偏好。它关乎模型外围的软件系统，包括工具、记忆、权限、规划、评估以及人工审批。

OpenAI 认为，过度的脚手架可能会固化下一代模型已不再具备的局限。Anthropic 最近的实验则得出了更具条件性的结论：更好的模型确实减少了部分编排需求，但当任务逼近模型能力边界时，规划器和独立评估器依然很有价值。

这场分歧影响的不只是 Codex 和 Claude Code。企业正在将通用模型转变为能够编辑代码库、操作浏览器、分析文档及协调长期项目的智能体。每增加一项控制都可能提升可靠性，但也会增加延迟、复杂度，以及一项可能过时的假设。

因此，核心问题并不是 harness 是否重要。两家公司的工程实践都表明，它确实重要。问题在于，进步究竟会将价值转移到模型中、转移到 harness 中，还是会在两层之间反复流动。

OpenAI 和 Anthropic 实际上改变了什么

两家公司如今都将 agent harness 视为决定产品特性的关键层，但对于这一层应包含多少智能，它们意见不一。

agent harness 是将模型与工具、上下文、记忆、反馈循环和用户控制连接起来的运行时系统。模型生成决策；harness 决定模型能看到哪些信息、可采取哪些操作，以及如何捕捉错误。

OpenAI 的立场在 8 月有关其将智能体扩展至软件开发以外领域的报道中体现得很清楚。其工程师表示，好的 harness engineering 是为模型提供所需的精确工具和信息，而不让它被不必要的规则包围。

工程师 Nick Gershenson 告诉 TechCrunch，复杂的条件逻辑和工具组合能带来短期收益。不过，他认为新模型可能会在数月内让这些附加设计过时。他更倾向于克制的界面，让有能力的模型自行解决更多问题。

这一原则呼应了 苦涩的教训：这是 Rich Sutton 提出的一个颇具影响力的观点，即通用计算最终会胜过围绕大量人类知识构建的系统。将其应用于智能体时，这一教训更支持广泛通用的模型，而非针对每种预期失败模式手工设计工作流。

OpenAI 并未放弃 harness engineering。其关于 Codex engineering 的说明将代码库、文档、测试、反馈循环和机器可读计划列为关键基础设施。该公司称，在一个内部项目中，平均每名工程师每天提交 3.5 个 pull request。

区别在于 OpenAI 希望复杂性存在于何处。其工程师更青睐易于理解的环境和清晰反馈，而不是不断加码、规定模型必须如何推理的复杂分支。

Anthropic 3 月 24 日的研究则提出了另一种压力测试。研究员 Prithvi Rajasekaran 使用规划器、生成器和评估器，在长时间自主运行中构建完整应用。

规划器将简短请求转化为结构化规格说明；生成器实施该计划；评估器操作应用、检查约定标准，并返回待修复的缺陷。

Anthropic 的初步对比发现，单智能体运行生成的应用，其核心玩法功能无法正常工作。多智能体 harness 则交付了更完整、可运行的结果，尽管仍存在缺陷。

这并不意味着更重的方案总会胜出。随后，当 Claude Opus 4.6 能够更连贯地处理更长周期的工作时，Anthropic 移除了 sprint 级任务分解。不过，规划器和评估器仍持续发现缺失或流于表面的功能。

因此，这一事件既体现了趋同，也揭示了分歧。OpenAI 和 Anthropic 都会在模型吸收旧有职责后简化 harness。不同之处在于，开发者应以多快速度相信这种能力转移。

为什么 OpenAI Anthropic Harness 之争此刻重要

压力来自智能体正从边界清晰的编程任务，走向成功更难定义、失败更难逆转的工作。

编程为智能体提供了第一个有利环境。代码库包含结构化文件，编译器会暴露错误，测试通常能给出明确的通过或失败信号。harness 可以将这些信号转化为模型的下一次尝试。

通用知识工作提供的可靠检查更少。一份战略备忘录可能表面连贯，却建立在薄弱假设之上。一份电子表格可能计算正确，却回答了错误的业务问题。智能体可能完成了一份精美演示文稿，却没有意识到证据已经过时。

OpenAI 正将其智能体方法延伸到这些结构较弱的场景。这一举动要求公司在保留强模型所带来的简洁性的同时，加入普通用户所需要的控制机制。

Anthropic 则面临相反的压力。Claude Code 的吸引力很大程度上来自可见的进度、频繁互动和用户参与。这种方式可能让人更安心，但反复提问和审批会增加操作者的工作量。

这场竞争反映了两种产品直觉。OpenAI 经常追求的是：用户交办一个目标，然后收到完成的结果。Anthropic 通常则通过计划、备选方案和权限请求，呈现更多中间推理过程。

没有哪一种直觉在所有场景下都更好。当目标明确、验证成本低时，自主性很有吸引力；当偏好未被说明或后果难以衡量时，协作就更有价值。

这也解释了，为什么相同模型在不同界面中会呈现出不同的表面质量。harness 控制上下文选择、工具描述、重试行为、文件访问以及用户介入的时机。这些决定塑造了模型采取的每一个行动。

独立框架构建者也观察到了同样的依赖关系。LangChain 报告称，与默认配置相比，针对不同模型的 harness profiles 在 tau2-bench 的一个子集上带来了 10 到 20 分的提升。其 harness profiles 会针对不同模型行为调整提示词、工具和中间件。

这一结果挑战了 OpenAI 论点的一种简单版本。若 harness 只是临时拐杖，那么在底层模型保持不变时，修改 harness 不应产生如此显著的性能差异。

不过，它也支持 OpenAI 对不必要抽象的批评。LangChain 并未找到一种对所有模型都有效、且日益复杂的统一架构。它发现，不同模型对不同配置的响应不同。

实际压力落在产品团队身上。他们必须决定，是为单一供应商进行深度优化，还是在多种模型之间维持可移植层。

深度优化可以带来更好的即时结果，但也可能造成对供应商特定工具、提示词和上下文行为的依赖。可移植性能够限制这种依赖，但通用 harness 也可能无法充分利用模型能力。

随着智能体获得更广泛的权限，这些选择会变得更加重要。一个建议补丁的编程助手，角色边界仍较清晰；一个能够阅读通信内容、编辑共享文档并触发业务系统的智能体，则跨越了多重信任边界。

因此，评估这些产品的团队不应只看模型基准。他们需要了解在真实权限、数据和失败条件下，完整模型与 harness 组合的表现证据。

OpenAI 希望模型主导

OpenAI 的轻量 harness 观点认为，开发者应清晰地呈现环境，随后让模型承担大部分自适应行为。

这一立场并不意味着移除测试、权限或上下文管理。它意味着应抵制那些为弥补预计将消失的局限而构建的、手工设计的推理流程。

OpenAI 在首个 Codex web application 上的经历，有助于解释这一信念。该公司最初押注于让模型在用户极少参与的情况下完成任务。Anthropic 更具互动性的 Claude Code 方法，则被证明更符合当时模型能够可靠完成的工作。

OpenAI 后来增加了更多让用户引导 Codex 的机会。一名工程师承认，早期产品走在了其模型和 harness 能力的前面。

这段历史之所以重要，是因为它展现了两方面的风险。harness 可能包含过多僵化逻辑；它也可能高估用户实际获得的模型能力。

OpenAI 当前的方法试图通过更清晰的环境和更强的反馈，避免再次出现这种错配。其内部工程说明强调了结构化文档、代码库规则、计划和自动化检查。

这些要素比规定每一步推理的工作流更轻量，但它们依然代表了大量工程工作。harness 将判断交给模型，同时让成功更容易被检验。

这一方法也符合 OpenAI 的产品雄心。一个通用职场智能体无法依赖设计师预测用户可能提出的每一种操作序列，潜在任务空间实在过于广阔。

当条件发生变化时，以模型为主导的系统可以选择工具并修订计划。当用户在同一项任务中从研究切换到电子表格、消息、代码和演示文稿时，这种灵活性颇具吸引力。

然而，极简 harness 会将更多责任转移到模型身上。模型必须察觉歧义、索取缺失信息，并识别何时一项操作值得确认。

这些行为并不会仅凭通用能力自动得到保证。模型可能更擅长执行指令，却未必同样更擅长识别存在缺陷的目标。

用户体验进一步放大了这种风险。研究职场 AI 的沃顿商学院教授 Ethan Mollick 曾对比过两类系统：一类立即尝试完成工作，另一类则展示比较结果并请求反馈。

当智能体正确理解目标时，更自主的设计能减少摩擦；但当它理解错误时，用户可能只有在一长串看似连贯、实则偏离方向的工作完成后，才会发现问题。

这使上下文质量成为核心。轻量 harness 在提供简洁、相关且最新的信息时效果最佳。即使模型支持长上下文窗口，大量未经筛选的上下文也可能淹没重点。

对于知识工作者而言，组织这些证据仍然是一个独立的工程问题。一个可搜索的 知识库 可以在智能体开始行动前减少检索噪声。

OpenAI 的论点在机器反馈密集的任务中最具说服力。编译器、测试套件、linter 和浏览器检查能让智能体在无需持续人工判断的情况下评估进展。

当完成依赖于品味、组织历史或未被记录的预期时，它就会变得更弱。模型无法推断从未进入其上下文的证据。

因此，OpenAI 正在进行一场经过权衡的押注。随着模型不断进步，它们将能在内部承担更多规划与恢复工作。Harness 设计者应当保留通用性，而不是把昨天的模型局限固化进明天的产品。

Anthropic 表示，更艰巨的工作仍需要更多结构

Anthropic 关于更重型 harness 的证据表明，更强的模型并不会消除编排需求；它们只是将其有效边界推向更困难的任务。

Anthropic 的长时间运行 harness源于两项反复出现的弱点：模型会在长时间工作中失去连贯性，并且对自身产出的评价过于宽松。

第一个问题涉及上下文。长任务会不断积累决策、工具结果、错误与部分实现。即使上下文窗口足以容纳这些内容，其组织方式仍会影响模型能注意到什么。

Anthropic 使用了带有结构化交接文件的上下文重置。重置可为新的 agent 会话提供干净的工作状态，同时保留关键进展和后续步骤。

第二个问题是自我评估。生成应用的同一模型往往会接受质量较弱的结果，尤其当质量取决于设计判断时更是如此。

Anthropic 将创作与审查分开。其评估器采用明确标准和浏览器自动化来测试功能。生成器接收具体发现后尝试修复。

第一个完整 harness 将一句话的游戏需求扩展为十个 sprint 中的 16 项功能。评估器对每个 sprint 应用详细契约，其中一个关卡编辑器阶段就包含 27 项标准。

Anthropic 报告称，多 agent 结果提供了单 agent 尝试所缺少的可用核心功能。不过，它也需要显著更多的运行时间、编排工作和模型使用量。

这一权衡使该实验比简单的基准胜利更有价值。它展示了额外结构能带来什么，也揭示了为何团队不能不加选择地增加评估器。

随后，Anthropic 使用更强的模型重复了这一过程。Opus 4.6 在没有此前 sprint 拆分的情况下，持续进行了两个多小时主要构建工作。

这印证了 OpenAI 的核心观察：此前由 harness 提供的一项能力已经转移到模型内部，使得部分脚手架不再必要。

评估器仍发现了影响重大的缺口。它识别出一些核心音频功能仅以浅层界面元素或占位符形式存在。随后，生成器解决了其中若干遗漏。

Anthropic 的结论并不是每项任务都需要三个 agent。评估器在工作处于生成器可可靠完成能力边界附近时，能产生最大价值。

这一边界是动态的。一次模型发布会将其向外推移；而更高要求的任务又会将其重新向内拉回。

这带来了对“苦涩教训”的另一种解读。通用模型会取代为昨天的问题手工打造的解决方案，但也会让此前不切实际的目标变得可达。

一旦团队尝试实现这些目标，新的失效模式就会出现。Harness 并不会消失；它会跟随能力前沿移动。

Anthropic 的立场还承认，评估本身是产品的一部分。一个能生成更多输出的系统并不自动更有用。必须有人或某种机制来判断这些输出是否满足实际需求。

对于开发者而言，测试套件可以承担很大一部分判断工作。对于设计、研究和管理工作，标准往往必须在 agent 行动前就明确说明。

规划器—评估器架构会将这些预期显性化，但也可能放大糟糕的标准。评估器会执行其收到的可衡量代理指标，即便这些指标遗漏了用户真正重视的内容。

因此，更重型的 harness 也会带来自身的治理问题。更多组件意味着需要维护更多提示词、权限、日志、交接以及失效路径。

Anthropic 的证据支持选择性结构，而非永久性复杂化。移除更强模型如今能处理的部分，然后将工程投入重新用于验证仍能带来显著收益的地方。

模型与 Harness 之争仍未有定论

任何一方都尚未证明，其偏好的架构能在不同模型、任务、预算和风险水平下全面胜出。

OpenAI 与 Anthropic 围绕 harness 的争论，很大程度依赖内部实验和产品观察。这些来源揭示了工程选择，但并未提供 Codex 与 Claude Code 之间的受控比较。

OpenAI 的论述反映了其自身模型、代码库和团队实践。Anthropic 的案例则使用 Claude 模型处理经过挑选的应用构建任务。两家公司都选择了各自的环境与成功标准。

即使 Anthropic 的详细比较也同时改变了多个变量。完整系统加入了规划、评估、拆分、更长执行时间和更多模型调用。结果无法孤立说明每个组件分别带来了哪些改进。

该公司后来使用组件移除来理解这个问题。但其结论仍来自少量演示，而非广泛、独立的复现。

第三方基准有所帮助，但也会引入额外复杂性。某个 harness 可能表现良好，只是因为基准任务与其偏好的工作流相似。另一种配置则可能优化 token 使用、通过率、延迟或可恢复性。

相同分数也可能掩盖不同的运营风险。一个 agent 可能显著失败并停止；另一个则可能生成看似合理但实际错误的结果，并通过自动检查。

针对生产级编程系统的研究正越来越多地将模型与 harness 视为一个组合单元。最近一项源代码研究考察了 11 种编程 harness，其中包括 Claude Code、Codex CLI、Gemini CLI、Pi、OpenCode 和 OpenHands。

这种多样性削弱了存在单一最优 harness 的观点。这些系统在上下文管理、扩展点、规划、隔离和工具执行方面各不相同，因为其设计者面向不同用户。

可移植性则是另一个尚未解决的问题。有报道引用了一项比较：开源 Pi harness 在使用同一 OpenAI 模型时，表现优于 Codex。

这样的结果表明，模型提供方并不必然能为每项任务构建最佳环境。但这并不能证明 Pi 在广泛场景中胜出，因为基准设置和配置仍起决定性作用。

开放 harness 可以暴露专有产品隐藏的轨迹、token 用量和配置细节。这种透明度有助于团队诊断失败并切换提供方。

由提供方控制的 harness 能更早获得模型特定能力。其开发者可以围绕未公开行为进行调优，并部署协同更新。

商业激励也很重要。OpenAI 和 Anthropic 都会在客户通过其自身界面使用模型时获益。拥有 harness 能强化分发，并可通过存储的上下文、集成和已学习的工作流提高迁移成本。

这并不意味着它们的工程主张是错误的。它意味着客户应将技术证据与平台战略分开看待。

即使不比较公开价格数据，成本仍是另一项不确定因素。多 agent 的规划和评估会消耗额外 token 与时间。当失败成本高昂时，更高的完成率可以证明这些开销是合理的。

常规且可逆的工作则恰恰相反。为每一次微小编辑运行评估器，消耗的资源可能比纠正偶发错误更多。

安全性进一步复杂化了轻量 harness 的论点。更好的模型可以执行更长的行动序列，并更有效地使用工具。这些改进也会加大误解指令的后果。

权限边界、审计日志、沙箱和确认机制都是 harness 功能。更强的能力即使降低了对规划脚手架的需求，也可能提高这些功能的重要性。

因此，团队应拒绝单维度测试。一项有用的评估必须衡量任务完成情况、隐蔽缺陷、人工审查时间、资源消耗以及失败后的恢复能力。

它还应在同一模型下比较不同配置。否则，团队可能会购买更强的模型，而实际只需调整上下文或工具即可解决问题。

目前的证据支持一条条件性原则：使用能满足既定可靠性阈值的最轻量 harness，然后在观察到的失败足以证明其合理性时增加结构。

这条原则听起来像是折中方案，但它带来了要求很高的运营工作。团队需要可重复的评估、轨迹检查和版本化配置，才能知道某个组件何时仍然有用。

缺乏这些证据时，“更轻”就会变成对下一代模型的信念；“更重”则会变成被编码进提示词和工作流分支的累积经验主义。

三个信号将决定哪种方法胜出

下一阶段将由比较性证据决定，而不是由任何一家公司对其架构的偏好性描述决定。

第一个信号是 harness 互换后的表现。研究人员和框架构建者需要进行受控测试，使模型、任务、工具访问和资源限制保持不变。

如果第三方 harness 在使用相同模型时反复优于提供方界面，价值正转向编排。这一结果将削弱“模型进步自然会吸收大部分产品差异化”的信念。

如果精心设计的 harness 之间的性能差异缩小，OpenAI 的论点就会获得支持。这将表明，更强的模型需要更少的专门干预，并可在更简单、标准化的环境中运行。

第二个信号是 Anthropic 和 OpenAI 在每次模型发布后如何简化自身系统。Anthropic 已经通过从 Opus 4.6 工作流中移除 sprint 拆分，展示了这一测试的一种形式。

关注接下来会消失哪些组件。规划、上下文重置、独立评估和频繁审批，各自代表了对模型局限的不同假设。

如果移除某个组件而不降低任务质量，就会强化轻量 harness 的论点。若将该组件转移到更困难的一类工作中，则支持 Anthropic 的动态前沿解读。

第三个信号是软件工程以外的采用情况。编程 agent 受益于代码库、测试和数字化反馈。知识工作则包含更弱的信号和更多隐性偏好。

如果人们无需大量修正便接受已完成的工作，模型主导型 agent 将显得很有说服力。若用户始终需要预览、比较和审批检查点，协作式 harness 则会显得更强。

最有用的采用指标不会是启动任务的数量，而是在考虑人工审查和返工后，正确完成任务的占比。

开发者还应追踪失败的严重程度。一个完成较少任务但能安全停止的 harness，可能优于另一个完成更多任务却会犯下难以察觉错误的系统。

企业买家应要求使用其自身文档、权限和工作流进行评估。公开排行榜无法代表组织特有的正确性定义。

知识工作者也可以采用更简单的版本：从熟悉且可逆的任务开始，将 agent 的结果与既有人工基线进行比较。

记录模型在哪些地方缺少上下文、选择了错误工具或需要主观指导。这些观察将揭示下一项干预应放在指令、检索、审批规则还是独立审查中。

OpenAI 与 Anthropic 围绕 harness 的争论，不会以一家公司选择薄层、另一家公司构建厚层而结束。随着模型和任务变化，双方都已在不断添加或移除组件。

持久的优势将属于那些能够迅速衡量这些变化的团队。他们会知道哪些约束仍在防止失败，哪些只是保留了旧模型时代的假设。

对于任何部署智能体的人而言，眼下的行动很直接：共同测试模型与 harness，检查真实追踪记录，并在授予更广泛自主权之前明确成功标准。更强的模型会改变工程边界，但不会消除识别这一边界的必要性。