Natural-Language Agent Harnesses 精读

论文链接：arxiv.org/abs/2603.25723 代码仓库：github.com/curated-skills/LinguaClaw 发表时间：2026年3月（v2: 2026年5月） 机构：清华大学深圳国际研究生院、哈尔滨工业大学（深圳）

一、论文背景

1.1 从「模型决定一切」到「Harness 决定体验」

2025 年以来，大语言模型（LLM）的能力飞速增长，但一个被长期忽视的事实逐渐浮出水面：模型再强，如果外围的执行系统拉胯，Agent 的实际表现依然很差。

这催生了一个核心公式：

其中，Harness（脚手架/执行框架） 指的是模型之外的整套系统——系统提示词、工具调用接口、文件系统、沙箱环境、编排逻辑、验证机制、反馈回路、重试恢复策略、约束机制等一切让模型从"能说"变成"能做"的基础设施。

一个直观的类比：模型是 CPU，Harness 是操作系统。CPU 再快，如果操作系统天天崩溃，用户体验也不会好。LangChain 在 Terminal Bench 2.0 上的实战经验很好地印证了这一点——他们没有更换模型，只优化了 Agent 的运行环境（文档组织方式、验证回路、追踪系统），排名从全球第 30 名升到第 5 名，得分从 52.8% 跃升到 66.5%。更有甚者，同一个模型仅换了文件编辑接口的调用方式，编码基准分数就从 6.7% 跳到了 68.3%。

1.2 Harness 的核心困境：策略与机制交织

Harness 的重要性已经不言而喻，但问题在于：现有的 Harness 通常不是一种清晰的研究对象，而是一团糊在一起的代码。

在一个典型的代码 Harness 中，以下内容可能全部交织在同一个控制器包里：

• 提示词（Prompt）：告诉模型该怎么做
• 工具适配器：把外部工具接口包装成模型可调用的形式
• 解析规则：把模型的输出解析成结构化指令
• 验证脚本：检查中间结果是否正确
• 重试逻辑：失败后如何恢复
• 上下文策略：何时压缩、何时清除上下文
• 基准测试假设：针对特定评测的硬编码逻辑

这种紧耦合带来了四个严重问题：

1.3 一个新兴的研究方向：Harness Engineering

面对这些困境，Harness Engineering（脚手架工程） 作为一个独立学科在 2026 年正式崛起。它关注的核心问题是：如何系统性地设计、实现、调试和评估 Agent 的外围执行系统。

这个方向已经有了实质性进展：

• AutoHarness（Google DeepMind, 2026.02）：让 LLM 自动合成代码 Harness，在 145 种 TextArena 游戏中阻止所有非法动作，配备自动 Harness 的小模型甚至超越了更大的模型。
• Meta-Harness（Stanford, 2026.03）：端到端地优化模型 Harness，提出了基于文件系统的 Harness 提议器和基于环境的验证器。

但这些工作仍然在代码层面解决 Harness 问题——用代码生成代码，用代码优化代码。一个更根本的问题尚未被回答：Harness 中那些属于"策略"的部分，能否不用代码来写？

这就是本文要回答的问题。

二、论文定位和关联工作

2.1 研究方向全景

本文处于三个研究方向的交汇处：

Agent Harness / 脚手架感知评估
        ↘
自然语言指令载体（AGENTS.md, CLAUDE.md 等）→ ★ 本论文（NLAH + IHR）← 自然语言作为程序/工作流/约束
        ↗                                          （LMQL, DSPy, SGLang 等）
Agent 技能 / 记忆系统

2.2 与现有工作的定位关系

（1）Agent Harness 和脚手架感知评估

直接前驱工作：

关键差异：上述工作都在代码层面处理 Harness。本文的核心假设是：Harness 中有一部分是"策略"而非"机制"，策略可以用自然语言表达。

（2）自然语言指令载体

并行工作：

关键差异：现有指令文件是静态知识容器，告诉 Agent “你应该知道什么”。NLAH 是动态策略文档，告诉运行时"你应该怎么执行"。

（3）自然语言作为程序/工作流/约束

相关工作：

