企业官网建设流程全解析

模型又在基准测试上通关了，这次被讨论最多的不是参数规模，而是它背后那个叫Harness的评测框架。看到“Opus 5通关ARC-AGI-3”这类的消息，多数人的第一反应是问“分数多少”“是不是真的”。但真正值得拆开的，是模型在什么条件下跑完整套测试：提示词怎么写的、工具调用开到了什么程度、失败任务有没有重试、评分规则是严格匹配还是人工放水。这些问题，全部属于Harness的范畴。

如果只看热闹，你可能会觉得这是一次模型能力的胜利。但做过评测工程的人会先问一句：这个Harness是帮模型把正常水平发挥出来，还是替模型垫了台阶？从Opus 5、ARC-AGI-3到Harness，这三个词串起来，背后其实是同一个现象：大模型的评测，正在从“跑一个脚本出结果”变成一门需要认真对待、也会产生误导的工程。

这篇文章不打算论证“哪个模型更强”，而是想把评测这件事拆开。ARC-AGI系列到底在测什么，Harness在其中起什么作用，为什么说它正在变成捆住模型的绳子，以及作为开发者，怎么避免被评测成绩带偏。

1. 一个通关消息，最该先看的是评测框架

1.1 为什么模型名字最容易骗人

大部分人看到“Opus 5通关ARC-AGI-3”的第一感觉，是“这个模型很厉害”。这个判断可以理解，但不够严谨。

同一套基准，可以有很多种测法。最简单的测法是直接把题目图丢给模型，让它硬想，然后看输出。复杂一点的测法，是给模型搭一个完整的工作环境：提供示例、允许写代码、允许跑多次、中途给反馈、最后再汇总答案。这两种测法对同一个模型来说，成绩可能差出几个档位。

也就是说，当你听到“模型通关了基准测试”时，真正重要的不是模型叫什么名字，而是它外挂了哪些工具、被给了多少额外机会。

这个道理在传统机器学习里也成立，只是很多人没有意识到。一个分类器在测试集上拿高分，有可能是因为数据清洗时把重复样本漏掉了，也有可能是因为测试集和训练集有重合。评测框架就是一个放大镜，它能让模型的真实能力显现，也能捏造出一个虚假的“强模型”。

1.2 三条判断标准，比分数本身更重要

我一般会建议身边刚接触大模型评测的朋友，先别急着背分数，先问三个问题。

第一，测试是不是封闭式的。模型是否见过测试集，数据是否从同一个分布里采样，测试过程中有没有人工干预。如果测试集本身出现在训练数据里，分数就没有多少参考价值。

第二，测试环境是不是最小干预的。模型是裸推理，还是给了代码执行、网络搜索、长思考提示词、多轮自我反思？这些外部能力会放大模型表现，但也意味着你测的并不是模型本身。

第三，评分是自动匹配还是人工判断。ARC这类任务通常有标准答案，可以自动比对网格。但有些评测会用大模型当裁判，这就会引入裁判偏好。一旦裁判误判，分数就不稳定。

这三个问题，其实都落在同一个词上：Harness。Harness就是那个把模型架起来跑测试的外部框架。它负责所有“不是模型本身、但会影响模型输出”的部分。

1.3 这次话题里，为什么Harness成了主角

回到标题本身：“Harness正在变成捆住模型的绳子”。

我理解这个判断的背景是，最近围绕模型的评测和Agent实践，大家越来越依赖Harness。DeepSeek有围绕它的Harness实践，Codex也有自己的Harness，各种开源项目里也频繁出现Harness这个关键词。它已经从测试框架延伸到日常开发工具，变成了模型使用方式的一部分。

问题也随之而来。同一个模型，换一个Harness，结果可能完全不同。模型本身的能力没变，变的是外部环境。于是，模型评测成绩越来越不是“模型能力的度量”，而是在度量“模型加Harness系统”的整体性能。

这不算坏事，真实产品里本来就是模型加工具加流程的组合。但如果把这种成绩直接解读为“模型智能水平”，就是被评测带偏了。

2. ARC-AGI到底在测什么，以及为什么版本越来越难

2.1 一套反记忆的推理任务

ARC-AGI的全称是Abstraction and Reasoning Corpus，也就是“抽象与推理测试集”。

