不是能力问题：LLM智能体层级间的控制敏感度是非单调的

# Harness敏感度在LLM Agent层级中是非单调的  
来源：<https://arxiv.org/html/2605.26731>  

## 并非能力问题：LLM Agent层级中的Harness敏感度是非单调的  

###### 摘要  
LLM agent部署中普遍存在一种假设：结构化的harness普遍能提高可靠性，并且能力更强的模型需要的结构化指导更少——这共同暗示了**模型能力层级与最优harness复杂度之间存在单调逆关系**。我们通过一个受控的432次运行实验来检验这一假设：在HEAT-24（一个包含24个任务的合成基准，基于git的工作空间验证）上，对六个模型（跨越四个能力层级）使用三种harness条件（轻量、平衡、严格）。我们的结果从两个方面否定了单调逆关系。首先，对于评估的前沿**对话**模型（Gemini 2.5 Flash），增加harness的详细程度会使VTSR降低29–38个百分点——即一种harness复杂度悖论。其次，对于评估的前沿**推理**模型（Qwen3.5-122B，启用扩展思考），严格harness达到了**最高**VTSR（91.7%）和**最低**延迟，与预测相反。在受限层级内，一个2B模型（Gemma4:e2B）在所有harness下都匹配了强开放层级的稳定性，达到91.7%。由于本研究中每个层级仅由一个模型代表，这些结果应解读为模型特定的观察；在评估的模型中，harness敏感度呈现**非单调**性，并且关键地取决于模型类型（对话与推理）。我们引入了一个六标签失败分类法，显示在能力强的模型中`format_violation`占主导，而在能力低的模型中`wrong_file`占主导，并推导出实用的层级感知harness选择指南。  

---

## 并非能力问题：LLM Agent层级中的Harness敏感度是非单调的  
Yong-eun Cho  
KailosLab  
首尔，韩国  
[email protected]  

