从ARC-AGI-3看Harness真相：别把系统能力当模型能力

最近开发圈里有个消息传播得很快：Opus 5 拿下了 ARC-AGI-3。

只看标题，这又是一个“模型变强了”的故事。看惯了大模型新闻的开发者，可能已经条件反射地准备收藏一份“最强模型”清单。但我想先拦一下：如果你做 AI 应用开发，或者在大模型评测、Agent 框架相关方向工作，请先别急着把功劳全记在模型身上。

因为 ARC-AGI 这个 benchmark，从来就不是一个“只需要模型聪明就能得高分”的考试。它考的是抽象推理、泛化能力，是专门设计用来防止模型靠背诵训练数据蒙混过关的。ARC-AGI-1 时代，最顶尖的模型也得靠庞大的搜索和程序合成方法才能迫近人类基线；到 ARC-AGI-2，很多模型甚至被认为“几乎没有通过的可能”。这种情况下，一个模型想在 ARC-AGI-3 上通关，靠的必然不只是参数规模。

那靠的是什么？答案指向一个这两年被炒热的概念：harness。

我的判断很明确：Opus 5 通关 ARC-AGI-3 的真正看点不是 model，是 harness。但更值得警惕的是，harness 正在从“帮模型发挥实力的工具”，慢慢变成“捆住模型的绳子”。这篇文章就围绕这个判断展开，讲清楚 ARC 评测的真相、harness 为什么突然变热，以及开发者怎么避免被 harness 误导甚至锁死。

1. 从 ARC-AGI-3 说起：为什么“通关”这两个字不简单

1.1 ARC 系列到底考什么

ARC-AGI（Abstraction and Reasoning Corpus，抽象与推理语料库）由 François Chollet 提出，核心思路是让 AI 在从未见过的图形推理任务上，从几个输入输出示例中归纳出变换规则，再把规则迁移到新输入上。

它和 MMLU、GPQA 这类“知识型 benchmark”完全不同。知识型考试可以靠记忆、靠训练数据覆盖来得分，你在预训练阶段见过足够多的相似题目，考试时就能答对。但 ARC 系列不是这样，它要求模型在没见过的情况下做规则归纳，本质上是在考举一反三的能力，而不是记忆检索能力。

ARC-AGI-1 刚出来那几年，人类平均分能到 85% 左右，顶尖模型却往往在 30% 上下挣扎。2024 年，o3 在受限版本和大量额外计算资源的条件下拿到了高分，但同时被指出主要靠 search 算力换推理能力，这个操作在评测圈引起了很大争论。ARC-AGI-2 则进一步压缩了侥幸空间，题目更难、规则更复杂、对泛化的要求更高。

到了 ARC-AGI-3，我们可以把它理解为在任务难度、规则组合复杂度和约束条件上继续加码的版本。它延续了 ARC 系列“反记忆、考推理”的设计哲学，同时把模型的容错空间压得更小。

这不意味着 ARC-AGI-3 在技术上不可超越，但它确实说明了一个事实：一个模型如果只靠“读题 -> 写答案”这种两段式回答，得分几乎不可能达到通过线。想要通过，必须有“生成推理过程 -> 验证 -> 修正 -> 再验证”的完整循环能力。

1.2 “通关”的完整表述应该是什么

所以“Opus 5 通关 ARC-AGI-3”这句话，如果写完整，更贴近事实的版本其实是：

“Opus 5 模型，配合一套包含代码生成、沙箱执行、结果比对、错误回灌、多轮自我修正能力的 harness 工程系统，在 ARC-AGI-3 评测中达到了通过标准。”

这个表述听起来没那么带感，但更接近真实。

ARC 系列任务的典型解法，在 2024 年之后基本演变成：让模型把图形变换规则写成 Python 代码，再在沙箱环境里逐一运行验证。模型真正承担的是“模式识别 + 规则假设 + 代码生成”，而后面的“运行、报错、回灌、再试”循环，来自 harness。

这引出一个关键问题：我们该把这份功劳算在谁头上？

如果评测报告只报一个“模型通关”的结果，不披露 harness 对分数的贡献比例，那么开发者在拿到这个分数时，其实无法判断“换一个模型裸跑，还能不能有这么强”。

1.3 这里真正值得警惕的是什么