它和传统基准测试最大的区别，是故意设计成“不能靠背”的形态。每个任务都是一个小型网格，通常几格到几十格，格子里有不同颜色的色块。输入是一组示例，输出是另一组示例，模型要根据示例推导出变换规则，然后预测新输入对应的输出。

听起来很简单，但实际非常难。因为每个任务只有少量示例，模型不能靠大量统计规律去拟合。它必须“看”出规则，可能是对称变换、形状补全、颜色替换、位置移动，也可能是这些规则的组合。人类做这种题也要花点时间，机器更容易被小样本干扰。

所以ARC-AGI虽然不是严格意义的通用智能测试，却一直被当作“抽象推理能力”的重要参考指标。它更接近智力测试，而不是知识问答。

2.2 从第一版到第三版，难度在往哪里加

ARC-AGI-1在2019年前后发布，它率先提出了“从少量示例中学习规则”的评测思路。社区后来跑了很多模型，成绩普遍不理想，说明它不是靠堆参数就能过的。

ARC-AGI-2是之后推出的升级版本。从公开讨论来看，它保留了小网格推理的形式，但在任务设计上加入更多干扰项，也把不少人类解题过程变长。换句话说，以前一眼能看出来的规则，现在需要更多推理步骤，或者存在容易误导的细节。

ARC-AGI-3是这个系列的最新迭代，也就是标题里提到的版本。它延续了前两代的路线，但根据社区讨论，难度和防记忆设计都在继续加码。这里我没有官方数据，也不确定具体题量和评分规则，只能说：如果前两代已经很难，第三代大概率会更难。

这个“越来越难”的方向是合理的，因为基准只有不被刷穿，才有持续存在的价值。一旦模型在某套测试上逼近满分，测试就该升级了。

2.3 为什么大模型在ARC上容易翻车

大模型在对话、写作、代码生成上表现很强，但面对ARC任务时经常翻车。原因有几个。

第一，ARC任务需要结构化推理。模型需要先理解网格里每个色块的位置关系，再抽象出变换规则。这比生成一段自然语言更依赖结构化的推理过程。

第二，任务样本太少。语言模型靠大量文本训练，擅长从上下文中找统计关联。但ARC每个任务只有几个示例，统计线索非常稀疏。

第三，结果判定严格。ARC的输出是网格，错一个色块就算错。不像文本生成，可以接受部分正确。这种二值判定对大模型很残酷。

这些原因决定了，ARC这类任务不能单靠模型的“直觉”完成，需要在推理过程中反复尝试、检查、修正。而这个过程，恰好给了Harness发挥空间。

3. Harness的双面身份：辅助工具和隐形束缚

3.1 Harness到底做了什么

简单说，Harness是模型运行时的一切外部配套。

往细了看，它包含这些组件：

• 提示词管理和任务说明
• 输入数据的预处理和格式转换
• 模型调用方式，比如温度、top_p、最大token
• 工具调用配置，比如代码执行环境、外部接口
• 输出解析和后处理
• 失败重试机制
• 评分逻辑
• 日志和监控

这些组件单独拿出来都不起眼，但它们组合起来，会对最终分数产生巨大影响。

举例来说，某项ARC任务要求“把某种颜色的格子全部替换成另一种颜色”。如果Harness把任务说明写得含糊，模型可能理解成其他规则。如果Harness允许模型写Python代码去试探规则，模型能在本地快速验证很多假设，最终准确率会高很多。同一个模型、同一个权重文件，只是外部环境不同，结果就可能天差地别。

3.2 Harness的辅助面：把模型的真实能力引出来

合理的Harness设计，确实能帮助模型发挥出真实水平。

比如给模型一个思考模板：“请先列出可能的规则，再选择一个最符合所有示例的规则，最后给出输出网格。”这能让模型不急于给答案，减少低级错误。

再比如允许模型在给定环境里执行Python代码，用代码枚举候选规则、验证规则是否正确。这种“自主探索”能力，在很多推理型任务里能显著提高准确率。

还有多轮反馈。模型先给一个预测，Harness检查后发现不对，把错误信息反馈给模型，让模型修正。这相当于给模型多次尝试机会。对复杂推理任务来说，这更接近人类解题过程中的试错。