关键差异：这些工作把自然语言或声明式语法当作程序来编译和执行，追求精确控制。NLAH 刻意保持自然语言的自由形式，牺牲一些精确性来换取可编辑性、可读性和广泛表达力。

2.3 本文的独特定位

本文在上述工作中的定位可以用一句话概括：

它是第一个系统性探索"Agent Harness 策略能否外化为可执行自然语言对象"的工作。

它不试图替代代码（精确机制仍由代码承担），不试图替代指令文件（项目知识仍由 AGENTS.md 等承担），而是在两者之间开辟了一个新的表示层：用自然语言写策略，用代码写机制，用运行时连接两者。

三、问题定义

3.1 从现象到本质的抽象

论文面对的现象很直观：同一个模型，配上不同的 Harness，表现差异巨大。但当你想要研究"什么样的 Harness 策略是好的"时，你会发现根本无从下手——因为 Harness 策略埋藏在代码里，你无法把它拎出来单独看。

论文的核心抽象可以分两步理解：

第一步：策略与机制的分离

一个 Agent 的运行逻辑可以粗分为两层：

• 机制层（Mechanism）：工具怎么调用、输出怎么解析、沙箱怎么隔离、测试怎么运行——这些需要精确执行，差一个字符都不行。
• 策略层（Policy）：任务怎么分解、什么时候该验证、失败后怎么恢复、什么证据才算合格——这些是决策逻辑，需要的是可读、可讨论、可修改。

当前的困境是：策略层和机制层混在了一起。你没法在不破坏机制的前提下修改策略，也没法在不理解策略的情况下审计机制。

第二步：策略层的自然语言表示

如果策略层可以独立出来，用什么来表示？论文给出的答案是：自然语言。

理由如下：

• 策略是给人读、给人讨论、给人修改的，自然语言天然适合。
• 策略不需要逐字符精确执行，它规定的是方向和边界，而非具体操作。
• 自然语言可以直接被 LLM 理解和执行，不需要额外的编译步骤。

3.2 精确的问题定义

在排除了外部干扰后，论文的核心问题可以表述为：

Agent Harness 的可复用设计模式，能否表示为可执行的自然语言对象？

这个问题包含三个关键约束：

进一步拆解，论文需要回答三个研究问题：

• RQ1（Harness 实现）：NLAH 能否塑造可观察的 Agent 行为，同时保持与代码和提示实现相当的任务结果？
• RQ2（Harness 机制实现）：IHR 执行的 NLAH 是否保留并实例化了预期的 Harness 机制（工作流结构、合同执行、工具使用、恢复和信息交接）？
• RQ3（模块消融）：一旦 Harness 模块用自然语言表达，它们能否在模块级别被干净地消融和分析？

四、问题解法

4.1 核心思想：四层架构

论文的解决方案由两个核心概念构成：NLAH（自然语言 Agent 脚手架） 和 IHR（智能脚手架运行时）。它们共同形成一个四层架构：

┌─────────────────────────────────────────────────────────┐
│  第四层：脚本和适配器（确定性代码）                        │
│  运行测试、解析结果、调用基准工具、检查产物                │
├─────────────────────────────────────────────────────────┤
│  第三层：NLAH（自然语言策略文档）                         │
│  描述任务运行的阶段、角色、状态规则、验证规则、             │
│  恢复规则和停止条件                                      │
├─────────────────────────────────────────────────────────┤
│  第二层：运行时策略（固定指令）                            │
│  将基础 Agent 转变为 IHR，定义如何解释和执行              │
│  Harness 文档                                           │
├─────────────────────────────────────────────────────────┤
│  第一层：基础 Agent（代码形式的最小可执行基底）             │
│  仅是 LLM 循环，可调用模型，唯一暴露的工具是终端           │
└─────────────────────────────────────────────────────────┘

一个通俗的类比：想象你是一个项目经理（IHR），你手下有一个新员工（子 Agent），你需要给他一份工作手册（NLAH）让他知道怎么做事。手册里写的是策略——“先检查需求，再写代码，写完要跑测试，测试不过要改”。但手册不会写"怎么运行测试"——那是工具和脚本的事。

