最近技术社区关于“Opus 5 通关 ARC-AGI-3”的讨论热度很高。很多人在转发消息时会下意识配上“AGI 又近了一步”“推理能力已经超过人类”之类的感叹。但如果你亲手跑过模型评测或者自己搭过 Agent 应用大概率会多问一句这个成绩是模型直接跑出来的还是外部套了一层 Harness评测脚手架/工具框架之后跑出来的这其实不是一个小问题。ARC-AGI-3 这类基准测试测的是模型在新任务上的抽象推理能力本意是希望尽量排除“背题”和“刷榜”的可能。可一旦 Harness 参与进来事情就变得微妙合理的 Harness 是让模型更接近任务环境的“助跑器”但过度设计的 Harness 会变成替模型答题的“外挂”甚至把模型本体能力掩盖在一堆外部逻辑里。这篇文章不打算对某个具体模型做结论式评价而是想从工程视角把 ARC-AGI-3、Harness、模型真实能力这三者的关系拆清楚。适合关注大模型评测的算法工程师、做 Agent 应用的后端开发者以及正在学习 Prompt 工程和模型评估的新人。看完之后你会对“高分榜单”和“模型能力”这两个概念有一个更冷静的判断框架。1. 先理解基准ARC-AGI 系列到底在考什么1.1 ARC-AGI 不是普通榜单ARC-AGI 全称是 Abstraction and Reasoning Corpus直译为“抽象与推理语料库”。它最早由 François Chollet 提出目标不是考模型记住了多少知识而是考模型能不能从少量示例中抽取出规律并把规律迁移到全新的图形输入上。它和刷题式评测最大的区别在于两点训练样本没有公开的标准答案集模型很难通过预训练数据“背题”。每个任务都强调泛化模型必须在没见过的新例子上正确推理。所以 ARC 系列的成绩经常被当作“模型是否具备类人抽象推理能力”的参考指标之一。这也是为什么每次 ARC 系列出现高分时技术讨论的热度都会很高。1.2 ARC-AGI-3 延续了什么ARC-AGI-3 是 ARC 基准系列中较新的版本。按照该系列一贯的设计思路它仍然围绕图形变换、组合泛化、规律识别这类任务展开。相比早期版本新的版本通常会在任务难度和干扰项设计上做调整减少模型通过统计捷径蒙对答案的可能。不过要强调一个问题ARC-AGI-3 的具体题目数量、评分方式、是否引入了新的任务类型这些细节需要以 ARC Prize 官方公告和论文为准。因为基准版本迭代很快网上转述往往带有很多加工成分。看评测结果时最稳妥的方式是回到官方原始文档去核对。1.3 “通关”这个词需要打引号在 ARC 系列里“通关”并不是一个官方术语。它更像是社区对“模型在测试集上达到某个高分”或“超越了某个公开基线”的形象化表达。由于 ARC 系列强调生成式推理一个任务的正确解法可能有很多种模型输出结果也需要经过规则解析、格式对齐、答案映射等步骤才能判定对错。换句话说同一个模型评测时是否允许它进行多轮思考、是否给了它外部工具、是否允许程序化枚举候选答案都会直接影响最终分数。这也是“Opus 5 通关 ARC-AGI-3”这类消息最容易被误读的地方公众看到的往往只是“得分很高”的结论但隐藏在这些分数后面的评测配置、Harness 设计、算力消耗才是决定分数可信度的关键。2. Harness评测里的隐形放大器2.1 Harness 的原始含义Harness 这个词在英文里有“马具、挽具”的意思引申为用户将某个能力“套上外部控制和驱动装置”。在软件工程里我们经常听到 test harness指的是一套驱动被测代码运行的脚手架包括测试数据准备、调用规则、结果校验和报告输出。到了大模型时代“harness”的含义又扩展了一层。它不再只是测试工具还包括任务解析器把原始评测输入转换成模型能理解的格式。提示模板为模型设计上下文、示例和指令。外部工具循环允许模型调用代码解释器、搜索引擎、脚本等。答案校验器将模型输出解析成可判分的结构化结果。错误重试策略模型输出格式不对时自动重试。这些组件合在一起就构成了一套完整的“模型评测环境”或者“Agent 操作框架”。2.2 在模型评测中Harness 承担什么角色在 ARC-AGI-3 这类任务中Harness 最直接的作用是把模型“接进”评测环境。因为 ARC 任务输入通常是网格图形输出通常是另一个网格图形而大模型能接受的是文本或图片 token。Harness 至少要完成输入编码把网格转换成模型可读的文本格式或图像 token 序列。示例编排把若干训练样例拼接成模型的上下文示例。预测生成调用模型生成输出。结果解码把模型输出还原成网格结构并校验。如果只是做上面这些事Harness 更像一个“翻译层”没有替模型思考。可一旦加上“允许程序化尝试多种候选变换”“允许模型调用外部函数做穷举”“允许对模型输出做模糊匹配和自动纠错”Harness 就从数据管道变成了能力补强组件。2.3 Harness 与模型本体的边界在讨论评测分数时我们最好默认区分两层模型本体能力指模型在仅给定 Prompt 和上下文的情况下独立完成推理的能力。系统整体能力指模型加上外部工具、脚本、检索、重试策略后共同完成任务的能力。Harness 位于两者之间。它的价值是可以拉齐模型和任务之间的格式差距问题是它也可能在无形中承担了部分推理工作。如果 Harness 只是把网格序列化、把输出的字符串对成网格、用规则判断对错那这个 Harness 是干净的。如果 Harness 允许模型在多个候选假设之间执行程序化搜索、允许外部脚本根据测试样例反向拟合规则那这个 Harness 就已经不是一个“评测脚手架”而更像一个“解题系统”。“模型分数高”和“Harness 系统分数高”是两件完全不同的事。3. 当 Harness 变成“捆住模型的绳子”3.1 从助跑器到代跑Harness 最初被设计出来是为了让模型更容易暴露真实能力。但现实使用中Harness 很容易从“助跑器”变成“代跑”。举个例子。一个 ARC 任务的目标是识别“每一行中两个图形是否关于垂直轴对称”。如果没有 Harness模型必须在输出端直接画出完整的新网格这对很多模型来说难度很高。但如果 Harness 预先实现了“对称变换枚举”工具模型只需要在几种候选变换中选择一种难度就下降了一个维度。甚至更极端的做法是Harness 预先穷举了若干种图形变换规则模型输出只是作为“选择器”去挑其中一个规则。此时模型不需要真正泛化出抽象规律它只需要在 Harness 给出的规则库里做匹配。这看起来像“推理”实际上是检索和选择。当这类重 Harness 被用于公开评测分数就真的变成了“系统性得分”而不再代表模型本体推理能力。3.2 评测污染与过拟合风险与 Harness 过度参与绑定在一起的另一个问题是评测污染。预训练数据里很可能包含 ARC 相关任务讨论、答案示例甚至 Harness 工程实现。如果模型在训练阶段见过这些内容那么评测分数就会虚高。ARC-AGI-3 之所以被寄予厚望是因为它试图通过新题降低污染影响但只要题目被纳入公开评测并经过多轮验证它对于后续模型而言就逐渐不再是“新任务”。更值得警惕的是 Harness 的过拟合。当开发团队不断调整 Harness 去适配某个基准时Harness 本身也会产生对特定任务格式的过拟合。换一个任务体系、换一种输入格式这个 Harness 可能立刻失效。这正是“Harness 变绳子”的典型表现它帮助模型在某个特定评测上取得了高分同时把模型限制在了特定任务模式里。3.3 Harness 被复用到底好不好现在社区里有很多开源 Harness 项目比如和特定模型品牌绑定的 harness、面向代码生成的 codex harness以及各类 agent harness。它们的价值在于标准化了模型调用、工具调用、结果校验流程提高了开发效率。但问题在于当这些 Harness 被复用到不同任务时往往被认为“只是工程配置”人们会忽略它对能力边界的影响。同一个模型在轻 Harness 和重 Harness 下跑出来的分数可能差异巨大。如果不标注评测时使用的 Harness 版本和工具集任何分数的横向对比都没有意义。所以我的观点是Harness 复用是好事但复用后必须公开“评测配置快照”。否则 Harness 就会从透明工具变成黑盒放大器最终捆住的是我们对模型真实能力的基本判断。4. 用代码拆解一个最小 Harness这一节我们抛开“Opus 5”和“ARC-AGI-3”的具体分数用代码来理解一个最小 Harness 是如何影响模型输出的。下面的示例是通用思路不依赖任何特定模型品牌只关注 Harness 的“解析、组织、校验”三个环节。4.1 目标让裸模型更接近任务假设评测任务是给定若干个 3x3 网格示例要求模型预测另一个 3x3 网格。模型本身只能输入文本、输出文本。一个最简 Harness 需要做把网格序列化成文本。组装成 Prompt。请求模型。把模型输出解析回网格。与期望结果比较。4.2 最小示例# 文件路径harness_demo/mini_harness.py import json from typing import Callable, List, Optional def serialize_grid(grid: List[List[int]]) - str: 将 3x3 网格序列化为模型可读的文本。 例如 [[0,1,0],[0,1,0],[0,1,0]] 0 1 0 / 0 1 0 / 0 1 0 return / .join( .join(str(cell) for cell in row) for row in grid) def build_prompt(train_examples: List[dict], test_grid: List[List[int]]) - str: 组装 Prompt把训练示例作为上下文示例最后要求模型输出测试网格结果。 lines [] lines.append(请观察下面示例中的输入网格和输出网格规律。) lines.append(每个网格用 3 个数字表示一行多行之间用 / 分隔。) lines.append() for idx, ex in enumerate(train_examples, 1): lines.append(f示例 {idx}) lines.append(f输入: {serialize_grid(ex[input])}) lines.append(f输出: {serialize_grid(ex[output])}) lines.append() lines.append(请只输出推测出的完整输出网格不要输出解释。) lines.append(f输入: {serialize_grid(test_grid)}) lines.append(输出:) return \n.join(lines) def parse_output_to_grid(raw_output: str) - Optional[List[List[int]]]: 将模型输出文本解析成网格异常时返回 None。 try: cleaned raw_output.strip().replace(\n, / ) rows cleaned.split(/) grid [] for row in rows: cells row.strip().split() grid.append([int(c) for c in cells]) return grid except Exception: return None def run_mini_harness( model_predict: Callable[[str], str], train_examples: List[dict], test_grid: List[List[int]], expected_grid: List[List[int]], ) - dict: 最小 Harness 主流程构造 Prompt - 调用模型 - 解析结果 - 校验。 prompt build_prompt(train_examples, test_grid) # 调用模型的预测函数 raw_output model_predict(prompt) predicted_grid parse_output_to_grid(raw_output) if predicted_grid is None: return { ok: False, raw_output: raw_output, predicted: None, expected: expected_grid, reason: output parse failed, } return { ok: predicted_grid expected_grid, raw_output: raw_output, predicted: predicted_grid, expected: expected_grid, }这个 Harness 做了三件事serialize_grid把网格转成文本这样模型才能读。build_prompt把示例和测试输入组织成一段指令。parse_output_to_grid把模型输出转回网格。在这个阶段Harness 没有替模型做任何推理。它只负责“翻译”。如果模型本身不会做这个规律推理再完善的序列化也无济于事。4.3 运行结果怎么看我们假设有一个模型预测函数# 文件路径harness_demo/run_demo.py from mini_harness import run_mini_harness def fake_model(prompt: str) - str: # 真实项目中这里会换成模型 API 调用 return 1 0 / 1 0 / 1 0 train_examples [ { input: [[0, 0, 0], [1, 1, 1], [0, 0, 0]], output: [[1, 1, 1], [1, 1, 1], [1, 1, 1]], } ] test_grid [[0, 0, 0], [1, 1, 1], [0, 0, 0]] expected_grid [[1, 1, 1], [1, 1, 1], [1, 1, 1]] result run_mini_harness( model_predictfake_model, train_examplestrain_examples, test_gridtest_grid, expected_gridexpected_grid, ) print(result)运行之后如果ok为True只能说明“模型返回文本经过 Harness 解析后与期望网格一致”。这比直接比对原始文本好因为我们接收的是结构化网格而不是一段松散文本。但请注意这个 Harness 并没有把“判断规律”做进代码里。它只是让模型的文本输出能被判定。这说明一个干净 Harness 的主要目标不是答题而是“连接并判分”。4.4 如果再套上工具循环如果我们在 Harness 里加一段“允许外部脚本生成若干候选变换”的逻辑情况就完全不同了。# 文件路径harness_demo/tool_harness.py def enumerate_transformations(grid: List[List[int]]) - List[List[List[int]]]: 枚举常见图形变换例如水平翻转、垂直翻转、旋转 90 度等。 仅作为示例真正实现需要按任务调整。 candidates [] # 示例水平翻转 flipped [row[::-1] for row in grid] candidates.append(flipped) # 示例垂直翻转 flipped_v grid[::-1] candidates.append(flipped_v) return candidates如果评测任务允许模型先生成“操作指令”再由 Harness 执行那么模型就不需要直接在输出端画出完整网格它只需要从有限的候选变换里选一个。这种情况下模型的推理负担被大幅削减Harness 的工具集开始承担解题压力。我不能说这种做法一定不对。在某些真实业务场景中让模型调用外部工具是合理的架构选择。但如果这个架构被用到 ARC-AGI-3 这类强调模型本体抽象推理能力的评测中分数含义就完全不同了。所以当你看到一个“高分通关”新闻时第一件事不是惊叹而是去看它的 Harness 到底有多重。5. 常见问题与排查思路5.1 为什么同一个模型在不同评测里分数差距很大这通常是 Harness 配置不同导致的。有些评测只给模型纯文本输入有些允许模型调用外部脚本。评测配置不是一个可有可无的细节它直接影响分数可比性。5.2 为什么模型输出总被解析失败网格类任务里模型输出格式不稳定是常见问题。排查时可以从三个维度看Prompt 是否给出了明确的输出格式示例。解析逻辑是否处理了分隔符变体例如中文逗号、空格数量不一致。模型是否需要 few-shot 示例来稳定输出结构。5.3 Harness 能提升模型能力吗不能。Harness 能提升的是“系统完成任务的能力”不能提升模型本体的知识或推理上限。如果 Harness 过度参与甚至可能掩盖模型本体的真实短板让后续优化方向跑偏。下面用一个表格汇总常见问题问题现象常见原因解决思路同一模型不同评测差距大Harness 配置差异大对比评测时统一 Harness 版本和工具集模型返回格式不稳定Prompt 缺少格式约束给出更明确的输出模板和 few-shot 示例高分离不开重 Harness工具承担了部分推理把系统得分与模型裸测得分分开记录Harness 在新任务上失效对旧任务格式过拟合定期换任务样本精简不必要的工具逻辑无法复现高分结果评测配置未公开保存完整配置快照记录模型版本和 Harness 版本6. 最佳实践与工程建议6.1 评测透明化无论你是模型开发者还是应用开发者只要对外汇报模型成绩都应该把评测环境配置一并说明。建议至少记录以下信息模型版本和参数格式。Harness 仓库版本和依赖清单。Prompt 模板全文。是否允许工具调用。是否允许多次重试。数据切分方式和训练集隔离方案。没有这些信息的“高分榜单”参考价值都有限。6.2 Harness 分离与回归测试在工程实现上建议将 Harness 拆成独立模块并且对每个模块做单元测试。比如“序列化”“解析”“判分”三个函数要单独测试这样当某个评测分数变化时可以快速定位是模型变化还是 Harness 变化。可以用回归测试来固定 Harness 行为# 文件路径harness_demo/test_parser.py from mini_harness import parse_output_to_grid def test_parse_output_normal(): raw 1 0 / 1 0 / 1 0 assert parse_output_to_grid(raw) [[1, 0], [1, 0], [1, 0]] def test_parse_output_with_newline(): raw 1 0\n1 0\n1 0 assert parse_output_to_grid(raw) [[1, 0], [1, 0], [1, 0]]这样能保证 Harness 自身的稳定性避免因为一个小的解析逻辑改动破坏整个评测结果的可复现性。6.3 避免 Harness 依赖如果你正在开发 Agent 应用我建议在一开始就定义清楚“哪些能力必须由模型完成哪些能力允许外部工具完成”。否则业务迭代到后期系统会越来越依赖工具链模型本身的能力反而得不到提升。一个简单的判断标准是把 Harness 外部工具全部关闭后模型还能不能完成任务的简化版本如果能说明模型本体能力是真实的如果不能说明系统的核心能力其实握在 Harness 手里。这个实验值得每个评测团队定期做一次。6.4 安全与合规边界Harness 如果涉及外部工具调用必须注意权限边界任何命令执行、文件访问、网络请求都要走白名单机制。评测环境与生产环境严格隔离避免模型输出的恶意内容被执行。涉及敏感数据或生产环境变更时必须经过人工审批而不是让模型直接调用。大模型评测最重要的原则是结果可复现、过程可审计。一个记录完整的 Harness即使配置比较重也比一个不清楚内容的黑盒评测要更有工程价值。7. 写在最后Opus 5 通关 ARC-AGI-3 的消息无论最终被证实还是被证伪它都给我们提了一个醒在模型能力评估这件事上分数从来不是一个孤立数字而是一个由模型、数据、Prompt、Harness、算力、评测规则共同构成的系统表现。与其争论“这个模型是不是真的接近 AGI”不如先问一句评测这个分数时Harness 是干净的数据管道还是替模型答题的外部大脑如果你正在做 Agent 开发或模型评测建议你在自己的项目里做一件小事把 Harness 从“一次性脚本”升级成“可配置、可回归、可审计的工程模块”。这份投入会在你看榜单时带来一个额外的好处——你一眼就能看出某个高分到底有多少水分哪些模型是真的在推理哪些只是被 Harness 这根绳子拴着跑完了全程。