同一大模型分差36%，Harness决定表现

2026年9月3日，一项用于测试接近人类极限推理能力的综合考试ARC Prize公布了ARC-AGI-3的最新测试结果，数据呈现出反直觉的反差：同一款GPT-6 Astra模型，在两套不同的Harness框架下跑出了完全不同的得分。使用标准Harness时，模型得分仅为62.7%；而切换到Provider Adapter Harness后，得分直接达到98.6%，两者分差高达35.9个百分点。更让人意外的是，得分更高的测试方案成本反而更低，从约2.61万美元降到1.73万美元，降幅约34%。这意味着，仅仅更换了运行框架，同一个AI Agent的性能就仿佛提升了一个等级。

这场测试结果引发了行业广泛讨论，不久后YC专门举办了一场主题为《Why the Harness Matters More Than the Model》的论文分享会，由YC的François Chaubard主持，邀请了来自Prime Intellect、斯坦福以及YC内部的多位研究员，从不同视角探讨了模型之外的这套运行框架的价值。参会团队的研究虽然各有侧重，但都指向同一个核心观点：AI领域的竞争胜负手，正在从“谁拥有更强的基础模型”转向“谁能更高效地组织和调度模型能力”。如今基础模型的能力已经逐渐成为行业标配，在模型参数和推理强度一致的前提下，不同的Agent方案可以拉开最高36个百分点的性能差距，这部分空间正是Harness所能提供的价值增量。

要理解这个概念，我们可以从Harness的本义说起——这个单词原本指的是套在马身上的马具，用于将马匹的力量传导到车辆上。在AI语境中，Harness指代的是大模型在完成真实任务时的整套运行框架，包括系统提示词的设计、上下文的组织方式、可调用的工具集、记忆存储机制、子Agent的分工逻辑以及会话管理规则等。简单来说，基础模型决定了“大脑的聪明程度”，而Harness则决定了这个大脑在工作时能够调用哪些资源、拥有多少发挥空间。Agent执行任务时能够访问的资料、可用的工具、当前的执行进度以及能否继续推进任务，这些都不由基础模型决定，而是由Harness框架直接把控。

YC合伙人François Chaubard亲身经历过Harness带来的能力跃升。今年3月，他在试用Karpathy的自动研究项目时，最初只是想添加一个可视化界面，方便查看Agent的执行过程和实验进度。但在开发过程中，资料检索、实验评审、论文写作、进度管理等模块陆续被接入系统，他无意间搭建出了一套完整的Harness框架。如今他只需要给出研究方向和评价指标，后续工作就可以由多个Agent自动推进。三四月份产出的研究成果还比较粗糙，到了后期，他一次性提交多个研究想法，系统就能自动运行并产出高质量的结果。即便基础模型没有更新，Agent交付的成果质量却有了显著提升。这背后的朴素逻辑是：基础模型决定了能力上限，而Harness决定了团队能否触达这个上限。

值得一提的是，Harness这类工作在过去的机器学习圈子里并不被看好。调整提示词、接入工具、封装任务循环，这类工作更像是工程优化而非模型研究，甚至有人质疑这是否属于真正的AI研究。但如今，这个曾被轻视的环节，已经成为拉开AI系统性能差距的关键变量。

随着技术发展，Harness的优化方向也在不断进化。早期的Harness主要聚焦于提升模型的输出能力，而如今，Harness本身已经成为独立的优化对象。首先被优化的环节是提示词工程。过去调整提示词依赖开发者反复尝试，而现在像DSPy这类工具可以自动生成多种提示词版本，通过测试结果筛选出效果最优的方案，将原本依赖经验的手工调整转化为标准化的搜索问题。其次是对Harness框架本身的优化。Darwin Gödel Machine（DGM）的思路更进一步：它不仅可以调整提示词，还能直接修改运行Agent的Harness代码。当现有任务流程效果不佳时，系统会自动替换实现方式，并通过测试结果判断新版本的优劣。在相关论文的实验中，这套系统将SWE-bench的测试成绩从20%提升到了50%。第三步则是让历史经验沉淀到Harness中。Continual Harness框架允许Agent回顾过往的任务记录和执行结果，自主决定是否需要调整提示词、新增技能、更新记忆库或者修改子Agent的配置方案。也就是说，多次任务执行积累的经验，会逐步融入到下一版的Harness框架中。当前更激进的技术方向，是让模型在运行过程中自主学习：将Agent刚生成的数据重新用于模型训练，甚至在测试阶段直接更新模型权重。这意味着优化的边界正在从Harness向模型内部渗透，Agent的性能提升越来越依赖于Harness的迭代优化，Harness和基础模型之间的界限正在逐渐模糊。

