26年3月来自阿里公司的论文"Harness Engineering for Language Agents: The Harness Layer as Control, Agency, and Runtime"。
通过工具、文件、浏览器、API 和持久会话执行操作的语言智体，其行为不仅仅取决于基础模型或单一提示。它们的可靠性依赖于一个驾驭Harness层，该层决定了哪些指令仍然有效、哪些操作可用、状态如何传递以及如何随时间推移处理故障。近期的实践已使该层足够清晰可见，值得在自然语言处理（NLP）中进行明确处理。本文提出并实现了harness层的工作分解，将其分解为控制、智体和运行时（CAR）；将harness工程置于从软件工程到提示和上下文工程的整个发展轨迹中；并对选定证据库中的 40 篇与harness相关的作品进行轻量级审计，指出学术论文和公开的工程笔记之间存在可见性差距。其进一步指出，许多已报道的智体性能提升可能部分取决于harness，而非完全由模型驱动，并提出 HARNESSCARD 作为轻量级报告人工品（artifacts），其中包含一个已填写的示例。语言智体的进展不仅应该报告模型，还应该报告将能力转化为受控行动的harness层。
可靠的智体是设计出来的，而非推断出来的。一旦语言模型通过工具、文件、浏览器、API 和持久会话执行操作，其可靠性就取决于一个harness层：这个模型之外的层决定哪些指令仍然有效、哪些操作可用、状态如何外化，以及如何保持多步骤执行的界限性、可恢复性和可检查性。"harness工程"是描述该层工作的恰当名称，语言智体研究应该将其作为一个显式对象进行研究，而不是将其视为隐藏的实现残留。图 1 展示了工程对象的扩展以及对harness层的 CAR 分解。
近期公开的工程笔记使这种转变显得尤为明显。Anthropic 将智体harness（或脚手架scaffolding）定义为使模型能够作为智体运行的系统，并强调评估"智体"意味着同时评估模型和harness，而不是孤立地评估模型（Grace，2026）。OpenAI 使用更广泛的标签"框架工程"来指代那些可靠性依赖于存储库映射、AGENTS.md 文件、架构规则、清理循环和运行时控制，而不仅仅是提示文字的长期系统（Choi，2026；Lopopolo，2026；OpenAI，2026a,b）。Anthropic 长期开展的harness工作和研究系统笔记将同样的理念延伸到编码之外，强调在多会话或多智体工作中状态外化、进度文件、编排和恢复结构的重要性（Hadfield，2025；Young，2025）。综上所述，这些研究成果促成该文工作：harness 是一种额外的模型系统，它将持久控制组件、中介动作接口和运行时策略耦合到一个受控的执行机制中。
然而，其背后的设计问题由来已久。工具使用、浏览器智体、软件智体、编排框架（orchestration framework）、交互式评估、运行时协议和部署说明等方面的研究早已涵盖了同一层面的各个部分，只是没有正式命名（Jimenez et al. 2023; Li et al. 2023; Liu et al. 2023; Schick et al. 2023; Wang et al. 2024a; Xie et al. 2024; Yang et al. 2024; Yao et al. 2022; Zhou et al. 2023）。因此，并非类似 Harness 的机制是全新的。正是由于最近的实践使得这一层面足够清晰可见，因此该领域现在可以受益于对该层进行直接命名、分解和报告。
下表 1 所示公开的理论所阐述的将harness层视为一个独立的系统对象的理由：
从历史角度来看，harness工程并非取代早期围绕模型的工程形式，而是对其进行嵌套。软件工程使该领域关注接口、测试、模块化和操作规范（Naur & Randell，1969）。提示工程将直接干预的范围缩小到指令和示例的设计（Liu，2023）。上下文工程则将范围扩大到智体在每一步中携带的不断演变token状态，包括检索、记忆、工具上下文和历史记录（Rajasekaran，2025）。Harness工程再次扩展了这一范围：不仅包括进入上下文的内容，还包括如何协调行动、如何控制运行时、如何修复故障以及如何维护治理和追踪。因此，提示设计仍然局限于控制层面，上下文设计涵盖了控制和运行时，而harness工程则定义了使智体能够长期保持持久性的耦合层。如表 2 所示按工程问题、典型工件（artifacts）以及每个框架仍未充分描述的内容总结了这种扩展。
这种扩展至关重要，因为即使基础模型和提示信息变化不大，系统也能得到改进，原因可能仅仅是记录系统、重试策略、操作界面、验证循环或恢复结构发生了变化。一旦智体随着时间的推移而行动，科学上有趣的问题就不再仅仅是模型接收到了什么信息，而是哪个harness层帮助保持了其行为的可靠性。
1 标签虽新，设计问题却由来已久
"harness工程"一词近期才出现在人工智能领域的公开讨论中，但其背后的设计问题却已酝酿多年。ReAct 将推理和行动轨迹明确化（Yao，2022）。Toolformer 和 API-Bank 将工具调用和评估转化为具体对象（Li，2023；Schick，2023）。AgentBench、WebArena、GAIA、SWE-bench、BrowseComp 和 OSWorld 则将交互式操作（而非静态文本生成）置于评估的核心（Jimenez，2023；Liu，2023；Mialon，2023；Wei，2025；Xie，2024；Zhou，2023）。 SWE-agent、OpenHands 和 CodeAct 的研究表明，界面设计和动作底层选择会显著影响软件智体的性能（Wang，2024a,b；Yang，2024）。随后，MCP 将工具互操作性本身提升为协议层面的问题，而非特别细节（模型上下文协议MCP，2025）。
通常缺失的并非机制本身，而是一个通用的抽象概念，用于描述将这些元素连接在一起的层面。Anthropic 提供部分词汇，例如智体驾驭（agent harness）和评估驾驭（evaluation harness）（Grace，2026）。OpenAI 随后将更广泛的工程实践明确地命名为驾驭工程（harness engineering）（Lopopolo，2026）。这一命名举措的意义在于方法论层面，而不仅仅是术语层面：它明确定义了一个反复出现的系统对象，其职责涵盖上下文规范、工具协调、运行时控制、验证、治理和追踪等多个方面。
2. 典型公开案例
近期三类公开案例使这一概念更加具体化。首先，OpenAI 的harness工程文档将持久项目指令、架构约束、自定义代码检查器、清理循环和自动化审查视为促使编码智体在长期内生成可维护代码的核心杠杆（Lopopolo 2026）。其次，Anthropic 长期开展的harness工作将状态外化、初始化、进度文件和恢复机制视为实现有效多会话智体的先决条件（Young 2025）。第三，Anthropic 的多智体研究系统和浏览器式评估工作在代码库之外也论证了同样的观点：源代码层级结构、工具访问、并行探索、内存结构和恢复策略可以显著改变研究和浏览环境中的行为（Hadfield et al. 2025; Mialon et al. 2023; Wei et al. 2025; Zhou et al. 2023）。上表1显示，这些材料从不同角度都指向同一个观点：如果想要科学地理解语言智体，就需要对将模型转化为能够行动、恢复和被控制的系统这一"harness层"进行推理。
这也是本文与相关综述的不同之处。近期关于自主智体、多智体系统和智体评估的综述固然有价值，但它们大多将智体、协作模式或基准测试作为分析单元，而非harness层本身（Luo et al. 2025; Piccialli et al. 2025; Wang et al. 2024; Yehudai et al. 2025）。以harness层为中心的视角能够超越这些局限，并有助于解释为什么在模型层面看起来相似的系统在实践中往往表现不同。
上述公开表述仅为建议而非定论。在此基础上，提出本文的一个工作定义。将"驾驭层"（harness layer）定义为模型之外的层，它决定了智体（agent）所看到的内容、能够执行的操作、其工作如何随时间展开、接收到哪些反馈，以及如何约束、观察和评估其行为。"harness工程"则是对该层的设计和维护。在操作层面上，"harness层"协调模型能力和情境化行动：它将模型输出转化为受控执行，并将环境反馈转化为可操作的状态。
将"harness层"简洁地表示为 H = ⟨C, A, R⟩，其中 C 为控制层，A 为智体层，R 为运行时层。用缩写 CAR，因为它明确顺序，并强调了"harness"不仅仅是运行时的底层架构。该符号并非旨在构建一个僵化的本体论。其目的在于解释：它标记三个耦合的功能，而这些功能通常被论文捆绑在一起，却鲜有详细描述。
控制。控制层包含持久化的工件，这些工件在执行步骤之前塑造行为：存储库图、AGENTS.md、工具描述、系统指令、架构规则、测试、代码检查器、权限策略和成功标准（Lopopolo 2026；OpenAI 2026a,b）。换句话说，控制层是将人类判断转化为机器可读约束的地方。一个关键harness洞察是，可靠的智体很少受提示文字的限制；它们通常受规范的限制。
智体。智体层决定了模型被允许如何行动。它包括行动基础，例如代码执行或浏览器交互、规划器-验证器或协调器-工作器结构、审查者角色以及定义行动空间的具体接口（Hadfield et al. 2025；Wang et al. 2024a；Yang et al. 2024）。在这里使用"智体"一词时，指的是狭义的系统意义：harness允许的中介行动表面和委托结构，而不是关于不受限制的自主性或通用能力的声明。
运行时。运行时层控制着工作随时间展开过程中发生的一切：上下文组装、内存和压缩、检查点、重试、回溯、审批流程、预算、跟踪收集和重放支持（Chen 2026；Rajasekaran 2025；Young 2025）。这是长时程行为成功或失败的关键所在。许多智体失败都是运行时失败：过时的状态、脆弱的重试循环、过大的上下文或对中间错误恢复不佳。
两个具体的小例子。首先考虑一个代码库编码智体。两个系统可能共享相同的边界模型和几乎相同的任务提示，但行为却截然不同，因为其中一个harness添加代码库图、根级 AGENTS.md 文件、必需的测试、代码检查器、有界 shell 访问权限、进度文件以及对特权操作的手动审批。CAR 视角解释为什么这些并非无关紧要的细节：映射、测试和审批策略都处于控制之下； shell 和文件编辑界面位于智体层；而进度文件、重试机制和升级逻辑则位于运行时层。所报告的性能部分取决于harness层，而不仅仅是模型本身。现在考虑一个浏览器或研究智体。两个系统可能共享相同的浏览模型和高级任务提示，但由于一个harness定义源层级结构、引用规则、笔记格式、不确定性触发的升级机制、工具配额和可重放的跟踪记录（Hadfield，2025；Mialon，2023；Wei，2025；Zhou，2023），因此它们之间存在差异。这里，控制层包括源权威性和引用策略；智体层包括搜索、浏览器和委托界面；运行时层包括草稿本、分支跟踪记录以及证据冲突时的恢复机制。同样，看似"智体质量"的部分属性取决于模型周围的框架层。
此定义也阐明了harness工程不是什么。它比提示工程的范围更广，因为提示只是更大控制结构中的一个组成部分。它比"智体系统"的范围更窄，因为并非环境的每个属性都属于框架。它与平台工程和 MLOps 有重叠，但更具体地说，它关注的是以语言为中心的模型如何转化为可用智体的层面。harness始于系统主动塑造轨迹之处：精心设计的上下文、中介工具、重试、检查点、评分器、权限、跟踪以及类似的控制点。
有两个边界澄清尤为重要。首先，harness工程并非提示的另一种说法。一篇论文如果只报告提示，而忽略哪些文件构成记录系统、可以调用哪些工具、哪些测试是绑定的、哪些信息会被记住以及何时需要人工或策略干预，通常会忽略系统中最重要的部分。其次，harness工程并不等同于围绕模型的所有软件基础设施。仅仅将文本转发给模型的Web前端还不是通常意义上的"harness"。真正的harness始于系统能够主动塑造随时间推移的轨迹、协调行动、编码约束、管理恢复，并生成可供他人检查事件经过的痕迹。
为了避免讨论沦为纯粹的术语之争，对40 篇相关文献进行了轻量级的描述性审计，并重用了清单中已分配的主要harness-组件标签。此次审计有意控制在较低水平：它仅是对本文所用证据库的可见性检查，而非对整个领域的普遍性估计。尽管如此，其模式仍然具有参考价值。
表 3 显示，证据库中的论文和基准测试最常强调接口、智体和可观察性。而公开的工程笔记、协议文档和技术文章则更常强调运行时、控制和治理。换言之，面向学术界的文献更倾向于描述操作界面和评估环境，而面向实践者的文档则更倾向于描述使系统日常运行的持久指令、恢复策略和权限结构。
编码是解释性的，证据库的选择也是有意为之。但这种不对称性有助于解释为什么在学术界的自然语言处理领域，harness层的概念似乎比在实践中更新：对于部署和迁移而言最重要的harness层部分，往往也是工程笔记而非正式系统论文中最常提及的部分。这种差距正是像 HARNESSCARD 这样的报告工具发挥作用的原因之一。
许多已报道的智体性能提升可能部分取决于其所采用的harness。
当两个系统使用相似的边界模型却表现截然不同时，其原因通常至少部分在于harness层。软件智体的性能提升不仅体现在其模型的替换上，也体现在其动作底层的重新设计上（Wang et al. 2024a; Yang et al. 2024）。当跟踪、重试、隐藏检查和验证器得到更好的协调时，交互式基准测试会变得更加易于处理（Jimenez et al. 2023; Liu et al. 2023; Pan et al. 2024; Zhou et al. 2023）。长时间运行的智体在状态外部化且进度可恢复的情况下，性能也会得到提升（Wang et al. 2023; Young 2025）。当编排、源选择和记忆结构与任务更好地匹配时，研究和浏览智体的性能可以得到提升（Hadfield et al. 2025; Wei et al. 2025）。即使模型至关重要，可靠性的最终保障往往取决于harness。
评估必须考虑harness。一旦智体通过工具运行并经过一段时间，孤立地评估模型就无法真正了解其本质。Anthropic 明确指出：智体评估是对harness和模型的评估（Grace et al. 2026）。这包含四个方面。首先，评估应该衡量轨迹和结果，而不仅仅是字符串。其次，论文应该报告行动预算、重试次数、检查点、评分器和干预措施，因为这些因素会影响结果。第三，与轶事性的说法相比，结合明确的验收测试和运行范围，生产力或可靠性的声明会更易于理解。第四，应该预料到会有偏差：交互式系统比静态基准测试运行更容易受到基础设施噪声和控制策略的影响。 Anthropic 认为，在评估资源配置得到记录和匹配之前，智体编码评估中排行榜上的微小差距值得怀疑（Segato 2026）。
harness的敏感性也改变了公平比较的含义。在保持模型系列匹配的同时改变工具访问权限、重试预算、验证器严格程度或升级策略，这并非受控比较；同样，在保持提示符不变的情况下，悄悄地改变记忆压缩或检查点机制，也并非受控比较。在智体环境中，实验单元是耦合的执行机制。因此，论文不仅应该报告成功率，还应该报告获得成功的范围：预算上限、允许的副作用、审批要求，以及失败是可恢复的还是致命的。如果没有这个范围，基准测试数据看起来可能具有可比性，但实际上反映的是不同类型的系统。
可复现性现在取决于harness层。如果harness描述不足，一篇关于语言智体的论文可能会显得比实际情况更新颖。重试预算、隐藏的人工升级机制、工具过滤器、存储库说明或评分器提示等，即使它们至关重要，也常常被隐式地忽略。这并非一个无关紧要的报告问题。它掩盖了哪些收益可以跨设置迁移，哪些收益依赖于特定领域的控制逻辑，以及哪些收益是特定运行时环境的产物。以harness为中心的研究实践可以扭转这种不对称性：模型之外的层将像模型本身一样得到详尽的描述。
目前，许多关于harness工作的最清晰的公开描述都来自产品团队，而非学术论文。这应被视为研究界的一个机遇，而非避而远之的理由。自然语言处理（NLP）通过将混乱的实践转化为明确的方法而不断取得进步：标注、评估、检索、提示和人类反馈都遵循了这一路径。harness工程也已准备好迈出同样的步伐。该领域可以贡献正式的任务定义、隔离控制层影响的基准套件、跨领域的报告规范，以及关于语言何时是状态、工具和监督的合适界面的理论。
harness工程与自然语言处理（NLP）尤其相关，因为harness层本身通常由承载语言的工件构成。存储库图、任务分解、工具描述、批准提示、错误摘要、进度文件和策略消息不仅仅是界面副本；它们是操作控制媒介。因此，harness将语言从输出形式转变为规范、恢复和监督的工具。这正是NLP应该关注的原因：措辞、权威性、基础和状态表示问题不再是边缘的用户体验（UX）细节，而是系统正确性的一部分。
以harness为中心的程序也将提高智体声明的质量。上述描述性审计表明，学术论文更倾向于展示接口和评估，而非那些往往决定系统是否迁移的持久控制和运行时策略。更严格的规范将奖励相反的行为：明确说明harness，通过实验对其进行调整，并解释哪些部分是可移植的，哪些部分是特定于领域的。
将harness视为一个层也能使基线更加清晰。最具启示性的对比往往不仅仅是模型A与模型B之间的对比，还包括更薄与更厚的控制、更窄与更宽的动作表面，或者同一模型上无状态与可恢复运行时间的对比。具有层-觉察能力的基线将使该领域能够判断进展是来自模型本身还是来自其周围的层。如果没有这些基线，归因和可重复性仍然会纠缠不清。
近期关于自动化研究系统、公共智体生态系统以及以验收测试为中心的生产力报告的相邻位置文章，尽管并未直接使用"harness层"框架，但它们都强化了同一转变的相邻部分（He，2026a,b,c）。
两个可能的反对意见。一个自然的反对意见是，harness工程"只是软件工程"。这种反对意见忽略了问题的特定对象性质。语言智体的harness并非通用的基础设施。它们的控制工件往往部分是语言对象：指令、存储库图、工具描述、摘要、批准提示、评分标准和进度文件。同样，它们的治理往往是通过语言来介导的，而不仅仅是低级系统调用。另一个反对意见是，该术语可能过于新颖或过于特定于供应商，无法作为研究的锚点。这种担忧是合理的，但它更倾向于支持澄清而非沉默。当一个反复出现的设计问题在多个智体系列中变得明显时，明确抽象化有助于该领域更诚实地比较系统。
"harness视角"使几个研究问题更容易被理解。其中一个问题涉及情境中的权威性。当存储库文档、检索的片段、工具输出、策略文本和运行时观察结果不一致时，智体应该最信任哪些工件？OpenAI强调存储库的"记录系统"，而Anthropic强调进度文件，这些都是切实的解决方案，但自然语言处理（NLP）可以提出更深层次的问题：语言应如何表示状态，以便后续决策保持有据可依（Lopopolo 2026；Young 2025）。这不仅是产品问题，更是关于语言作为控制媒介的问题。
另一类问题涉及恢复。基准测试通常会奖励最终完成，但长时间运行的系统能否存活，取决于其从错误的中间步骤中恢复的能力。何时应该重试、回展（rollback）、检查点、升级或终止？应保留多少之前失败尝试的记忆？哪些摘要能够保留正确信息以供未来修复，同时又不污染后续推理？这些并非边缘的实现细节。它们决定了智体在现实世界中多次运行后是否仍然有用。
第三个方面涉及通过语言进行治理（governance）。策略检查、批准提示、不确定性声明和来源追踪通常被视为用户体验（UX）的残留物。然而，对于语言智体而言，它们是系统和人类协调所依赖的语法的一部分。什么样的措辞能导致适度的升级，而不是过度阻止或过度遵从？智体应如何解释被阻止的操作、工具请求或风险较高的下一步建议？当故障部分源于模型错误，部分源于工具错误时，应如何分配责任？这些问题处于自然语言处理（NLP）、人机交互（HCI）、安全和软件工程的交叉领域，一旦将工具层作为明确的研究对象，这些问题就会变得更加尖锐。
第四个方面涉及迁移。一些改进随模型迁移，一些随harness迁移，还有一些仅随任务环境迁移。更强大的存储库图或验证器循环可能跨编码领域迁移，却无法帮助浏览器任务；更好的浏览策略可能跨网站迁移，却不适用于外壳繁重的工作流。分别报告模型迁移、工具迁移和任务迁移将使智体论文更具累积性，因为读者可以判断所声称的改进是涉及通用能力、可移植控制逻辑还是本地基础设施调优。
以harness为中心的视角也使得重复出现的设计模式更易于比较。一些系统依赖于相对较薄的单一智体工具循环；另一些系统则为模型提供了一个可执行的动作底层，如代码；还有一些系统构建了用于浏览或软件编辑的智体-计算机界面；还有一些系统采用编排器-工作者或规划器-验证器结构；还有一些系统则强调长时间运行的状态以及策略-觉察的部署。这些选择并非仅仅是美观的包装。它们重新分配了错误发生的位置以及可能的干预措施。
对于失败也是如此。上下文漂移、动作模式不匹配、规划失败、验证器过拟合、策略违规和成本激增等问题，通常被作为独立问题来讨论。通过认知自主性机器人（Cognitive Autonomous Robot，CAR）的视角，这些失败是相互关联的：每种类型的问题都是在控制、自主性和运行时与任务不匹配时出现的。下表4总结具有代表性的模式以及它们倾向于出现的失败情况。关键不在于哪种模式最好，而在于不同的约束选择会产生不同的可靠性特征，智能体论文应明确指出这一点。
这会产生方法论上的影响。以工具为中心的实验不仅应询问系统是否成功，还应询问哪些控制工件、运行时策略和界面选择对于成功是必要的。这意味着应将模式作为模式进行基准测试，而不是将其视为未报告的实现残留物。这也意味着，论文应报告工具何时（而非模型本身）恢复了故障，因为恢复行为通常是系统中最具实用重要性的部分之一。
harness工程不应被视为实施后的附加工作。它为自然语言处理（NLP）开辟了一个独特的研究议程。
首先，将控制作为可执行规范进行研究。存储库图、AGENTS.md、架构规则和清理循环表明，智体性的"指令遵循"在一定程度上是规范设计的问题，而不仅仅是合规性的问题（Lopopolo 2026；OpenAI 2026b）。自然语言处理（NLP）可以研究如何组合语言、代码、模式和测试，以使指导保持持久性和权威性。
其次，将智体问题视为一个接口问题。智体的动作空间是通过线缆介导的。工具模式、界面设计和执行底层可以同时影响性能和安全性（Aizawa，2025；Wang，2024a；Xie，2024年；Yang，2024）。从这个角度来看，智能体能力是特定界面和控制机制下模型的一种属性。
第三，将运行时间视为科学变量。压缩、状态持久化、恢复策略和执行预算并非多余。它们决定了系统能否在长期内保持一致性（Choi 2026；Rajasekaran等人 2025；Young 2025）。研究应探讨哪些运行时策略能保留正确信息，以及智体应在何时回溯、升级或重新计算。
第四，规范harness的报告。HARNESSCARD，一种用于语言智体系统的轻量级报告工件。表5给出论文的正文简化版（此处仅出于空间考虑，将治理和可观察性合并）。至少应披露基础模型、控制工件、运行时策略、动作底层、反馈堆栈、治理层和评估协议。目标不是官僚主义，而是可审计、可转移的结果。与模型卡片不同，HARNESSCARD记录了使智体声明可解释的装置。
第五，构建具有层次-觉察的基线。对照比较应逐层进行：使用不同控制工件的相同模型、使用不同运行时策略的相同动作基质，或使用不同验证和治理机制的相同运行时环境。这对于评估进展是来自模型还是来自harness层是必要的。报告利用情况有助于明确可重复性和归因。
如表（A6）所示一张填写完整的HARNESSCARD示例图，用于说明仓库编码智体。该示例综合OpenAI和Anthropic公开资料中的常见模式，而非逆向工程得出的产品规格说明。