这些做法没有任何问题，它们展示的是模型在合理辅助下的能力上限。问题只在于：当你把这个成绩绑定到“模型本身很强”的叙事上时，要提前说明成绩包含Harness的贡献。

3.3 Harness的束缚面：绳子是怎么勒紧的

但Harness也有另一面。

第一，提示模板可能成为束缚。很多Harness为了控制输出格式，把提示词写得很死，要求模型必须按“答案:xxx”的形式输出。这种强约束对文本简单的任务有效，但对复杂推理任务可能是灾难。模型需要更多token来表达思考过程，被截断在固定模板里，能力自然大打折扣。

第二，超时设置可能太短。ARC这类任务需要模型反复推演，如果Harness对单次推理设置了很短的超时，模型没想完就被强制返回，分数就会偏低。

第三，工具调用可能被限制。有的评测不提供代码执行环境，模型只能用语言推理。这本身就是一种环境限制，但在宣传成绩时容易被忽略。

第四，评分只看最终答案。有些模型推理过程是对的，只是在最后输出时格式不规范，被解析器判错。这种错误不能简单归因于“模型不会做”。

第五，重试逻辑也可能误导。一种Harness允许模型失败后自动重试一次，另一种不允许。这样评测出的分数差异，实际上来自调用策略，而不是模型能力。更麻烦的是，如果重试条件写得太宽松，模型可能每次都随机输出一个答案，遇到对的就算通过，这会让成绩虚高。

当一个模型在某个Harness里表现很好，但在另一个Harness里明显变弱时，我们就可以说，Harness部分地“捆住”了模型，或者反向地，替模型兜了底。它究竟是工具还是绳子，取决于设计者想要什么。

3.4 为什么“Harness工程”越来越热

从最近社区的热词来看，围绕DeepSeek、Codex等模型的Harness实践非常活跃。这说明大家已经意识到，模型能力不是孤立存在的，模型与外部框架的配合方式，甚至比单个模型的选择更重要。

这个趋势在工程上是对的。真实产品里，没有模型是裸奔的，都要通过API、工具、流程来使用。把Harness做得好，产品确实能取得超过单模型的效果。

但反过来说，如果评测圈把模型成绩过度归功于模型本身，忽略Harness的贡献，就会形成误导。这也是“Harness正在变成捆住模型的绳子”这句话的真正含义：工具本来是提高上限的，现在却变成了定义成绩的隐藏变量。

4. 从“能不能跑”到“跑得对不对”：评测工程化的实战细节

前面说了很多概念，这一节落到实操。不管你是想复现别人的评测，还是想搭建自己的评测流程，下面的细节都会踩到。

4.1 环境准备，先别急着跑

以ARC-AGI这类任务为例，环境准备包括四块。

第一是硬件。推理小模型还好，跑大模型需要至少一张足够显存的显卡。显存不够，批量处理时频繁换入换出，速度会非常慢，还容易OOM。内存也要留足，数据集和模型权重文件通常都不小。磁盘空间要看模型大小和日志量，建议多留几十GB给临时文件。

第二是依赖版本。模型推理框架和Python版本、CUDA版本、驱动版本之间的匹配非常敏感。同一个模型，框架版本不同，生成结果都可能不一样。评测前最好用需求文件或者容器镜像，把依赖版本固定住。

第三是数据准备。ARC任务通常包含训练示例和测试输入，输入输出都是网格数组。下载后要检查文件完整性，不要把测试样例当训练样例。如果格式不对，后面解析那一关就会出问题。

第四是模型权重和评测代码的路径。路径写错是最常见的低级错误，但也是最容易浪费半天时间的问题。我一般会把模型权重、数据集、日志、输出分别放在独立目录，用配置项指定路径，而不是硬编码。

4.2 先跑通单条任务，再谈批量

很多人一上来就写一个循环，把几百条任务全部跑完，然后看平均分。这个做法在刚开始时风险很大。

我更建议先筛出三五条代表性任务，手动跑一遍，确认三个环节都正常：

• 模型能正常加载
• 提示词能被模型接受
• 模型输出能被解析器正确转换成网格