一个反直觉的技术趋势是：随着基础模型能力不断增强，Harness反而不需要将执行流程写死。传统的Agent设计思路通常是将任务流程拆分为多个固定步骤，比如第一步做什么、第二步调用什么工具、第三步如何判断结果。这种方案的优点是运行稳定，但缺点也很明显：当任务周期变长、执行环境发生变化时，提前预设的流程很容易失效。Prime Intellect的Seth在分享中介绍了团队开发的Prime Agent，其设计思路恰好相反：减少对执行流程的硬性规定，而是为模型提供丰富的可调用资源。其中的核心设计是“信息分层”，将Agent需要的信息存储在三个不同的位置：当前正在使用的核心信息直接放入上下文窗口；如果历史信息过长，则先进行压缩，仅保留当前任务真正需要的部分；程序代码、计算结果和任务进度则保存在持续运行的REPL环境中，这相当于一个不会因为单次调用结束而清空的编程环境，Agent之前编写的代码、计算出的结果以及任务的推进状态，都可以在后续执行中直接复用；长期记忆、技能库和提示词模板则存储在外部存储中，不需要一直塞入上下文窗口，需要时再按需调取。子Agent的设计也遵循同样的逻辑：完成单次任务后不会立即清空上下文，之前积累的执行状态会被保留，当子Agent再次被唤醒时，可以直接承接之前的工作继续推进。

这种职责划分的优势在长周期任务中体现得尤为明显。Seth的团队曾让Agent连续运行七天的《异星工厂》游戏——这是一款高度复杂的自动化经营游戏，玩家需要自主规划生产线、调配资源、解锁技术，且任何一次操作失误都可能改变后续的发展路线。在七天的运行中，该Agent总共调用了633个子Agent，生成超过2300万输出Token，最终完成了196项技术中的24项，并将“高级电路”技术的研究推进到71%。期间还发生过一次严重失误，任务进度从完成5项技术倒退到仅完成1项，但系统并没有清空状态重新开始，而是保留了此前的程序、资源和任务记录，让模型可以根据新的局面重新判断下一步行动，继续推进任务。这正是Harness在长周期任务中的核心价值：对于无法提前预设所有情况的长周期任务，模型需要根据当前执行结果自主决定下一步动作，而Harness负责保存此前的执行状态和工作成果，让模型的自主决策能够连续进行。

不过，给予模型更大的自主空间，并不意味着Harness可以替代基础模型的能力。在ARC-AGI-3公开测试集上，Prime Agent搭配Claude Opus 5时的RHAE得分达到95.5%，但换成Terra模型后，得分仅为25.7%。同一套Harness框架，搭配不同的基础模型，性能差距可以达到近70个百分点。因此准确的结论是：Harness可以放大模型已有的能力，但无法凭空创造能力，它的作用是帮助模型发挥出自身的全部潜力。

除了优化现有高性能模型的调度方式，Harness还有一个更实际的应用场景：弥补本地小模型和云端大模型之间的性能差距。如今大量个人AI Agent依赖云端大模型，写作、研究、编程、日程管理等任务都可以交由云端模型完成，但这带来了高昂的长期API成本，同时还存在将个人邮件、文件等敏感数据上传到云端的隐私风险。斯坦福研究者Jon Saad-Falcon在分享中介绍的OpenJarvis项目，正是为了解决这个问题：尽可能将个人AI系统部署到本地设备上。

但目前本地模型的能力和最前沿的云端模型之间，还存在6到12个月的差距，这个差距并非简单更换开源模型就能弥补。研究团队做过一个对照实验：将OpenClaw和Hermes Agent原本使用的Claude Opus 4.6直接替换为Qwen3.5-9B，其他配置完全保持不变，结果两项测试的准确率分别下降了24.8和38.8个百分点。那么，这个性能差距能否通过模型之外的手段来弥补？OpenJarvis的解决方案是对整个AI系统进行全链路优化，将个人AI拆分为五个层级：基础模型的选择、模型的运行配置、Agent的工作逻辑、可调用的工具集和记忆库、以及系统的持续学习机制。每个层级都可以独立调整并重新组合。比如，可以先用更强的云端模型分析失败案例，定位问题所在，再帮助本地系统调整配置；优化完成后，日常运行的仍然是本地模型。简单来说，就是“大模型负责判断方向，小模型负责具体执行”。

