LLM Agent评测中Harness的影响：为何需要披露评测框架

如果你最近在关注 LLM Agent 的评测榜单，可能会产生一个很直接的观感：同一个模型，有的团队测出来“表现很强”，换一个团队测出来“也就那样”。一开始大家习惯把差距归因于提示词写得不够好，但后来陆续有工程经验表明，问题往往出在评测链路本身。最近一篇论文把这个话题放到了明面上，标题非常直接：《Stop Comparing LLM Agents Without Disclosing the Harness》。它的核心观点是：在长程智能体评测中，“评测框架/驱动层”（Harness）对结果的影响可能比模型本身更大。

这篇论文提醒我们一个容易忽略的事实：大家在榜单上比较的并不是“模型能力”本身，而是一整套由数据、工具、流程和评价规则组成的系统。本文会从工程视角拆解为什么 Harness 会影响评测结论，同一个模型在不同 Harness 下为什么会出现结果差异，以及我们在设计自己的评测平台时可以从论文的批评中借鉴哪些规范。

1. 榜单上的“模型能力”，往往是一个系统能力

1.1 智能体评测到底在测什么

大语言模型 Agent 与传统问答模型最大的区别，在于它需要与环境交互。一次任务通常不是“输入一段文字、输出一段文字”就结束，而是包含多轮推理、工具调用、中间结果读取、错误修正、最终答案生成等步骤。也就是说，模型的行为不仅取决于权重，还取决于它“看见什么消息”“能用什么工具”“失败后能否重试”。

我们可以把评测结果写成这个粗粒度公式：

评测成绩 ≈ 模型能力 × Harness 能力 × 任务环境匹配度

在单轮问答中，模型能力占主导；但在长程智能体任务中，Harness 的工程实现会把模型能力放大或抑制。这也是论文主张“不要在不披露 Harness 的情况下比较 Agent”的根本原因。

1.2 隐藏变量远不止“提示词”

很多人以为 Harness 只是提示词模板，其实它覆盖了从任务下发到结果打分的全过程。我整理过自己在评测中踩过的隐藏变量，至少包括以下这些：

• 任务描述是直接发给模型，还是被拆成了 system/user/assistant 多段历史消息；
• 模型输出是自由文本，还是强制走 JSON 或 Function Calling 结构；
• 工具调用结果是否回填到对话历史，以什么格式回填；
• 智能体在中间步骤失败后是否允许重试，重试次数是多少；
• 是否给模型设置了最大步数、超时时间、最大 Token 限制；
• 环境状态是否被错误复用到其他评测任务；
• 打分模型是哪个版本，打分提示词是否稳定；
• 数据集的文件读取顺序和并发线程数是否变化。

上面任意一点变化，都可能导致一个任务从“能完成”变成“不能完成”。论文批评的正是这种比较：如果评测双方使用的 Harness 不同，最后得出的能力排名，更多反映的是评测系统差异，而不是模型真实差异。

1.3 长程任务尤其容易受 Harness 影响

长程智能体任务通常包含数十步甚至数百步动作，步骤越多，中间出错的位置就越多。Harness 在每一步里都扮演“裁判员和后勤人员”的双重角色：一方面它决定模型能否获得必要的动作空间，另一方面它也决定错误发生后任务是否可以恢复。

举个具体例子，一个网页自动化任务需要完成登录、搜索、对比、下单四个动作。如果 Harness 不允许模型在元素定位失败后重新读取页面，模型很可能卡在登录步骤；但同样的模型，在另一个允许读取页面快照并重试的 Harness 中，或许能顺利完成整单。论文提到 Harness 的影响可能超过模型本身，在长程任务中并不夸张，因为每一步的失败概率都会累加，最终的差距会非常明显。

2. 什么是智能体评测中的 Harness

2.1 从“比赛调校”理解 Harness

“Harness”这个词来自英文原意“马具”，后来被引申成测试工具中的“测试夹具/驱动框架”。放在 LLM Agent 场景里，我比较喜欢用一个类比：比赛评价一辆车时，不能只看发动机纸面马力，还要看变速箱、悬挂、轮胎、赛道条件和车手策略。发动机是模型，Harness 则是那套让发动机在赛道上真正跑出成绩的工程系统。

Harness 至少承担三件事：第一，把任务描述转换为模型可以处理的对话或动作指令；第二，在模型产生动作后，负责调用工具、读取环境状态并把结果回传；第三，在多个回合之后，把模型的执行过程转换成可打分的结果。简单说，它连接了模型和任务环境，并定义了智能体如何思考、行动、观察和终止。