4.2 IHR：轻量而共享的运行时

IHR（Intelligent Harness Runtime）的设计哲学是克制——它不是一个为某个基准定制的庞大控制器，而是一个给自然语言 Harness 策略提供通用执行基底的共享运行时。

IHR 的核心特点：

（1）父编排器 + 子执行 Agent 的模式

即使是名义上的单 Agent Harness，IHR 也将运行实现为"父编排器 + 一个执行子 Agent"。为什么？因为编排和执行是两种不同的职责：

• 父编排器负责读 NLAH、按照策略调度阶段、管理状态和产物、判断是否完成。
• 子 Agent 负责具体的任务执行（写代码、操作文件、调用工具）。

这种分离让策略和执行互不干扰。

（2）运行时策略的五大核心思想

IHR 的运行时策略（也叫"宪章"）包含五个关键设计：

（3）为什么 IHR 是"共享"的？

IHR 对所有 NLAH 都是一样的——它不包含任何特定任务的逻辑。不同的任务只需要更换 NLAH 文档，运行时本身不需要修改。这正是"策略与机制分离"的具体体现。

4.3 NLAH：可编辑的策略文档

NLAH（Natural-Language Agent Harness）是一份用自然语言编写的策略文档。它规定了一次任务运行"应该怎么做"，但把"具体怎么操作"留给运行时、工具和钩子。

NLAH 与普通提示词的区别：

普通提示词告诉模型"你应该这样做"——它关注的是模型的行为。NLAH 描述的是任务运行的生命周期——它关注的是整个执行流程的策略。

一个 NLAH 通常包含：

4.4 编写 NLAH 的五条原则

论文总结了编写高质量 NLAH 的五条原则，这些原则本身就很有参考价值：

① 首先声明任务合同

NLAH 应该首先定义输入、预期输出、允许的工具或产物以及运行完成的条件。这防止后续部分变成模糊的建议。例如：“输入是一个 GitHub Issue，输出是一个补丁文件，完成条件是补丁通过了仓库的测试。”

② 将阶段与机制分离

NLAH 应该命名运行的阶段（检查、计划、编辑、验证等），但不应该在散文中重新实现每个低级工具操作。“运行测试"是一个阶段，“怎么调用 pytest"是机制——后者不应该出现在 NLAH 里。

③ 使状态和证据显式化

可读的 NLAH 应该规定状态存储位置、哪些产物必须被后续 Agent 重新打开、什么证据支持声明。例如：“在委托前写入状态文件”、“没有目标文件证据不得完成”。

④ 编写可消融的模块边界

NLAH 的各节应该使用清晰的模块名称（如"验证器”、“自进化”、“多候选搜索”），以便可以单独消融某个模块来分析其效果。这正是 RQ3 实验的基础。

⑤ 优先使用简单可执行的语言

“小心”、“深度思考”、“像专家一样行动"是弱策略——它们不具体，模型无法据此执行。而"在委托前写入状态文件”、“仅在产生候选补丁后运行验证器”、“没有目标文件证据不得完成"则是强策略——具体、可执行、可审计。

4.5 自然语言与代码的分工边界

论文非常明确地界定了自然语言和代码各自的职责：

这个分工的关键洞察是：如果一个决策被所有 Harness 共享或需要机器精确执行 → 代码；如果一个决策是任务族特定的且应被读取、编辑、重构或消融 → 自然语言。

4.6 实验验证

论文在三大基准族上进行了实验：

最惊人的发现——策略简洁性审计：

NLAH 用不到代码 5% 的篇幅，表达了完整的 Harness 策略。这意味着策略层从几万行代码的泥潭中被提炼出来了。

模块消融的关键结论：

最有帮助的模块是那些收紧状态和验收纪律的模块：

• 文件支持状态（File-backed state）：SWE +2.6%，OSWorld +13.9%——把状态写入文件比只靠上下文记忆可靠得多。
• 自进化（Self-evolution）：SWE +5.8%——让 Agent 从自己的错误中学习是最有效的策略改进之一。
• 证据支持回答（Evidence-backed answering）：两个基准均 +2.8%——强制要求"有证据才能下结论”。