真正值得警惕的不是模型不够强，而是很多人会把“系统能力”误当成“模型能力”。

对大模型厂商来说，这种误读是乐见其成的。分数越高，品牌越亮，用户越愿意为 API 付费。但对我们这种要用模型做具体业务的人来说，这个误读会带来实打实的成本：你按照 benchmark 分数选了一个模型，接入自己简陋的业务代码后发现效果远没有分数显示的那么强——因为你在本地并没有那一套评测 harness。

这是理解文章标题的第一个关键点：模型分数不等于模型能力，更不等于你在业务里能复现的成绩。

2. 什么是 Harness：从测试脚手架到 Agent 运行时

2.1 传统软件里的 test harness

先说清楚 harness 这个词从哪来。

在传统软件工程里，test harness 指的是“为了跑通测试而搭的一套脚手架”，包括测试启动入口、桩模块、模拟数据、结果断言、环境清理等。它不属于被测系统本身，而是被测系统和测试环境之间的适配层。

到了大模型时代，这个含义被极大扩展了。早期大家用 harness 主要是为了批量跑评测：把一堆 prompt 格式化好，调模型 API，收集输出，和标准答案比对。代表性工具是 lm-eval-harness，被 HellaSwag、MMLU 等评测广泛使用。

在这个阶段，harness 还是“评测脚手架”，作用是自己藏在后台，不被用户感知。

2.2 从评测脚手架到 Agent 运行时

转折点出现在“让模型用工具”这件事流行起来之后。

当模型需要调用搜索、执行代码、操作文件、访问数据库的时候，仅仅发送 prompt、收取 completion 已经不够。需要在模型外面再加一个运行环境，它负责：

• 决定什么时候调用工具、调用哪个工具；
• 把工具返回的大段结果压缩成模型能消化的上下文；
• 在模型进入死循环或输出异常时打断、纠正、重试；
• 提供多轮记忆和长期存储；
• 对高风险操作做权限控制。

这一整套，就是今天大家在讨论 Agent 时说的 harness。

它不再是被动脚手架，而是一个主动的运行时环境。模型只负责“下一步该做什么”的判断，真正干活的是 harness 管理下的工具链。这个过程被社区命名为 agentic loop，而 harness 就是承载 agentic loop 的容器。

2.3 deepseek harness / codex harness 到底指什么

最近搜索热度很高的 deepseek harness、codex harness、deepseek harness 插件等词，本质上都是这个含义。

Codex 被定位为能自主完成编程任务的智能体，但它不是靠一个裸模型就实现的——在外面包了一层完整的工作环境、代码执行沙箱、任务拆解和自我验证机制，这套机制就是 codex harness。DeepSeek 场景下的 deepseek harness 也是类似：社区或框架作者把 DeepSeek 模型嵌入一个 Agent 编排层，让它具备代码执行、工具调用和多轮反思能力。

这些命名有一个共同的潜台词：大家开始觉得，真正决定 Agent 好不好的，不只取决于底座模型，还取决于外面这套 harness。甚至有人说，模型能力已经接近够用，Agent 体验的差距主要是 harness 工程的差距。

这个判断有一定道理，但也带来了我们今天要谈的问题。

3. 为什么 Harness 突然成了独立技术话题

3.1 模型同质化，工程差异化

2024 年到 2025 年，闭源模型和开源模型的差距在快速收敛。同样的任务，用不同厂商的 API，写出来的第一版回答往往都差不多。真正拉开体验差异的，是后面的编排：谁能更好地把模型放进业务闭环，谁就能做出更好的 Agent 应用。

于是大量团队把精力从“调模型”转向“调 harness”。prompt 怎么写、工具怎么定义、上下文怎么管理、失败怎么重试，这些工程细节逐渐变成一门专门的技术方向。社区给了它一个名字：harness engineering。

如果你关注 ChatGPT、Claude 等产品的演进，会发现它们的核心动作不只是换底座模型，更多是在持续优化外层 harness：更长的上下文窗口管理、更聪明的工具选择策略、更稳定的错误恢复机制。这些产品能力的提升，很大一部分来自 harness 工程，而不是模型单点能力提升。