2.2 Harness 中常见的模块

一个工程完整的智能体评测 Harness，通常会包含这些模块：

• 任务加载器：读取评测集，并将原始任务实例化到目标环境里；
• 对话管理：维护多轮 messages 列表，保证模型看到的上下文状态正确；
• 动作解析器：从模型自由文本中抽出 action，或直接消费 Function Calling 参数；
• 工具执行器：实际去调用搜索、数据库、网页、代码执行等工具；
• 反馈回填器：把工具返回结果拼装成模型能理解的消息；
• 状态检查器：判断任务是否已经完成、是否达到最大步数；
• 结果记录器：存储每个步骤的输入输出，便于后续复现；
• 指标计算器：按任务规则计算最终分数，或者调用评估模型打分。

如果你在调一个 Agent，却只关注模型权重版本而忽略这些模块的实现，那么测评结果很容易失真。因为修改任何一个模块都会直接决定模型能不能拿到有效信息。

2.3 Harness 与 Agent 框架的关系

有人会问：LangChain、LlamaIndex 这类框架算不算 Harness？更准确地说，Agent 框架是构建 Agent 的“开发库”，Harness 是把某个确定版本的 Agent 放进评测流程中的“运行驱动层”。你可以用 LangChain 写模型调用逻辑，但评测时还需要把 prompt、工具注册表、对话组装方式固定下来，这就是 Harness 的职责。

最近社区里越来越多人谈到“Harness Engineering”，也会出现类似“DeepSeek Harness”“Codex Harness”的说法。这些词并不是在说模型本身，而是在说围绕某个模型调优出的整套执行与评测环境。它们能成为热词，本身说明一个趋势：Agent 能力的比较，不再只是“模型参数和推理能力”的比较，还包括整个工程系统的设计质量。

3. 论文的核心命题与实验思路

3.1 “请停止比较”到底在反对什么

论文《Stop Comparing LLM Agents Without Disclosing the Harness》的核心主张是：如果研究论文、技术报告或产品发布只想把分数列出来并宣称自己比某个竞品好，却没有披露评测用的 Harness，这种比较缺少科学价值。

这里的“没有披露”包含两层问题。第一层是好坏问题：Harness 本身存在大量自由度，不同实现会显著改变结果，所以不披露就无法让读者判断分数是否可靠。第二层是复现问题：即使其他团队想复现实验，没有 Harness 的细节，也无从知道任务是怎么跑出来的。论文并不是全盘否定比较，而是要求比较必须建立在可审计的评测环境上。

3.2 实验设计上的启示：模型因素与 Harness 因素分开看

虽然我无法在这篇文章里完整复述论文里的每张实验表格，但它提出的实验设计思路是值得借鉴的，在团队内部做模型选型时尤其有用。

第一种做法是“固定 Harness，只换模型”。这种方式能比较出在相同条件约束下，模型本身的相对优势。第二种做法是“固定模型，只换 Harness”。这种做法更容易暴露出 Harness 是放大器还是限制器。假如同一个模型在 A Harness 下只能完成 30% 的任务，在 B Harness 下能完成 70%，而另一个模型在同样两组 Harness 下的表现却是反过来的，那就说明我们看到的结果很可能是“模型 × Harness”的交互效应，而不是单纯的模型能力差异。

论文标题用“不要比较”其实是一种提醒：当 Harness 属于系统的一部分时，我们得在报告里把“模型贡献”和“Harness 贡献”分开处理。否则，一个调得更好的 Prompt 模板或结果解析器，很容易被误报成模型能力的大幅提升。

3.3 “披露 Harness”的实际含义

“披露 Harness”不一定是要求把所有代码都公开，更合理的理解是，至少要公开一组可审计的评测配置。比如用哪个模型版本、哪个客户端的采样参数、构造了什么消息模板、工具如何执行、任务结束后如何判定成败、由哪个模型打分等。这些信息的作用是让读者能判断评测是否公正，也让后续研究者可以在同一套条件下继续比较。

用工程术语来说，这是给评测过程加上“版本管理”。你可以有自己的私有评测环境，但对外给出结论时，必须说明你的环境配置是什么。论文把“披露 Harness”当成比较 Agent 的必要前提，本质上是在推动评测透明化。那些只讲分数、不提供实验配置的对比，在科学严谨性上是不够的。

