Opus 5通关ARC-AGI-3？先看Harness这根绳子

这次热搜把两件事绑在了一起Opus 5 被报道通关 ARC-AGI-3Harness 这个词开始在评测讨论里高频出现。前者听起来像模型又跨了一大步后者更像是工程层面的内卷。我的判断是真正值得关注的不是那个分数而是分数到底怎么测出来的。ARC-AGI-3 本身就是冲着“防背题、防刷分”去的结果解码方式又绕回到 Harness 上这件事相当值得细看。这篇文章会把 ARC-AGI-3、Opus 5、Harness 三个概念拆开讲清楚重点回答几个问题ARC-AGI-3 比前代改了什么为什么“通关”要打引号Harness 为什么越来越像捆住模型的绳子以及如果你自己也想搭一个 ARC 类评测流程最小可运行的 Harness 应该怎么写。文章会附带可复制的代码框架和参数清单不绑定任何具体模型厂商你可以直接改造成自己的评估工具。1. 核心问题速览先把这轮讨论的关键信息列出来方便快速判断这篇文章是否适合你。议题说明主角Opus 5、ARC-AGI-3、Harness 评估脚手架核心矛盾模型真实能力与评测环境工程能力在分数中被混在一起ARC-AGI-3更强调抗记忆、抗刷分的抽象推理评测集Harness包裹模型的多步推理、代码执行、候选校验等外围工程典型工具Codex Harness、DeepSeek Harness 生态、第三方插件/桌面版适合读者做模型评测、Agent 工作流、RAG 或 LLM 应用落地的工程师核心建议复现任何高分时必须同时复现它的 Harness 配置一个分数能不能说明模型变强取决于评测时给它套了什么 Harness。这也是文章标题里“绳子”二字的来源。2. ARC-AGI-3一个怕背题的评测集2.1 从 ARC-AGI 到 ARC-AGI-3 在收紧什么ARC-AGI 这类抽象推理评测核心设计目标就是“测泛化不测记忆”。它给模型的不是一道可以靠题库刷出来的题而是一组输入输出示例让模型找出隐藏规则并推理出新的输出。人类看到这种题可以凭直觉推理大语言模型则需要把任务转换成自身能理解的符号空间。ARC-AGI-3 延续了这个思路但从当前讨论看它在几个方向上更严格任务不再依赖常见语义联想模型靠“见过类似题”更难得分。对测试时计算施加更严格约束防止模型无限多次尝试。对“外部工具介入”的容忍度更低试图考察模型自身推理能力。对输出格式要求更高答案不是“生成一段文字”而是给出确定性的网格结果。换句话说ARC-AGI-3 想逼着模型只用自己和少量上下文去解题而不是靠一个庞大的工程系统在旁边辅助。这个初衷是合理的。但问题在于完全不带任何工具的“裸模型”在复杂推理任务上表现并不稳定于是评测方和模型方都开始往模型外面加东西这一层东西就是 Harness。2.2 为什么“通关”要打引号“通关”这个说法在 ARC-AGI 系列里从来不是一个绝对概念。ARC-AGI 没有传统意义上的“通关线”更多是看准确率、稳定性、计算资源开销的曲线。模型从 0% 做到 30%、50%、85%每一步都可以被称为“通过”但含金量完全不同。更关键的是Arc 评测的历史上已经出现过多次“高分”被质疑的情况。有的高分来自精心构造的提示词有的来自外部代码解释器反复生成候选答案有的来自模型在训练阶段已经见过类似任务。ARC-AGI-3 的出现本身就是对这些刷分手段的一次反制。所以当 Opus 5 被传“通关 ARC-AGI-3”我不会直接把这个结论当成模型能力的唯一证据。更合理的理解方式是Opus 5 的模型本身可能确实变强了同时评测过程中一定也用了相当复杂的 Harness。两者共同贡献了那个结果。3. Opus 5 通关一次模型与工程的合谋3.1 模型能力不是唯一变量Opus 是 Anthropic 旗下 Claude 系列里的旗舰命名。如果 Opus 5 是新一代旗舰那么它被报道在 ARC-AGI-3 上表现突出首先说明模型本身的抽象推理能力确有提升。这是值得肯定的部分。但评测分数的构成里模型权重只是其中一个因素。一次典型的 ARC 类评测实际运行链路通常包含任务输入 - 提示词模板 - 模型多次采样 - 候选答案收集 - 规则校验/代码执行 - 重试机制 - 最终计分在这个链路里提示词模板怎么写、采样次数是多少、候选答案怎么校验、重试多少次每一个环节都会直接影响最终分数。同一个模型用简单 Harness 和高阶 Harness 跑同一个评测集结果可能差出几个百分点甚至更多。这已经不是一个“模型能力”问题而是一个系统工程问题。3.2 公开分数不等于可迁移能力CSDN 读者里应该有不少人做 Agent 或 RAG 应用应该对这种感受很熟悉同一个大模型在 Gartner 评测里表现很好换到自己的业务数据上就“翻车”。原因就是评测环境和你实际部署环境不一致。ARC 类评测也是一样。Opus 5 在 ARC-AGI-3 上的分数是基于一套特定 Harness 得到的。这套 Harness 是否使用了多轮自我反思是否允许模型输出 Python 代码再执行是否在失败时自动重试是否对多个输出结果做投票这些问题不公开外人很难精确复现。所以对普通开发者的价值不在于“Opus 5 到底多少分”而在于提醒我们做模型选型时不能只看厂商给出的榜单数字要自己搭一套尽可能贴近业务场景的评测流程并且固定 Harness 配置。4. Harness 是什么从 Codex Harness 到 DeepSeek Harness4.1 Harness 的标准组成Harness 不是新概念。它早先出现在编程评测领域最典型的就是 OpenAI 开源的 Codex Harness。它的作用是给模型提供一个统一的执行环境让模型不仅能生成代码还能把代码放进容器里运行、观察输出、根据反馈修改结果。这种做法在 SWE-bench 这类真实编程任务里非常有效。后来 Harness 的概念被带到更广的 LLM 评测中。现在常见的 Harness 组成包括提示词模板层把任务数据转换成模型能理解的格式。多步推理层让模型每轮输出一个“思考片段”再继续下一步。代码执行器允许模型生成可执行代码并跑出结果。答案校验器判断模型输出是否符合任务要求。重试与回溯失败后修改策略重新尝试。资源限制器控制 token、时间、执行次数上限。这层工程系统本身没有对错。问题在于当 Harness 复杂到一定程度模型的角色就从“解题者”变成了“零部件”。4.2 Codex Harness 与 DeepSeek Harness 生态从近期网络热词能看到DeepSeek Harness 相关讨论很多包括安装、插件、桌面版、官网下载等内容。这其实反映了 Harness 正在从小众评测工具变成一种通用工程范式。Codex Harness 是偏编程评测的开源基础设施做法是把评测任务封装成标准化的运行环境。DeepSeek Harness 相关生态则更多是社区围绕 DeepSeek 模型打造成调用、评测、任务执行的脚手架有的是命令行工具有的是 WebUI 插件有的做成桌面应用。它们的具体能力各不相同但核心思路高度一致把模型从“单轮问答”扩展成“可编程处理复杂任务的 Agent”。这类工具给工程师的便利是明显的不用自己从零写多步调用逻辑装上就能用。但风险也很明显如果这个 Harness 本身有偏向性测试结果就会失真。比如某个 Harness 特别擅长从错误信息里提取下一步指令那就相当于给模型加了外部提示产物会非常高。5. Harness 为什么会变成捆住模型的绳子5.1 分数换一个 Harness 就不成立Harness 变成绳子的第一个原因是分数高度依赖评测配置。ARC-AGI-3 本来想测“模型自身的泛化能力”但如果评测允许模型在循环里反复调用代码解释器模型的准确率就会有明显变化。这时分数反映的就包含了 Harness 的能力。一个足够强的 Harness 甚至可以让一个中等模型在特定任务集上超过一个强模型。这样的结果放到真实场景里并不具备可迁移性。因为生产过程里你不太可能为每个问题手工搭建一个高定制的 Harness。5.2 工程上限掩盖模型上限第二个原因是Harness 引入的“试错机制”会让模型的上限被工程能力覆盖。ARC 类任务的正确反馈本来很难获取很多问题要靠模型一次性推理出来。但有了 Harness 之后模型可以先生成 N 个候选方案逐个执行验证再选出最合理的。从工程角度这是合理的。但从模型能力评估角度这是一种污染——你无法判断成绩来自模型的抽象推理能力还是来自候选池的枚举暴力。ARC-AGI-3 试图限制这种机制但在执行层面也很难完全杜绝。5.3 评测的可比性被稀释第三个原因影响的是整个行业如果每个团队都用自己的 Harness 跑评测榜单上的分数就没有可比性。A 团队报告 Opus 5 在 ARC-AGI-3 是 70%B 团队报告另一个模型是 72%外部用户根本不知道这两组数字分别代表了什么。规范的做法是同时公开模型版本、采样参数、重试次数、是否使用代码执行器、是否允许多次尝试甚至一起公开 Harness 的源代码。没有这些信息任何高分都只能当作参考不能当作结论。6. 自己搭一个 ARC 类评测 Harness最小可运行示例与其看别人报告分数不如自己搭一个最小可运行的评测流程。下面这套框架不绑定任何厂商适合用来理解 ARC 类评测的组成。实际使用时需要替换成你自己的 API 地址和模型名。6.1 数据准备与约束定义ARC 类任务的数据格式通常是一个 JSON包含一组训练示例和一个测试输入。下面是一个简化示例{ train: [ { input: [[1, 0], [0, 1]], output: [[1, 0], [1, 0]] } ], test: { input: [[0, 1], [1, 0]] } }评测约束需要提前定义清楚是否允许多次尝试。是否允许模型生成 Python 代码并执行。是否允许外部检索。最大 token 数。温度参数。候选答案数量。这些配置记录在评测结果里才能保证别人可以复现。6.2 最小 Harness 代码下面是一个最小 Python 示例核心逻辑是读取任务数据、构造提示词、调用模型、解析输出并校验格式。注意这段代码是模板具体接口路径以你的模型服务为准。import json import os from openai import OpenAI client OpenAI( api_keyos.getenv(MODEL_API_KEY, your_api_key), base_urlos.getenv(MODEL_API_BASE, https://api.example.com/v1), ) MODEL_NAME os.getenv(MODEL_NAME, your-model-name) def grid_to_text(grid): return \n.join( .join(str(c) for c in row) for row in grid) def build_prompt(task): lines [] for i, example in enumerate(task[train]): lines.append(f[示例 {i 1}]) lines.append(输入:) lines.append(grid_to_text(example[input])) lines.append(输出:) lines.append(grid_to_text(example[output])) lines.append() lines.append([测试输入]) lines.append(grid_to_text(task[test][input])) lines.append(请直接输出结果网格每个数字用空格分隔不要输出其他内容。) return \n.join(lines) def parse_answer(content): rows [] for line in content.strip().splitlines(): line line.strip() if line: try: rows.append([int(x) for x in line.split()]) except ValueError: continue return rows if rows else None def solve_task(task, max_attempts3, temperature0.0): prompt build_prompt(task) for _ in range(max_attempts): response client.chat.completions.create( modelMODEL_NAME, messages[{role: user, content: prompt}], temperaturetemperature, ) answer parse_answer(response.choices[0].message.content) if answer is not None: return answer return None if __name__ __main__: with open(tasks/sample.json, r, encodingutf-8) as f: task json.load(f) result solve_task(task) print(结果:, result)这个脚本没有加复杂的代码执行和候选投票但它已经具备了一个 Harness 的最小结构任务读取、提示词构造、模型调用、答案解析、失败重试。6.3 运行方式与预期结果假设你有一个模型 API 服务先用环境变量把模型信息配置好export MODEL_API_BASEhttps://api.example.com/v1 export MODEL_API_KEYyour_api_key export MODEL_NAMEyour-model-name # 运行脚本 python minimal_harness.py如果模型输出的是一个规范网格脚本会打印结果: [[0, 1], [1, 0]]如果模型返回了多余解释或者格式不对解析函数会返回None脚本会进入重试循环。这是最简单的一种 Harness 行为已经能看出“工程外壳”对最终成绩的影响。想进一步扩展的话可以在这个代码基础上增加以下模块代码执行器允许模型输出 Python 代码用子进程调用执行。多候选校验一次生成多个答案用规则筛选最合理的一个。日志系统记录每一步耗时、token 消耗、失败原因。批量评测遍历任务目录汇总准确率和平均耗时。7. 本地部署场景的资源占用与性能观察如果你用本地模型跑 ARC 评测不能忽略资源占用。ARC 任务本身不是大分辨率图像模型规模才是资源消耗的主要来源。观察几个维度显存占用批量评测时模型加载权重占用的显存是固定成本推理时会有额外峰值。多轮重试的累计延迟ARC 任务通常模型输出很短但 Harness 的重试机制会把单任务耗时拉长数倍。代码执行器的额外开销如果允许模型生成 Python 代码再执行每个候选答案都要贡献一次解释器启动成本。并发设计评测任务可以并发跑但要控制并发数量避免单卡 OOM。建议先在单任务上开小参数跑通再逐步增加并发。显存不足时优先缩小max_attempts和候选数量而不是降低模型尺寸。降低模型尺寸会直接改变能力线评测结果就不会准了。8. 结果报告与评测最佳实践8.1 强制记录清单如果你要用 ARC 类评测给模型做选型建议至少记录以下字段配置项说明模型名称与版本精确到 checkpoint不要只写“Opus 5”这种大版本评测集版本ARC-AGI-3 的哪个子集是否做过过滤温度随机性控制参数max_attempts单任务最大重试次数是否启用代码执行决定分数中是否包含外部计算能力候选数量每次生成几个答案再投票提示词模板固定版本改动要记录时间与 token 开销评估成本的关键指标这些字段写进评测报告的 Markdown 或 JSON 里后续复盘时不会被“模型变强了”这种模糊结论误导。8.2 去污染与防止刷分ARC-AGI 系列一直强调去污染实际上工程侧也需要做好这几点评测任务不得出现在模型训练数据里也不得通过外部检索间接获得。评测时禁止联网搜索除非明确说明这是“带工具评测”。禁止在评测集上做针对性微调或提示词优化除非目标是“刷榜”否则应当区分“泛化能力”和“拟合能力”。固定 Harness 之后再调模型不要为了追高分不断加 Harness 组件。另外涉及真实业务数据或隐私数据时务必脱敏并确认授权。没有授权的人脸、声音、文本材料不能直接进入评测或公开结果。9. 常见问题与排查问题现象可能原因排查方式解决方案评测脚本一直报接口超时模型服务负载过高或 API 端点不通检查服务日志、网络连通性降低并发增大超时时间或换更稳定的推理服务模型输出无法被解析提示词没有限制输出格式或模型返回了额外文字打印原始返回内容看格式强化提示词约束用 JSON 输出或代码块包裹同一个模型两次评测分数差异大没有固定温度、重试次数和候选数量检查 Harness 配置是否一致固定随机种子并记录完整配置本地模型推理显存溢出并发任务过多或输入长度超限观察 GPU 显存曲线降低并发缩小max_attempts关闭代码执行器复现不到官方公布的分数官方 Harness 版本与你的不一致对比 Harness 源码和默认参数尽量使用官方仓库直接跑不要自行修改默认配置评测集存在数据泄露任务被提前见过检查训练数据时间线和去污染策略换用私有版本或新题停止在该子集上继续训练Harness 越加越重反而拖慢任务多轮重试和代码执行带来大量额外请求观察每轮耗时限制单任务重试次数增加结果缓存10. 总结先看绳子再看分数Opus 5 能通关 ARC-AGI-3这个结果本身有价值它说明模型在抽象推理上的上限又往前推了一段。但更关键的判断点在于这套评测是在什么样的 Harness 下完成的Harness 提供了多少外部协助这些问题直接决定分数的可信度。对普通工程师来说不需要关心 Opus 5 具体打败了多少个任务而需要从这波讨论里带走一个工程习惯任何模型能力对比都必须把 Harness 配置写进报告里。没有 Harness 的分数等于没有单位的数据。建议收藏这篇文章的思路。下次看到“某模型又刷新了什么榜单”时第一反应不再是“这模型真强”而是先问三个问题用的什么 Harness、允许了几次重试、是不是挂了代码执行器。把这三个问题想清楚你就不会被任何花式榜单带偏。