DeepSeek 场景下，deepseek harness 之所以能成为热词，正是因为大家意识到：即使模型权重开放了，你也不能直接把它当成一个可用 Agent；要让它在真实任务里干活，必须搭一套 harness。

3.2 搜索热度背后的真实需求

从 deepseek harness 下载、安装、桌面版、插件这些热搜组合词来看，大量开发者并不是想研究学术概念，而是想把它当作一个能安装的软件来用。需求非常直接：把模型装进一个现成的 Agent 框架里，立刻获得代码执行、文件操作和联网能力。

这是一个非常合理的需求。对一个应用开发者来说，直接用现成 harness 比自己从零写 Agent 编排层要现实得多。但问题也出在这里：当 harness 越来越强、越来越厚，模型自身的能力边界开始变得模糊，甚至连“模型到底行不行”这个问题都难以回答。

3.3 一个被低估的变量：分数里有多少来自 harness

我们在评估模型时，经常忽略的变量是评测环境的一致性。同一个模型，直接 prompt 答题，可能只有 40 分；换成“生成代码 + 沙箱验证 + 错误回灌”的 harness，可能到 80 分。

这不是假分数。因为评测要的是最终正确率，harness 有效地提升了推理系统解决任务的能力，这符合评测规则。但它确实意味着：我们评测的对象其实是“模型 + harness”组成的系统，而不是模型本身。

如果厂商默认用最强 harness 测模型，再把分数讲成“这个模型多聪明”，就会产生系统性偏差。这不是操纵分数，而是评估口径问题——但对普通开发者来说，很难分辨两者的区别。

4. 核心矛盾：Harness 在增强模型，也在遮蔽模型

4.1 系统分数 vs 模型分数

任何基于 harness 的评测结果，严格说都是系统分数，而不是模型分数。

系统分数 = 模型基础能力 + harness 编排增益 + 评测集噪声。当 harness 增益足够大时，系统分数主要反映的是 harness 强不强，而不是模型强不强。

假设 ARC-AGI-3 的通过线是某个分数，Opus 5 “模型 + harness”通过了。但你如果对 base model 做一次裸测，可能离通过线还远。这两个数字并不矛盾，只是它们指向的能力载体完全不同。

一个完整评测报告至少应该回答三个问题：

• 模型单独答题的准确率是多少；
• 模型 + 完整 harness 的准确率是多少；
• 这两者之间的差距，是由 harness 的哪些模块贡献的。

如果评测方只发布第一个数字，那没问题。怕的是把第二个数字包装成第一个数字来传播。

4.2 一个比喻：运动员、教练和训练环境

可以把模型比作运动员，harness 就是教练团队、训练设施、医疗组和战术分析软件的集合。运动员能跑多快，既取决于自身天赋，也取决于整个团队怎么辅助他训练和参赛。

以前的教练团队很简陋，大家靠运动员天赋判断强弱。现在教练团队越来越专业，我们看到成绩时，很难分清天赋占几成、团队占几成。承认“Opus 5 团队很强”和“Opus 5 运动员很强”是两种结论，但很多传播媒体把它们混为一谈。

这对于看热闹的人无所谓，但对做技术选型的工程师来说，是个必须拆清楚的账。

4.3 harness 正在变成“外挂大脑”

更值得担心的一个趋势是：harness 的智能已经开始反向侵蚀模型能力的定义。

经典的 agent loop 是模型思考、工具执行。但现在的 harness 里，prompt 模板本身可能包含了大量领域知识，工具描述可能已经内置了任务分解策略，错误回灌机制意味着模型可以不断试错。模型在这个系统里面，更像一个“下一步行动选择器”，而不是“问题解决者”。

说白了，真正的解题思路可能一半藏在 harness 的编排逻辑里，模型只是被 harness 推着往前走。这就是“外挂大脑”。

5. Harness 变成“绳子”的三种典型信号

5.1 信号一：换掉 harness，分数大幅下滑

第一种信号最容易量化。

把一个模型从官方评测 harness 中拿出来，接入另一个普通 Agent 框架，在同一个任务集上跑，分数如果从 80 掉到 40，那说明模型对原 harness 有很强的依赖。这个模型的能力，很大程度是“官方 harness 环境下的能力”。

