企业官网建设流程全解析

最近，开源社区里关于 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-AGI（Abstraction 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 任务中，自我改进不是一个模糊的概念，而是一套明确的工程机制。常见实现包括：

1. 结果反馈循环：模型先生成代码，运行后如果失败，把错误信息拼回上下文，让模型生成新代码。
2. 验证器辅助：harness 内置一个验证器，把模型输出和标准答案比较，再返回差异描述，比如“前两行正确，第三行颜色不一致”。
3. 反思重写：模型在失败后，不直接改代码，而是先总结失败原因，再基于原因提出修改方案，最后重写代码。
4. 多候选投票：模型同时生成多个候选方案，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推理harness

3.1 基础环境与依赖

为了让你对 ARC-AGI-3 的 Agent 任务有一个直观感受，我们这里搭建一个最小可运行的推理 harness。它不会复刻完整刷榜系统，但会把核心流程演示出来：模型生成代码 -> 沙箱执行 -> 验证 -> 反馈 -> 重试。

建议环境：

如果你本地没有可以调用的推理模型，也可以先用一个简单的规则模型或者一个本地小模型占位，重点理解 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.py

import json def load_task(path): with open(path, "r", encoding="utf-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.py

import json import requests def call_llm(prompt, api_url="http://localhost:8000/v1/chat/completions", api_key="EMPTY", model="local-model"): payload = { "model": model, "messages": [{"role": "user", "content": prompt}], "temperature": 0.2, "max_tokens": 2048 } resp = requests.post(api_url, json=payload, headers={"Authorization": f"Bearer {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示例 {i+1}:\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.py

import subprocess import textwrap import sys import os def run_solve_code(code, input_grid, timeout=10): 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_output=True, text=True, timeout=timeout, cwd=os.getcwd() ) return proc.returncode, proc.stdout.strip(), proc.stderr.strip() except subprocess.TimeoutExpired: return -1, "", "Timeout"

文件路径：validator.py

import 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.py

import 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_attempts=5): 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"训练样本 {idx+1}: {'通过' if ok else '失败'}") if not ok: all_correct = False feedback_lines.append( f"训练样本 {idx+1} 失败，执行信息: {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"测试样本 {idx+1} 预测结果:", 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_attempts=5) 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 这类正式评测任务中，一个任务通常包含多个测试样本，最终得分是所有任务正确率的加权平均。评测框架一般会记录每个任务的模型输出、执行过程、成功与否，方便后期分析。

在工程中，我建议日志至少包含以下字段：

记录这些字段能帮你快速定位问题。比如某个任务反复失败，你就可以查看是不是模型一直生成语法错误代码，或者验证器本身有 bug。

5.3 自我改进前后对比

为了直观理解“自我改进”的收益，我们可以做一个简单实验：把max_attempts分别设置为 1 和 5，观察最终通过率差异。

• 当max_attempts=1时，模型只有一次生成机会，如果刚开始思路不对，就会直接失败。
• 当max_attempts=5时，模型可以利用错误信息迭代修正，成功率通常明显提升。

这就是反馈循环的价值。在 ARC-AGI-3 这类任务上，反馈循环的作用尤其明显，因为图形变换规则往往可以通过一次小规模试错快速发现。需要注意的是，这种提升并不完全来自“模型学会了推理”，更准确地说，是来自“模型被允许在外部校验器的帮助下搜索解决方案”。

6. 常见问题与排查思路

在实际运行 Agent harness 时，你可能会遇到下面这些问题。

排查建议：

1. 先确认模型返回的代码能独立运行。把代码复制到本地 Python 环境，手动喂一个输入，看输出是否正常。
2. 确认验证器逻辑没有 bug。单独写单元测试，测试验证器对相同输入返回 True，对不同输入返回 False。
3. 检查错误信息是否真正传回模型上下文。如果反馈信息被截断，模型就得不到有效修正依据。
4. 分阶段记录日志。执行阶段、验证阶段、模型调用阶段分别打点，便于定位瓶颈。

7. 工程实践与思考：harness能用到生产吗

7.1 评测场景下的harness设计

如果你要搭建一个正式的 ARC-AGI-3 或类似任务的评测 harness，有几点值得注意：

第一，隔离性。模型生成的代码必须在沙箱中运行，避免对宿主环境造成破坏。推荐用 Docker 容器或 nsjail，限定 CPU、内存、网络、文件系统权限。

第二，可复现性。评测结果必须可复现。你需要固定模型版本、prompt 模板、温度参数、随机种子。任何微小的变化都可能影响得分。

第三，公平性。横向对比不同 Agent 框架时，确保每个框架使用相同的计算资源和尝试次数限制，否则结果没有可比性。

第四，成本控制。ARC-AGI-3 类任务如果允许模型反复尝试、生成大量 token，API 费用会快速上升。建议设置每任务 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 开发，可以从以下路径入手：

1. 掌握大模型 API 调用基础，理解 prompt 工程。
2. 理解 Agent 的基本循环：决策、行动、观察、再决策。
3. 学会用 Python 实现一个最小工具调用系统。
4. 学习代码沙箱隔离方案，确保模型生成的代码安全执行。
5. 研究 ARC 类任务的数据格式，尝试用代码生成方式解决图形推理题。
6. 阅读社区开源 harness 项目的源码，理解评测框架设计。
7. 最后，如果你有探索精神，可以尝试自己设计一个“带自我改进能力”的 Agent，在固定任务上对比加入反馈循环前后的效果差异。

这个过程不需要一步到位。从一个最小闭环开始，逐步加入更复杂的工具、更完善的验证器、更智能的反思逻辑。你会发现，Agent 开发的核心并不只是模型本身，而是模型和外部环境之间的交互设计。

如果这篇文章对你有帮助，可以先收藏备用。后面有空可以拿示例代码跑一跑，相信你会对 ARC-AGI-3 的争议有更具体的理解。