4. 用一个小 Demo 观测 Harness 的影响

为了把原理讲得更具体，我设计了一个最小可运行示例。它的思路是：固定同一个“模型后端”，分别用两种不同 Harness 跑同一任务，观察评测结果差异。示例采用模拟后端，不需要 API Key，可以直接运行。

4.1 示例场景与文件结构

假设业务里有一个订单结算智能体，任务是：某个订单包含 100 件电子产品，单价 399 元，请计算订单的总税额。这里的关键前提是：税率不能由模型凭记忆猜测，必须通过工具 lookup_tax_rate 查询业务系统，系统返回税率为 0.12。

我先创建下面文件结构：

agent-harness-demo/ ├── run_demo.py └── README.md（可选）

所有代码都写在 run_demo.py 中，完全可复制运行。运行环境方面，只要 Python 3.9 以上都可以，不需要安装第三方依赖。

4.2 先搭建一个可替换的模型后端

真实项目中，我们会调用 OpenAI 兼容接口或各家模型 SDK。我这里先用一个 MockBackend 模拟模型，它模拟的是“模型不知道业务系统里的真实税率，需要使用工具后才能正确计算”的合理行为。真实使用时，可以把 chat 方法内部替换成模型客户端。

# 文件路径：agent-harness-demo/run_demo.py import re TOOLS = { "lookup_tax_rate": { "description": "查询商品分类对应的税率，输入电子产品等品类名称", "run": lambda category: 0.12 if category.strip() == "电子产品" else 0.06 } } class MockBackend: """ 演示用模型后端。 真实项目可把 chat() 内部替换成 OpenAI 兼容 API： response = client.chat.completions.create( model="your-agent-model", messages=messages, temperature=0.2, ) """ def chat(self, messages): last = messages[-1]["content"] if "【工具结果】lookup_tax_rate -> 0.12" in last: return "最终答案：总税额 = 100 * 399 * 0.12 = 4788.00 元。" if "请直接给出最终答案" in last: return "无法直接给出可靠答案，因为我不清楚该业务系统内的真实税率，需要先查询税率。" return "调用工具查询税率：lookup_tax_rate(电子产品)"

这个模型后端的策略是：没有工具结果时，它不愿意编造税率；拿到工具结果后，它能完成乘法并给出最终答案。业务系统税率为 0.12 只是一个演示设定，不代表现实中的法定税率。

4.3 实现两种 Harness 并对比

下面这段代码分别实现了 FlatHarness 和 StepHarness。FlatHarness 只是把工具描述写进提示词，希望模型一步到位直接回答，但不会真正执行工具。StepHarness 则会解析模型输出中的工具调用，执行工具并把结果回填给模型，形成多一步的反馈闭环。

# 文件路径：agent-harness-demo/run_demo.py（继续追加） def flat_harness(model, question): """ FlatHarness：不提供真正的工具执行能力， 只把工具描述写进提示词，要求模型直接回答。 """ tool_doc = "可用工具：lookup_tax_rate(category)，查询品类税率。" messages = [ {"role": "system", "content": "你是订单结算助手。"}, {"role": "user", "content": f"{question}\n{tool_doc}\n请直接给出最终答案，不要假设税率。"}, ] response = model.chat(messages) success = False m = re.search(r"总税额 = [\d.]+ \* [\d.]+ \* [\d.]+ = ([\d.]+) 元", response) if m: success = True return { "response": response, "success": success, "score": 1.0 if success else 0.0, } def step_harness(model, question): """ StepHarness：支持工具调用。解析模型行动 -> 执行工具 -> 回填结果， 让模型拿到真实税率后再计算。 """ tool_doc = "可用工具：lookup_tax_rate(category)，查询品类税率。" messages = [ {"role": "system", "content": "你是订单结算助手，必须通过工具获取税率后计算。"}, {"role": "user", "content": f"{question}\n{tool_doc}"}, ] max_steps = 3 for _ in range(max_steps): response = model.chat(messages) messages.append({"role": "assistant", "content": response}) action = re.search(r"lookup_tax_rate\(([^)]+)\)", response) if not action: if "最终答案" in response: m = re.search(r"总税额 = [\d.]+ \* [\d.]+ \* [\d.]+ = ([\d.]+) 元", response) return { "response": response, "success": bool(m), "score": 1.0 if m else 0.0, } return { "response": response, "success": False, "score": 0.0, } tool_input = action.group(1).strip(" '\"") result = TOOLS["lookup_tax_rate"]["run"](tool_input) messages.append({ "role": "user", "content": f"【工具结果】lookup_tax_rate -> {result}", }) return { "response": messages[-1]["content"], "success": False, "score": 0.0, }