不一定是官方有意欺骗，更可能是模型在训练和评测阶段已经与 harness 深度适配。o3 时代就出现过“搜索流程是分数的重要来源”的讨论；到了 ARC-AGI-3，如果你不能在自己的 harness 里复现同样强的代码验证和错误回灌，模型就发挥不出理想效果。

所以当你看到“某个模型通关某某 benchmark”时，第一个应该问的问题是：它是在什么 harness 环境下通关的？这个 harness 我能不能复现？

5.2 信号二：harness 复杂度失控，问题无法定位

第二个信号发生在实际工程里。

当 harness 变成项目里最复杂的一个模块时，你会发现错误没法定位：某个功能不好用，可能是模型不行、prompt 太长、工具返回格式有问题、上下文被截断、重试策略太激进、沙箱缺依赖……任何一个环节都可能出问题。你升级了一次 harness 版本，应用行为变了，但你未必能说清是哪一行逻辑导致的。

这时候 harness 已经不是工具，而是一层难以改动的胶水。它确实在帮模型干活，但它的存在本身也在增加系统的不确定性。更麻烦的是，当模型输出和框架逻辑纠缠在一起时，你连“该优化模型还是优化 harness”都很难判断。

5.3 信号三：模型被框架锁死，失去可迁移性

第三个信号是工程里最贵的成本。

如果一个模型只在 deepseek harness 里能正常工作，换到另一个 runtime 就频繁出错，说明模型和 harness 已经深度耦合。你要换模型，得动 harness；你要换 harness，得调模型配置。两边都改，等于重构。

企业一旦被某套 harness 锁死，沉没成本会直接把技术选型拖入“将就着用”的状态。短期内省钱，长期看是不断累积的技术债。

5.4 一个最小配置看 harness 如何“包裹”模型

下面我用一段示意配置展示，为什么说 harness 已经厚到能“捆住”模型。这不是某个真实产品的配置，只是为了说明模型在整套系统中的占比其实很小。

# harness-example.yaml（示意，非真实项目配置） model: name: "opus-5" endpoint: "https://api.example.com/v1" temperature: 0.2 max_tokens: 8192 harness: loop: max_iterations: 30 early_stop_if_solved: true prompt_template: file: "templates/arc_solver_v3.txt" include_examples: 8 require_python_output: true tools: - name: "python_executor" runtime: "docker://arc-sandbox" timeout_seconds: 15 - name: "grid_visualizer" enabled: true - name: "answer_checker" compare_mode: "exact" feedback: on_failure: "append_error_and_retry" max_retries: 5 judge: type: "rule_based" output_format: "json"

看这份配置，模型部分只有四行。剩下 30 多行全部是 harness 的控制逻辑：循环次数、提示词模板、沙箱、工具、失败重试和质量判定。这样的系统跑出高分，你应该再想想，分数到底是谁的。

6. 工程判断：怎么分辨工具和绳子

6.1 四条判断准则

我整理了一个简单的判断表，供你在实际项目中评估 harness：

如果四条里命中两条以上“绳子型”，这个 harness 你要警惕。它可能在短期内帮你拿到漂亮分数，但长期会拖住整个项目的技术演进。

6.2 实操建议：做一个“替换测试”

最直接的方法，是在自己的评测集上做一次 harness 替换测试。

下面这段代码不是完整可运行的项目，而是演示方法论：同一批任务，分别用完整 harness 和裸模型跑一遍，对比两个分数。

# replacement_test.py（示意代码，需要按实际接口补全） from model_port import ModelPort def run_with_harness(model: ModelPort, tasks): """用当前 harness 跑评测，记录系统分数""" for task in tasks: plan = model.complete(task.prompt) result = execute_and_validate(plan) while result.failed and task.round < MAX_ROUNDS: feedback = format_error(result.error) plan = model.complete(task.prompt + feedback) result = execute_and_validate(plan) record(task, result) def run_bare_model(model: ModelPort, tasks): """直接把题目丢给模型，不允许工具、不允许重试，记录模型裸测分数""" for task in tasks: answer = model.complete(task.prompt_without_tools) record(task, answer, allow_unsure=True)

两段代码跑同一批任务、同一个模型。如果系统分数远高于裸测分数，说明当前成绩主要来自 harness。这个动作的成本很低，收益是帮助你建立正确的预期，避免把 harness 的能力误当成模型的能力。

