ARC-AGI-3 的榜单最近被开源项目刷屏了。刷屏的不是某个全新的大模型而是一套开源 Agent 框架配合 RLM harness 的组合方案。它的核心逻辑很直接模型不直接给答案而是进入一个“思考—验证—修正”的循环通过自我改进提高正确率。社区反应非常分裂有人说这是通往 AGI 的关键一步也有人说这只是在测试集上做搜索分数有水分。这篇文章我会把这条技术路线拆明白ARC-AGI-3 到底测什么RLM 和 harness 分别承担什么职责“自我改进”为什么引来这么多争议以及如果你也想复现该怎么搭环境、跑批量评测、控制成本和排查问题。适合正在做 Agent 应用、关注推理模型前沿或者对基准测试方法论有好奇心的同学。先说整体判断这次高分更像“系统性推理编排”的胜利而不是单一模型能力的断崖式提升。它的工程价值大于 AGI 信号价值。1. 核心概念速览在开始之前先把本文涉及的关键概念拉成一张速览表。后续所有讨论都围绕这几个术语展开。概念定位在本文中的角色ARC-AGI-3抽象推理评测基准被测对象近期被开源方案刷屏开源Agent框架任务分解、工具调用、循环控制的编排层承载推理流程的骨架RLM带显式推理循环的语言模型生成推理过程并迭代修正harness模型外部的控制/装载层负责提示词、验证和终止组织 RLM 完成任务的执行环境自我改进机制通过反馈信息调整后续尝试策略争议焦点ARC-AGI 系列基准从一开始就强调“抽象推理和泛化能力”不是让模型背题库。它给模型开放的输入输出空间很小多数任务需要模型自己把握抽象规则。ARC-AGI-3 在这个方向上进一步提高了门槛所以往常榜单上大多是顶配模型配合精心设计的评测流程。RLM 和 harness 在实现上有多种叫法但核心结构是一致的模型不直接输出最终答案而是先输出推理链然后由验证器检查结果失败就把反馈信息带回上下文让模型调整策略继续尝试。harness 则负责整个循环的调度包括上下文压缩、工具调用、终止条件等。这种结构并不是新东西但为什么这次能在 ARC-AGI-3 上引发这么大关注因为开源方案把“自我改进”做成了可以复现的公开流程而不是藏在技术报告里的实验性 Trick。它能刷高分意味着这套循环在抽象推理任务上确实有效它引争议也正因为它太有效以至于绕过了一部分“从零推理”的评测预期。2. 开源Agent框架为什么在 ARC-AGI-3 上能刷出存在感2.1 评测逻辑发生变化ARC-AGI-3 这类基准本质上是把“会做题”和“会做没见过的题”区分开。过去要刷高分主流思路是换更大的基座模型或者精心构造 few-shot 示例。现在开源Agent框架提供的是另一条路不追求单次回答正确而是把“思考—验证—修正”变成一个循环用计划外的计算量换正确率。这个变化是很微妙的。基准测试原本想要测量的是模型的“单次泛化能力”也就是给定一个从未见过的任务模型能否在有限的信息下快速找到规则。而 Agent 化评测引入了外部反馈通道模型不再依赖一次性判断而是可以在多次交互中对候选假设进行检验。这样一来得分的意义就从“模型推理能力强弱”变成了“系统在允许交互条件下解决问题的能力”。两者相关但不能直接画等号。2.2 开源路线天然适合循环式推理这次刷屏的方案之所以来自开源社区不是偶然原因可以归结为三点。第一可复现。模型、框架、提示词、验证器全部开源分数能复现社区可以快速验证。AI 在基准上的成绩如果没有开源流程跟进本质上很难被审计。开源让围观者可以立刻跑一遍看看分数是不是真的。第二可组合。同一套 harness 可以接不同推理模型本地权重或 API 都能接模型版本升级不影响编排逻辑。评测过程中可以自由替换基座模型来做控制变量实验这在封闭方案里很难做到。第三可扩展。批量评测、并行尝试、失败重试这些工程能力Agent 框架内部天然支持不用额外造轮子。ARC-AGI-3 这类任务数量并不少单任务推理又需要多轮没有良好的批量调度机制想刷高分基本不可能。2.3 分数高不等于 AGI 突破对待任何高分都要先问一句这个高分是来自更强的抽象能力还是来自更多的尝试机会开源方案可能两者都有但“自我改进”让后者变得非常显著。这篇文章不点名某个具体项目只分析技术路线本身因为作为技术从业者真正值得关心的是“为什么能拿到这个分数”而不是“谁拿到了这个分数”。3. RLM 与 harness 的机制拆解3.1 RLM把推理过程显式化RLM这里理解为带显式推理循环的语言模型Reasoning Language Model核心是把“思考”变成一段可执行的循环。模型先生成一段推理过程和候选答案验证器给出反馈模型再根据反馈生成下一轮。这个“思考—验证—修正”循环可以执行多轮直到验证通过或达到最大尝试次数。与常规生成的区别在于RLM 把推理状态留在上下文里每轮都能看到之前的推理记录和验证结果而不是每次从头开始。这意味着它能在失败中积累信息也就是“自我改进”的直接来源。从工程角度讲RLM 本质上是在用上下文窗口“模拟短期记忆”让同一道题的多轮推理结果相互影响。需要特别指出的是不同项目对 RLM 的定义可能不同。有的强调“递归式自我修正”有的强调“可回溯推理”。无论如何它们的共同点都是不把生成过程看作单次前向传播而是看作多次前向传播加外部反馈的闭环。3.2 harness编排引擎harness 是围绕模型的执行环境在 Agent 术语里可以理解成“控制层”或“装载层”。它至少做四件事。第一维护任务上下文压缩历史。多轮推理会把上下文快速撑满harness 需要决定哪些历史信息保留、哪些可以压缩。第二调度模型调用包括决定调用哪个模型、传什么提示词、用多少温度参数。第三调用验证器执行工具收集反馈。第四决定终止或继续防止死循环保证任务在有限预算内结束。可以简单理解模型是“大脑”harness 是“身体和神经系统”。模型负责生成推理内容harness 负责让这些内容在正确的时机被生成、被验证、被利用。3.3 自我改进的落地方式从实现角度看“自我改进”不是模型权重在推理时被更新而是 harness 在运行期维护一份“策略状态”。这份状态可以包含哪些类型的尝试失败了哪些验证反馈可复现下一步要换哪种解题思路。它本质上是动态提示词工程把过去的失败经验变成新的上下文引导模型换一个方向思考。下面给出一段通用伪代码实际实现需要按你的 Agent 框架接口调整# 通用 RLM harness 循环示例实际请按项目接口调整 def solve_with_harness(task, max_attempts10, verify_fnNone): context initial_prompt(task) history [] best_answer None best_score 0.0 for attempt in range(max_attempts): reasoning model_generate(context, history) candidate extract_answer(reasoning) score verify_fn(task, candidate) if score best_score: best_answer candidate best_score score if score 1.0: return {answer: candidate, attempts: attempt 1, verified: True} feedback build_feedback(reasoning, score) history.append((reasoning, feedback)) context update_context(context, reasoning, feedback) return {answer: best_answer, attempts: max_attempts, verified: False}这段代码里model_generate是模型服务调用verify_fn是题目自带的验证器或自建规则验证update_context是 harness 中的上下文管理模块。不同 Agent 框架实现差异很大但循环骨架基本一致。写清楚这个骨架是为了让你在阅读任何开源 harness 源码时能快速找到对应的功能模块。4. 自我改进为什么引争议4.1 尝试次数 vs 泛化能力ARC-AGI-3 要求的是抽象推理。如果模型可以在一次任务里尝试 20 次、50 次每次都从验证器拿反馈那得分就包含了大量“搜索”成分。部分批评者认为这等同于在测试时用暴力搜索找答案不能证明模型具备读题后直接把握抽象规则的能力。支持者的回应也很直接人类解题也不是一次就能做对的拿到反馈后修正方向本身就是一个重要的智能行为。问题于是变成这个循环里“搜索”和“推理”的占比到底是多少如果模型前两次试错完全是随机猜测后面靠验证器筛选答案那可能是搜索如果模型能从失败中总结出规则变化那就是推理。可惜的是单纯看最终分数很难区分这两者。4.2 验证器泄漏风险“自我改进”依赖验证器。如果验证器或者反馈信息间接包含了正确答案的线索那改进就不是推理而是在读取提示。开源方案里验证器通常由人写规则或由 LLM 判分规则写得不严谨时很容易在多次尝试中把答案特征带出来。举个例子如果验证器只告诉模型“错误”这个反馈信息量很低但如果是“第 3 行的颜色不符合规则需要改成蓝色”这几乎就是在泄露答案。不同验证器的反馈粒度差异会让同一个模型拿到完全不同的分数。评测时要严格记录验证器版本和反馈格式否则分数不可比。4.3 评测协议问题ARC-AGI-3 是否允许交互式多次尝试允许多少次是否有统一的计算预算约束目前公开讨论中并未看到一套所有人都接受的严格协议。这样不同机构跑出来的分数就缺乏横向可比性榜单刷分价值也随之下降。社区里对“刷分”的敏感本质上是对评价体系公平性的关注。如果评测协议没有明确限制尝试次数那任何带循环机制的 Agent 框架都会天然受益而单次推理模型会显得吃亏。这不代表 Agent 框架有问题只说明基准测试本身需要跟上 Agent 化的新范式。4.4 反方观点也有支持者认为Agent 在现实任务中本来就是多轮交互的能在有限尝试内利用反馈修正解题方向本身就是泛化能力的一种体现。问题的关键不是“允不允许多次尝试”而是“算法是否具有搜索之外的结构化推理能力”。两种观点都有道理。作为从业者更值得关注的是工具层面的价值如果这套机制能在真实业务任务中稳定提升正确率那它就有工程意义至于它是否真正逼近 AGI那是学术讨论范围内的事。5. 尝试复现与验证跑通一套通用流程不针对某个特定项目给出一套可以复现的验证流程。你可以把这套流程接到任意支持工具调用的开源 Agent 框架上。5.1 准备评测集ARC-AGI 官方评测集需要单独获取注意使用官方渠道。准备好之后结构类似arc_tasks/ train/ # 训练/示例任务按需使用 test/ # 评测任务如果只是验证 harness 逻辑先用 10 到 20 道小题目跑通流程再上全量测试。不要一上来就跑完整测试集因为 harness 循环会把单任务耗时放大很多倍中途发现问题再排查成本很高。5.2 写通用批量评测脚本下面是一段批量评测脚本模板import json import time from pathlib import Path def run_batch(task_dir, output_file, solve_fn, max_attempts10, delay1.0): results [] task_paths sorted(Path(task_dir).glob(*.json)) for idx, task_path in enumerate(task_paths): task json.loads(task_path.read_text()) start time.time() result solve_fn(task, max_attemptsmax_attempts) elapsed time.time() - start results.append({ task_id: task_path.stem, correct: result[verified], answer: result[answer], attempts: result[attempts], elapsed_sec: round(elapsed, 2), }) # 控制请求频率避免触发限流 time.sleep(delay) Path(output_file).write_text( json.dumps( { results: results, accuracy: sum(r[correct] for r in results) / len(results), }, ensure_asciiFalse, indent2, ) ) return results跑之前建议先记录三个基线普通单次生成、harness 5 次尝试、harness 20 次尝试。只有做了对比才能判断分数提升到底来自循环还是来自模型本身。如果单次生成准确率已经很高那么循环带来的收益就有限如果准确率提升明显再进一步分析提升来自哪一轮的修正。5.3 判断成功标准每个任务记录是否验证通过、尝试次数、耗时和最终答案。判断整体成败的标准不是只看高分而是三个维度同时看准确率、平均尝试次数、总成本。如果准确率提升但成本激增在真实业务场景里可能不值得如果准确率提升且平均尝试次数只有 2 到 3 次那这个机制才是真正有效的。6. 搭建可复现的 Agent 评测环境6.1 环境分层评测环境建议拆成三层。模型层本地开源权重或者远程 API本地权重需要 GPU远程 API 需要凭证和预算。两者可以并行使用先拿 API 跑通逻辑再切本地模型做显存和速度验证。框架层选一个支持工具调用和自定义验证的回环型 Agent 框架优先选带日志和重试机制的。日志很重要因为 harness 循环一旦出错没有日志很难定位是哪一轮、哪个模块出了问题。评测层独立的 ARC-AGI-3 测试集、评分脚本、结果归档目录。评测层和数据层要跟框架代码分离这样换框架不用重下数据换模型不用改评测脚本。6.2 前置检查清单Python 3.10部分框架要求更高版本。如果本地推理CUDA/驱动版本按框架要求配置。磁盘空间要同时容纳模型权重和评测任务。端口 7860/8080 之类的 WebUI 或 API 端口不要冲突。记录随机种子和版本号保证复现性。6.3 启动与运行假设你已装好 Agent 框架并且模型服务跑在127.0.0.1:8000批量评测可以这样组织配置{ model_endpoint: http://127.0.0.1:8000/generate, model_name: your-model-name, harness: { max_attempts: 10, early_stop_on_verified: true, context_compress_threshold: 8000 }, evaluation: { task_dir: ./arc_tasks/test, output_dir: ./results, delay_between_tasks: 1.0 } }启动评测的命令取决于你选的框架一般会是一个evaluate或run子命令。先跑小批量确认日志和输出格式正常后再扩大规模。如果框架本身不带评测命令可以直接上面写的批量脚本把solve_fn换成框架自己的调用接口。7. 资源占用与性能观察7.1 请求量放大harness 循环会把 API 请求量放大 N 倍。N 等于平均尝试次数乘以每轮内部工具调用数。20 次尝试对比单次生成成本可能是 20 到 60 倍。评测前先计算预算设定一个最大尝试次数别让一个任务把额度烧完。这里给出一个简单的成本估算方式先测 5 个任务的平均请求量再乘以总任务数得到总请求量。按平台的每千 token 价格估算费用。控制预算的办法包括缩短上下文、限制尝试次数、降低验证器调用频率。7.2 本地模型显存观察如果使用本地模型显存由基座模型决定跟 harness 关系不大。7B 模型和 14B 模型占用量有明显差距具体数值以本机nvidia-smi为准。建议边跑评测边观察显存曲线nvidia-smi -l 1如果显存不足优先降低上下文长度或压缩历史再考虑换小模型。harness 的上下文管理策略会影响峰值显存因为多轮推理历史会被拼接进下一次请求。context_compress_threshold 设置得越小显存压力越小但可能损失历史信息。7.3 性能瓶颈harness 评测的性能瓶颈往往不在生成而在验证环节。验证器如果是 LLM 判分会额外放大延迟验证器如果是规则脚本则几乎可以忽略。批量评测时优先把验证器做成非 LLM 的确定性规则能省掉大量等待时间。如果必须使用 LLM 判分可以考虑把验证器请求和推理请求放进不同的并发池避免互相阻塞。同时给验证器设置独立的超时时间防止某个任务长时间卡住。8. 常见问题与排查方法问题现象可能原因排查方式解决方案评测任务全部超时单个任务尝试次数太多或模型延迟高查看日志中超时任务的平均尝试数调低 max_attempts缩短上下文分数比公布值低很多尝试次数不同或验证器逻辑不同对比评测协议和验证器实现统一验证器记录完整计划预算API 被限流请求频率高或并发数过大查看返回码和限流头增加 delay降低并发显存不足本地模型上下文被历史推理填满观察 nvidia-smi 显存曲线打开上下文压缩减少保存的轮次输出结果不稳定模型温度过高或提示词含随机分支固定 seed记录每次推理参数设置温度接近 0 或固定 seed自建验证器误判规则有歧义或覆盖不全抽样人工复核结果补充规则或改用更严格的判分器复现不出榜单分数评测集版本不一致比对任务 ID 和文件 hash切换到官方评测集版本锁定 hash循环不收敛提示词没有携带足够的失败反馈检查 history 是否传入下一轮调整 update_context确保反馈可见排查时先看日志再看版本。很多问题不是代码 bug而是环境差异或配置不一致导致的。建议每次实验前把模型版本、harness 版本、评测集 hash 三项写进结果文件头部。9. 工程启示与使用建议9.1 不要盲目在业务里上“自我改进”harness 的自我改进机制在评测任务里效果明显但在真实业务中会放大三个风险成本不可控、输出难以审计、可能被恶意提示词引导。业务中使用时必须加人工审核和权限边界。以文档问答为例如果要让 Agent 多次尝试解答问题每次尝试都要消耗 token且多轮输出可能包含不同答案。如果没有人工复核错误答案会被自动交付。建议先用低风险任务验证效果再逐步放开范围。9.2 把评测当工程做分数要可复现、可对比、可审计。记录每次评测的模型版本、harness 版本、尝试次数、随机种子、验证器版本。不要把“刷新一次 score”当成终点要把评测流程做成 CI 里可以反复执行的任务。建议每次评测输出一份完整的 JSON 报告包含任务 ID、每轮推理摘要、验证反馈、最终答案、时间戳。这样即使结果不理想也能回溯是哪个环节出了问题。9.3 判断模型能力时先看协议拿到任何高分新闻先看三个问题测试集是否隔离允许多少次尝试验证器是否会泄漏答案这三个问题不回答分数只能当作“在特定条件下的表现”不能当作普适能力。这套判断框架也可以用到日常技术选型。遇到供应商宣传“我们模型在 XX 基准上超过 GPT”先看它的评测脚本是否开源、是否有统一的评分协议。没有协议的高分参考价值有限。9.4 合规边界使用开源模型权重、代码和数据集时确认许可证允许你的用途。涉及真实用户数据、私密文档、人物肖像等场景必须脱敏和取得授权。ARC-AGI-3 评测集如果需要授权申请按官方规则使用不要自行传播评测题目。如果要在团队内部分享评测结果注意不要包含原始评测题目的完整内容只保留任务 ID 和得分摘要避免扩散受控数据。10. 总结与下一步ARC-AGI-3 这次被开源Agent框架刷屏最值得关注的不是榜单上的数字而是背后这条技术路线用 RLM harness 把调模型变成编排任务用验证反馈循环换更高正确率。这套思路确实有工程价值但“自我改进”带来的争议也提醒我们分数提升要结合评测协议来解读。如果你想自己验证建议从三件事开始选一个支持工具调用和验证反馈的开源 Agent 框架先接远程 API。拿 10 道 ARC-AGI-3 小任务跑对比单次生成 vs 5 次尝试 vs 20 次尝试。全程记录尝试次数、验证器命中率和成本再判断这条路值不值得投入。最容易踩的坑是实验预算失控。harness 循环会让请求量放大几十倍建议先把max_attempts设置到 5跑通以后再逐步加大。后续可以继续扩展的方向更强的验证器设计、上下文压缩策略、多模型投票融合以及在真实业务任务上做迁移评测。这个方向值得长期跟进但请带着协议意识和工程心态去看分数。