ARC-AGI-3高分背后：RLM Harness与Agent评测争议解析

最近几天技术社区被一张 ARC-AGI-3 榜单截图刷屏了。一个开源 Agent 框架配合某种 RLMReasoning Language Model专用 harness把分数刷到了让不少人大吃一惊的水平。兴奋的人说这是“开源模型的逆袭”质疑的人则直接抛出一个问题这到底是在考模型还是在教模型做卷子我看了几个社区讨论串之后更关心的是另一个问题大家争论越激烈越说明“harness 工程”正在从论文附录里的小众技巧变成评测榜单上真正决定排名的胜负手。过去我们讨论模型能力谈的是参数量、训练数据、推理步数现在讨论 Agent 能力谈的却是“怎么搭 harness”“怎么让模型在测试时自我改进”。这篇文章不站队只把概念拆开把争议背后的技术原因讲清楚再给出一套可以动手验证的最小 harness 工程示例。读完你会明白ARC-AGI-3 上的高分背后到底发生了什么、harness 和 Agent 的区别在哪里、以及为什么“自我改进”会引起这么大争议。1. 这篇文章真正要解决的问题如果你最近在关注 AI Agent 或推理模型评测大概率会看到下面这类碎片信息“某开源 Agent 框架在 ARC-AGI-3 上刷爆了”“RLM harness 是什么和 Agent 有什么区别”“测试时训练能让模型自我改进这是不是作弊”“DeepSeek harness 安装卡在 pnpm dsh web”这些信息单独看都不难难的是把它们串起来。很多人会有一种感觉字都认识但不知道这件事为什么重要也不知道自己能不能复现。这篇文章要帮你解决的正是三个具体问题。第一理解 ARC-AGI-3 为什么难。它不是一个普通的 benchmark而是 ARC-AGI 系列的延续专门测试模型从未见过的新任务的抽象推理能力靠记忆训练数据几乎没有效果。第二理解 RLM 和 harness 到底改了评测的哪个环节。传统评测是“提示词进、答案出”harness 则把评测变成了一个多轮交互的工程系统。第三理解“自我改进”争议的技术本质。它不是简单的作弊与否而是“测试时训练是否超出评测任务边界”的规范问题。读完这篇文章你能独立判断一个高分刷榜消息含金量有多高也能照着文中的最小示例在本机跑通一个带 Agent 循环的评测 harness 雏形。2. 先理清三个概念ARC-AGI-3、RLM、Harness2.1 ARC-AGI-3衡量“没见过也能推理”的基准ARC 是 Abstraction and Reasoning Corpus 的缩写最早由 François Chollet 提出设计目标是评测 AI 的抽象推理能力而不是记忆力。它的题目对人类很简单几张彩色小格子按规律推测下一张图但对 AI 来说很难因为题目几乎不会出现在训练数据里。ARC-AGI-2 已经比第一代难度上了一个台阶而讨论中提到的 ARC-AGI-3 延续了这个方向题目更复杂、干扰项更多、更强调多步逻辑组合。从社区讨论的热度来看ARC-AGI-3 被当作衡量模型“泛化推理上限”的标尺。关键点在这里ARC 系列题目的核心特征是训练阶段无法为测试题目准备专门样本。所以任何靠“背题”的模型都会在它面前露馅。这也是为什么一个 Agent 框架能在 ARC-AGI-3 上拿到高分会引起那么大关注——它暗示的不是模型记得多而是模型在测试时“做了更多事”。2.2 RLM把“想”和“做”都变成可训练的回路RLM 是 Reasoning Language Model 的缩写中文可以理解为“推理语言模型”。它和普通 LLM 的最大区别是模型在生成最终答案之前会先产出一段较长的中间推理过程甚至会在特殊 token 之间反复“思考”。很多人容易把 RLM 和 CoTChain of Thought混在一起。严格来说CoT 是一种提示策略你说一句“Lets think step by step”模型就开始推导而 RLM 是把这种推理能力训练进了模型参数里模型不依赖用户提示自己就知道应该先推理再给答案。DeepSeek R1、OpenAI o1 系列都属于典型的 RLM。RLM 对 harness 工程的影响很大因为推理过程更长、中间状态更多模型更需要外部工具来记录轨迹、控制停止条件、执行验证和回溯。这就自然引出了 harness。2.3 Harness给模型“戴上手刹测试系统”Harness 这个词在工程界并不新鲜字面意思是“安全带”或“线束”。在机器学习评测领域它通常指“评测框架”——用于加载数据、调用模型、计算指标的工程套件比如斯坦福的 lm-evaluation-harness 就是这个含义。但在 Agent 和 RLM 语境下harness 的含义正在扩大。它不只是评测工具而是一个包围模型的运行时系统负责给模型提供工具、接收模型发出的动作请求、执行代码、回传结果、决定是否重试、控制整个测试时的循环流程。有一个类比可以帮助理解如果模型是驾驶员harness 就是安全带加驾驶舱仪表盘。好驾驶员需要好仪表盘才能发挥水平同样同一个模型放在不同的 harness 里得分可能天差地别。这不是模型权重变了而是“测试时计算”变了。3. 争议焦点“自我改进”到底是能力还是策略3.1 争议是怎么被点燃的围绕 ARC-AGI-3 刷榜的讨论指向一个关键词自我改进self-improvement。大致流程是模型先做一遍题目如果答案不确定它会通过 harness 提供的工具写代码尝试、跑结果、自评分数甚至尝试多种解法最后选择一个它认为最合理的答案。在传统评测里这是不可想象的。传统评测是一场闭卷考试给一个输入模型在固定参数下输出一个答案不许翻书不许和外部程序交互。而 Agent harness 的评测更像开卷考试加带计算器模型可以检索知识、执行代码、反复试验。于是问题来了——这还算是“模型的能力”吗3.2 支持者的逻辑问题求解本来就该能用工具支持者认为工具的可用性本身就是智能的一部分。人类解决 ARC 题目时也可以拿纸笔推算不只是盯着图发呆。如果模型能在测试时通过代码验证规律、枚举可能性这恰恰说明它具备抽象推理和工具调用的组合能力。在 ARC Prize 官方的一些讨论中也强调 ARC-AGI 的目标不是禁用工具而是评测系统能否在有限资源下解决新任务。如果工具调用能帮助模型解决任务则系统得分反映的是“系统智能”不只是“模型权重智能”。3.3 质疑者的逻辑测试时训练可能越过了边界质疑者担心的则是另一个问题。如果 harness 允许模型在测试阶段对同一道题反复尝试甚至根据结果反推规律那评测实际上变成了“在测试数据上做后验拟合”。这种情况下模型的分数不再代表泛化能力而代表穷举能力和 search 能力。更敏感的一点是有些 harness 在测试时会存储中间结果多个模型、多次会话可能共享这些结果。一旦存在这种跨会话记忆ARC-AGI-3 精心设计的“新任务”就不再新了。从公开讨论看这是很多人真正担心的红线——不是模型会推理而是评测过程被改写了。我的判断是这两种观点并不完全对立。它们其实在回答不同的问题。支持者回答的是“系统能不能解决新任务”质疑者回答的是“模型权重自身有没有获得泛化能力”。ARC-AGI-3 刷榜的争议本质上是这两个问题被混为一谈。4. Harness 工程是什么它和 Agent 有什么本质区别4.1 从“Agent 框架”说起在说 harness 之前先要分清 Agent 框架。Agent 框架是一个用于构建自主代理的软件框架它提供任务规划、工具注册、上下文管理、记忆持久化等能力。LangChain、LlamaIndex、AutoGen以及社区里很多叫 Agent 的项目都属于这一类。典型 Agent 工作流是用户提出目标Agent 拆解成步骤逐步选择工具执行最后输出结果。它的核心价值在“自主性”——尽量少的人为干预。4.2 Harness 在评测场景中扮演的角色Harness 和 Agent 框架看起来很像但目标不同。Harness 的目标不是“尽量自主地完成商业任务”而是“在受控条件下测量一个系统的能力”。举一个具体差异Agent 框架会尽量让模型自由发挥容忍长链路、高失败率因为任务复杂Harness 会更强调可控性限制尝试次数、记录完整轨迹、可复现结果、避免污染测试集。也就是说Agent 框架追求“做成事”harness 追求“可测量地做成事”。4.3 一个表格看懂三个概念的分工概念核心目标典型问题关注点LLM / RLM生成文字和推理内容给我一个最优解参数量、推理长度、训练数据Agent 框架自主完成多步任务帮我把流程跑完规划、工具调用、记忆Harness受控条件下测量能力这个系统到底行不行可复现、边界控制、评分标准从社区热词“harness和agent区别”的高搜索量也能看出不少开发者在看到 DeepSeek harness、Codex harness 这类项目时第一反应就是“这不就是个 Agent 吗为什么起新名字”读完上面的对比你就明白为什么需要新名字了因为它在解决另一类问题。5. 从热词看社区实践为什么大家都在找 DeepSeek harness、Codex harness5.1 社区在找什么搜索热词很有意思deepseek harness 安装、deepseek harness 怎么使用、codex harness 保姆级安装教程、deepseek harness 卡在 pnpm dsh web……这些关键词背后是一个明确的信号开发者已经意识到 harness 的价值想拿它给自己本地的开源 RLM 做一套测评或增强环境。DeepSeek R1 和各类开源推理模型流行之后大家发现光有一个模型权重不够还需要一整套工具链调度推理请求、管理上下文、提供代码执行环境、保存轨迹。于是社区出现了大量把开源模型和 harness 结合的项目命名方式也很直接——就叫「某模型 harness」。另外热词里还有“harness工程”和“harness人工智能”。从语境推测“harness工程”应该是指为 AI 模型设计外围运行框架的工程方法“harness人工智能”则可能指向“用 harness 来增强或控制 AI 系统”的方向。这些都是同一个趋势的不同侧面模型能力进入平台期之后系统工程的增量价值开始凸显。5.2 为什么 pnpm dsh web 会被频繁搜索热词里有一个非常具体的问题“deepseek harness 卡在 pnpm dsh web”。这说明不少项目基于 Node.js/pnpm 构建dsh很可能是某个命令行工具web可能是启动桌面端或 Web 界面的子命令。这类问题在开源工具中特别常见原因通常有三个pnpm 安装依赖时网络环境不稳定导致包没下全项目要求 Node 版本和本机版本不一致编译原生模块失败启动时工具需要连接本地模型服务端口而用户没有先启动模型服务。这些内容没有官方文档佐证前我不下精确结论但排查方向是通用的。后面第 8 章会给出完整排查表。6. 搭一个最小 Harness 环境通用演示思路上面讲的都是概念下面进入动手环节。我们不用去复现某个特定项目的完整功能而是搭建一个 mini harness走通“模型推理 → 工具执行 → 自评重试 → 输出结果”的完整链路。这套结构理解之后再去看 DeepSeek harness、Codex harness 这类项目的源码会更轻松。6.1 环境准备推荐使用 Python 3.10 或更高版本以及一个 OpenAI 兼容接口的本地模型服务。如果你的机器上没有本地模型服务也可以用一个公共 API 的 key 走通流程但注意不要在代码中硬编码密钥。mkdir agent-harness-demo cd agent-harness-demo python -m venv .venv source .venv/bin/activate # Windows 使用 .venv\Scripts\activate pip install openai dotenv如果本机有 pnpm 和 Node.js 环境且希望体验 Web 界面类工具也可以顺手确认版本node -v pnpm -v这个最小示例不强依赖 Node.js核心流程用 Python 完成。6.2 定义评测配置这里用 YAML 保存配置方便以后切换模型、调整尝试次数。注意下面的配置是通用示意实际项目中的字段名以官方 README 为准。# 文件路径config/demo-harness.yaml harness: model: provider: openai-compatible base_url: http://localhost:8000/v1 model_name: deepseek-r1-distill agent: max_attempts: 3 tools: - python_repl - self_eval dataset: name: arc-demo task_ids: [demo_task_001] logging: level: INFO save_traces: true在这个配置里base_url指向本地 OpenAI 兼容服务max_attempts控制模型最多尝试几次save_traces决定是否记录完整推理轨迹。它们是 harness 的核心控制项。6.3 编写最小评测循环下面的代码演示一个带“自评重试”的评测循环。它不调用真实 ARC 数据只用一个模拟任务验证流程。核心逻辑是模型给出答案 → harness 用模拟验证器判断答案 → 如果不通过且未达到最大次数就构造反馈再次请求模型。# 文件路径harness/minimal_harness.py from openai import OpenAI import time class MinimalHarness: def __init__(self, config: dict): self.client OpenAI( base_urlconfig[harness][model][base_url], api_keynot-needed, ) self.model config[harness][model][model_name] self.max_attempts config[harness][agent][max_attempts] def generate_answer(self, task_prompt: str, feedback: str ) - str: messages [ {role: system, content: 你是严格按规则推理的助手输出必须简洁。}, {role: user, content: task_prompt}, ] if feedback: messages.append({role: user, content: feedback}) resp self.client.chat.completions.create( modelself.model, messagesmessages, temperature0.7, ) return resp.choices[0].message.content def verify(self, answer: str) - tuple[bool, str]: # 模拟验证器真实项目中这里会调用 ARC-AGI 的官方评分接口。 target B if target in answer: return True, return False, 答案不匹配请重新推导并检查是否输出了正确答案标识。 def run(self, task_id: str, task_prompt: str): trace [] feedback for attempt in range(1, self.max_attempts 1): print(fAttempt {attempt}) start_time time.time() answer self.generate_answer(task_prompt, feedback) elapsed time.time() - start_time trace.append({attempt: attempt, answer: answer, elapsed: elapsed}) ok, reason self.verify(answer) if ok: print(PASS) return {task_id: task_id, status: pass, trace: trace} feedback reason print(RETRY, reason:, reason) return {task_id: task_id, status: fail, trace: trace}这段代码的关键不在“调用 OpenAI 客户端”而在尝试次数的控制和反馈回路的构造。真实的 harness 会复杂得多比如支持让模型通过代码执行环境验证规律、把中间推理保存到磁盘、在多模态输入上运行等等但骨架就是这个循环。7. 运行验证与效果判断7.1 启动本地模型服务如果使用的是 llama.cpp 或 vLLM 启动的 OpenAI 兼容服务先要保证服务已经运行。以 vLLM 为例前提是你已经按官方文档安装好 vLLMpython -m vllm.entrypoints.openai.api_server \ --model /path/to/your-model \ --port 8000注意这里没有写死具体模型名因为你本地实际有哪些权重取决于你自己下载的模型文件。如果你还没有本地模型也可以临时用一个 API 兼容中转地址但不要把密钥提交到代码仓库。7.2 运行最小示例在项目根目录创建一个简单的模拟任务文件然后执行python -m harness.minimal_harness预期输出类似Attempt 1 RETRY, reason: 答案不匹配请重新推导并检查是否输出了正确答案标识。 Attempt 2 PASS判断成功有两个标准程序在有限次数内正常结束没有抛异常日志中出现了 PASS 或 FAIL 的最终状态。如果第一次调用就抛网络连接错误优先检查base_url是否配置正确、本地模型服务是否已经启动。如果模型一直返回超时优先检查推理长度是否设得太长。7.3 如何进一步验证 harness 的有效性最小示例跑通之后可以做一个更有说服力的对比实验基线方案直接让模型输出答案不做自评重试Harness 方案加上自评重试和反馈回路。然后对比两组在同一个题库上的平均得分。如果两组分数几乎一样说明这个任务模型本来就会harness 没有带来增量如果 harness 组显著更高说明问题出在“一次性答案”上模型的推理能力其实超过了直接采样的表现。这个对比实验是判断一个 harness 优劣的通用方法。社区里许多高分结果的争议其实也可以归结为到底是 harness 带来了更多系统能力还是评测本身被利用了对比实验虽然不能完全回答问题但至少能把效果量化出来。8. 常见问题与排查思路根据社区热词和开源工具使用经验下面这些问题最容易出现在 harness 环境搭建阶段。问题现象可能原因排查方式解决方案pnpm 安装依赖卡住网络不稳定或镜像源不通查看 pnpm 日志检查镜像切换 npm 镜像源重试pnpm installpnpm dsh web启动后页面空白前端资源未构建完整打开浏览器控制台看请求重新执行构建命令确认端口占用调用本地模型服务超时模型推理速度慢或上下文过长看模型服务日志测/health接口降低最大生成 token或换更小模型API 请求返回 404base_url 或模型名不匹配打印请求地址确认 OpenAI 兼容路径检查服务端实际挂载的模型名多轮重试导致结果不稳定采样随机性固定 temperature 或 seed对同一任务跑多次取多数结果评测分数高但复现困难未保存轨迹或缓存污染检查 save_traces 配置每次运行隔离目录保存完整 trace在社区讨论中关于“deepseek harness 卡在 pnpm dsh web”这个问题最有效的办法是先把前端构建和后端服务分开排查先确认后端 API 端口可以手动调用再看前端页面是否因为静态资源路径错误导致空白。大多数情况下不是模型问题而是开发环境问题。9. 工程建议与评测伦理如果你打算在自己的项目中引入 harness有几点建议值得认真考虑。9.1 把“测试时训练”和“测试时搜索”分开这是本文最重要的工程建议。“测试时搜索”是指模型在测试阶段通过多次尝试、工具验证、反馈循环找到更优答案这是合理且强大的能力“测试时训练”则是指模型在测试数据上更新权重或者通过跨会话共享答案来记忆任务这会直接破坏评测意义。在设计和评审 harness 时先给这两者划出清晰边界。一个合格的 harness应该允许搜索但禁止对测试集本身的记忆和参数更新。9.2 记录全量轨迹不只是记录得分很多人跑完评测只保存一个 JSON 分数文件真到论文或复盘阶段才发现完全看不清模型当时为什么答错。建议至少保存以下内容每次请求的完整 prompt 和 response验证器的判定逻辑工具执行的输入输出每次尝试的时间戳和耗时。有了完整轨迹才能定位高分是不是来自某个明显的数据泄漏或工具 bug。9.3 不要为了刷分而过度设计 harness这个坑在社区里越来越普遍。有些项目把 harness 做得越来越复杂到最后模型本身的能力已经不明显系统反而更像一个专门的 ARC 搜索机器。刷分一时爽但一旦评测换了一批新题分数可能会断崖式下跌。更健康的做法是把 harness 当作通用评测基础设施而不是为某个 benchmark 定制的解题器。今天你可以用它测 ARC明天应该能无缝切换去测代码生成、数学推理、多模态任务。如果系统每换一种任务都要重新写一半代码那说明你的 harness 工程抽象还不够成熟。9.4 涉及生产环境时隔离权限和资源虽然本文讨论的是评测场景但 harness 系统如果应用在生产环境比如让模型执行代码、访问文件系统一定要遵循最小权限原则给模型提供独立的容器或沙箱禁止访问生产数据库或内部网络对高危操作设置人工审批所有执行步骤保留审计日志。这一点和评测伦理是相通的工具越强边界管理越重要。10. 总结从刷榜争议到工程趋势回到开头的问题开源 Agent 框架刷爆 ARC-AGI-3RLM harness 引争议这件事到底该怎么看最简单的答案是分数已经不重要重要的是分数是怎么来的。ARC-AGI-3 之所以有意义是因为它测的是“模型面对新任务的抽象推理能力”。但一旦引入复杂 harness分数反映的就不再是纯粹的权重能力而是“模型权重 工具环境 评测循环”的复合能力。支持者认为这是系统智能的进步质疑者认为这偏离了评测初衷。两种观点都有道理关键是要把分数背后的系统组成说清楚。从工程角度看围绕 DeepSeek harness、Codex harness 等热词的关注度已经说明推理模型的下一波竞争很可能不只是模型训练而是 harness 工程。谁能提供更可靠、更可复现、更不易作弊的推理环境谁就能在评测和应用中占据明显优势。建议你下一步做两件事一是用本文的最小示例跑通整个循环感受一次“尝试-失败-反馈-重试”的链路二是选一个你手头真正关心的任务记录基线模型和 harness 增强模型的分数差异验证到底什么场景下 harness 的价值最大。记住一条原则让 harness 处理过程让人处理边界。把过程自动化做好把边界设计好这个工具就是能力放大器如果只看分数不看边界那它很快就会变成一场新的刷分游戏。