这一步很容易暴露问题。最常见的是模型输出里混了解释文字，比如“我觉得规则是……所以答案是……”，但Harness的解析器只认方括号数组，于是一整条题被判错。解决方法是把提示词写清楚，要求模型只输出JSON数组，或者在解析时做兼容处理。

跑通单条任务之后，再上批量循环。

4.3 批量运行时的并发、重试和命名

批量任务最需要关心的不是“能不能跑”，而是“跑得稳不稳”。

并发数建议从1开始逐步增加。不要一上来就开最大并发，因为并发越高，越容易出现资源竞争、超时和奇怪的互相影响。同一个推理框架，并发为4时能正常跑，并发为16时可能频繁报错。

重试逻辑要记录原因。失败重试本身是好事，但要在日志里区分“超时重试”“格式错误重试”“网络错误重试”。这样才能判断分数是模型的真实能力，还是运气成分。如果某条题连续重试三次才成功，它的单次得分和一次就成功的题目，含义是不同的。

输出文件命名也要规范。至少包含任务ID、模型版本号、Harness版本号、运行时间、随机种子。这样后续排查时，任何一个结果都能追溯到当时的完整配置。

4.4 日志是复现的灵魂

评测日志不是随便存一下，而是要能回答“这个结果怎么来的”。

一条有效日志应该包含：

• 输入任务的原始内容
• 送入模型的提示词
• 模型原始输出
• 解析后的结构化结果
• 判分结果
• 错误原因
• 重试次数
• 耗时和资源占用

有了这些，任何异常成绩都能定位到具体环节。某个分数特别低，是提示词写错了，还是模型推理本身出了问题，一查日志就知道。

我自己踩过的最典型的坑是：某天批量任务的分数突然下降，查了很久，最后发现是评测脚本里一个随机种子没有固定，导致每个任务的输出排序不同，格式解析大量失败。这种问题不看详细日志，根本定位不到。

4.5 评分标准：别只看一个数字

评分是评测的最后一道关卡，也是最容易被忽略的环节。

对于网格型任务，标准做法是逐格比对，相同算对，不同算错。这个逻辑简单，但要注意边界情况。比如模型输出了合法的网格，但尺寸和答案不一样，算不算错？模型输出格式保持正确，但颜色映射颠倒，算不算错？这些规则要在评分脚本里定清楚，最好在小规模样例上先验证一下评分脚本本身。

如果用的是大模型当裁判，评分会更复杂。大模型裁判可能有偏好，比如更倾向某个模型的表述风格。同一个答案，换个提示词让裁判评分，结论可能完全相反。所以裁判型评测最好有标准答案作为参照，错误率超过阈值时要人工复核。

最后，如果条件允许，建议同一套任务跑三遍，取多次结果的平均值或中位数。模型推理有随机性，单次分数可能偏高或偏低。多次运行能过滤掉偶然波动。

4.6 常见问题和排查顺序

评测结果异常时，不要一上来就怀疑模型能力，先按这条链路排查。

先看解析。模型原始输出是不是被正确解析成结构化结果。最典型的问题就是输出里带了解释文字，导致解析失败。解析环节是最高概率出问题的位置。

再看输入。任务文件有没有损坏，索引有没有错位，训练示例和测试输入是不是正确配对。

然后看环境。显存、内存、CPU占用是否异常，推理框架版本是否匹配，结果是否依赖随机种子。

再看参数。温度、top_p、最大token、超时时间、重试次数，这些参数都会影响输出质量。温度设太高，输出随机性变大；最大token设太小，长推理被截断。

最后再评价模型。如果前面的环节都没有问题，分数依然低，那才说明在这个任务分布上，模型或者当前Harness方案确实不擅长。

这套排查顺序，中心思想是先排除外部变量，再归因模型。否则很容易被误导。

5. 为什么“通关”不等于“具备通用智能”

5.1 基准分数反映的是特定条件下的表现

ARC-AGI设计得很好，但它毕竟是一个封闭任务集。模型在它上面的成绩，只能说明模型在当前Harness配置下，能较好完成这类抽象推理任务。

这距离“通用智能”还很远。通用智能意味着模型能把能力泛化到没见过的任务、环境、语言和交互方式中。ARC类基准测的是其中一个维度，不是全部。

