这几天技术社区在讨论 Opus 5 通过 ARC-AGI-3 的消息。不少人第一反应是“模型又变强了”但再看细节大家发现真正值得琢磨的不是模型本身而是搭在模型外面的那套东西——Harness。同一个模型换一套 Harness结果可能完全不同同一个基准换一种测试方式成绩也可能变得没有太多可比较性。这个问题如果不拆开很容易得出错误判断要么高估了模型要么低估了工程。我的基本判断是Harness 正在变成影响模型能力上限的隐形变量它一方面能帮模型释放能力另一方面也在变成捆住模型的绳子。如果你正在做 AI 应用开发、Agent 工程或者只是用 API 搭了一个自动化流程这篇文章值得看完。因为你会发现自己日常调优的很多“模型问题”其实都是 Harness 问题而你为了“提升效果”加的那些工程逻辑也可能正在限制模型原本的泛化能力。1. 同一个模型为什么换一套套装成绩就变了1.1 先理清这里说的 Harness 到底是什么很多人第一次听到 Harness 会误以为它是某个新模型或新框架。实际上Harness 不是一个具体产品而是一类工程包装层的统称。它指的是模型输入之前和输出之后外部技术团队加上的所有处理逻辑。具体来说Harness 可能包括Prompt 模板和系统提示词上下文组装策略比如先放什么、后放什么、截断什么工具调用协议比如模型如何申请调用某个函数、如何传参数外部记忆和状态管理比如把多轮对话压缩成摘要验证器和重试机制比如答错了要不要重新生成评分和反馈回路比如把执行结果回传给模型继续推理输出约束比如要求模型必须输出 JSON、必须按某个格式回答换句话说你调用的可能并不是“裸模型”而是一套已经经过包装的系统。模型像发动机Harness 像变速箱、传动系统和车身。同一台发动机放在不同车架里加速成绩、油耗、操控感完全不同。这个类比很简单但很多人实际做工程时会忘记。1.2 从 ARC-AGI-3 这个案例看到的现象模型、基准和脚手架分不开ARC-AGI-3 是一个以抽象推理为核心难点的基准它在设计上刻意回避语言模型擅长的知识记忆和文本生成更多考验模型在少量示例下完成模式识别和规则迁移的能力。传统 LLM 直接面对这种任务往往很吃力因为它不是用“背诵”能解决的。Opus 5 通关 ARC-AGI-3 的消息出来后很多人直觉认为这是模型推理能力的跃迁。但如果细看社区讨论和公开分析会发现成绩并不是“模型裸跑”得来的。它经常配合了一套复杂的 Harness通过代码生成来操作网格、自动验证中间结果、失败后重新尝试、把推理过程拆成多步……这些工程手段不是“作弊”它们确实帮助模型完成了任务但它们也让问题变得复杂了。这里要区分两件事模型本身的世界模型、模式识别能力能不能直接产生正确答案Harness 通过工具调用和试错能不能在模型“不会也能蒙”的情况下逼近正确答案如果 Harness 承担了太多“思考”那这个成绩就不能完全归功于模型。更麻烦的是如果 Harness 是为了某个基准专门调的那它在真实世界中的可迁移性就要打问号。这不是说 Harness 没用而是说我们必须把模型贡献和工程贡献分开。2. Harness 是怎么“帮”模型通关的三层机制拆开看2.1 输入层把任务翻译成模型更舒服的语言模型对原始输入的敏感度远超很多人的直觉。直接扔一个推理题给模型和把推理题转成中间步骤、伪代码、候选模板结果可能差一大截。Harness 最常见的操作是“翻译”。它可能做这些事把 ARC 的 2D 网格编码成更清晰的文本矩阵在输入中补充任务描述比如“这是一个关于颜色变换的推理任务”把输入拆成多个小问题让模型按步骤回答提供几个“思考示例”引导模型用归纳而不是直接猜这一步本身不算外部知识注入但它重新组织了输入分布。模型本来对某种格式最敏感Harness 就把任务转成那种格式。简单说Harness 在替模型降低“认知阻力”。不要小看这个操作。大量实验证明同样一个模型在措辞不同、示例不同、格式不同的 Prompt 下表现差异可以达到几个百分点甚至更高。这不是模型变聪明了而是输入侧的适配让模型更容易唤起已有能力。2.2 执行层工具、反馈和重试改变了推理过程比输入翻译更重要的是执行层的循环。模型不再只是“读题-输出答案”而是可以调用代码、执行操作、观察结果、再修正。这个过程会显著改变任务的性质。以 ARC 类任务为例一个 Harness 可以让模型做这样的事先描述自己对网格的观察生成一段 Python 代码来变换输入网格执行代码把输出和预期结果比对如果不对把错误信息回传给模型让它修改代码重复直到通过这种“程序合成 自动验证”的流程本质上是在用计算搜索替代一部分端到端推理。模型不需要一开始就完全猜对它只需要能够逐步逼近。这意味着模型的一部分“解题能力”被转移到了 Harness 提供的执行器上。这有什么问题吗如果是一个真实项目没问题。因为在真实项目里我们本来就可以让模型调用工具。但如果是在评估模型能力这种 Harness 会掩盖真实的推理缺陷。一个不能直接推理的模型在强大的工具循环下也可能拿到高分。所以不同 Harness 之间的差别很多时候不是模型差别而是工程脚手架差别。2.3 结果层验证器和评分规则也在参与“答题”还有一层容易被忽略验证器。很多 Harness 自带一个自动判断“答案是否正确”的函数。如果验证器更强比如能解析多种答案格式、能执行代码并比较网格、能容错那么模型试错的效率会大幅提升。相反如果验证器很弱模型明明生成了对的结果但因为没有按要求格式输出而被判错成绩就会下降。验证器不只是“批卷老师”它还在参与问题的探索空间。它告诉模型哪些尝试是错的哪些方向有用。这就像做实验时如果你有一个精准的测量仪器多试几次就能逼近答案如果仪器是坏的试多少次都没用。所以在分析一个模型为什么在某项基准上取得好成绩时不能只看模型卡上的参数还要看这一套 Harness 的输入处理、工具循环、验证器设计。它们共同决定了最终数字。3. 为什么说 Harness 正在变成捆住模型的绳子3.1 当工程脚手架变成了模型的“拐杖”Harness 最初是为了增强模型而存在的。它帮模型做工具调用、管理上下文、处理错误。但当 Harness 越来越复杂就可能出现一个反效果模型越来越依赖外部逻辑越来越不擅长自己组织推理。原因在于Harness 把很多工作“自动化”了。模型只需要生成一个很小的子步骤比如写一段 JSON 描述需求剩下的由代码执行。久而久之如果评估任务也允许这种模式和外部反馈模型的端到端推理能力就不会被真正检验也就不会被真正提升。更危险的是在模型训练时如果大量使用这类 Harness 来构造数据模型学到的东西可能不是抽象规则而是“如何配合外部系统”。换句话说Harness 越强大模型自身的自主推理空间可能越窄。这就像一个人习惯了计算器口算能力就可能退化。不是计算器没用而是如果所有任务都依赖计算器你就不知道这个人到底会不会算术。3.2 过度适配基准会让真实能力失真还有一种更隐蔽的束缚Harness 针对某个基准做了精细调优。比如为了让 ARC-AGI-3 分数更高工程师可能会专门设计一种“网格推理模板”加入大量与该基准格式相关的提示甚至把几个已知题型的解法暗示放进系统提示里。这不是作弊但它是过拟合。过拟合的问题在于换一个分布略有变化的真实任务这套 Harness 可能立刻失效。真实世界的推理任务没有固定的网格格式没有标准答案比对器也没有可重复的验证函数。如果在基准上很厉害的模型到了用户真实场景里表现平平那很可能不是模型骗人而是 Harness 与应用场景不匹配。对于使用者来说最危险的是被基准分数误导。你看到某个模型在某个榜单上排名很高以为自己接入后也能得到同样的效果结果发现完全不是这样。因为你没有那套专门为基准定制的 Harness。榜单分数本质上衡量的是“模型Harness”组合而不是模型单独的能力。3.3 Harness 绑死了通用性换个任务就失效我最近看到不少团队在复盘时提到一个现象他们在某个业务问题上把 Agent 的效果调得很好模型提示词、工具调用、上下文管理都打磨得非常精细。但一旦换一个业务场景哪怕只是改了几个字段整个系统就很难迁移需要重新调很多参数。这不是偶然。Harness 越复杂和特定任务的绑定就越深。它内部可能包含大量假设比如“用户输入一定是结构化 JSON”“任务一定可以拆成三步”“最多重试三次一定够”。这些假设在一个场景里是优化在另一个场景里就是枷锁。所以当我们在说“Harness 正在变成捆住模型的绳子”时说的不是不要用 Harness而是你要意识到任何 Harness 都有边界。它帮你拿到了当前任务的分数也可能让你失去跨任务迁移的灵活性。尤其当 Harness 承担了太多逻辑时模型的真实自适应能力反而被掩盖了。4. 一个可复用的判断框架是模型强还是 Harness 强4.1 四步归因法先隔离变量如果我们要判断一个系统表现好到底是模型贡献多还是 Harness 贡献多不能靠感觉。可以用一个四步归因法逐步隔离变量裸跑基线直接给模型一个最朴素的 Prompt不套任何工具、不提供额外反馈记录结果。加输入侧处理只加 Prompt 优化、格式转换、示例补充不加工具记录结果变化。加工具循环加入代码执行、结果验证、错误回传和重试记录结果变化。加专业验证器加入针对性更强的解析器、判分器或状态管理记录结果变化。每一步提升都代表 Harness 某一层的贡献。如果裸跑基线已经很高说明模型本身强如果裸跑很低但加上工具循环后大幅跳升说明是工程脚手架在起作用。当然这里的每一层贡献不是完全独立的也可能存在交互效应。但作为初步归因这个流程足够实用。4.2 三组对照实验用实验拆出模型本身的贡献更严谨一点可以设计三组对照实验。第一组同 Harness 不同模型把同一个 Harness 套在不同模型上看成绩差异。如果 A 模型显著高于 B 模型说明模型本身有差异如果所有模型都差不多说明 Harness 的主导作用太强。第二组同模型不同 Harness同一个模型分别用“裸跑”“标准 Harness”“强 Harness”测试。如果强 Harness 带来巨大提升说明模型对外部反馈依赖性强自身推理能力并不充分。第三组同 Harness 换任务分布把同一个 Harness 用在与训练领域不同的任务上。如果分数剧烈下降说明 Harness 过拟合了原任务。这三组实验不一定要做成完整论文但在选型或评估时只要做一个简化版本就能避免很多误判。4.3 判断结果时要问的三个问题最后无论实验多复杂都要回到三个朴素问题如果我什么都不加直接把真实用户的问题丢给模型它能做得怎么样这个 Harness 里的规则、工具和验证器换到另一个场景还能复用吗如果 Harness 挂掉模型还能不能自己完成核心任务这三个问题里第一个问题衡量模型的基础能力第二个问题衡量 Harness 的通用性第三个问题衡量系统的鲁棒性。如果你的回答都是否定的那说明这套系统更像是一个“特定任务的定制机器人”而不是一个智能体。5. 如何设计一个“不捆人”的 Harness从最小可用到工程化5.1 搭建最小 Harness 的六个步骤讨论完 Harness 可能带来的问题更重要的是知道怎么做。我建议遵循“先最小、后增强、分阶段解耦”的原则。一个推荐流程是先用裸模型跑通主链路。不要一开始就加入各种工具和模板。确保模型能在最简单的情况下输出可用的结果哪怕效果一般。记录失败模式。把模型答错、答偏、卡住的情况分门别类比如格式错误、逻辑错误、信息不足、上下文丢失。针对失败模式加最小修复。如果是格式错误加输出解析如果是信息不足加检索如果逻辑错误再考虑加验证和重试。每加一层做一次 A/B 测试。对比加之前和加之后的效果确认这一层真的有用。避免无脑堆砌。把 Harness 与任务逻辑解耦。把通用工具如代码执行器、检索器和任务专用规则如业务字段、验证器分开。用一组真实场景的样例做回归测试。不要只盯一个 benchmark要准备多元化的测试集。这样做的核心目标是让 Harness 成为“可插拔”的组件而不是黏在模型上的不可拆卸外壳。5.2 关键参数和建议值上下文窗口、最大迭代、验证方式在不同的 Harness 里有几个关键参数直接影响效果需要单独调试参数作用建议上下文窗口决定模型能同时看到多少信息不是越大越好。大的上下文会增加成本也可能引入噪音。先尽量精简再按需扩容最大迭代次数决定工具循环最多能试几次从 1 到 3 开始。如果超过 3 次才能成功说明任务拆解或 Prompt 有问题先优化上游验证方式决定如何判断“答对了”可以先做宽松匹配再做严格验证。不同任务用不同验证器重试策略决定失败后是否重新生成建议先做“加反馈重试”而不是“无脑重试”。后者成本高且容易重复同一个错误工具调用格式决定模型如何表达调用意图优先使用稳定的 JSON Schema并做工具参数的有效性校验实际落地时这些参数要结合你的成本上限和延迟要求来调。不要追求单次任务 100% 成功而是要在可接受成本内达到稳定输出。5.3 工程化时最容易翻车的四个点我见过很多团队在 Harness 工程化时翻车通常集中在四个地方Prompt 模板过度膨胀。系统提示写了上千行模型反而抓不住重点还容易分心。更好的做法是精简核心规则把细节放到需要时才检索。工具数量过多。模型每轮要从几十个工具中选一个决策负担太重。先给最少的几个工具再逐步增加。上下文污染。多轮交互后历史记录、错误日志、中间结果全部塞进 Prompt模型被大量无关信息干扰。需要做压缩和摘要。验证器与真实任务不一致。验证器只检查格式不检查语义。结果模型输出看似合格实际上业务上不可用。这四个点如果处理不好Harness 不仅不会增强模型反而会成为新的故障源。6. 排障路径当模型表现波动时先别急着骂模型6.1 按层排查输入、上下文、工具、参数、系统边界当你发现一个模型在某些时候表现时好时坏不要第一时间得出“模型不稳定”的结论。建议按下面这个顺序排查输入层任务描述清晰吗输入格式一致吗有没有历史字段污染上下文层相关信息是否在窗口内是否被截断顺序是否合理工具层工具调用是否成功返回结果是否被正确解析错误信息是否被吞掉参数层温度、top-p、最大 token、迭代次数这些参数有没有被无意改动系统边界API 超时并发限制第三方服务不稳定缓存命中不一致每层都可能有独立问题也可能层层叠加。比如输入格式变了导致工具解析失败进而让上下文里混入错误结果最终表现波动。如果不逐层排查很容易把工程问题归因到模型能力上。6.2 常见问题和对应检查项表格这里给出一个常见问题排查表适合生产环境遇到波动时快速对照现象可能原因检查项有时好有时差Prompt 示例顺序改变固定 Prompt 模板只改变变量部分总是格式错误输出约束太弱检查是否声明了输出格式是否用了结构化生成工具调用经常失败参数 schema 不够严格检查工具参数是否缺必填字段返回值是否可解析多轮后开始变笨上下文被噪音填满检查历史摘要是否过长是否需要压缩重试后结果不变没有把错误反馈给模型检查错误信息是否真的被拼进下一次请求换一个业务场景就崩溃Harness 与场景过度绑定检查有哪些规则是写死的是否可配置化对照表格并不是万能解药但它能帮你把“模型玄学”变成可定位的工程问题。6.3 如何记录 Harness 行为形成可复现报告为了更高效地排查建议在生产环境里记录完整的 Harness 行为日志而不只是记录模型输入输出。一个可复现报告至少应该包含以下信息请求 ID 和时间戳当前模型版本和 Harness 版本完整 Prompt 内容包括系统提示、上下文、工具定义模型每次生成的原始输出工具调用请求、返回结果和耗时验证器判断结果和分数重试次数和最终输出任何被截断、报错、超时的事件有了这些日志遇到问题时才能回放。很多团队只记录最终答案出了问题根本无法定位。Harness 的复杂度越高日志越要完整。7. 回到那个根本问题模型越来越强Harness 应该往哪个方向走7.1 更好的 Harness 不是替模型思考而是给模型干净的思考空间从 Opus 5 通关 ARC-AGI-3 这件事里我看到的不是“模型已经全知全能”而是“工程脚手架开始深度参与推理”。这个趋势会持续但方向需要纠偏。一个好的 Harness标准不是它自己有多强大而是它能不能让模型最干净地发挥能力。这听起来矛盾但其实是两件事让模型不要被格式问题、上下文缺失、工具调用失败这些外部因素拖累让模型必须自己承担推理、规划、判断等核心认知任务。也就是说Harness 要负责“扫清障碍”而不是“替跑”。如果 Harness 把最终答案都算好了模型只负责填空那这不是增强是替代。替代的问题在于一旦场景变化机器就会露馅。7.2 评估与工程分离才能看到模型的真本事对基准测试和榜单我有一个建议每次看成绩时先问一句“这个成绩是裸模型跑出来的还是带 Harness 跑出来的”。如果是后者就要追问 Harness 的每个组件是否公开、是否通用、是否针对该基准做了特殊优化。理想情况下评估体系应该分成两层第一层模型原生能力评估只给任务描述不允许工具和外部反馈看模型自己能做到什么程度。第二层工程化能力评估在统一的标准 Harness 下看模型能利用多少外部资源完成任务。两个分数分开看才能知道模型真本事如何以及它搭配工程后能走多远。如果混在一起榜单会变成一个玄学数字既不能指导选型也不能指导开发。7.3 对普通开发者的一条实在建议如果你的目标是做一个真实可用的产品我的建议是不要迷信任何“裸模型高分”或“带 Harness 刷榜”。优先做几件事准备一个小而真实的测试集覆盖主流程和边界情况。在你的业务场景里对比“裸跑 vs 极简 Harness vs 复杂 Harness”的效果。选一个可控的复杂度宁可损失一点极限分数也要保证系统可解释、可维护、可迁移。Harness 不是越复杂越好而是越合适越好。合适的尺度是它能帮你稳定复现效果但没有替你思考和决策它能适配当前业务但换一个场景时你可以快速拆掉它、重构它而不会被它绑死。回到开头那个问题Opus 5 通关 ARC-AGI-3到底意味着什么答案也许并不复杂。它既说明新一代模型的能力在提升也说明 Harness 已经成了一股不可忽略的力量。真正值得长期关注的不是某一个模型在某一天刷了多少分而是我们能不能分清哪些进步来自模型哪些进步来自脚手架。这个分界线越清晰我们对 AI 能力的判断就越准确做出的工程选择也就越不容易被短期的榜单数字带偏。