6.3 接口与实现分离

更长期的做法，是让产品代码永远依赖“模型接口”，而不是依赖具体 harness。

# model_port.py —— 抽象出模型端口，harness 只是其中一种实现 class ModelPort: """一切模型调用的唯一入口""" def complete(self, messages: list[dict], tools: list[dict] | None = None) -> str: raise NotImplementedError # HarnessModelPort 实现了编排逻辑，但对外只暴露同一个接口 class HarnessModelPort(ModelPort): def __init__(self, base_model: ModelPort, harness_config: dict): self._base = base_model self._harness = build_harness(harness_config) def complete(self, messages: list[dict], tools: list[dict] | None = None) -> str: return self._harness.run(self._base, messages, tools)

这样，业务层看到的是统一的模型能力接口；你换 harness、换模型，都不会波及业务代码。这看起来是普通的软件工程原则，但很多 AI 项目恰恰因为“时间紧”跳过这一层，最后被 harness 绑死。

7. 对开发者的实际启示

7.1 选模型时不要只看 benchmark 总分

第一点：把 benchmark 分数当成“系统分数”看待。选模型之前，先问评测方是否披露了 harness 配置，是否给了裸测分数。没有这些信息，总分只能作为参考，不能作为能力承诺。

如果某个模型宣称“最强”，却没有公开评测配置和复现方式，那这个“最强”至少要打一个问号。

7.2 确定你的应用需要多厚的 harness

第二点：了解自己的业务需要多厚的 harness。

如果你的业务是问答、摘要、翻译，一个轻量 harness 就够；如果你的业务是自主编程、数据分析、网页操作，那么你需要完整的 agentic harness。不要盲目堆功能，每新增一个 harness 组件，都会增加系统的复杂度和失败概率。

很多团队一开始只需要一个简单 prompt 包装，却直接引入完整的 Agent 框架，结果是徒增运维成本，换来少量功能增强。

7.3 评测要分层记录

第三点：在团队内部建立分层评测习惯。模型评测、harness 评测、系统评测分开记录。

至少要做到跑任务时记录两个数字：裸模型准确率和系统准确率。这会帮你回答老板最常问的“为什么演示效果这么好，生产环境就不行”这个问题——大部分时候，差异就出在演示环境有一套精心配置的 harness，生产环境没有。

7.4 保持“模型可替换”的底线

第四点：任何 harness，都应该在“模型可替换”这个前提下使用。

不要为了短期效果，把模型私有格式直接写进 harness 的每一层。你不知道哪一天会有更强的模型出现，也不知道供应商会调整哪个 API。保留替换能力，就是保留主动权。

7.5 警惕 harness 信仰化

最后一点，警惕“harness 信仰化”。

最近社区有一个倾向：把 harness 说得无所不能，仿佛任何模型套上 harness 都能变成顶尖 Agent。这个说法对了一半：harness 确实能放大模型能力，但它不能无中生有。基础模型太弱时，harness 会把错误放得更大，而不是把错误消化掉。

真正健康的姿势是把 harness 当作放大器，而不是造物主。

8. 结语：把绳子变成缰绳

harness 本身不是一个坏东西。它是大模型工程化的必然产物，也是 Agent 应用落地的必需品。没有 harness，模型只能孤独地处理文本，没法操作真实世界。我们要反对的，不是 harness，而是“把系统能力偷换成模型能力”的传播方式，以及“在业务里被 harness 绑死”的工程状态。

好的 harness 应该是一根缰绳：它能让模型往正确的方向发力，又保留随时调整方向的自由度。坏的 harness 才是一根绳子：看起来在牵着模型走，实际把模型捆在原地，让你产生“模型很强”的幻觉，却无法在真实项目里复现同样的效果。

下次看到“XX 模型通关某 benchmark”的新闻，不妨多问一句：它背后的 harness 做了什么？给我同样的模型、同样的任务，我能复现这个分数吗？这比收藏一张“最强模型排行榜”有价值得多。

Opus 5 通关 ARC-AGI-3 是一次值得关注的工程展示。但我们真正应该记住的不是分数，而是分数背后的工程分层和可复现性。把模型能力、harness 能力和系统能力分开记账，你会少踩很多坑，也会更清楚下一步该优化什么。