ARC-AGI-3 的讨论热度最近明显升温。与以往“更大的模型 更多的数据”叙事不同这一轮冲在前面的不少方案来自开源Agent框架它们没有把全部希望寄托在基座模型的参数规模上而是把“模型在环境里多步推理、执行、验证、重试”做成了一套工程系统。舆论把这些框架的成绩拆成了几个热词RLM、harness、自我改进。其中“自我改进”最容易引发争论因为它听起来既诱人又可疑。这篇文章想聊清楚几件事ARC-AGI-3 这类基准到底难在哪RLM、harness、自我改进分别指什么一个最小可复现的“自我改进 harness”工作流长什么样以及这个组合为什么会引起争议。最后会给出对普通开发者的评估方法和落地建议。1. ARC-AGI-3 为什么能成为热点1.1 ARC 系列基准到底测什么ARC-AGI 是 Abstraction and Reasoning Corpus 的缩写最初由 François Chollet 提出。它和常见的“知识问答式”评测完全不同题目不是让模型回忆训练数据里的知识而是给它几个输入输出网格对要求模型推断出背后的变换规则再把这个规则应用到新的输入网格上。举个例子题目可能给出左边一个 3x3 网格右边一个按某种规则变化的 3x3 网格。连续给 2 到 3 组这样的“输入-输出对”。最后给一个新的输入网格要求模型生成对应的输出网格。这里的难点在于给定有限的例子可以拟合出无数种规则。模型必须选择“最自然的规则”而不是“能解释当前例子的规则”。这正是人类抽象推理的典型形式也是大模型最难突破的地方。ARC-AGI-2 发布时已经让很多评测体系重新洗牌人类得分、AI 得分同时大幅下降说明基准设计者有意去掉了模型靠记忆和模式匹配能“蒙对”的空间。ARC-AGI-3 延续了这种路线进一步压缩了示例数量提高了规则组合的复杂度。从已公开信息看它追求的是“少样本抽象归纳 规则外推”而不是“知识复用”。1.2 为什么这个基准容易引发争议ARC-AGI 系列从诞生起就带有话题性。一方面它把“智能”定义成一种可测量的抽象推理能力另一方面任何基准都可能被策略性优化。你说它在测通用智能但反过来看模型只要在训练集里见过大量类似的网格变换就能在测试集上表现更好。所以当开源Agent框架在这个基准上取得亮眼成绩时很多人第一反应不是“这个框架真强”而是“是不是又用了什么 tricks”。加上“自我改进”这个标签争议就更大了。我的判断是ARC-AGI-3 的价值不在于谁刷了多高的分而在于它迫使研究者把“推理”做成一个可观测、可迭代的工程过程。这比分数本身更有意义。2. RLM从“生成答案”到“推理过程”2.1 什么是 RLMRLM 的全称是 Reasoning Language Model中文可以叫推理语言模型。它不是某个具体产品而是一类强调“先推理、后回答”的模型设计思路。传统 LLM 的用法是用户输入问题模型直接输出答案。遇到复杂任务时这种“一步到答案”的方式非常不稳定因为模型没有机会在内部展开思考也没有机制去验证自己的答案。RLM 的思路是让模型先生成一段推理过程——可能是思维链、草稿、计划、候选规则甚至是一段伪代码——然后再基于这些推理内容给出最终答案。在 Agent 场景里RLM 的优势更明显。Agent 需要做规划、拆解任务、调用工具、解读结果。如果模型只能“直接回答”它就没有办法在处理多步任务时保持一致性。而 RLM 的显式推理过程可以让每一步决策都被记录下来、被审查、被修正。2.2 RLM 与普通 LLM 的差异维度普通 LLMRLM输出形式直接给出答案先给推理过程再给答案推理方式隐式无法干预显式可观察、可校验适合任务快速问答、文本生成数学、代码、规划、抽象推理主要问题复杂任务容易直接出错推理长度长开销更大在 Agent 中的角色单轮工具调用多步规划与回溯的核心决策器需要强调的是RLM 不只是一种提示词技巧。真正支持 RLM 的模型在训练阶段就会用大量推理轨迹做监督微调或者用强化学习奖励“正确推理过程”而不只是奖励最终答案。这也是为什么 RLM 和 harness 总是绑定出现推理过程需要被放进一个可以执行的系统里才能发挥价值。2.3 RLM 在 ARC-AGI-3 上的作用ARC-AGI-3 的任务非常依赖“规则假设 验证”。模型看到例子后需要先猜测一个规则再把规则套到新输入上生成输出最后对照预期结果判断是否成立。这个流程天然适合 RLM模型先描述它认为的规则再用规则写出转换过程最后输出答案。如果没有显式推理模型很可能“凭感觉”生成一个网格错了也不知道为什么。Rust 不重要重要的是“推理过程”让后续的 harness 有了可操作对象。3. harness把模型放进可控制的执行环境3.1 什么是 harness中文语境里harness 常被翻译成“马具”或“安全带”但在 Agent 领域它指的是“连接模型与外部世界的执行外壳”。简单说harness 负责把模型的输出变成工具调用把工具执行结果反馈给模型并控制整个循环的终止条件。如果模型是发动机harness 就是变速箱、方向盘和驾驶舱。发动机决定了动力上限但能不能安全到达目的地取决于整套操控系统。最近社区里频繁提到“harness 工程”其实就是在说不要只关注模型本身要把“模型 执行环境 工具 验证器”作为一个整体来设计。OpenAI Codex 周边、DeepSeek 工具链里被反复提到的 harness本质上都指向同一件事——如何让推理模型在一个受控环境中高效工作。3.2 harness 与 Agent 框架的区别很多人会把 harness 和 Agent 框架混用但它们其实不是一个层级的东西。Agent 框架是面向任务的完整系统包含任务拆解与规划工具注册与调用记忆管理策略模型结果评估人工介入接口。而 harness 更聚焦于“模型与工具之间的交互循环”。它通常包含接收模型输出的结构化指令调用对应工具把工具结果整理成模型可读的上下文检查是否需要重试或终止记录轨迹日志。可以这样理解Agent 框架是一套公司体系harness 是其中“执行引擎”的核心环节。很多轻量级 Agent 项目其实只做了一个 harness就已经能解决大量实际问题。3.3 harness 工程设计的关键点从工程角度来看一个好的 harness 至少要做对四件事第一状态可控。每一步都需要明确记录当前状态已经执行了哪些工具、得到了什么结果、模型下一步能看什么、不能看什么。第二重试有界。不能让模型无限循环。必须设置最大步数、最大 token 数、超时时间以及“最终答案”的强制信号。第三可观测性好。每一步的输入输出都要落日志。没有日志调试 Agent 会变成一场灾难。第四验证闭环。harness 不能只负责执行还要有“验证器”判断当前结果是否足够好决定是继续还是终止。社区里看到的很多 harness 项目核心都是这四件事。不同的只是交互形式有些是命令行工具有些是桌面端有些是插件。安装方式也不统一——你可能会看到 pnpm 构建的桌面端、Python 包、GitHub 仓库等各种形态。但底层逻辑一致。4. 自我改进从“自我纠正”到“策略升级”4.1 先厘清概念“自我改进”是争议最大的词。为了理解它我们先把两个容易混淆的概念分开。自我纠正是单次运行内完成的模型答错了通过观察工具执行结果或重新审视推理过程自己修正答案。很多 Agent 框架里的“反思”机制就属于这一类。自我改进是跨运行完成的系统记录多次运行的成功与失败轨迹然后利用这些轨迹更新策略。更新方式可以是不需要更新权重把成功轨迹写入经验库后续任务检索相似经验并注入提示。更新权重用成功/失败轨迹构造训练数据对模型做有监督微调或强化学习。更新流程调整 harness 内部的工具选择规则、重试策略、验证标准。从公开资料看多数开源 Agent 框架优先选择的是“不更新权重”的方式因为成本更低、更可控。但它们在宣传上都会用“自我改进”这个更性感的词。4.2 经典自我改进路径一个典型的自我改进循环是基准策略运行一批任务收集轨迹。用验证器或执行结果给每条轨迹打分。筛选出成功轨迹和失败轨迹。从成功轨迹中提取可复用的模式注入经验库或训练集。在开发集上验证更新后的策略。如果效果下降回滚到上一版策略。这套流程在 ARC-AGI-3 这类任务上尤其有用。因为任务有明确的“输出网格”作为验证信号模型生成规则 → 执行规则 → 对比预期 → 得到对错。这个“对错”信号是自我改进最需要的燃料。4.3 自我改进在 ARC-AGI-3 上的优势ARC-AGI-3 任务胜在“验证信号清晰”。模型可以大胆提出多个规则假设harness 逐个执行并用预期输出验证。不需要人工标注只需要一个网格对比函数。这意味着系统可以在推理阶段就做“搜索”第一次尝试规则 A验证失败观察失败模式尝试规则 B再失败从更小规则集合里尝试规则 C直到找到与所有示例一致的规则。这本质上是一种“推理时搜索”。当搜索到的规则被记录并在后续任务中复用系统就进入了“自我改进”的状态。这也是它能在一些抽象推理任务中超越“直接输出答案”的主要原因。4.4 自我改进的软肋自我改进并不是免费的。它有三个明显问题第一依赖“验证信号”。如果没有明确的执行结果系统就不知道哪些轨迹是好的。在开放任务里只能靠另一个模型打分那就可能引入偏见。第二容易过拟合基准。在 ARC-AGI-3 上自我改进系统可能只是记住了常见的网格变换套路换一套全新分布的任务提升就消失。第三成本非线性增长。每一轮改进都需要大量重试和验证token 消耗会成倍上升。项目收益可能增长但成本增长更快。后面会专门展开争议。5. 最小可复现的自我改进 harness 工作流前面讲了很多概念这一章给出一个可落地的框架。下面内容不绑定具体开源项目而是提炼通用流程。你把它迁移到任何支持 Python 调用的 Agent 框架里都可以。5.1 整体架构任务输入 └─ Policy模型生成推理和动作 └─ Harness 执行工具调用 └─ 工具返回结果 └─ Verifier 判断是否终止 └─ 记录轨迹 └─ 策略更新 / 经验库harness 在这里扮演“执行 反馈 记录”的角色。verifier 是关键模块决定循环何时结束。5.2 配置示例我们先用 YAML 定义一套最小配置。它描述的是“任务、模型、工具、循环、评估”五部分。# 文件路径config.yaml # 本配置为示意具体字段名以你选择的 Agent 框架为准 task: name: arc_agi_3_style_grid max_steps: 20 # 单次任务最多运行 20 步 model: provider: openai_compatible model_name: your-reasoning-model temperature: 0.6 reasoning: true # 开启显式推理 tools: - name: python_executor sandbox: docker timeout_seconds: 30 - name: grid_visualizer sandbox: local loop: max_attempts: 5 # 一个规则假设最多尝试 5 次 retry_on_error: true stop_signal: ANSWER: # 模型输出该信号时强制终止 evaluator: type: grid_match score_threshold: 1.0这里的核心是loop.stop_signal和evaluator.score_threshold。如果没有终止信号推理模型很容易陷入死循环。如果没有评估阈值harness 就不知道什么时候应该停止尝试。5.3 模型推理提示模板为了让模型先推理、再输出答案可以在 prompt 中固定格式你是一个抽象推理求解器。 任务根据输入-输出网格对推断变换规则然后将规则应用到新的输入网格。 要求 1. 先描述你推断出的规则 2. 再用规则推导出输出网格 3. 最终输出必须严格以 ANSWER: 开头。 示例 输入[[0,1],[1,0]] 输出ANSWER: {grid: [[1,0],[0,1]]} 新输入[[1,1,0],[0,1,1]]这种“先规则后答案”的提示有两个好处一是让模型的推理可审查二是给 harness 提供解析依据比如从ANSWER:后面的 JSON 中提取最终网格。5.4 核心循环伪代码下面代码是示意伪代码目的是展示“生成轨迹 → 执行 → 验证 → 策略更新”的最小闭环。# 文件路径self_improving_harness.py # 注意以下为示意伪代码API 需要替换为你实际使用的 Agent 框架 from dataclasses import dataclass from typing import List, Dict dataclass class Trial: task_id: str trajectory: List[Dict] # 每一步的推理、工具调用、结果 answer: str score: float def run_single_episode(task, policy, tools, evaluator, config) - Trial: 在 harness 中运行一次任务 state initialize_state(task) trajectory [] for step in range(config[task][max_steps]): action policy.generate_action(state, trajectory) observation execute_action(action, tools) trajectory.append({step: step, action: action, observation: observation}) if action[type] final_answer: score evaluator.score(task, action[answer]) return Trial(task_idtask.id, trajectorytrajectory, answeraction[answer], scorescore) return Trial(task_idtask.id, trajectorytrajectory, answerstate.get(last_answer), score0.0) def policy_update(trials: List[Trial], policy, evaluator) - None: 用成功/失败轨迹更新策略 success_trials [t for t in trials if t.score evaluator.score_threshold] failure_trials [t for t in trials if t.score evaluator.score_threshold] policy.learn_from_trajectories(success_trials, failure_trials) def main(): config load_config(config.yaml) tasks load_tasks(dev_tasks.jsonl) policy Policy(config[model]) tools init_tools(config[tools]) evaluator Evaluator(config[evaluator]) # 第一轮当前策略直接运行 baseline_trials [ run_single_episode(task, policy, tools, evaluator, config) for task in tasks ] # 自我改进用第一轮结果更新策略 policy_update(baseline_trials, policy, evaluator) # 改进后再次运行观察分差 improved_trials [ run_single_episode(task, policy, tools, evaluator, config) for task in tasks ] baseline_avg sum(t.score for t in baseline_trials) / len(baseline_trials) improved_avg sum(t.score for t in improved_trials) / len(improved_trials) print(fbaseline: {baseline_avg:.2f}) print(fimproved: {improved_avg:.2f})这个循环的关键点在于policy.learn_from_trajectories是自我改进的入口。实现它时最简单的方式是“把成功轨迹的推理摘要写入经验库在后续任务里检索相似片段注入 prompt”更复杂的方式是“用轨迹构造数据集做微调”。从社区实践看先做经验库是最稳妥的。5.5 运行与验证# 1. 先在开发任务集上跑一轮确认 harness 基本可用 python run_harness.py --config config.yaml --mode evaluate --dataset dev_tasks.jsonl # 2. 开启自我改进循环 python run_harness.py --config config.yaml --mode improve --epochs 3 # 3. 输出评测报告 python run_harness.py --config config.yaml --mode report如果第一轮跑出来全部是 0 分不要急着做自我改进。先用人工方式把 2 到 3 个任务跑通确认 prompt、工具调用和 evaluator 都正常。自我改进的前提是“基线流程能产出有效轨迹”而不是在坏流程上反复叠加盲区。6. 争议焦点基准分数、自我改进与真实收益6.1 基准分数可信吗这是最直接的问题。ARC-AGI-3 的公开排行榜看起来很有说服力但任何公开评测都可能被策略性优化。如果框架在开发阶段反复测试并针对测试集特征调整了规则库那分数就不能代表“通用推理能力”只能代表“在该基准上的表现”。更稳妥的判断是除非你亲眼看到框架在全新、未见过的任务上依然保持同等水平否则不要把它当作通用智能的证据。排行榜的价值是“信号”不是“结论”。6.2 自我改进是否真的提高了“通用智能”很难。现阶段的自我改进更多是“策略适应”而不是“能力涌现”。模型本身的知识容量和推理上限没有变改变的是它在特定任务分布上的探索效率。这类似于一个学生做了大量同类题熟练度提升了。但换一类题熟练度可能归零。自我改进的收益高度依赖任务分布的稳定性。ARC-AGI-3 的规则空间相对封闭所以自我改进有效果真实业务场景千变万化效果会明显下降。6.3 分数提升来自算法还是来自工程搜索另一个争议焦点是分数提升到底来自“模型更聪明”还是来自“harness 允许更多次试错”。如果是后者那就不能称为“模型改进”而是“计算预算换分数”。这在学术上可能被批评为作弊但在工程上未必是坏事。很多时候业务需要的不是“模型一次答对”而是“系统最终能答对”。harness 的价值恰恰在这里。但如果你追求的是“更强的通用智能”就需要分开看推理时搜索提升的分数和策略权重更新提升的分数不是一回事。6.4 开发者的判断原则我建议用三个问题判断一套 Agent 方案是否值得跟进第一它的提升是否来自可复用的机制如果是无限重试生产环境复制不了。第二它的验证集是否和真实场景同分布如果是精心挑选的题目参考价值有限。第三它有没有报告失败案例没有失败分析的 Agent 框架测评不值得完全信任。7. 开发者如何评估这类方案并落地7.1 判断你的场景是否适合 RLM harness不是所有业务都需要 Agent 化。先看问题特征适合的场景任务有明确目标且可以拆分步骤每一步都有工具可以执行执行结果可以自动验证或半自动验证用户能接受“多等几秒换来更可靠结果”。不适合的场景纯闲聊、单轮问答目标模糊、无法验证结果对延迟极度敏感工具调用风险极高且未配置人工审批。场景是否建议接入原因代码生成 自动测试建议测试结果就是验证信号数据分析报告建议查询结果可校验客服对话谨慎用户满意度不易自动评估自动下单操作不建议金融风险高需要人工审批实时翻译不建议延迟要求高harness 价值低7.2 落地三个验证步骤第一步用小规模样本跑基线。选 20 到 50 个真实任务记录“成功率、平均步数、token 消耗”。第二步加入 harness 和验证器。对比同一批任务的成功率和耗时。如果成功率没提升问题大概率在评估器或 prompt而不是 harness 本身。第三步做自我改进实验。用第一轮失败轨迹构建经验库观察后续任务是否复用成功模式。如果 100 个任务后效果没有变化说明你的场景不适合自我改进及时止损。7.3 安全与合规边界Agent 接入生产环境时安全是第一优先级。需要至少做到以下几点工具权限最小化harness 只能调用当前任务必需的工具高危操作必须走人工审批。沙箱执行涉及代码执行时优先使用 Docker 等隔离环境。日志全量记录每一步推理、工具调用、参数、结果都要留存便于审计和回溯。数据脱敏自我改进收集的轨迹如果包含真实用户数据必须先脱敏并取得合法授权。回滚机制策略更新失败时可以一键切回到上一版本。7.4 成本评估思路Agent 方案的成本不能只看单次推理价格。要计算平均每任务调用模型次数每次调用平均 token 数工具执行资源成本失败重试带来的额外成本人工处理失败任务的成本。一个常见现象是单次成功率从 70% 提升到 90%看起来只涨了 20 个百分点但 token 消耗可能翻了 3 倍。这未必是个好交易要看业务对“失败率”的容忍度。8. 常见问题与排查思路问题现象可能原因排查方式解决方案harness 安装阶段卡住Node 版本或 pnpm 版本不匹配、依赖源不稳定先查看node -v、pnpm -v再查看安装日志升级到 LTS 版本更换镜像源删除node_modules后重新安装模型一直重复调用同一工具缺少终止条件或状态更新异常查看轨迹日志确认每一步的 state 是否变化在 harness 中强制加入“最大步数”和“禁止重复相同参数”规则模型不输出ANSWER:信号Prompt 格式约束不足检查模型原始输出确认是否被截断简化输出格式提高max_tokens在 prompt 中重复强调输出要求自我改进后分数不升反降策略过拟合失败轨迹或验证信号有噪声对比 baseline 与 improved 在验证集上的逐任务分数缩小策略更新范围增加验证集回滚到上一版本策略执行工具报权限错误Agent 运行环境缺少必要权限查看工具调用报错信息在沙箱中补齐最小权限不要直接给宿主机完全权限推理耗时长token 消耗过高重试次数过多、上下文越来越长查看单任务平均步数和 token 统计设置上下文压缩策略限制最大重试次数设置超时时间排错优先顺序是先看日志确认模型输出了什么再看工具返回确认执行是否正确最后看验证器确认成功标准是否合理。不要一上来就调 prompt。9. 最佳实践与工程建议9.1 先用最小任务跑通闭环不要一开始就压 ARC-AGI-3 这种高难度基准。先选自己业务里最简单的任务比如“根据表格生成一段 SQL 并执行”把“模型 → 工具 → 验证 → 重试”闭环跑通。只要闭环通畅再逐步增加任务复杂度。9.2 把验证器当成一等公民很多 Agent 项目失败不是因为模型不够强而是因为验证器太弱。验证器决定“什么算成功”也就决定了自我改进的方向。设计验证器时要注意验证标准要和业务目标一致分类结果要考虑临界情况验证器本身要有测试用例。9.3 轨迹日志是自我改进的燃料确保每轮运行都留下结构化轨迹字段至少包括task_id模型推理文本工具调用参数工具返回结果验证器得分最终答案运行耗时。有了这些数据你随时可以离线分析失败原因也可以重新构建训练集。9.4 对“自我改进”保持克制自我改进不是自动提分机。它只在满足三个条件时有效验证信号清晰、任务分布稳定、轨迹数据质量可控。三个条件缺一个效果都会打折。建议把“改进前后分数对比”作为标准动作上线而不是直接信任“改进”本身。9.5 保留人工审查出口无论 harness 设计得多好都要保留人工审查和中断能力。尤其是涉及生产数据、外部系统写入、账号操作时必须让系统在关键动作前停下来等待人工确认。这既是为了安全也是为了在出现误判时能快速止损。9.6 关注正收益在哪个环节出现当你观察到效果提升时要追问一句提升来自模型推理能力来自工具执行稳定性还是来自验证器策略这三者的后续投入方向完全不同。如果提升来自验证器你需要继续加固验证逻辑如果来自模型推理你要考虑换更强的基座模型如果来自工具稳定性你应该优化工具层而不是模型层。10. 总结ARC-AGI-3 引发的讨论表面上是刷榜实质是“如何用工程手段放大推理模型能力”的路线之争。RLM 把推理过程显式化harness 把推理过程变成可控的执行闭环自我改进让系统能从历史尝试中积累经验。这三件事叠加在一起构成了当下开源Agent框架的主流技术路径。这个路径有价值但不是银弹。它的价值在于当你有一个验证信号足够清晰、任务分布相对稳定的业务场景时这套方法能稳定提升系统的最终表现。它的风险在于一旦验证信号失真、任务分布偏移或成本失控“自我改进”就会变成一种昂贵的过拟合。建议你从一个小任务开始先跑通“模型 工具 验证器”的最小闭环再考虑加入自我改进。把基础流程做稳比追逐任何榜单分数都重要。