企业官网建设流程全解析

最近读论文时，我撞上一个让人没法忽视的标题：《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 代码”，模型一次输出就能完成，外部脚手架的影响很小。

但长程智能体任务完全不同。它需要模型在一个动态环境里连续行动，可能是浏览器操作、代码仓库修复、数据分析、客服流程处理，通常要跑几十步甚至上百步。每一步都要经历：

1. 观察当前环境状态；
2. 结合历史信息做决策；
3. 选择一个工具并生成参数；
4. 等待工具返回结果；
5. 把结果写回上下文，进入下一步。

这个循环只要有一个环节出错，后续任务就可能跑偏。如果 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 有多“偏心”。

具体可以按这个流程走：

1. 挑选 5 到 10 个有代表性的长程任务，先不追求数量；
2. 固定一个主候选模型；
3. 定义一个 baseline harness，比如你当前项目里默认采用的配置；
4. 固定随机种子，把所有任务各跑一遍，记录成功/失败/卡在哪一步；
5. 接下来每次只改一个 harness 变量；
6. 观察同一个模型在单变量变化下的成功率、失败点和平均步数。

你可能会发现，改动系统提示词里的一句话，或者给工具调用加一次重试，成功率变化 20 个点都是可能的。这不是罕见现象，而是 Agent 评测刚起步时最容易被忽略的真相。

4.2 两轮实验法：先找 harness 基线，再比较模型

真正合理的模型比较，最好在一个“模型 × harness”的矩阵里进行，而不是只固定一套 harness 然后换模型。

如果你只有时间做两轮实验，可以这样安排：

第一轮，固定一个模型，比较几个有代表性的 harness。目的不是找出“最好的 harness”，而是看你的任务对 harness 的敏感度到底有多高。如果结果波动很小，说明模型可以独立比较；如果结果波动很大，说明当前任务里，harness 才是核心杠杆变量。

第二轮，固定一套你已经长期维护的 production harness，再比较模型 A 和模型 B。你可以把结论写成“在当前 harness + 任务集下，模型 A 比模型 B 更合适”，而不是“模型 A 比模型 B 更强”。

这两轮实验的差别，是能不能保证结论可解释的关键。

4.3 用“模型 × harness”矩阵代替一张分数表

如果你同时想考察两个模型和两套 harness，可以直接列一个结果矩阵：

只看这张表，你会得出两个不同判断：

• 如果只固定 H0，模型 B 是更好的选择；
• 如果只固定 H1，模型 A 反而优势明显；
• 如果把两个 harness 都看一遍，你会发现自己根本不能笼统说“谁更强”，只能说“谁在什么配置下更适合什么任务”。

很多评测之所以给人错觉得，不是因为模型差异不存在，而是因为只做了一个点的比较。 Agent 系统太复杂，单点结果承载不了那么多解释压力。

4.4 把评测过程当作工程产物来记录

建议每个评测任务都建立一个实验记录，字段至少包含：

• 实验 ID；
• 评测日期；
• 模型名和版本；
• harness 仓库 commit hash；
• 核心配置文件名和哈希；
• 系统提示词 hash；
• 评测集版本；
• 结果文件路径；
• 运行日志路径；
• 复现命令。

如果团队里有人想在一个月后重新跑同一个结果，这些信息能让复现更容易。否则，很可能连你自己也解释不了当初的结果是怎么来的。

5. 复现失败？按这个顺序先查 harness，再怀疑模型

5.1 先归类现象

复现不出别人的 Agent 结果时，不要一上来就换模型。先看现象是哪一种：

• 完全无法跑通：可能是依赖环境、工具定义或模型返回格式不一致。
• 能跑但结果忽高忽低：可能是采样参数、seed 或上下文管理没见过。
• 结果稳定但总体偏低：大概率是系统提示词、成功判定标准或终止条件不一致。
• 个别任务分数高得离谱：先怀疑评测集污染或评分器有偏好。

现象分类能帮你快速缩小范围，避免把时间耗在错误层面。

5.2 按“harness 优先”链路逐层排查

如果你对照的论文或开源项目没有公开足够配置，可以用下面的排查顺序从工程层找差异。

这个顺序不是从代码开始，而是从“模型外的那层”开始。因为多数 Agent 复现失败，根本原因都在 harness，而不是模型权重。

5.3 记录差异根因，而不是只记一个“复现率”

当你通过一次改动让结果从 20% 变成 45%，不要只是高兴。记录下这个改动是什么，并把它当作敏感变量去理解。

比如：

• 改动一：把工具描述前加了一句“请结合历史信息选择最合适的参数”，成功率提升了；
• 改动二：给工具调用失败增加了一次重试，成功率再提升；
• 改动三：把最大步数从 10 改成 20，成功率也提升了。

这些改动叠在一起，最有可能解释你和他人的结果差异。如果你把这些信息写进一篇博客或评估报告，那后面的读者就不会再经历一轮盲猜。

6. 排行榜、模型选型和日常使用中的信息减法

6.1 排行榜更准确的名字：Agent 系统排行榜

榜单不是不能存在，但应该被重新命名。

一个不披露 harness 的 Agent 排行榜，本质上是“某个 harness + 某个模型 + 某个评测集”的一次性快照。有人看榜单选模型，买回去后发现实际业务完全不是那么回事，原因往往不是模型被高估，而是那张榜单背后藏着一套他没见过的 harness。

如果论文作者或评测方愿意公布 harness，榜单名称就应该改成“xx 平台配置下的模型对比”。读者至少能判断：这个配置和自己的使用场景是否接近。否则，一个泛化的排行榜只会不断制造误导。

6.2 工程选型要看组合，不要只看单点分

对实际业务来说，更重要的不是“哪个模型通用能力最强”，而是“哪组配置在我的任务和环境下最稳定”。这里你可以把模型和 harness 当成一个整体来做选型。

一个务实的做法是：

1. 固定你自己的 production harness，也就是团队打算长期维护的那套工具调用和记忆配置；
2. 候选模型 2 到 3 个；
3. 跑一组贴近业务的长程任务；
4. 不只看最终成功率，还要看失败重试率、单任务成本、平均耗时、日志可解释性；
5. 选一个在“当前 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 放到桌面上，再开口说你的模型比它强。