而那些主要添加本地过程层、额外分支或压缩摘要的模块则不太有用，甚至有害：

• 多候选搜索：Agent 调用从 1.1 跳到 5.7，但 SWE 反而下降 1.6%——更多分支 ≠ 更好结果。
• 上下文压缩：OSWorld 下降 8.3%——激进压缩可能丢掉关键信息。

五、必要知识反推

假设让一个完全没有背景知识的人来完成这篇论文的研究工作，他需要掌握哪些必要知识和信息？以下从"发现问题"到"解决问题"的角度进行反推。

5.1 发现问题阶段所需的知识

5.2 提出方案阶段所需的知识

5.3 验证方案阶段所需的知识

5.4 知识融合路径

以上知识的融合路径可以概括为：

观察痛点（Harness 紧耦合）
    → 识别本质（策略与机制未分离）
        → 提出假设（策略可以用自然语言外化）
            → 设计架构（NLAH + IHR 四层分离）
                → 制定原则（五条 NLAH 编写原则）
                    → 验证可行性（三大基准 + 三种实现方式对比）
                        → 深入分析（机制审计 + 模块消融）

最关键的融合节点是**“识别本质"到"提出假设”**这一步——你需要同时理解 Harness 的痛点（策略和机制交织）、自然语言的优势（可读、可编辑、可被 LLM 执行）和代码的不可替代性（精确操作），才能提出"自然语言写策略、代码写机制、运行时连接两者"的方案。

六、论文中可以提取的通用性灵感

灵感 1：策略与机制的分离是一种普适的架构思想

本文最根本的贡献不是 NLAH 本身，而是策略与机制的分离这一思想。在任何系统中，只要你发现"决策逻辑"和"执行细节"纠缠在一起，都可以考虑这种分离：

• 软件架构：业务规则（策略）与基础设施（机制）的分离，这正是六边形架构和整洁架构的核心思想。
• 组织管理：战略（策略）与流程（机制）的分离。战略应该用自然语言写，让所有人能读、能讨论、能修改；流程应该是标准化的操作手册。
• 教育培训：教学目标（策略）与教学方法（机制）的分离。不同老师可以用不同方法达成同一个教学目标。
• 法律制度：法律条文（策略）与执法程序（机制）的分离。法律应该清晰可读，执法应该精确可复现。

核心原则：策略给人读、给决策者改；机制给机器执行、给工程师优化。两者不应用同一种语言写。

灵感 2：自然语言可以作为可执行的策略载体

本文证明了一个反直觉的结论：自然语言不只是"给人看的文档”——它可以是"可执行的策略程序"，前提是你有一个足够智能的运行时。

这个灵感的推广方向：

• 项目管理：项目计划书可以不只是静态文档，而是一个可被项目管理工具解释和执行的策略文档——自动分配任务、检测瓶颈、触发审批。
• 运维手册：SOP 可以不只是人读的指南，而是一个可被运维 Agent 解释和执行的策略——自动巡检、自动恢复、自动升级。
• 产品设计：PRD 可以不只是产品经理的描述文档，而是一个可被原型生成工具解释和执行的策略——自动生成界面、自动走查逻辑。

核心原则：当运行时足够智能时，自然语言策略 > 代码策略，因为前者更容易理解、讨论、修改和传播。

灵感 3：简洁的表示比复杂的实现更有价值

NLAH 用不到代码 5% 的篇幅表达了完整的 Harness 策略。这不是因为 NLAH “省略"了什么，而是因为策略本身就是简洁的——是代码把策略埋在了实现细节的汪洋大海中。

这个灵感的推广：

• 知识管理：好的知识表示应该是简洁的。如果你的文档库里有 10 万字，但核心知识只有 2000 字，说明你的表示效率太低了。
• 代码审查：如果你写了一段 1000 行的代码，但它的核心逻辑只有 50 行，说明代码里混入了太多策略无关的实现细节。
• 沟通表达：如果你用 10 分钟解释了一个想法但听众还是没懂，可能不是想法太复杂，而是你的表达中混入了太多无关信息。

