最近这段时间如果你的时间线经常刷技术讨论应该能感受到一个词的出现频率突然变高了——harness。从 DeepSeek harness、Codex harness 这类社区封装工具被反复翻出来对比到一个开源 Agent 框架在 ARC-AGI-3 上的表现刷爆讨论区整个话题并不是孤立发生的。很多人第一次看到“harness”这个英文词以为是某种新模型其实它更像一套把模型“架起来跑”的工程框架。这套框架最吸引人的地方是它让语言模型不再只是“生成一次答案就结束”而是可以把生成、执行、检查、纠错循环起来。社区里讨论得最凶的就是 RLM harness——一套带自我改进机制的 Agent 封装。我的核心判断是真正值得关注的不是某个 Agent 又在推理基准上刷了多少分而是“自我改进”从一个模糊概念变成了一套可工程化、可复用的流程。但与此同时你必须分清楚哪些改进是真的哪些只是用算力换来的“看起来更强”。下面我会从 ARC-AGI-3 为什么难、RLM harness 的核心机制、争议焦点、最小工程落地以及我的个人判断几个角度展开。1. ARC-AGI-3 到底难在哪它考的不是知识而是规律归纳要理解这次讨论为什么这么激烈得先明白 ARC-AGI-3 这类评测到底在做什么。它和传统的知识问答、数学题、代码题都不一样核心难点不在“知道什么”而在“能不能当场发现规律”。1.1 从 ARC 系列的设计逻辑看这为什么是硬骨头ARC 系列评测有一个共同设定给模型看几个输入输出示例每个示例都是一张网格图模型需要归纳出输入到输出之间的变换规律然后把它应用到新的输入上。这些题目不是靠背诵能解决的因为训练数据里几乎不可能出现同样的题目。模型面对的不是“知识回忆”而是“当场归纳规则”。ARC-AGI-3 延续了这种设计思路区别在于题目更复杂、更陌生也更考验模型的组合推理能力。它要求的不是“这个知识点我见过”而是“我能不能从三个例子里猜出变换规则并用它预测第四个例子”。这里有个很容易被低估的难点网格题的规则空间非常大。一个看起来简单的变换可能是颜色替换、形状移动、数量统计、对称翻转也可能是几种规则的组合。更麻烦的是同一个示例集可能对应多种规则其中有一种是自然的其他几种是勉强成立的。模型不仅要找到一条规则还要找到那条最可能被出题人采用的规则。1.2 单次生成模型的天然劣势传统的大模型调用方式是输入问题输出答案一次完成。你给它三个网格示例它生成一个输出网格。如果错了就错了没有机会再检查。对 ARC 这类任务来说这是致命的。因为人在做这类题目时并不是一次就能想到正确答案。我们通常先形成一个候选假设用它去验证示例里的输入输出如果对不上就换一个假设。单次生成模型跳过了“验证”这一步等于要求模型看一眼题目就说出最终答案。你可能会想让模型在多轮对话里自己检查一下不就行了理论上是行得通的但实践中很难稳定。模型在“生成答案”和“检查答案”之间切换时经常会顺着自己的错误往下走。它会把错误答案当作已知前提然后解释得头头是道。这种现象在推理任务里非常常见不是简单加一句“请仔细检查”就能解决的。1.3 Agent 框架为什么能刷上去开源 Agent 框架的做法是把“生成答案”拆成“生成方案—执行方案—检查方案—修正方案”多个步骤。每一步由独立模块负责失败之后不是让模型自己硬想而是把错误信息回传再生成新的方案。这就像考试时单次生成是“看一眼就交卷”Agent 框架是“做完之后可以重读检查、验算、再做一遍”。自然后者在 ARC 这类需要反复试错的题目上会拿到更高分数。但这里要澄清一点Agent 框架在 ARC-AGI-3 上表现提升不表示它打通了通用推理。它更像把原本被压缩在“一次生成”里的推理过程显式地拆成了一个搜索过程。模型本身的知识和能力没有变化变化的是系统允许它“多试几次”并“从失败中修正”。所以刷榜背后的真正变量不是模型变聪明了而是系统允许它花更多算力去逼近正确答案。这个判断是理解后面所有争议的起点。2. RLM harness 的核心机制从“答题模型”到“会检查答题的系统”既然 Agent 框架能靠“多步尝试”提升成绩那一个很自然的问题是这种尝试是怎么组织起来的RLM harness 给出的答案是把整个流程封装成一个可循环运行的系统。它不依赖人工在提示词里反复说“请检查”而是用工程手段把“反思—修改—再执行”固化下来。2.1 一个最小 harness 由哪些组件组成不同项目里 RLM 的展开不完全一样有的叫 Recursive Language Model有的把它理解成循环反思机制。但抛开名字一个最小的 RLM harness 通常包含这些组件任务解析器把题目转换成模型能理解的结构化描述比如把网格表示成坐标或字符序列。生成器负责生成候选方案或答案通常就是主语言模型。执行器把方案落到具体操作上比如运行代码、调用工具、执行命令。验证器判断结果是否符合预期。这是整个框架里最关键也最容易出错的部分。反思器当验证失败时分析失败原因生成下一轮的改进建议。记忆模块把失败原因和策略记忆写入上下文让下一轮尝试有据可依。这些组件串起来之后一次任务就不再是“输入—输出”而是一个循环。一个常见流程可以简化成下面这样for attempt in range(max_attempts): # 生成器基于当前记忆生成一个计划或答案 plan model.generate(task, strategy_memory) # 执行器把计划落到具体操作上 result execute(plan) # 验证器判断结果是否正确 verdict validator(task, result) if verdict.is_pass: return result # 反思器分析失败原因 error model.analyze(task, plan, result, verdict) # 把反思结果写入记忆供下一轮使用 strategy_memory.append(error)这个循环看起来简单但它的价值在于把“失败—修正”这个过程从不可控的提示词工程变成了可控的工程流程。每一轮尝试的输入、输出、验证结果、反思内容都会被记录你可以定位到具体是哪一步出了问题。2.2 自我改进到底发生在哪一步很多人的第一反应是自我改进难道不是更新模型权重吗不是。大多数 RLM harness 里的“自我改进”并不动模型权重而是改“轨迹”。也就是说模型本身没有变聪明但它面对同一个任务时思考路径和尝试策略会发生变化。这个变化通过上下文管理实现上一轮失败产生的错误信息被注入到下一轮的生成上下文里。这就像程序员调试代码不是重写编译器而是看日志、加断点、改代码、再跑。它改的是执行方案不是编程语言本身。更准确地说这是一种运行期改进。模型在一道题上吃一堑长一智但这个“智”只存在于当前任务上下文里。换一道新题它不会记得上一道题的经验。所以它更接近“系统级的自我修正”而不是数据科学意义上的“自我改进”。2.3 为什么这样的设计有优势最大的优势是它不需要重新训练也不需要微调。只要模型有足够的上下文长度和推理能力就能在运行过程中实现纠错。对开源社区来说这意味着不需要大规模训练算力也能提升基准表现。你不需要收集大量数据、跑分布式训练、做对齐调优只需要在生成流程外面套一层循环逻辑。这是 harness 能在短时间内火起来的重要原因。但这也是争议的来源。因为这种“改进”是有代价的——它用更多的模型调用、更多的 token、更多的计算时间换取了更高的正确率。你得到的不是一个更强的基础模型而是一个更强的推理系统。3. 争议的焦点这是真能力还是用算力换分数ARC-AGI-3 刷爆之后社区里立刻分成了两派。一派认为这类框架代表了 Agent 的发展方向另一派则认为这只是一场“用算力套利”的表演。两边都有道理但我觉得争论真正混乱的地方是大家对“自我改进”这个词的理解不在一个层级上。3.1 支持者的逻辑结果正确就是能力支持者会说最终评测看的是正确答案比例。如果一个系统能通过检查、反思、重试拿到正确答案那它确实有更强的解题能力。人类做题时也有反复验算的过程没有人规定考试只能提交一次答案。既然 ARC-AGI-3 没有限制模型调用次数那把它当成一种能力去评估也没什么问题。而且从工程角度讲“能在失败后自我修正”恰恰是 Agent 和大模型产品化的关键能力。现实世界的任务很少有一帆风顺的代码会报错、接口会超时、数据会有噪声。一个系统能不能在出错后自己发现问题、调整策略、继续推进直接决定了它能不能用在真实项目里。支持者认为RLM harness 把这种能力从一个模糊愿景变成了可落地的代码。3.2 质疑者的逻辑这更像在搜索答案质疑者的观点也很直接这种“改进”是发生在固定题目上的模型并没有变得在任何新问题上都更强。它只是在遇到未知题时多了几个尝试机会。如果验证器比较宽松或者题目分布稍微超出尝试策略的覆盖范围它可能还是会失败。更关键的是成本。一次任务可能花费十几次模型调用、几万到几十万 token推理成本远高于单次生成。如果拿同样的算力去做集成学习、搜索算法或者更精细的提示词设计可能也能拿到类似效果。所以与其说这是一种“能力提升”不如说这是一个“用算力换分数”的优化过程。质疑者还有一个关注点当评测允许无限重试时分数会变得很难解释。你是在测模型的推理能力还是在测系统的搜索能力如果大家都用 100 次尝试、100 万token去刷榜那排名就会变成“谁能烧更多算力”的排名而不是“谁更会推理”的排名。3.3 我的看法真正的分歧在于“改进”发生在哪个层级围绕“自我改进”的争议本质上是概念混淆。如果“自我改进”指的是训练过程中权重不断调整、模型获得新能力那 RLM harness 确实不算。它没有改变模型本身。但如果“自我改进”指的是系统在运行过程中根据反馈不断调整策略以提高任务成功率那它实实在在地实现了。它不是虚的而是跑在生成器、验证器、反思器之间的真实工程逻辑。这两类改进发生在完全不同的时间尺度和系统层级上。前者发生在训练阶段影响所有后续任务后者发生在推理阶段只影响当前任务。它们都叫“自我改进”但内涵差别极大。我在实际使用这类框架时最深刻的感触是大多数争议其实不是技术争议而是定义混乱。建议读者在讨论一个问题前先问清楚对方说的是哪种改进。否则很容易变成一个人说“模型没变强”另一个人说“系统变强了”双方争了一下午发现根本不在一个频道上。4. 真想搭一套 harness建议先跑通这个最小闭环讨论完宏观争议还是回到实际。对于普通开发者来说最值得做的不是站队而是自己动手跑通一个最小闭环。只有亲手把一个任务从“一次生成”变成“多轮反思”你才能真正理解这类框架的优缺点。4.1 最小可用流程不要一开始就上重框架社区里像 DeepSeek harness、Codex harness 这类项目热度很高很多人一上来就想复现完整的封装工程。但我的建议是先别急着上复杂框架。你只需要用一个循环把单次生成变成多轮尝试就行。上面那段 Python 伪代码就是一个可运行的骨架。你不需要写复杂的插件系统也不需要做漂亮的日志面板先把它跑通。更具体一点我建议按这个顺序操作选一个你有明确判断标准的小任务比如“根据题目生成代码并运行测试”。先跑一次单次生成记录它的成功率。再套一个循环生成—执行—验证—反思—重试。记录两次的通过率和 token 消耗差异。跑 20 到 30 条样例再下结论。这个过程里最值得观察的不是最终正确率而是失败模式。你会发现有些错误是模型生成的方案本身就不对有些错误是执行环境的问题有些错误是验证器判断失误。不同类型的失败需要不同的处理策略。4.2 关键参数从 max_attempts 到验证器严格度搭好最小闭环之后你需要关注几个关键参数。这些参数直接影响效果、成本和稳定性。max_attempts最大尝试次数。建议先设置为 2 到 3不要一开始就拉满。尝试次数太高token 消耗会快速上涨而且上下文中塞入大量失败信息后模型生成质量反而可能下降。验证器严格度验证器是整个 harness 里最容易被低估的部分。如果验证器太宽松错误结果会被当成正确结果反思循环失去意义如果验证器太严格会把正确结果误判为错误导致系统在正确路径上白白浪费算力。能用程序化判断的就不要让模型来打分。上下文预算每一轮反思都会往上下文里增加内容。反思信息过长时模型会抓不住重点。常见做法是只保留最近几轮的错误摘要而不是把所有历史都塞进去。并发与速率限制如果你的任务量较大一定要限制并发。否则可能触发 API 限流或者本地资源耗尽结果不是慢而是直接失败。4.3 常见坑点与排查链路这类系统一旦出问题往往不是单一原因。我的经验是按下面的顺序排查先看现象是全部失败还是部分失败是第一次就失败还是重试之后才失败这决定了排查方向。再看输入任务解析是否正确网格数据有没有在转换过程中变形文件路径、编码、字段名是否都符合预期再看验证器是不是验证器本身把正确答案判错了用一个已经知道结果的任务去单测验证器是最快的方式。再看反思内容模型生成的反思是不是真的指出了问题很多时候模型不仅答错了反思也是错的。这种情况下把反思注入下一轮反而会加剧错误。再看上下文和资源上下文是否被塞满模型是否还有足够空间生成高质量内容API 是否触发了限流这套排查链路适用于大多数 harness 类系统的性能问题。不要一上来就怀疑模型能力很多问题出在流程的中间层。注意不要一上来就把批量数和并发数拉满先用一条样例确认输入、输出和日志都正常再逐步扩展。4.4 从单条样例到正式使用还差哪些工程能力如果你只是偶尔跑几道题上面的最小闭环已经够了。但如果你想把它放进自己的开发流程、自动化脚本或团队工具里还需要补上下面这几块拼图。失败日志记录每一轮的生成、反思、验证结果。没有日志就没有复盘没有复盘就无法判断系统到底在哪一步失败。缓存对于相似度较高的任务把已经成功过的结果缓存下来避免重复烧 token。评估集准备一组固定测试样例。每次改动 harness 逻辑后都在这组样例上跑一遍用来判断改动是变好还是变坏。成本监控统计每次任务的 token 消耗和延迟。很多开源框架公布的结果是不包含成本数据的你要自己算出单位成本。可观测性确认系统是“因为什么”成功的。是靠生成器一次做对还是靠验证器纠错还是靠反思器救回来的这些归因信息决定了后续优化方向。从最小闭环到正式工程化真正拉开差距的不是模型选型而是这些看不到的工程细节。5. 我的判断它真正改变的是“反思”从个人习惯变成了系统能力讨论到这里我有一个很明确的观点这类框架的长期价值不是某个基准上的分数而是它把“反思”从一个依赖个人习惯的行为变成了一种可以被工程化、被复用、被优化的系统能力。5.1 对多数开发者来说价值不是刷榜单而是可复用性过去我们想让模型输出更可靠主要靠两条路一是换更大的模型二是在提示词里反复强调“请检查一下”。前者成本高后者效果不稳定。RLM harness 提供了第三条路把检查、反思、重试变成代码逻辑。这意味着你不需要每次都在提示词里写一堆“请仔细思考”而是可以通过工程手段让系统天然具备这种能力。一旦做成模块它可以复用到不同任务上。对于开发团队来说这种能力迁移的意义其实比单次跑分更有价值。因为它解决的不是“某一道题能不能做对”而是“一个系统能不能在无人干预的情况下稳定地完成复杂任务”。5.2 适用边界什么任务适合上 harness什么任务不适合这类框架不是万能的它有自己的适用边界。适合上 harness 的任务通常具备三个特征有明确验证标准、允许一定延迟、任务复杂度高。比如算法题和推理题可以用程序化验证器判断结果是否正确。代码生成与调试可以跑测试用例来判断代码是否正确。信息提取后的二次校验可以基于结构化规则验证结果。不适合上 harness 的任务也有三个特征验证标准模糊、对延迟敏感、任务非常简单。比如实时对话用户等不了你循环十次再回复。没有明确对错的开放性任务验证器无从判断反思也会失去方向。简单文本分类或关键词提取一次生成就够了额外加循环反而增加成本和复杂度。5.3 我给普通开发者的三点建议第一先用手里的任务构建一个 20 条样例的小评估集对比单次调用和 harness 的通过率。不要凭感觉判断要用数据说话。第二先设置 max_attempts2 或 3观察每个任务的平均 token 消耗再决定是否加大。如果一个任务 3 次尝试都失败通常说明模型本身能力不足或者验证器设计有问题而不是尝试次数不够。第三记录所有失败和反思日志。这些数据比最终分数更有价值。它们会告诉你系统真正薄弱的地方在哪里也会让你在下一次优化时不再靠猜。我觉得与其去争论一个 Agent 框架在 ARC-AGI-3 上刷了多少分不如把它看成一个信号当模型开始通过不断验证来提高输出质量时我们正在从“生成器时代”走向“验证器时代”。下一步真正决定差距的不是谁生成得更快而是谁能在失败之后给出更好的修改方向。对于普通开发者来说与其围观这场争议不如自己搭一条最小闭环跑一跑。你先跑通一条样例再打开失败日志看看你就能理解这个所谓的争议到底在争什么。那种“生成—验证—反思—再生成”的循环一旦跑起来你对大模型应用的认知会和以前完全不一样。