在 StepHarness 中，循环次数被限制为 3 次。实际长程评测系统里，这个 max_steps 通常允许模型调用几十次工具，但实现思路是一致的：解析动作、执行动作、回填观察、进入下一轮决策。

4.4 运行主函数查看结果

# 文件路径：agent-harness-demo/run_demo.py（继续追加） def main(): question = "某订单包含 100 件电子产品，单价 399 元，请计算该订单的总税额。" model = MockBackend() flat_result = flat_harness(model, question) step_result = step_harness(model, question) print("FlatHarness 结果：", flat_result) print("StepHarness 结果：", step_result) if __name__ == "__main__": main()

在终端里执行：

cd agent-harness-demo python run_demo.py

预期输出大致是：

FlatHarness 结果： {'response': '无法直接给出可靠答案，因为我不清楚该业务系统内的真实税率，需要先查询税率。', 'success': False, 'score': 0.0} StepHarness 结果： {'response': '最终答案：总税额 = 100 * 399 * 0.12 = 4788.00 元。', 'success': True, 'score': 1.0}

注意，这里的 MockBackend 行为是刻意设计的，所以运行结果非常干净。真实模型的行为不会这样二元化，但它足以帮助我们理解同一个模型在两种 Harness 下的“有效表现”差异：FlatHarness 根本不给模型拿到真实税率的机会，StepHarness 则把环境中的关键信息交给了模型。

4.5 从一步工具调用看长程评测

这个 Demo 只用了一个工具调用步骤，严格来说并不能算“长程任务”。但它的价值在于展示 Harness 影响模型的机制：模型的能力需要借助 Harness 提供的信息通道才能发挥。长程任务会把这种机制放大许多倍，模型每走一步都要依赖 Harness 正确处理状态、动作和反馈，任何一环做得不好，后续步骤就会连锁失败。

我在实际评测项目里经常看到类似现象：两个团队评测同一个开源模型，A 团队的 Harness 支持完整的工具结果回填和失败重试，B 团队的 Harness 却只是简单解析模型文本。最后 A 团队报告的成功率远高于 B 团队，但这不一定说明 A 团队调模型调得更好，只能说 A 团队把“评测环境”建得更完整。论文批评的正是这种不能被当作模型能力差异的系统差异。

5. 落地评测平台时，如何减少 Harness 带来的干扰

5.1 锁定 Harness 版本，像锁代码一样锁评测配置

生产项目里的依赖会升级，评测代码也一样会改动。为了得到可互相比较的结论，任何一次 agent 评测都应该使用确定的 Harness 版本。可以在评测入口处用一个 JSON/YAML 配置记录模型名、提示词版本、工具注册表版本、最大步数、温度等，这样每次评测报告都能追溯到具体环境。

# 文件路径：demo-eval-config.yaml eval_meta: project: order-agent-eval model_name: your-model-name model_version: commit-hash harness_version: v1.2.0 prompt_version: v3 task_set: long_horizon_seed_001 max_steps: 30 run_count: 5 temperature: 0.2 judge_model: your-judge-model-name judge_prompt_version: v1

这份配置的价值不在格式，而在“版本化”。当评测结果发生变化时，先查看是模型版本变了还是 Harness 版本变了，能省去大量排查时间。

5.2 让每一次任务记录都可完整回放

评测平台不能只保存最终分数，最好把每一步的完整日志都保存下来。比如模型发了什么动作、工具返回了什么结果、Harness 是否重试过、任务在哪一步失败。这样一旦分数异常，就能回到具体步骤观察是模型判断错误还是 Harness 解析错误。

记录日志时，我会按一次评测任务一个目录来存，内容包括原始任务文本、完整 messages 序列、工具执行时间、错误堆栈、打分结果等。虽然存储成本会比单轮问答高不少，但对于定位长程智能体问题来说，这一步是必要的。

5.3 先做 Harness 自检，再测模型

评测前可以准备一批“确定性任务”：任务的标准答案和流程步骤都是人工定义好的，甚至不需要真实模型参与，用一个规则脚本就能跑通。先用这批任务验证 Harness 本身是否正确，再让模型进场。如果规则脚本都跑不通，那就说明问题出在 Harness，测试大模型只会得到无效分数。