优化效果如何？在Qwen3.5-9B模型本身没有任何改动的前提下，整套系统优化后，在上述两项测试中分别追回了约56%和77%的性能损失。在更完整的八项测试中，表现最优的本地方案平均准确率达到80.3%，而Claude Opus 4.6的准确率为83.5%，两者的差距仅为3.2个百分点，其中四项测试的本地方案已经追平甚至超过了云端模型的表现。更重要的是，这套本地方案的运行成本极低，根据测试数据，其边际API成本仅为云端方案的八百分之一，端到端延迟也缩短到了原来的四分之一左右。OpenJarvis证明：个人AI从云端走向本地，不需要等到本地模型完全追平云端模型，通过优化Harness框架，就可以先弥补一部分性能差距。

当Agent真正进入企业办公场景，问题就不再只是“能否完成任务”这么简单。当数十个Agent同时运行时，如何部署、维护这些Agent，它们能够访问哪些信息、可以修改哪些内容，这些问题的重要性开始凸显。YC从2025年初就开始探索企业级Agent应用。早期的方案仅包含系统提示词、工具集和任务循环，后续陆续接入了Slack、定时任务和虚拟机，让Agent可以修改代码、运行测试，甚至拥有独立的工作环境。但当这套方案扩展到全公司规模时，问题很快暴露出来：团队曾在虚拟机中部署了50多个Hermes Agent，每个Agent都需要单独配置；当某个Agent出现故障时，工程师需要逐个登录对应的实例进行排查和修复，随着Agent数量增加，维护成本急剧上升。

为了解决规模化部署的问题，YC内部开发了名为QM的Harness框架。QM的核心改进是：不再让Agent“绑定”在某一台特定的机器上，而是将对话上下文和长期状态集中存储，虚拟机和隔离环境则变成按需调用的资源。Agent可以根据任务需求选择不同的机器，甚至切换不同的模型服务商。到这一步，Harness的角色已经不再局限于为单个Agent接入工具，而是开始负责管理一批Agent的状态、资源分配和运行逻辑。但在真实的企业办公环境中，规模化部署还面临三个难以绕开的问题：

第一个问题是Agent容易将局部问题放大为全局问题。YC曾尝试让Agent根据运行记录自主发现Bug并修改系统，效果参差不齐。团队将其中一种失败模式称为“主角综合征”：Agent仅关注自己遇到的局部问题，却可能提出影响整个系统的修改方案，目前这类修改仍需要人工审核把关。第二个问题是Agent容易提前放弃任务。明明还有足够的时间和可用工具，Agent在尝试几次失败后就可能直接宣布任务失败。YC的解决方案是开发了Grind Tool，为任务设置最低运行时间或Token预算，在达到阈值之前不允许Agent主动结束任务。第三个也是最棘手的问题是权限管理。当Agent接入Slack等协作工具后，可以访问大量上下文信息，但未必能准确理解哪些信息可以共享给哪些用户。人类员工知道同事私下的对话不能随意转发到其他群组，但如果没有明确的权限边界，Agent可能会在不同会话之间流动敏感信息。YC目前的做法是：大部分数据库保持只读权限，当Agent需要执行写入操作时，必须先提出具体方案，再由人工确认。但人工审核并非万能解决方案，随着员工对Agent的信任度提升，可能会逐渐习惯直接点击通过审核，导致审核流程流于形式。这意味着企业级Agent下一阶段需要补足的，并非更多的能力，而是一套既能实现Agent规模化部署，又能严格管控权限的Harness框架。

过去两年，AI行业的注意力几乎全部集中在基础模型的研发上，这无疑是正确的，基础模型仍然是AI应用的地基。但在未来，AI系统之间的性能差距将越来越多地产生在地基之上。基础模型决定了AI系统能够跑多快，而Harness则决定了AI系统能够持续运行多久、能够走多远。