最近读论文时我撞上一个让人没法忽视的标题《Stop Comparing LLM Agents Without Disclosing the Harness》。翻译成大白话就是别在不披露 harness 的情况下比较 LLM Agent。看见这种句子第一反应会觉得有点绝对但如果你真的去复现过几篇 Agent 评测就会明白它更像是一句迟到多年的警告。过去很长一段时间我们习惯把 Agent 评测结果解释成“模型 A 比模型 B 强”。但模型只是被评测系统里的一层真正驱动整个多步任务跑完的是包在模型外面的 harness。什么是 harness简单说就是模型之外让 Agent 能持续决策、调用工具、接收反馈、管理记忆、判断何时结束的那套脚手架。很多人把它当作“工程细节”可论文标题直接抛出一个反直觉的判断在长程智能体评测上harness 的影响可能超过模型本身。如果这个判断成立那我们平时看到的不少对比实验、排行榜和选型报告都建立在很薄的假设上。今天这篇博客我想把这层问题拆开为什么 harness 会主导长程评测披露时到底该披露什么以及作为研究者和工程师怎么避免被隐藏的 harness 带偏。1. harness躲在模型身后却决定模型能不能“跑起来”1.1 一句人话解释 harness很多读者看到 harness 会条件反射地以为是“测试框架”。在 LLM Agent 语境里它更接近 Agent 的整套运行脚手架。你可以把大模型想象成一个聪明但容易失忆、容易跑题的实习生。给他一个简单任务他可能直接答出来但让他完成一个需要连续处理十个步骤、调用多个工具、途中还要应对报错的任务他能不能顶下来很大程度上取决于公司给他配了什么。harness 就是那张工作台上面有岗位手册、工具清单、审批流程、便签纸、提醒机制还有出错以后谁来补救的规则。具体到代码层面harness 会包含这些东西系统提示词和任务拆解指令Agent 的主循环结构比如 ReAct、Plan-and-Execute或者多智能体协作工具的定义、调用方式、返回值解析模型返回内容的解析策略上下文管理比如截断、压缩、摘要、历史记录保留失败重试、超时判断、停止条件结果输出和打分规则同样是调用一个工具不同的 harness 可能给模型看到不同的工具描述、不同的示例、不同的参数格式这会让模型的选择完全不同。同样是一次工具返回错误有的 harness 直接把错误文本丢给模型有的会清理历史、重新格式化后再让模型继续最终成功率自然不一样。1.2 在长程任务里harness 不是外围是主流程短任务通常不太需要担心 harness。比如“把这段英文翻译成中文”“写一段 Python 代码”模型一次输出就能完成外部脚手架的影响很小。但长程智能体任务完全不同。它需要模型在一个动态环境里连续行动可能是浏览器操作、代码仓库修复、数据分析、客服流程处理通常要跑几十步甚至上百步。每一步都要经历观察当前环境状态结合历史信息做决策选择一个工具并生成参数等待工具返回结果把结果写回上下文进入下一步。这个循环只要有一个环节出错后续任务就可能跑偏。如果 harness 没有把模型输出格式处理好模型生成了半截 JSON工具调用直接失败如果 harness 没有正确截断或总结上下文模型到第 20 步时已经完全忘了前面的目标如果 harness 没有重试机制一次网络抖动或工具超时就会让整个任务被判失败。这些都不是模型能力问题而是 harness 是否把模型保护好的问题。1.3 harness 与 agent 的区别agent 是“模型脚手架”的组合行为很多讨论里agent 和 harness 经常被互相替换但其实概念应该分清楚。模型是一个静态参数集。agent 是模型之外还包含任务规划、工具调用、记忆管理等机制后形成的整体系统。同一个模型接上不同的 harness产生的是两个不同的 agent。这也是为什么论文标题会说“Stop Comparing LLM Agents Without Disclosing the Harness”。因为当你说“Agent A 比 Agent B 强”的时候你真正比较的是一整套组合而不是底层的某一个模型。如果组合里的 harness 存在明显差异那结论就可能反过来了你测出来的不是模型谁更强而是脚手架谁更顺手。2. 一篇论文为什么要提出“先披露再比较”2.1 长程评测里误差和偏差会被不断放大长程任务有一个短任务不具备的特性复合误差。短任务里模型犯一次错可能只会影响当前答案的一个点。长程任务里前一步的错误会被带到后一步后一步的错误又会污染再后面的决策。如果整个过程有 30 步哪怕每步只有 2% 的概率出问题最终成功率也会明显下降。而这个概率不是只来自模型更多来自 harness 在每步循环中如何处理输入输出。比如上下文截断。上下文窗口有限任务很长时模型不可能把所有历史都留在窗口里。有的 harness 只保留最近三轮对话但把任务的原始目标给截掉了另一种 harness 会保留高层目标并把中间步骤压缩成摘要。在两种配置下跑同一个模型任务成功率很可能差出很大一截。再比如重试策略。同样遇到工具调用失败一种 harness 直接终止并把失败原因当作答案另一种 harness 会向模型反馈“刚才这个工具返回了某某异常请重新生成参数”。后者给了模型第二次机会前者没有。放到几十步的长程任务里这种差异会被反复累积。所以论文标题提出“harness 的影响可能超过模型本身”并不是危言耸听而是对长程评测中常见现象的一个概括。2.2 不披露 harness读者无法判断功劳归属假设有人报告说模型 A 在某项 agent 任务上比模型 B 高了 20 个百分点。这个结论会让人立刻觉得“模型 A 更强”。但如果他给模型 A 配的 harness 支持失败重试、长文本摘要、任务规划给模型 B 用的只是最简单的状态机循环那么这 20 个百分点的差异根本不能归给模型。这并不是说论文作者一定有这个意识。很多实验可能只是顺手用了自己团队内部的脚手架并没有刻意让两个模型处于同等条件。可问题在于不披露结果就无法被解释。更重要的是评测的目的不只是看谁“赢面大”而是看“为什么赢”。不披露 harness几乎所有关于“为什么”的讨论都会失真是模型推理能力强还是 harness 给了它更多纠错机会是模型更懂工具调用还是 harness 把工具描述写得足够详细是模型长程规划能力好还是 harness 在每一步都帮它列出了候选项没有这些信息读者只能得到一个大数字。久了以后排行榜就失去了指导价值。2.3 标题的潜台词停止比较而不是停止开发“Stop Comparing”听起来很激进但我们不能把这句话理解成“禁止做模型对比”。它的真正意思是当你还不愿意把 harness 说清楚时比较本身就是无效劳动。这不是反对进步而是希望评测先回到一个能对结论负责的坐标系里。更合理的解读是你可以比较模型但必须把 harness 当成一个可明示、可固定、可审查的变量。否则你比较出来的东西没有可解释性也没有可复现性。3. 如果真要披露 harness最小披露清单长什么样好的声明总是具体的。与其泛泛说“我们用了默认配置”不如把那份配置真正拿出来。下面是一份我认为比较可行的小披露清单按影响从大到小排列。3.1 第一层模型与采样信息这是目前很多人已经会写的部分但往往还少几个字段。至少需要记录模型名称和版本比如某个模型的日期版本或稳定版本号API 供应商或本地部署地址对应的部署版本temperature、top_p、max_tokens、seed尤其是 seed 是否固定是否使用了结构化输出模式、JSON mode 或 function calling 专用接口。同一个模型在不同采样参数下的行为差异非常大。长程任务中如果 temperature 过高模型的工具参数就可能频繁漂移如果某个 Agent 框架内部默认用了不同的 system prompt也会影响结果。3.2 第二层提示词和工具交互协议这部分最容易被省略因为它看起来只是“配置”不是模型权重。但它可能是对结果影响最大的单个变量。建议至少披露系统提示词全文或者至少提供不可逆的完整哈希用户指令模板工具的总数、名称、描述、参数结构以及是否有 few-shot 示例工具返回结果处理规则比如截断长度、是否过滤错误信息模型输出解析失败时的处理逻辑。你可以试着做一次实验同一个模型同样的任务只把工具描述从“根据用户需求调用函数”改成“根据用户意图选择合适的函数如果输入不完整请先向用户确认”结果很可能立刻变化。工具描述中的微小措辞会影响模型在 open-ended 任务里的决策路径。3.3 第三层循环控制、记忆策略和重试逻辑这可能是 Agent 评测中最像“模型能力放大镜”的部分。需要写清楚主循环是单 Agent 还是多 Agent如何做任务规划最大步数上限是多少达到上限后是不是直接判失败失败后的重试次数、重试是否清空历史是否允许模型在每步间“自我反思”反思结果是否写入上下文上下文管理方式是截断、压缩还是自动摘要触发阈值是什么历史信息中是否会保存工具返回的原始长日志。这些变量在长程评测里几乎主导一切。一个带轻量反思循环的 harness可以让同一个模型在复杂任务上表现出更强的纠错能力。可如果论文只写“我们使用 Agent 框架”读者完全无法判断实验到底怎么跑的。3.4 第四层任务环境与成功判定标准模型和 harness 之外评估环境的差异也要记录。建议包括环境版本、配置文件和依赖任务数据集的版本和过滤规则成功判定的方法是人工还是脚本还是另一个大模型prompt 中是否包含了标准答案或暗示性信息评测任务是否做过难度分层如果有自动评分器它的版本和提示词也需要披露。现实里有很多评测结果差距来自评分器差异。自动评分器宽松一点成功率就高严格一点立刻掉几个点。如果只报最终数字不报判定过程那这个数字几乎无法复现。3.5 披露到什么粒度才算够一个简单标准另一位研究者拿到你的论文描述后能不能在不猜谜的情况下复原出你认为合理的 Agent 行为不需要把所有代码都贴进正文但关键配置应该像软件发布一样有版本号。你可以提供代码仓库的 commit hash一份完整的配置文件提示词全文或哈希评测环境的 Dockerfile 或依赖锁文件评测判定脚本。如果用的是商业 harness 或闭源平台至少也要给出平台名称、版本号、关键可配置项以及“如果你也打开某个开关会得到更接近你的结果”的说明。4. 实操别急着比模型先把 harness 变量拉出来4.1 最小实验协议固定模型先扫 harness 变量如果你正在做一个长程 Agent 项目并且想判断两个模型哪个更适合当前业务我建议你先不要直接跑 100 个任务去比模型。第一步应该是先理解你的 harness 有多“偏心”。具体可以按这个流程走挑选 5 到 10 个有代表性的长程任务先不追求数量固定一个主候选模型定义一个 baseline harness比如你当前项目里默认采用的配置固定随机种子把所有任务各跑一遍记录成功/失败/卡在哪一步接下来每次只改一个 harness 变量观察同一个模型在单变量变化下的成功率、失败点和平均步数。你可能会发现改动系统提示词里的一句话或者给工具调用加一次重试成功率变化 20 个点都是可能的。这不是罕见现象而是 Agent 评测刚起步时最容易被忽略的真相。4.2 两轮实验法先找 harness 基线再比较模型真正合理的模型比较最好在一个“模型 × harness”的矩阵里进行而不是只固定一套 harness 然后换模型。如果你只有时间做两轮实验可以这样安排第一轮固定一个模型比较几个有代表性的 harness。目的不是找出“最好的 harness”而是看你的任务对 harness 的敏感度到底有多高。如果结果波动很小说明模型可以独立比较如果结果波动很大说明当前任务里harness 才是核心杠杆变量。第二轮固定一套你已经长期维护的 production harness再比较模型 A 和模型 B。你可以把结论写成“在当前 harness 任务集下模型 A 比模型 B 更合适”而不是“模型 A 比模型 B 更强”。这两轮实验的差别是能不能保证结论可解释的关键。4.3 用“模型 × harness”矩阵代替一张分数表如果你同时想考察两个模型和两套 harness可以直接列一个结果矩阵模型 / HarnessHarness H0简单循环Harness H1带反思与摘要模型 A18%45%模型 B26%38%只看这张表你会得出两个不同判断如果只固定 H0模型 B 是更好的选择如果只固定 H1模型 A 反而优势明显如果把两个 harness 都看一遍你会发现自己根本不能笼统说“谁更强”只能说“谁在什么配置下更适合什么任务”。很多评测之所以给人错觉得不是因为模型差异不存在而是因为只做了一个点的比较。 Agent 系统太复杂单点结果承载不了那么多解释压力。4.4 把评测过程当作工程产物来记录建议每个评测任务都建立一个实验记录字段至少包含实验 ID评测日期模型名和版本harness 仓库 commit hash核心配置文件名和哈希系统提示词 hash评测集版本结果文件路径运行日志路径复现命令。如果团队里有人想在一个月后重新跑同一个结果这些信息能让复现更容易。否则很可能连你自己也解释不了当初的结果是怎么来的。5. 复现失败按这个顺序先查 harness再怀疑模型5.1 先归类现象复现不出别人的 Agent 结果时不要一上来就换模型。先看现象是哪一种完全无法跑通可能是依赖环境、工具定义或模型返回格式不一致。能跑但结果忽高忽低可能是采样参数、seed 或上下文管理没见过。结果稳定但总体偏低大概率是系统提示词、成功判定标准或终止条件不一致。个别任务分数高得离谱先怀疑评测集污染或评分器有偏好。现象分类能帮你快速缩小范围避免把时间耗在错误层面。5.2 按“harness 优先”链路逐层排查如果你对照的论文或开源项目没有公开足够配置可以用下面的排查顺序从工程层找差异。排查层核心问题常见原因Harness 版本两边用的是同一个 commit 或同一个版本吗框架升级后默认行为变化系统提示词提示词是否完全一致很多项目只写“默认 prompt”工具描述工具 schema 和 few-shot 示例是否一致描述会影响模型选工具上下文策略截断长度、摘要阈值、历史保留策略是否一致长程任务对记忆很敏感循环控制最大步数、停止条件、重试次数是否一致不同上限导致完成度不同输出解析模型输出解析失败时是重试还是直接失败解析错误会制造大量假失败环境与评分任务环境版本与成功判定标准是否一致判定不同结果差距巨大这个顺序不是从代码开始而是从“模型外的那层”开始。因为多数 Agent 复现失败根本原因都在 harness而不是模型权重。5.3 记录差异根因而不是只记一个“复现率”当你通过一次改动让结果从 20% 变成 45%不要只是高兴。记录下这个改动是什么并把它当作敏感变量去理解。比如改动一把工具描述前加了一句“请结合历史信息选择最合适的参数”成功率提升了改动二给工具调用失败增加了一次重试成功率再提升改动三把最大步数从 10 改成 20成功率也提升了。这些改动叠在一起最有可能解释你和他人的结果差异。如果你把这些信息写进一篇博客或评估报告那后面的读者就不会再经历一轮盲猜。6. 排行榜、模型选型和日常使用中的信息减法6.1 排行榜更准确的名字Agent 系统排行榜榜单不是不能存在但应该被重新命名。一个不披露 harness 的 Agent 排行榜本质上是“某个 harness 某个模型 某个评测集”的一次性快照。有人看榜单选模型买回去后发现实际业务完全不是那么回事原因往往不是模型被高估而是那张榜单背后藏着一套他没见过的 harness。如果论文作者或评测方愿意公布 harness榜单名称就应该改成“xx 平台配置下的模型对比”。读者至少能判断这个配置和自己的使用场景是否接近。否则一个泛化的排行榜只会不断制造误导。6.2 工程选型要看组合不要只看单点分对实际业务来说更重要的不是“哪个模型通用能力最强”而是“哪组配置在我的任务和环境下最稳定”。这里你可以把模型和 harness 当成一个整体来做选型。一个务实的做法是固定你自己的 production harness也就是团队打算长期维护的那套工具调用和记忆配置候选模型 2 到 3 个跑一组贴近业务的长程任务不只看最终成功率还要看失败重试率、单任务成本、平均耗时、日志可解释性选一个在“当前 harness 当前场景”下综合收益最高的模型。如果未来模型升级也不能只换模型因为新模型可能对旧 harness 的提示词风格和输出格式更敏感。正确做法是重新跑一遍同场景评测。6.3 “harness 工程”正在变成一个独立关注点模型领域的社区讨论也正在发生这种变化。不管是某些项目里被反复搜索的“deepseek harness”相关关键词还是像“agent harness”“harness工程”这样的表述开始变多都能看出一个趋势大家已经把模型和脚手架分开审视了。这并不是说某个带模型名前缀的 harness 一定成熟而是说明 harness 开始变成一件可以被独立安装、配置、调优和传播的东西。过去它只是论文里的一行字现在更像是 Agent 领域里的一条新基础设施。对一个还没找到合适评测方法的人来说这意味着你不必等到模型 API 更新换代才做实验你可以先把 harness 版本固定下来把工具接口管理好把日志和评估脚本沉淀成团队资产。6.4 边界不是所有差异都是 harness 的锅强调 harness 重要不等于反过来说模型不重要。边界条件同样要写清楚如果两个模型在多种差异很大的 harness 下都保持稳定高低关系那模型差异是真实存在的如果某个模型在同一 harness 下总是输给另一个模型即使你已经调过提示词、重试、记忆策略那很可能就是模型本身的能力边界如果任务只要求一次输出没有多步工具调用harness 的影响就会小非常非常多。真正负责任的评测应该同时承认模型和 harness 都是变量。我们需要做的是把它们拆开讨论而不是把所有功劳或问题都扣到模型头上。7. 与其继续争“谁更强”不如先把 harness 放上台面7.1 刚入门的人最该养成的习惯不是追新模型如果你刚开始做 LLM Agent 相关工作我的建议很简单先选一个你能完全控制的 harness把每一步的输入、输出、工具调用和失败日志都记录下来。先在一个任务上把系统跑通再考虑换模型、换提示词、换记忆策略。你不需要一开始就配一套复杂的多智能体系统。一个最简单的循环给模型工具列表让它生成工具调用解析结果把结果返回给模型再决定下一步。只要你能把这个循环里的每个变量都描述清楚你以后的评测就会比大量只看最终分数的人扎实得多。7.2 长期做 Agent 的团队把评测配置纳入代码审查如果你的团队已经在开发 Agent 产品我建议你把“harness 配置审查”纳入日常流程。每次 Agent 行为变化或者模型升级不是只留一句“效果变好了/变差了”而是要回答四个问题prompt 和工具描述有没有变agent 循环和控制参数有没有变记忆策略和上下文处理有没有变评测数据和成功判定标准有没有变任何一条变化都应该有记录和 diff。Agent 系统的可复现性不来源于某一次漂亮的实验结果而来源于每次变化的来源都可追溯。7.3 真正值得长期关注的东西可解释的 Agent 评估如果我们把这篇论文的观点延伸一下会发现 Agent 评测目前最缺的不是更多分数而是一套可解释、可复现、可审查的方法论。当一个领域开始大量出现“模型 A 比模型 B 强”的结论时往往意味着它还在早期。早期判断很容易被表面差异带偏因为大家都还没学会把变量拆开。等越来越多的研究者愿意公开自己的 harness、配置和判定逻辑Agent 领域才会从“能不能赢”进入“为什么会赢换台机器还能不能赢”的新阶段。到那时候模型仍然是重要变量但任何人都没办法再用一个隐藏的 harness 去制造一场不公平的比赛。这在所有工程技术领域里都是最基本的底线。先把自己的 harness 放到桌面上再开口说你的模型比它强。