即使是模型在ARC-AGI-3上拿了高分，也依然要回答几个问题：它是不是见过类似题目？它在开放环境里能不能稳定解题？它的答案是否可解释？它面对真实场景中的长尾问题时能不能转换规则？

这些问题，恰恰是单一基准测试无法回答的。

5.2 数据集污染和过拟合风险

大模型训练语料规模很大，很难完全排除测试集出现在训练数据中的可能。如果测试集被无意或有意收集进预训练语料，模型完全可能通过记忆通道解题，而不是通过推理。

这不是危言耸听。在很多基准上都已经出现过训练集和测试集重叠导致的分数虚高。ARC类基准一直强调防记忆设计，但每一代新版本上线后，仍然需要时间观察是否被污染。

所以，看到“通关”消息时，最好记录一下模型参数、Harness版本、测试集版本和运行时间，保证后续可以复现。不能复现的成绩，参考价值很低。

5.3 模型可能学会的是“在这个Harness里得分”

一个更隐蔽的问题是：模型在Harness的指导下，可能学会了“在特定任务格式下得分”，而不是“学会通用规则”。

比如Harness给模型提供了Python环境，模型每次都会写代码穷举规则。只要任务集规则是可穷举的，这种方式就能不断得分。但这和人类面对一个新任务时的抽象能力，是两回事。

也就是说，Harness放大的是系统能力，而系统能力由模型、工具、提示词、流程共同组成。把系统能力的得分直接等同于模型能力，本质上是一种概念混淆。

我并不是说Harness辅助下的成绩没有价值。真实产品里，模型本来就应该和工具配合。只是当你说“模型通关ARC-AGI-3”时，这句话应该更准确地表述为“模型在某个评测框架下，借助工具和流程，通关了ARC-AGI-3”。

5.4 真实任务比基准复杂得多

基准任务再复杂，也是经过清洗和标注的。真实世界的任务往往更混乱。

举个例子。ARC任务里，每个网格都是规则明确的色块组合，而真实数据里噪声很多。模型在ARC上的规则推断能力，能否迁移到有大量干扰、信息不完整、目标模糊的真实场景，很难直接等价。

所以，如果你准备根据某个模型在ARC-AGI-3上的成绩决定是否引入它，我建议再做三个验证：

• 拿自己业务里的典型推理任务，做成一个小测试集。
• 在同一个Harness下，对比多个模型的成绩。
• 观察失败样例，而不是只看平均分。

只有在你自己的数据上验证过，成绩才对你真正有用。

6. 如何理性看待模型评测：给三类人的实际建议

6.1 普通用户：先看Harness，再看成绩

对普通用户来说，最需要改变的习惯是“唯分数论”。

看到“通关”“达到人类水平”这类消息时，先去查测评报告里的评测配置。模型是裸跑，还是给了代码环境、思考模板、多次尝试机会？评测集和训练集有没有隔离？评分是人工还是自动？

这些信息有时不会出现在宣传里，但大概率会在官方文档或技术报告里。找到“评测环境”或者“实验设置”那一节，仔细看一眼。

如果实在找不到，就用一个通用原则：任何评测成绩都应该被当作“在特定条件下，系统能力的相对快照”，而不是“模型智能的绝对证明”。

6.2 开发者：搭一套自己的评测集

对做模型选型或者Agent开发的人，我更建议不要完全依赖第三方榜单。

你可以从自己的业务场景里抽20到50个有代表性的问题，覆盖不同类型、不同难度，然后把它们做成一个固定测试集。每次模型更新、Harness调整、提示词改动，都在这个测试集上验证。

自己的评测集未必比官方基准更权威，但它直接反映你关心的任务分布。还有一个好处：小规模测试集可以支持频繁运行，方便做回归对比。

需要注意的是，自己的测试集也要防污染。不要把测试样例放进模型的微调数据里，否则后面所有测试都失去意义。

6.3 研究人员：重新审视Harness的公平性

对评测方法的研究者来说，Harness本身就是一个值得研究的对象。

同一个模型，不同Harness下分数差异有多大？哪些组件对分数的贡献最大？提示词模板、工具权限、超时设置、重试策略，分别引入多少偏差？这些问题目前还没有统一结论。

如果还想更进一步，可以考虑“