核心原则：好的表示应该把策略从机制中提炼出来，让人一眼就能看到"做什么"和"为什么”，而不需要翻遍"怎么做"的细节。

灵感 4：收紧验收纪律比扩大搜索范围更有效

模块消融实验揭示了一个重要且反直觉的结论：最有帮助的模块不是那些扩大搜索范围的（如多候选搜索），而是那些收紧验收纪律的（如文件支持状态、证据支持回答）。

多候选搜索让 Agent 调用从 1.1 跳到 5.7（5 倍），但 SWE 分数反而下降 1.6%。而文件支持状态几乎没有增加调用次数，却提升了 2.6%-13.9%。

这个灵感的推广：

• 团队管理：给团队更多选择（扩大搜索）不如明确验收标准（收紧纪律）。与其说"你们想办法解决这个问题"，不如说"解决了这个问题并且通过了以下测试才算完成"。
• 个人效率：列出 10 个候选方案不如写清楚 1 个方案的验收条件。明确"什么算做完"比探索"还有什么可能"更有效。
• 产品迭代：A/B 测试 10 个版本不如定义清楚 1 个版本的成功标准。先确定"什么是好"，再去追求"更好"。

核心原则：在资源有限的情况下，定义好"什么算成功"比探索更多可能性更能提升结果质量。

灵感 5：可消融性是系统设计的硬需求

本文的模块消融实验之所以能做，是因为 NLAH 天然具有可消融的模块边界——你只需要删掉 NLAH 中的某个模块，就能干净地移除对应功能。在代码 Harness 中做同样的事情，你需要理解几千行代码的依赖关系。

可消融性的推广：

• 微服务架构：每个服务应该可以独立下线而不影响其他服务。如果你的服务之间有隐性依赖，你就做不到可消融。
• 功能设计：每个功能应该可以独立关闭。如果你的功能之间有深度耦合，你就无法做 A/B 测试。
• 人生规划：每个投入应该可以独立暂停。如果你所有的投入都绑在一起，你就无法判断哪个是有价值的。

核心原则：可消融性 = 可分析性 = 可改进性。如果你无法干净地移除一个模块，你就无法判断它是否有价值，也就无法系统地改进系统。

灵感 6：弱策略 vs 强策略的区分

论文指出了一个重要区分：“小心”、“深度思考"是弱策略——它们不具体，无法被执行；“在委托前写入状态文件”、“没有目标文件证据不得完成"是强策略——它们具体、可执行、可审计。

这个区分在任何需要"指导别人做事"的场景都适用：

• 教育：告诉学生"要认真思考”（弱策略）不如告诉学生"写出三个支持你结论的证据”（强策略）。
• 管理：告诉员工"注意质量"（弱策略）不如告诉员工"每个提交必须通过单元测试"（强策略）。
• 自我管理：告诉自己"今天要高效"（弱策略）不如告诉自己"今天 10 点前完成第一项任务并提交"（强策略）。

核心原则：好的策略是具体、可执行、可验证的。如果你的策略听起来像是"鸡汤"，那它就是弱策略。

总结

Natural-Language Agent Harnesses 这篇论文做了一件非常漂亮的事：它不是在代码层面继续优化 Harness，而是退后一步，问了一个更根本的问题——Harness 中的策略部分，能不能用自然语言来写？

答案是可以。NLAH + IHR 用不到代码 5% 的篇幅表达了完整的 Harness 策略，在三大基准上取得了与代码实现可比的结果，而且让策略变得可检查、可比较、可消融。

但这只是起点。论文也坦诚地指出了当前的局限：自然语言的精确性不足、信息交接的召回率偏低（0.32-0.55）、运行时工程开销较大。未来的工作需要在保持自然语言可编辑性的同时，提升精确性和效率。

更重要的是，这篇论文开启了一个新的研究方向：Harness 作为科学研究对象。当 Harness 策略从代码中独立出来，它就从"工程师的直觉和经验"变成了"可以系统研究、比较和优化的科学对象"。正如论文结尾所说：

“Harness 可以从模型周围的偶然粘合代码，转变为科学的表示对象。”