## 1 引言  
自主LLM agent能够读取、推理并修改工作空间工件，正越来越多地部署在软件工程（Liu等，2024 (<https://arxiv.org/html/2605.26731#bib.bib5>)；Jimenez等，2024 (<https://arxiv.org/html/2605.26731#bib.bib12>)）、文档处理和操作工作流中。**harness**——即系统级提示，指定任务范围、允许的操作、输出格式和验证过程——的质量被广泛认为是提高agent可靠性的主要杠杆（Yao等，2023 (<https://arxiv.org/html/2605.26731#bib.bib2>)；Shinn等，2023 (<https://arxiv.org/html/2605.26731#bib.bib3>)）。现有基准在固定harness下评估agent并报告总体准确率，掩盖了harness复杂度与模型能力之间的交互。实践者通常在部署舰队中对所有模型应用严格、高度结构化的harness，基于两个隐含假设：更多结构总能提高可靠性，且能力更强的模型需要的结构化指导更少——从而形成**能力层级与最优harness复杂度之间的单调逆关系**。我们提出疑问：这种单调逆假设是否在多个能力层级上经验成立？答案在对话导向的前沿模型与推理导向的前沿模型之间是否不同？  

我们做出以下贡献：  
- • **HEAT-24**（Agent任务Harness评估），一个确定性的24任务合成基准，包含工作空间级别的基于git的验证，覆盖六类任务。  
- • 首次对单调逆能力-harness假设进行受控实证检验，跨越六个模型（四个能力层级）和三种harness条件（共432次运行）。  
- • 证据表明该假设同时以相反方向失败：harness复杂度悖论（严格harness**损害**前沿对话模型）与非单调模式（严格harness**最有助于**前沿推理模型）。  
- • 发现参数量不是harness敏感度的可靠代理：一个2B模型（Gemma4:e2B）匹配了强开放层级的稳定性，表明指令微调质量才是真正的调节变量。  
- • 一个六标签失败分类法以及实用的**层级感知和类型感知** harness选择指南。  

## 2 相关工作  

#### LLM agent基准。  
Liu等（2024 (<https://arxiv.org/html/2605.26731#bib.bib5>)）在八个交互环境中评估LLM，显示前沿模型与开源模型之间存在显著能力差距。Wei等（2022 (<https://arxiv.org/html/2605.26731#bib.bib1>)）证明链式思考推理仅在超过特定模型大小阈值时才可靠出现，暗示结构化提示可能给较小模型带来过度认知负担——我们在受限层级中观察到了这一模式。  

#### 指令遵循与格式合规。  
Lou等（2024 (<https://arxiv.org/html/2605.26731#bib.bib6>)）调查了指令遵循能力，发现合规性随指令复杂度增加而降低，这直接激励了我们的harness复杂度研究。Sclar等（2024 (<https://arxiv.org/html/2605.26731#bib.bib13>)）显示提示格式的细微变化会导致开源模型之间高达76点的性能差异，确立了提示结构是主要方差来源——我们在harness层面直接研究这一问题。Mizrahi等（2024 (<https://arxiv.org/html/2605.26731#bib.bib15>)）认为单提示评估不稳定，呼吁多提示评估，这支持了我们的跨harness设计。关于结构化输出生成的工作（Geng等，2025 (<https://arxiv.org/html/2605.26731#bib.bib7>)）显示JSON和模式合规性在不同模型家族间差异很大，促使我们设计了格式敏感的任务类别。Deng等（2025 (<https://arxiv.org/html/2605.26731#bib.bib8>)）发现将任务求解与输出格式分离可以改善两个维度，这与我们在复杂过程指令混合输出格式要求时观察到的格式违规现象一致。  

#### Agent脚手架。  
ReAct（Yao等，2023 (<https://arxiv.org/html/2605.26731#bib.bib2>)）和Reflexion（Shinn等，2023 (<https://arxiv.org/html/2605.26731#bib.bib3>)）证明结构化推理-动作循环能改善agent性能。我们的研究通过询问不同**级别**的harness结构是否适合不同模型层级，以及扩展思考模式是否以可预测的方式与harness结构交互，对上述工作进行补充。  

#### 提示复杂度与性能反转。  
Schulhoff等（2024 (<https://arxiv.org/html/2605.26731#bib.bib14>)）系统调查了提示技术，并列出了提示工程改善或降低性能的条件，为我们关于harness复杂度的发现提供了广泛的实证背景。Hakim (2026 (<https://arxiv.org/html/2605.26731#bib.bib10>)）发现对模型输出的简洁性约束会反转跨模型规模的性能层级——大型模型在被要求简洁时变得相对**更差**。Khan (2025 (<https://arxiv.org/html/2605.26731#bib.bib11>)）认为增加提示特异性可能反转预期的性能排序，对于能力强的模型，简单提示可能优于工程化的提示。这两个发现都与我们的harness复杂度悖论一致：指令丰富度与任务成功之间的关系是非单调且层级依赖的。  

#### 自我纠正与错误恢复。  
Li (2025 (<https://arxiv.org/html/2605.26731#bib.bib9>)）分解了LLM自我纠正，发现准确率-纠正悖论：更强的模型会犯更“深层”的错误，难以自我纠正，而较弱模型犯更易处理的表面错误——该模式与我们的失败分类法部分一致。  

## 3 HEAT-24基准  

### 3.1 工作空间与任务设计  
所有任务在一个共享的合成工作空间上运行，包含十二个文件：配置YAML和JSON、Python源文件和测试文件、Markdown文档、一个CSV数据文件以及变更日志片段。每次运行前，工作空间初始化为一个git仓库；验证使用`git diff`检测并限定文件更改范围。所有十二个工作空间文件被注入每个harness提示中，使模型无需外部工具即可读取任何文件。  

我们定义了24个任务，跨越六个类别（表1）：  

**表1：HEAT-24任务类别（每类4个任务；共24个）**  

| 类别 | 描述 |
|------|------|
| inspect_local | 读取文件，返回JSON |
| structured_edit | 修改一个文件 |
| format_sensitive | 输出严格的JSON模式 |
| verification_recovery | 修复bug，运行测试 |
| repair | 纠正格式错误的内容 |
| multi_step_ops | 协调多个文件 |

每个任务都有一个确定性的二元验证器。任务设计为具有确定性的二元结果。验证器检查：JSON键的存在和值、git限定的文件修改、YAML/JSON解析有效性以及子字符串存在性。模型输出中表达的文件修改使用结构化`<<`⋯`>>`标记，harness运行器在验证前解析并应用到工作空间。该标记格式包含在所有文件修改任务的原始任务指令中，适用于所有三种harness条件；harness条件仅在额外添加的过程指令、范围约束和验证规范上有所不同。  

### 3.2 Harness条件  
我们定义了三种harness条件，结构复杂度递增：  

- **Light**：两行提示：角色陈述加原始任务指令。无格式规范、无范围约束、无验证过程。  
- **Balanced**：添加一个四步过程模板（计划、执行、检查、响应），并列出允许的文件。无模式或验证规范。  
- **Strict**：添加六个显式阶段（预检/计划/执行/验证/恢复/报告）、允许文件列表、明确的成功标准、验证规范以及使用`<<`⋯`>>`标记表达文件更改的指令。  

### 3.3 模型  
我们评估了六个模型，跨越四个能力层级（表2）。层级分配基于部署特征——参数量和推理基础设施——**而非**任务性能，以避免循环论证。目标是测试这种常规分类方案是否能预测harness敏感度。本研究中每个层级由单一模型代表；因此层级层面的声明应解读为模型特定的观察，等待后续在每个层级内使用更多模型进行重复验证。  

API托管的模型（Gemini 2.5 Flash、Qwen3.5-122B、GPT-OSS-120B）在实验时使用提供商的默认温度和采样设置进行查询；确切的参数值记录在发布的运行脚本中。Ollama托管的模型使用`think=False`抑制链式思考token，通过每个模型的Modelfiles将上下文长度固定为4096 token。Qwen3.5-122B的“前沿-推理”分类反映了在所有运行中启用了扩展思考作为推理配置选择，而非架构属性；如果禁用扩展思考，结果可能会不同。  

**表2：评估的模型，按四个能力层级划分。层级分配基于部署特征（参数量和推理基础设施），而非任务性能。受限层级模型名称反映了对应Google/Meta/Alibaba基础模型的Ollama标签。**  

| 层级代码 | 层级名称 | 模型 | 参数量 | 托管方式 |
|----------|----------|------|--------|----------|
| FP | 前沿-专有 | Gemini 2.5 Flash | ~未公开 | API |
| FR | 前沿-推理 | Qwen3.5-122B | 122B | API |
| SO | 强开放 | GPT-OSS-120B | 120B | API |
| C | 受限 | Llama4:Scout、Gemma4:e2B | 2B–未公开 | Ollama |

### 3.4 指标与失败分类法  
我们报告每次运行的两个指标：  

- **TSR（任务成功率）**：由工作空间验证器确定的二进制通过/失败。  
- **VTSR（验证任务成功率）**：在本基准中与TSR相同（所有验证器完成无基础设施错误）；保持该区分是为了那些需要将验证器失败与模型失败分离的部署场景。  

失败由自动化的基于规则的分类器分配六个标签之一，该分类器检查git diff输出、JSON解析结果和测试执行日志；未进行手动标注：  

- `format_violation`：输出无法解析为所需模式  
- `wrong_answer`：可解析但值错误  
- `wrong_file`：修改了允许集合之外的文件  
- `missing_change`：未检测到文件修改  
- `unrelated_change`：修改了正确文件但内容错误  
- `tests_still_fail`：代码更改未修复目标测试失败  

## 4 结果  

### 4.1 各Harness条件下的总体性能  
表3报告了每个模型-harness组合在24个任务上的平均VTSR（每个单元格24次运行）。由于每个层级由单一模型代表，跨层级比较是探索性的；层级行之间的差异反映的是模型特定观察，而非层级层面的规律。  

**表3：按模型和harness条件划分的平均VTSR（%）（n=24每个单元格，k=1次重复）。粗体=每行最佳。层级代码：FP = 前沿-专有，FR = 前沿-推理，SO = 强开放，C = 受限。GPT-OSS-120B的strict条件T13-T24因原始运行耗尽了200k TPD速率限制后使用第二个API密钥重新评估；重新评估使用相同的提示模板和提供商默认参数，在同一日历周内完成。代表性95%威尔逊置信区间（n=24）：95.8%→[78.9, 99.9]，75.0%→[53.3, 90.2]，58.3%→[36.6, 78.2]，0%→[0.0, 14.2]。结果应解读为初步证据，等待k≥3次重复以获得统计可靠性。**  

| 模型 | 层级 | Light | Balanced | Strict |
|------|------|-------|----------|--------|
| Gemini 2.5 Flash | FP | **95.8** | 58.3 | 66.7 |
| Qwen3.5-122B | FR | 87.5 | 75.0 | **91.7** |
| GPT-OSS-120B | SO | 70.8 | 70.8 | **83.3** |
| Llama4:Scout | C | 66.7 | **79.2** | 75.0 |
| Gemma4:e2B | C | **91.7** | 87.5 | 91.7 |

**图1：按模型和harness条件划分的VTSR（%）。虚线分隔前沿/强开放（左侧）和受限（右侧）层级。**  

### 4.2 Harness复杂度悖论：前沿对话模型  
对于Gemini 2.5 Flash（前沿-专有），轻量harness达到VTSR=95.8%，在平衡条件下下降到58.3%（-37.5个百分点），严格条件下为66.7%（-29.2个百分点）。两种复杂条件中的主导失败模式是`format_violation`（平衡失败中10/10；严格失败中8/8）。类别级别分析（表4）将悖论定位在`inspect_local`和`format_sensitive`任务上：Gemini在轻量harness下这两个类别均达到100%，但在严格条件下`inspect_local`为0%，`format_sensitive`为25%。需要结构化文件编辑的任务（`structured_edit`、`repair`）在所有harness下保持100%，确认悖论特定于**格式敏感的输出任务**，而非通用能力回归。我们假设，复杂的多阶段指令将生成分布转向说明性散文，导致模型叙述其推理过程而不是直接输出所需的JSON模式。这与Deng等（2025 (<https://arxiv.org/html/2605.26731#bib.bib8>)）的发现一致：任务求解与输出格式是部分冲突的目标。  

### 4.3 非单调模式：前沿推理模型  
Qwen3.5-122B（前沿-推理，启用扩展思考）对harness复杂度表现出**非单调**响应：在平衡harness下VTSR最低（75.0%），严格harness下最高（91.7%），轻量harness下居中（87.5%）。据我们所知，这是首次实证记录层级特定的harness复杂度与模型类型之间的非单调交互。值得注意的是，严格harness下的平均推理延迟（23.3秒）**低于**轻量（35.4秒）或平衡（38.5秒），这与显式约束减少了模型输出前的思考链长度一致。类别分析揭示了结构：平衡harness失败集中在`inspect_local`（仅25%通过）和`format_sensitive`（50%通过），两者都是