最近开源社区里关于 Agent 框架和 ARC-AGI-3 的讨论非常多。不少开发者在群里转发某个开源项目刷榜的消息紧接着又围绕RLM、harness、自我改进这些词展开激烈争论这到底是大模型能力真的变强了还是测试方式本身为模型“开了一扇窗”如果你也关注 AI Agent 开发或者正在研究推理模型在不同评测基准上的表现这篇文章会帮你把这些概念一次理清楚。本文会围绕三个问题展开第一ARC-AGI-3 是什么为什么用它来评测 Agent 框架会引发讨论第二RLM harness和自我改进机制到底做了什么让很多团队拿到了明显更好的结果第三抛开争议我们可以怎么理解这套思路并把它用在真实的 Agent 工程里。内容会包含代码示例、配置思路、常见问题和工程建议既能给新手补基础也能给有经验的开发者提供一些可落地的参考。1. 背景ARC-AGI-3、Agent框架与RLM是什么1.1 从 ARC-AGI 到 ARC-AGI-3一个越来越难的推理基准ARC-AGIAbstraction and Reasoning Corpus是一套用于评估模型抽象推理能力的基准测试。它不像普通问答数据集那样考察知识记忆而是给出若干个输入输出网格示例要求模型根据这些示例推断出隐藏的图形变换规则并应用到新的测试输入上。这套基准的原始版本设计得很有挑战性因为人类很容易理解这些图形规则但传统深度学习模型却很难泛化。随着大语言模型和视觉语言模型的发展社区陆续推出了难度更高、更强调多步推理的版本。ARC-AGI-3 可以理解为这个系列中的一个阶段任务更加复杂更考验模型在未知规则面前的适应能力也让单纯的“背题式”训练难以奏效。那么ARC-AGI-3 和普通评测有什么不同最核心的一点是它更接近“在没有明确指令的情况下通过少量示例发现规律并完成变换”。这意味着模型不仅要理解图形还要拥有类似程序合成、规则搜索、自我验证等能力。传统的一次性生成答案方式很难得高分于是很多团队开始把 Agent 框架引入进来让模型可以在推理过程中“动手尝试”。1.2 Agent框架与harness从“写提示词”到“搭系统”当我们说“Agent 框架”时通常会联想到让语言模型执行一系列自主行为的系统模型根据当前情况做决策调用工具观察结果然后再次决策直到完成任务。这类框架一般包含模型调用层负责与大模型交互。工具层提供代码执行、文件读写、网络请求等能力。记忆层保存历史信息、中间结果。规划层决定下一步动作。验证层确认任务是否完成以及结果是否可靠。而harness这个词在 Agent 语境里通常指“控制 Agent 运行的外部框架”或“评测时的整套执行环境”。它有点像汽车里的安全约束系统把模型的输出约束在一定的操作空间里同时提供反馈信号。在 ARC-AGI-3 任务中harness 可以决定模型是否有权限运行 Python 代码、是否能查看错误信息、是否能在失败后重新尝试。这些能力对最终得分影响非常大。这里需要澄清一个容易混淆的概念Agent和harness不是同一个东西。Agent更像是“大脑 动手能力”而harness更像是“外壳 约束 反馈系统”。同一个模型放在不同的 harness 里表现可能完全不同。这也正是 ARC-AGI-3 争议的核心。1.3 RLM推理语言模型为什么是这次的主角RLM通常指 Reasoning Language Model即具有显式推理能力的语言模型。和普通 LLM 直接输出答案不同RLM 会先生成一段推理过程再给出最终结论。常见的做法包括 Chain-of-Thought思维链、Self-Consistency自我一致性以及更复杂的 Test-Time Compute Scaling测试时计算扩展。在 ARC-AGI-3 这种需要多步推导的任务中RLM 的优势很明显它可以把一个复杂问题拆解成多个中间步骤然后逐步验证每个步骤的正确性。更重要的是如果把 RLM 放进 Agent 框架中模型在推理过程中不只是“想”而是真的可以写代码、跑结果、看反馈形成闭环。这种模式下模型的能力边界被大幅扩展。但问题也来了当得分提升主要来自外部工具和反复尝试时我们还能说这是模型“智能”的提升吗这是 ARC-AGI-3 争议的另一个核心。2. 争议焦点自我改进的harness算不算“作弊”2.1 harness在Agent评测中的角色在 ARC-AGI-3 这类评测任务中harness 的核心作用可以拆成三块第一提供执行环境。模型可以生成 Python 代码然后在沙箱中运行得到实际输出。这相当于给模型装上了“手”。第二提供反馈信号。模型运行代码后如果结果不对系统会把错误信息、实际输出、期望输出的差异返回给模型让模型有机会修正思路。这个循环在普通大模型评测中是不存在的。第三控制搜索空间。harness 可以决定模型尝试多少次、是否允许访问额外数据、是否允许生成多个候选答案再做选择。这些参数直接决定了模型的“探索能力”。从工程角度看harness 就是一种典型的 Agent 编排方式本身并没有问题。问题在于当我们说“某个 Agent 框架在 ARC-AGI-3 上取得了 XX 分”时这个分数反映的是“模型 Agent 框架 执行环境 评分策略”的整体表现而不是模型本身的纯推理能力。这样看争议的本质其实是评测目标和评测对象之间的错位。2.2 “自我改进”机制的技术本质自我改进self-improvement是这次讨论中的高频词。在 ARC-AGI-3 的 Agent 任务中自我改进不是一个模糊的概念而是一套明确的工程机制。常见实现包括结果反馈循环模型先生成代码运行后如果失败把错误信息拼回上下文让模型生成新代码。验证器辅助harness 内置一个验证器把模型输出和标准答案比较再返回差异描述比如“前两行正确第三行颜色不一致”。反思重写模型在失败后不直接改代码而是先总结失败原因再基于原因提出修改方案最后重写代码。多候选投票模型同时生成多个候选方案harness 运行所有候选挑选与预期输出最接近的一个。从技术本质上看这套机制就是经典的generate - execute - verify - retry循环。之所以叫“自我改进”是因为模型不依赖人类标注或额外模型而是利用执行反馈逐步修正自己的输出。这种做法在代码生成、数学推理等领域已经很常见ARC-AGI-3 只是把这个思路用在了图形推理任务上。2.3 支持派与质疑派分别怎么看支持派认为模型 harness的联合系统本身就是未来 AI 应用的雏形。现实世界中没有人要求模型只凭记忆和单次生成完成任务相反能使用工具、能试错、能看反馈的系统才更接近真实智能。ARC-AGI-3 测试的不再是“模型的记忆”而是“系统解决问题的能力”这恰恰是 Agent 应用最需要的。质疑派则指出这样的评测会掩盖模型底层能力的不足。如果模型本身不会推理但只要给它一个代码执行环境再让它多试几次就能在很多任务上拿到不错的分数那 ARC-AGI-3 测的实际上是“搜索能力 代码生成能力 错误信息利用能力”而不是“抽象推理能力”。如果所有模型都在同一个 harness 下运行得分或许可以比较但不同项目使用不同 harness横向对比就失去了意义。我的看法是两种观点都有道理。评测应当区分“模型能力”和“系统能力”。如果你的目标是在业务中构建可靠的 Agent那么 harness 带来的提升是实打实的如果你的目标是研究模型本身的智能水平那么就需要剥离外部工具单独评估纯推理能力。关键在于发布结果时要说清楚评测环境不让读者误以为分数完全来自模型本身。3. 环境准备搭一个最小的Agent推理harness3.1 基础环境与依赖为了让你对 ARC-AGI-3 的 Agent 任务有一个直观感受我们这里搭建一个最小可运行的推理 harness。它不会复刻完整刷榜系统但会把核心流程演示出来模型生成代码 - 沙箱执行 - 验证 - 反馈 - 重试。建议环境组件推荐版本/方案操作系统Ubuntu 20.04 或 macOS 12Python3.10 或 3.11大模型接口OpenAI 兼容接口可以是本地 vLLM/Ollama 或云 API沙箱执行本地 Python 子进程或 Docker 沙箱辅助库requests, json, subprocess 标准库即可如果你本地没有可以调用的推理模型也可以先用一个简单的规则模型或者一个本地小模型占位重点理解 harness 流程。3.2 开源工具链选择目前在 Agent 开发领域社区常用的工具链包括几类通用 Agent 框架如 LangChain、LlamaIndex 等提供记忆、工具调用、Agent Loop 的基础能力。代码执行沙箱如 Docker、nsjail、restricted Python 子进程确保模型生成的代码不会破坏宿主机。评测驱动框架最近较受关注的harness类项目会专门为某个评测集定制执行与验证流程比如把 ARC 任务转换成代码生成任务再用执行结果打分。核心思路是评测任务最好被转换成“可以执行、可以验证”的形式。ARC-AGI-3 的图形变换天然适合转成 Python 代码任务因为模型可以写函数harness 运行函数并校验输出网格。这也是为什么许多开源 Agent 框架能在 ARC-AGI-3 上表现不错的原因它们把视觉推理任务变成了“代码生成 执行验证”任务。3.3 项目结构设计我们创建一个简单的项目结构arc_agent_harness/ ├── main.py # 主入口运行 Agent 循环 ├── agent_core.py # 模型调用与决策逻辑 ├── sandbox.py # 代码沙箱执行 ├── validator.py # 输出校验器 ├── tasks/ │ └── sample_task.json # 示例任务数据 └── logs/ └── run_log.jsonl # 运行日志设计思路main.py负责流程编排。agent_core.py是模型交互层负责构造 prompt、发送给模型、接收回复。sandbox.py是代码执行层把模型生成的代码放到受限环境运行。validator.py是比较结果层判断输出网格是否与期望一致。这个分层结构清晰后续如果你想接入更完整的 Agent 框架只需要替换agent_core.py或增加更多工具即可。4. 核心实现以代码生成 执行验证方式跑 ARC 任务4.1 任务加载与输入格式ARC 类任务通常是一个 JSON 文件包含训练样本和测试样本。每个样本由多个input_grid和output_grid组成。我们先写一个任务加载函数。文件路径tasks/sample_task.json{ train: [ { input: [[0, 1], [1, 0]], output: [[1, 0], [0, 1]] } ], test: [ { input: [[1, 0], [0, 1]] } ] }这里的示例非常简化实际 ARC-AGI-3 任务会复杂得多比如更大的网格、多种颜色、复杂的形状变换规则。我们先用这个简化任务演示流程。文件路径main.pyimport json def load_task(path): with open(path, r, encodingutf-8) as f: data json.load(f) return data if __name__ __main__: task load_task(tasks/sample_task.json) print(训练样本数量:, len(task[train])) print(测试样本数量:, len(task[test]))这段代码的作用很简单把任务文件读入内存。在真实项目中你还需要处理更大规模的任务集并添加冲突检查逻辑比如确认训练集中所有input和output的尺寸一致。4.2 让模型“写代码解题”的Agent循环接下来是 Agent 循环的核心我们把任务描述、训练示例和模型需要生成的要求放进 prompt让模型输出一个可执行的 Python 函数。函数接收input_grid返回output_grid。文件路径agent_core.pyimport json import requests def call_llm(prompt, api_urlhttp://localhost:8000/v1/chat/completions, api_keyEMPTY, modellocal-model): payload { model: model, messages: [{role: user, content: prompt}], temperature: 0.2, max_tokens: 2048 } resp requests.post(api_url, jsonpayload, headers{Authorization: fBearer {api_key}}) resp.raise_for_status() data resp.json() return data[choices][0][message][content] def build_prompt(train_samples): prompt 请仔细观察以下输入输出网格样例总结变换规则。\n for i, sample in enumerate(train_samples): prompt f\n示例 {i1}:\n prompt f输入:\n{json.dumps(sample[input])}\n prompt f输出:\n{json.dumps(sample[output])}\n prompt \n请编写一个 Python 函数 solve(input_grid)输入是一个二维列表输出是变换后的二维列表。\n prompt 只输出函数代码不要输出额外解释。\n return prompt这里有几个关键点temperature设置较低是为了让模型在生成代码时更稳定。prompt 中明确要求“只输出函数代码”减少模型废话。实际项目中你可以根据模型能力调整函数名、输入输出格式。为了让代码更容易被沙箱执行建议在call_llm后加一个简单清理函数去掉 Markdown 代码块标记。4.3 验证器与错误反馈模型生成代码后harness 需要在沙箱中执行代码并把输出与期望结果比较。如果失败需要把错误信息返回给模型。文件路径sandbox.pyimport subprocess import textwrap import sys import os def run_solve_code(code, input_grid, timeout10): wrapped_code textwrap.dedent(code) # 建立可执行脚本 script f {wrapped_code} if __name__ __main__: test_input {input_grid!r} result solve(test_input) print(result) try: proc subprocess.run( [sys.executable, -c, script], capture_outputTrue, textTrue, timeouttimeout, cwdos.getcwd() ) return proc.returncode, proc.stdout.strip(), proc.stderr.strip() except subprocess.TimeoutExpired: return -1, , Timeout文件路径validator.pyimport ast def parse_output(stdout): if not stdout: return None try: return ast.literal_eval(stdout) except Exception: return None def validate(expected_output, actual_output): return expected_output actual_output沙箱需要注意安全性subprocess运行模型生成的代码存在风险。在本地演示环境中我们只运行可信代码在生产环境中你需要把代码放到 Docker 容器、nsjail 或云沙箱中运行。4.4 写入反思与自我改进的简化流程现在我们把所有环节组合起来模型生成代码 - 执行 - 校验 - 如果失败把错误信息拼回上下文让模型修改代码 - 重复若干次。文件路径main.pyimport json from agent_core import call_llm, build_prompt from sandbox import run_solve_code from validator import parse_output, validate def extract_code(text): if python in text: return text.split(python)[1].split()[0].strip() if in text: return text.split()[1].strip() return text.strip() def run_agent(task, max_attempts5): train_samples task[train] test_samples task[test] first_prompt build_prompt(train_samples) prompt first_prompt for attempt in range(1, max_attempts 1): print(f\n 第 {attempt} 次尝试 ) response call_llm(prompt) code extract_code(response) print(生成的代码:\n, code) # 在训练集上执行拿到期望输出与模型输出的对比 all_correct True feedback_lines [] for idx, sample in enumerate(train_samples): expected sample[output] returncode, stdout, stderr run_solve_code(code, sample[input]) actual parse_output(stdout) ok validate(expected, actual) print(f训练样本 {idx1}: {通过 if ok else 失败}) if not ok: all_correct False feedback_lines.append( f训练样本 {idx1} 失败执行信息: {stderr}, 期望输出: {expected}, 实际输出: {actual} ) if all_correct: print(所有训练样本通过尝试预测测试样本。) for idx, sample in enumerate(test_samples): returncode, stdout, stderr run_solve_code(code, sample[input]) print(f测试样本 {idx1} 预测结果:, stdout) return code feedback \n.join(feedback_lines) prompt first_prompt \n\n你上一次生成的代码在训练样本上失败错误信息如下\n feedback \n请修正代码。\n print(达到最大尝试次数未完全通过训练集。) return None if __name__ __main__: task load_task(tasks/sample_task.json) solve_func run_agent(task, max_attempts5) print(\n最终得到的函数代码:\n, solve_func)这个循环的意义在于模型拿到错误信息后会尝试分析失败原因。比如上一次代码把颜色值 0 和 1 对调了但训练集暴露了这一点模型下一次就可能修正。这就是一个迷你版的“自我改进”流程。在真实项目中你可能还需要加入seed固定便于复现。加入 token 预算控制避免无限重试。记录每次尝试的完整日志便于后续分析。对多候选方案进行排序选择表现最好的一个。5. 运行流程与效果评估5.1 运行Agent harness在终端执行cd arc_agent_harness python main.py如果模型接口配置正确你会看到类似输出 第 1 次尝试 生成的代码: def solve(input_grid): return [[1 - x for x in row] for row in input_grid] 训练样本 1: 失败 第 2 次尝试 生成的代码: def solve(input_grid): return [[1 - x for x in row] for row in input_grid] 训练样本 1: 通过 所有训练样本通过尝试预测测试样本。 测试样本 1 预测结果: [[0, 1], [1, 0]]这个日志展示了 Agent 的决策过程第一步失败错误信息被反馈给模型第二步模型修正思路最终通过。虽然这个例子很简单但它演示了generate - execute - verify - retry的完整闭环。5.2 得分与日志分析在 ARC-AGI-3 这类正式评测任务中一个任务通常包含多个测试样本最终得分是所有任务正确率的加权平均。评测框架一般会记录每个任务的模型输出、执行过程、成功与否方便后期分析。在工程中我建议日志至少包含以下字段字段含义task_id任务编号attempt当前尝试次数prompt_hash提示词哈希便于复现generated_code模型生成的代码execute_status执行状态成功/失败/超时validate_result是否通过校验error_message错误信息timestamp运行时间记录这些字段能帮你快速定位问题。比如某个任务反复失败你就可以查看是不是模型一直生成语法错误代码或者验证器本身有 bug。5.3 自我改进前后对比为了直观理解“自我改进”的收益我们可以做一个简单实验把max_attempts分别设置为 1 和 5观察最终通过率差异。当max_attempts1时模型只有一次生成机会如果刚开始思路不对就会直接失败。当max_attempts5时模型可以利用错误信息迭代修正成功率通常明显提升。这就是反馈循环的价值。在 ARC-AGI-3 这类任务上反馈循环的作用尤其明显因为图形变换规则往往可以通过一次小规模试错快速发现。需要注意的是这种提升并不完全来自“模型学会了推理”更准确地说是来自“模型被允许在外部校验器的帮助下搜索解决方案”。6. 常见问题与排查思路在实际运行 Agent harness 时你可能会遇到下面这些问题。问题现象常见原因解决思路模型生成代码包含 Markdown 标记prompt 未约束输出格式后处理时移除python标记沙箱执行超时模型生成的代码死循环设置timeout并在 prompt 中提醒模型避免复杂循环所有训练样本均通过但测试集全错模型过拟合训练样例增加训练样本数量或使用更多候选方案做投票模型生成代码语法错误模型能力限制或上下文过长减少 prompt 中无关信息或换更强的模型API 请求超时模型服务不稳定增加重试机制提高超时时间测试样本输出格式与预期不一致模型返回了 JSON 字符串而非列表在 prompt 中明确要求返回二维列表格式排查建议先确认模型返回的代码能独立运行。把代码复制到本地 Python 环境手动喂一个输入看输出是否正常。确认验证器逻辑没有 bug。单独写单元测试测试验证器对相同输入返回 True对不同输入返回 False。检查错误信息是否真正传回模型上下文。如果反馈信息被截断模型就得不到有效修正依据。分阶段记录日志。执行阶段、验证阶段、模型调用阶段分别打点便于定位瓶颈。7. 工程实践与思考harness能用到生产吗7.1 评测场景下的harness设计如果你要搭建一个正式的 ARC-AGI-3 或类似任务的评测 harness有几点值得注意第一隔离性。模型生成的代码必须在沙箱中运行避免对宿主环境造成破坏。推荐用 Docker 容器或 nsjail限定 CPU、内存、网络、文件系统权限。第二可复现性。评测结果必须可复现。你需要固定模型版本、prompt 模板、温度参数、随机种子。任何微小的变化都可能影响得分。第三公平性。横向对比不同 Agent 框架时确保每个框架使用相同的计算资源和尝试次数限制否则结果没有可比性。第四成本控制。ARC-AGI-3 类任务如果允许模型反复尝试、生成大量 tokenAPI 费用会快速上升。建议设置每任务 token 上限并把中间结果缓存下来避免重复调用模型。7.2 生产Agent系统的harness设计从评测 harness 到生产 Agent 系统中间有很多可以迁移的经验。有限重试机制生产环境中Agent 不能无限重试。你需要定义最大尝试次数、最大 token 数、最大执行时间。可观测性每个 Agent 决策都应该有日志包括 prompt、模型输出、工具返回、最终结果。这样出现问题可以快速回放。安全边界模型调用工具时要明确工具的权限范围。尤其是执行代码、访问数据库、发送外部请求等高风险操作必须走独立的权限流程。反馈质量harness 返回给模型的反馈信息越具体模型修正效果越好。与其说“结果不对”不如说“第 2 行第 3 列的颜色值应该是 5”。在设计验证器时可以尽量生成可解释的错误描述。7.3 伦理与边界测评分数的“含金量”围绕 ARC-AGI-3 的争议其实给整个行业提了一个醒。当我们看到一个“开源 Agent 框架刷榜”的消息时不要只关注分数还要关注几个问题这个分数是在什么提示词、模型、工具组合下取得的模型被允许尝试多少次是否使用了额外数据集或训练技巧测试环境是否与推理阶段环境完全隔离如果评测的是“Agent 系统解决问题的能力”那么高分是合理的。但如果评测的是“模型本身的能力”那么加入代码执行、重试、验证器这些辅助手段会让分数失真。发布结果时最好把 harness 配置一并公开这不仅是学术诚信问题也是工程效率问题别人可以根据你的配置做对照实验而不是从头猜测。8. 下一步学习建议8.1 从ARC-AGI到更通用的Agent评测ARC-AGI-3 只是 Agent 评测体系中的一环。如果你想深入研究可以关注这几个方向推理能力评测使用不依赖工具的纯文本推理任务考察模型基础能力。工具调用评测提供一个工具集让模型自主选择并调用工具完成任务。多轮交互评测让 Agent 与模拟用户或环境进行多轮交互评估长期任务完成能力。自我改进评测设计需要多轮尝试才能解决的复杂任务评估模型的错误修复能力。每个评测方向都需要不同的 harness 设计。不要试图用一个框架打天下而是根据评测目标灵活组合。8.2 学习路线建议如果你刚接触 Agent 开发可以从以下路径入手掌握大模型 API 调用基础理解 prompt 工程。理解 Agent 的基本循环决策、行动、观察、再决策。学会用 Python 实现一个最小工具调用系统。学习代码沙箱隔离方案确保模型生成的代码安全执行。研究 ARC 类任务的数据格式尝试用代码生成方式解决图形推理题。阅读社区开源 harness 项目的源码理解评测框架设计。最后如果你有探索精神可以尝试自己设计一个“带自我改进能力”的 Agent在固定任务上对比加入反馈循环前后的效果差异。这个过程不需要一步到位。从一个最小闭环开始逐步加入更复杂的工具、更完善的验证器、更智能的反思逻辑。你会发现Agent 开发的核心并不只是模型本身而是模型和外部环境之间的交互设计。如果这篇文章对你有帮助可以先收藏备用。后面有空可以拿示例代码跑一跑相信你会对 ARC-AGI-3 的争议有更具体的理解。