我在团队里通常把 Harness 自检拆成三块：工具调用是否能正确执行、工具结果是否能正确回填、结果抽取和打分规则是否稳定。这三块都通过后，模型的评测结果才具备解读价值。

5.4 控制并行、随机性和采样参数

长程智能体评测存在明显的不确定性。温度太高会让同一个任务跑两次结果不一致；并行过度可能让环境状态互相污染；评测集顺序变化也可能影响带缓存或有状态的环境。尽量固定随机种子、降低温度、串联运行有状态任务，或者至少多次运行并报告均值和失败样例。

论文强调 Harness 对评测影响重大，也包含这层意思：当我们没有控制好随机性时，模型之间的微小差异会被随机噪声淹没，而 Harness 中的细节则可能变成“稳定的噪声源”。想让结论可信，就得把可能影响结果的条件尽量固定下来。

6. 常见问题与误区

6.1 常见误区表格

下面整理几个我在评测中经常遇到的问题，可供快速对照。

6.2 不要简单迷信“Agent 榜单”

看到任何 Agent 排行时，先不要急着得出“模型 A 比模型 B 强”的结论。可以问几个问题：榜单的评测任务是什么类型？每个任务的执行环境是否一致？工具调用失败是否有重试？最终结果由谁判定？如果这些信息不完整，那么榜单更适合作为参考，而不是直接指导选型。

论文标题里用了“Stop Comparing”，并不是要求我们完全不做对比，而是希望对比前先解决评测环境的可比性。这也是工程师视角下最理性的做法：把模型能力从系统能力中剥离出来，能剥多少算多少。

7. 建设可复现评测体系的最佳实践

7.1 评测报告至少披露这些字段

如果要在内部报告或对外技术文章中给出 Agent 评测结论，建议至少记录以下字段：

• 模型名称与版本；
• 基础提示词模板及版本；
• Harness/Agent 框架版本；
• 工具函数列表与实现版本；
• 最大步数、超时、重试策略；
• 评测数据集版本与筛选规则；
• 评分方式：规则匹配还是 Judge 模型；
• 运行次数与随机种子；
• 失败任务的日志链接。

披露这些内容并不难，却能让读者快速判断你的评测结论在什么范围内成立。论文标题中的 Disclosing the Harness，落到日常工作中就是这张清单。

7.2 将评测代码纳入版本管理和 CI

现实中很容易出现“为了修一个临时 Bug 改了评测脚本，结果整个历史分数不可比”的尴尬。评测代码应纳入 Git 仓库，任何改动都走合并请求，并在改动后重新跑基线任务。可以用一组回归任务充当评测系统的“单元测试”，每次 Harness 变更都检查是否有异常分数波动。

当评测环境像业务代码一样被认真管理，模型升级或 Harness 升级带来的影响才可能被识别出来。否则，所谓能力提升只是环境漂移的幻影。

7.3 区分模型的失败与 Harness 的失败

长程智能体任务失败时，先做归因。如果模型输出了错误动作但动作本身可以被 Harness 正确执行，这是模型问题；如果模型输出了正确动作，但 Harness 没有调用到工具或没有把结果正确回传，这是 Harness 问题。把这两类失败分别计数，比只看一个总体成功率有价值得多。

一个实用的归因方式是记录失败点的快照：失败时模型看到了什么消息、上一个动作是什么、工具返回了什么。如果错误始终集中在某个工具解析环节，就去修 Harness；如果错误集中在模型对工具结果理解不足，再去换更大的模型或改 Prompt。

8. 结语与后续关注方向

这篇来自“Stop Comparing LLM Agents Without Disclosing the Harness”的核心批评，本质上是把智能体评测从“比模型”拉回到“比系统”的层面。对开发者而言，它带来的启发非常实际：模型很重要，但不能脱离评测环境谈模型。

后续关注方向可以有两条：一是 Harness Engineering 是否会进一步标准化，形成类似“评测驱动层协议”的东西；二是评测平台如何更好地把过程日志、动作空间、反馈机制纳入可审计范围，让不同团队之间能够做更有意义的对比。对普通项目团队来说，与其着急追逐新模型，不如先把评测环境版本化、透明化，让每一次“模型变强了”都建立在可信证据上。

下一次团队准备升级模型之前，可以先问一句：我们上次评测用的 Harness 还完整保留着吗？提示词、工具、判分脚本的版本都锁定了吗？如果这两个问题都回答不了，那结果里看起来几个点的提升，很可能只是噪声。