最近开发圈里有个消息传播得很快Opus 5 拿下了 ARC-AGI-3。只看标题这又是一个“模型变强了”的故事。看惯了大模型新闻的开发者可能已经条件反射地准备收藏一份“最强模型”清单。但我想先拦一下如果你做 AI 应用开发或者在大模型评测、Agent 框架相关方向工作请先别急着把功劳全记在模型身上。因为 ARC-AGI 这个 benchmark从来就不是一个“只需要模型聪明就能得高分”的考试。它考的是抽象推理、泛化能力是专门设计用来防止模型靠背诵训练数据蒙混过关的。ARC-AGI-1 时代最顶尖的模型也得靠庞大的搜索和程序合成方法才能迫近人类基线到 ARC-AGI-2很多模型甚至被认为“几乎没有通过的可能”。这种情况下一个模型想在 ARC-AGI-3 上通关靠的必然不只是参数规模。那靠的是什么答案指向一个这两年被炒热的概念harness。我的判断很明确Opus 5 通关 ARC-AGI-3 的真正看点不是 model是 harness。但更值得警惕的是harness 正在从“帮模型发挥实力的工具”慢慢变成“捆住模型的绳子”。这篇文章就围绕这个判断展开讲清楚 ARC 评测的真相、harness 为什么突然变热以及开发者怎么避免被 harness 误导甚至锁死。1. 从 ARC-AGI-3 说起为什么“通关”这两个字不简单1.1 ARC 系列到底考什么ARC-AGIAbstraction and Reasoning Corpus抽象与推理语料库由 François Chollet 提出核心思路是让 AI 在从未见过的图形推理任务上从几个输入输出示例中归纳出变换规则再把规则迁移到新输入上。它和 MMLU、GPQA 这类“知识型 benchmark”完全不同。知识型考试可以靠记忆、靠训练数据覆盖来得分你在预训练阶段见过足够多的相似题目考试时就能答对。但 ARC 系列不是这样它要求模型在没见过的情况下做规则归纳本质上是在考举一反三的能力而不是记忆检索能力。ARC-AGI-1 刚出来那几年人类平均分能到 85% 左右顶尖模型却往往在 30% 上下挣扎。2024 年o3 在受限版本和大量额外计算资源的条件下拿到了高分但同时被指出主要靠 search 算力换推理能力这个操作在评测圈引起了很大争论。ARC-AGI-2 则进一步压缩了侥幸空间题目更难、规则更复杂、对泛化的要求更高。到了 ARC-AGI-3我们可以把它理解为在任务难度、规则组合复杂度和约束条件上继续加码的版本。它延续了 ARC 系列“反记忆、考推理”的设计哲学同时把模型的容错空间压得更小。这不意味着 ARC-AGI-3 在技术上不可超越但它确实说明了一个事实一个模型如果只靠“读题 - 写答案”这种两段式回答得分几乎不可能达到通过线。想要通过必须有“生成推理过程 - 验证 - 修正 - 再验证”的完整循环能力。1.2 “通关”的完整表述应该是什么所以“Opus 5 通关 ARC-AGI-3”这句话如果写完整更贴近事实的版本其实是“Opus 5 模型配合一套包含代码生成、沙箱执行、结果比对、错误回灌、多轮自我修正能力的 harness 工程系统在 ARC-AGI-3 评测中达到了通过标准。”这个表述听起来没那么带感但更接近真实。ARC 系列任务的典型解法在 2024 年之后基本演变成让模型把图形变换规则写成 Python 代码再在沙箱环境里逐一运行验证。模型真正承担的是“模式识别 规则假设 代码生成”而后面的“运行、报错、回灌、再试”循环来自 harness。这引出一个关键问题我们该把这份功劳算在谁头上如果评测报告只报一个“模型通关”的结果不披露 harness 对分数的贡献比例那么开发者在拿到这个分数时其实无法判断“换一个模型裸跑还能不能有这么强”。1.3 这里真正值得警惕的是什么真正值得警惕的不是模型不够强而是很多人会把“系统能力”误当成“模型能力”。对大模型厂商来说这种误读是乐见其成的。分数越高品牌越亮用户越愿意为 API 付费。但对我们这种要用模型做具体业务的人来说这个误读会带来实打实的成本你按照 benchmark 分数选了一个模型接入自己简陋的业务代码后发现效果远没有分数显示的那么强——因为你在本地并没有那一套评测 harness。这是理解文章标题的第一个关键点模型分数不等于模型能力更不等于你在业务里能复现的成绩。2. 什么是 Harness从测试脚手架到 Agent 运行时2.1 传统软件里的 test harness先说清楚 harness 这个词从哪来。在传统软件工程里test harness 指的是“为了跑通测试而搭的一套脚手架”包括测试启动入口、桩模块、模拟数据、结果断言、环境清理等。它不属于被测系统本身而是被测系统和测试环境之间的适配层。到了大模型时代这个含义被极大扩展了。早期大家用 harness 主要是为了批量跑评测把一堆 prompt 格式化好调模型 API收集输出和标准答案比对。代表性工具是 lm-eval-harness被 HellaSwag、MMLU 等评测广泛使用。在这个阶段harness 还是“评测脚手架”作用是自己藏在后台不被用户感知。2.2 从评测脚手架到 Agent 运行时转折点出现在“让模型用工具”这件事流行起来之后。当模型需要调用搜索、执行代码、操作文件、访问数据库的时候仅仅发送 prompt、收取 completion 已经不够。需要在模型外面再加一个运行环境它负责决定什么时候调用工具、调用哪个工具把工具返回的大段结果压缩成模型能消化的上下文在模型进入死循环或输出异常时打断、纠正、重试提供多轮记忆和长期存储对高风险操作做权限控制。这一整套就是今天大家在讨论 Agent 时说的 harness。它不再是被动脚手架而是一个主动的运行时环境。模型只负责“下一步该做什么”的判断真正干活的是 harness 管理下的工具链。这个过程被社区命名为 agentic loop而 harness 就是承载 agentic loop 的容器。2.3 deepseek harness / codex harness 到底指什么最近搜索热度很高的 deepseek harness、codex harness、deepseek harness 插件等词本质上都是这个含义。Codex 被定位为能自主完成编程任务的智能体但它不是靠一个裸模型就实现的——在外面包了一层完整的工作环境、代码执行沙箱、任务拆解和自我验证机制这套机制就是 codex harness。DeepSeek 场景下的 deepseek harness 也是类似社区或框架作者把 DeepSeek 模型嵌入一个 Agent 编排层让它具备代码执行、工具调用和多轮反思能力。这些命名有一个共同的潜台词大家开始觉得真正决定 Agent 好不好的不只取决于底座模型还取决于外面这套 harness。甚至有人说模型能力已经接近够用Agent 体验的差距主要是 harness 工程的差距。这个判断有一定道理但也带来了我们今天要谈的问题。3. 为什么 Harness 突然成了独立技术话题3.1 模型同质化工程差异化2024 年到 2025 年闭源模型和开源模型的差距在快速收敛。同样的任务用不同厂商的 API写出来的第一版回答往往都差不多。真正拉开体验差异的是后面的编排谁能更好地把模型放进业务闭环谁就能做出更好的 Agent 应用。于是大量团队把精力从“调模型”转向“调 harness”。prompt 怎么写、工具怎么定义、上下文怎么管理、失败怎么重试这些工程细节逐渐变成一门专门的技术方向。社区给了它一个名字harness engineering。如果你关注 ChatGPT、Claude 等产品的演进会发现它们的核心动作不只是换底座模型更多是在持续优化外层 harness更长的上下文窗口管理、更聪明的工具选择策略、更稳定的错误恢复机制。这些产品能力的提升很大一部分来自 harness 工程而不是模型单点能力提升。DeepSeek 场景下deepseek harness 之所以能成为热词正是因为大家意识到即使模型权重开放了你也不能直接把它当成一个可用 Agent要让它在真实任务里干活必须搭一套 harness。3.2 搜索热度背后的真实需求从 deepseek harness 下载、安装、桌面版、插件这些热搜组合词来看大量开发者并不是想研究学术概念而是想把它当作一个能安装的软件来用。需求非常直接把模型装进一个现成的 Agent 框架里立刻获得代码执行、文件操作和联网能力。这是一个非常合理的需求。对一个应用开发者来说直接用现成 harness 比自己从零写 Agent 编排层要现实得多。但问题也出在这里当 harness 越来越强、越来越厚模型自身的能力边界开始变得模糊甚至连“模型到底行不行”这个问题都难以回答。3.3 一个被低估的变量分数里有多少来自 harness我们在评估模型时经常忽略的变量是评测环境的一致性。同一个模型直接 prompt 答题可能只有 40 分换成“生成代码 沙箱验证 错误回灌”的 harness可能到 80 分。这不是假分数。因为评测要的是最终正确率harness 有效地提升了推理系统解决任务的能力这符合评测规则。但它确实意味着我们评测的对象其实是“模型 harness”组成的系统而不是模型本身。如果厂商默认用最强 harness 测模型再把分数讲成“这个模型多聪明”就会产生系统性偏差。这不是操纵分数而是评估口径问题——但对普通开发者来说很难分辨两者的区别。4. 核心矛盾Harness 在增强模型也在遮蔽模型4.1 系统分数 vs 模型分数任何基于 harness 的评测结果严格说都是系统分数而不是模型分数。系统分数 模型基础能力 harness 编排增益 评测集噪声。当 harness 增益足够大时系统分数主要反映的是 harness 强不强而不是模型强不强。假设 ARC-AGI-3 的通过线是某个分数Opus 5 “模型 harness”通过了。但你如果对 base model 做一次裸测可能离通过线还远。这两个数字并不矛盾只是它们指向的能力载体完全不同。一个完整评测报告至少应该回答三个问题模型单独答题的准确率是多少模型 完整 harness 的准确率是多少这两者之间的差距是由 harness 的哪些模块贡献的。如果评测方只发布第一个数字那没问题。怕的是把第二个数字包装成第一个数字来传播。4.2 一个比喻运动员、教练和训练环境可以把模型比作运动员harness 就是教练团队、训练设施、医疗组和战术分析软件的集合。运动员能跑多快既取决于自身天赋也取决于整个团队怎么辅助他训练和参赛。以前的教练团队很简陋大家靠运动员天赋判断强弱。现在教练团队越来越专业我们看到成绩时很难分清天赋占几成、团队占几成。承认“Opus 5 团队很强”和“Opus 5 运动员很强”是两种结论但很多传播媒体把它们混为一谈。这对于看热闹的人无所谓但对做技术选型的工程师来说是个必须拆清楚的账。4.3 harness 正在变成“外挂大脑”更值得担心的一个趋势是harness 的智能已经开始反向侵蚀模型能力的定义。经典的 agent loop 是模型思考、工具执行。但现在的 harness 里prompt 模板本身可能包含了大量领域知识工具描述可能已经内置了任务分解策略错误回灌机制意味着模型可以不断试错。模型在这个系统里面更像一个“下一步行动选择器”而不是“问题解决者”。说白了真正的解题思路可能一半藏在 harness 的编排逻辑里模型只是被 harness 推着往前走。这就是“外挂大脑”。5. Harness 变成“绳子”的三种典型信号5.1 信号一换掉 harness分数大幅下滑第一种信号最容易量化。把一个模型从官方评测 harness 中拿出来接入另一个普通 Agent 框架在同一个任务集上跑分数如果从 80 掉到 40那说明模型对原 harness 有很强的依赖。这个模型的能力很大程度是“官方 harness 环境下的能力”。不一定是官方有意欺骗更可能是模型在训练和评测阶段已经与 harness 深度适配。o3 时代就出现过“搜索流程是分数的重要来源”的讨论到了 ARC-AGI-3如果你不能在自己的 harness 里复现同样强的代码验证和错误回灌模型就发挥不出理想效果。所以当你看到“某个模型通关某某 benchmark”时第一个应该问的问题是它是在什么 harness 环境下通关的这个 harness 我能不能复现5.2 信号二harness 复杂度失控问题无法定位第二个信号发生在实际工程里。当 harness 变成项目里最复杂的一个模块时你会发现错误没法定位某个功能不好用可能是模型不行、prompt 太长、工具返回格式有问题、上下文被截断、重试策略太激进、沙箱缺依赖……任何一个环节都可能出问题。你升级了一次 harness 版本应用行为变了但你未必能说清是哪一行逻辑导致的。这时候 harness 已经不是工具而是一层难以改动的胶水。它确实在帮模型干活但它的存在本身也在增加系统的不确定性。更麻烦的是当模型输出和框架逻辑纠缠在一起时你连“该优化模型还是优化 harness”都很难判断。5.3 信号三模型被框架锁死失去可迁移性第三个信号是工程里最贵的成本。如果一个模型只在 deepseek harness 里能正常工作换到另一个 runtime 就频繁出错说明模型和 harness 已经深度耦合。你要换模型得动 harness你要换 harness得调模型配置。两边都改等于重构。企业一旦被某套 harness 锁死沉没成本会直接把技术选型拖入“将就着用”的状态。短期内省钱长期看是不断累积的技术债。5.4 一个最小配置看 harness 如何“包裹”模型下面我用一段示意配置展示为什么说 harness 已经厚到能“捆住”模型。这不是某个真实产品的配置只是为了说明模型在整套系统中的占比其实很小。# harness-example.yaml示意非真实项目配置 model: name: opus-5 endpoint: https://api.example.com/v1 temperature: 0.2 max_tokens: 8192 harness: loop: max_iterations: 30 early_stop_if_solved: true prompt_template: file: templates/arc_solver_v3.txt include_examples: 8 require_python_output: true tools: - name: python_executor runtime: docker://arc-sandbox timeout_seconds: 15 - name: grid_visualizer enabled: true - name: answer_checker compare_mode: exact feedback: on_failure: append_error_and_retry max_retries: 5 judge: type: rule_based output_format: json看这份配置模型部分只有四行。剩下 30 多行全部是 harness 的控制逻辑循环次数、提示词模板、沙箱、工具、失败重试和质量判定。这样的系统跑出高分你应该再想想分数到底是谁的。6. 工程判断怎么分辨工具和绳子6.1 四条判断准则我整理了一个简单的判断表供你在实际项目中评估 harness判断维度工具型 harness绳子型 harness抽象边界模型调用层和编排层接口清晰逻辑混在一起改动一处牵动全身可替换性换模型只需改 adapter换模型需要重写大量 prompt 和工具可观测性日志能区分模型输出和框架动作失败时无法判断是谁的问题评测口径同时报告模型裸测和系统测试只报告系统总分不拆分贡献如果四条里命中两条以上“绳子型”这个 harness 你要警惕。它可能在短期内帮你拿到漂亮分数但长期会拖住整个项目的技术演进。6.2 实操建议做一个“替换测试”最直接的方法是在自己的评测集上做一次 harness 替换测试。下面这段代码不是完整可运行的项目而是演示方法论同一批任务分别用完整 harness 和裸模型跑一遍对比两个分数。# replacement_test.py示意代码需要按实际接口补全 from model_port import ModelPort def run_with_harness(model: ModelPort, tasks): 用当前 harness 跑评测记录系统分数 for task in tasks: plan model.complete(task.prompt) result execute_and_validate(plan) while result.failed and task.round MAX_ROUNDS: feedback format_error(result.error) plan model.complete(task.prompt feedback) result execute_and_validate(plan) record(task, result) def run_bare_model(model: ModelPort, tasks): 直接把题目丢给模型不允许工具、不允许重试记录模型裸测分数 for task in tasks: answer model.complete(task.prompt_without_tools) record(task, answer, allow_unsureTrue)两段代码跑同一批任务、同一个模型。如果系统分数远高于裸测分数说明当前成绩主要来自 harness。这个动作的成本很低收益是帮助你建立正确的预期避免把 harness 的能力误当成模型的能力。6.3 接口与实现分离更长期的做法是让产品代码永远依赖“模型接口”而不是依赖具体 harness。# model_port.py —— 抽象出模型端口harness 只是其中一种实现 class ModelPort: 一切模型调用的唯一入口 def complete(self, messages: list[dict], tools: list[dict] | None None) - str: raise NotImplementedError # HarnessModelPort 实现了编排逻辑但对外只暴露同一个接口 class HarnessModelPort(ModelPort): def __init__(self, base_model: ModelPort, harness_config: dict): self._base base_model self._harness build_harness(harness_config) def complete(self, messages: list[dict], tools: list[dict] | None None) - str: return self._harness.run(self._base, messages, tools)这样业务层看到的是统一的模型能力接口你换 harness、换模型都不会波及业务代码。这看起来是普通的软件工程原则但很多 AI 项目恰恰因为“时间紧”跳过这一层最后被 harness 绑死。7. 对开发者的实际启示7.1 选模型时不要只看 benchmark 总分第一点把 benchmark 分数当成“系统分数”看待。选模型之前先问评测方是否披露了 harness 配置是否给了裸测分数。没有这些信息总分只能作为参考不能作为能力承诺。如果某个模型宣称“最强”却没有公开评测配置和复现方式那这个“最强”至少要打一个问号。7.2 确定你的应用需要多厚的 harness第二点了解自己的业务需要多厚的 harness。如果你的业务是问答、摘要、翻译一个轻量 harness 就够如果你的业务是自主编程、数据分析、网页操作那么你需要完整的 agentic harness。不要盲目堆功能每新增一个 harness 组件都会增加系统的复杂度和失败概率。很多团队一开始只需要一个简单 prompt 包装却直接引入完整的 Agent 框架结果是徒增运维成本换来少量功能增强。7.3 评测要分层记录第三点在团队内部建立分层评测习惯。模型评测、harness 评测、系统评测分开记录。至少要做到跑任务时记录两个数字裸模型准确率和系统准确率。这会帮你回答老板最常问的“为什么演示效果这么好生产环境就不行”这个问题——大部分时候差异就出在演示环境有一套精心配置的 harness生产环境没有。7.4 保持“模型可替换”的底线第四点任何 harness都应该在“模型可替换”这个前提下使用。不要为了短期效果把模型私有格式直接写进 harness 的每一层。你不知道哪一天会有更强的模型出现也不知道供应商会调整哪个 API。保留替换能力就是保留主动权。7.5 警惕 harness 信仰化最后一点警惕“harness 信仰化”。最近社区有一个倾向把 harness 说得无所不能仿佛任何模型套上 harness 都能变成顶尖 Agent。这个说法对了一半harness 确实能放大模型能力但它不能无中生有。基础模型太弱时harness 会把错误放得更大而不是把错误消化掉。真正健康的姿势是把 harness 当作放大器而不是造物主。8. 结语把绳子变成缰绳harness 本身不是一个坏东西。它是大模型工程化的必然产物也是 Agent 应用落地的必需品。没有 harness模型只能孤独地处理文本没法操作真实世界。我们要反对的不是 harness而是“把系统能力偷换成模型能力”的传播方式以及“在业务里被 harness 绑死”的工程状态。好的 harness 应该是一根缰绳它能让模型往正确的方向发力又保留随时调整方向的自由度。坏的 harness 才是一根绳子看起来在牵着模型走实际把模型捆在原地让你产生“模型很强”的幻觉却无法在真实项目里复现同样的效果。下次看到“XX 模型通关某 benchmark”的新闻不妨多问一句它背后的 harness 做了什么给我同样的模型、同样的任务我能复现这个分数吗这比收藏一张“最强模型排行榜”有价值得多。Opus 5 通关 ARC-AGI-3 是一次值得关注的工程展示。但我们真正应该记住的不是分数而是分数背后的工程分层和可复现性。把模型能力、harness 能力和系统能力分开记账你会少踩很多坑也会更清楚下一步该优化什么。