夜雨聆风很多人还在盯着模型排行榜。
谁的推理分数更高，谁的上下文更长，谁的代码能力更强，几乎每天都有新答案。
但真正把AI接进工作流之后，很多开发者会发现一个尴尬事实：
模型会答题，不等于Agent会干活。
让AI写一段代码，通常只需要一次对话；但让它独立完成一个真实项目，往往要经历需求拆解、资料检索、文件修改、运行测试、错误修复和结果验收。
中间任何一步失控，最后交付的都可能是一堆看起来很努力、实际上不能用的半成品。
最近，Nvidia发布的一项研究引发关注：在同一个模型的情况下，仅仅更换一套围绕模型设计的运行系统，任务表现就可能出现巨大差异。
这意味着，AI竞争正在发生一个重要转向：
模型负责思考，但Harness决定它能不能把事情做完。
一、什么是Harness？它不是另一个模型
“Harness”可以理解为套在大模型外面的执行系统。
它负责的不是生成一句话，而是组织模型完成一连串动作：
• 把大任务拆成多个小任务； • 决定什么时候调用工具； • 保存和整理上下文； • 记录中间结果； • 发现错误后重新尝试； • 必要时让另一个“监督者”检查结果； • 最后判断任务到底有没有完成。
如果把大模型比作一个聪明的大脑，那么Harness更像是工作计划、工具箱、记事本、项目经理、质量检查员和失败后的应急预案。
没有这些东西，模型再聪明，也可能只是在聊天窗口里持续输出。
以一个全栈开发者的任务为例。
你让普通聊天模型“帮我做一个用户登录页面”，它可能会直接给出一份代码。
但真实项目通常还需要：
1. 先检查当前项目使用的前端框架； 2. 找到现有路由结构； 3. 确认数据库字段； 4. 修改登录页面； 5. 接入后端接口； 6. 运行测试； 7. 处理报错； 8. 检查是否破坏其他页面； 9. 返回修改清单。
这已经不是一次问答，而是一条持续几十分钟甚至几小时的执行链。
模型只负责其中一环，Harness负责把这些环串起来。
二、为什么同一个模型，换套系统后差距会这么大？
Nvidia相关研究被TechCrunch报道后，最受关注的数字是：
在ARC-AGI-3交互式推理基准中，Claude Opus 5直接运行时得分约为30%；加入经过定制的Harness后，得分提升到100%。
这个结果不能简单理解为“模型能力突然提升了两倍多”。
模型本身没有换，真正变化的是外围执行机制。
研究中涉及的关键设计包括：
• 更好的记忆管理； • 更适合长任务的上下文组织； • 一个类似“主管”的监督组件； • 对任务过程进行持续反馈。
也就是说，模型并不是每次都从零开始思考，而是能够记住已经尝试过什么，知道当前处于哪一步，发现某条路径失败后及时调整，并让监督组件检查结果。
这与人类团队的工作方式很像。
一个聪明但没有流程的员工，可能会把任务做得一团糟；一个普通员工，如果拥有清晰的目标、合适的工具、完善的检查机制，也可能稳定交付。
AI Agent也是如此。
单轮回答比的是模型，长链路交付比的是系统。
三、Agent真正的能力，不是“会说”，而是“能闭环”
可以把一次Agent任务的成功率粗略拆成一个公式：
任务成功率≈ 模型判断能力× 工具调用准确率× 上下文保持能力× 失败恢复能力× 结果验证能力假设一个模型本身的判断质量达到90%，但其他几个环节分别只有90%、80%、70%和80%，那么一次完整任务的理论成功率大约是36%。
这就是为什么很多Agent演示看起来非常惊艳，真正放进生产环境却频繁出错。
模型单步能力并不差，但任务一旦变长，每个环节的小概率错误都会累积。
如果任务需要连续完成10步，每一步的成功率都是95%，那么全部完成的概率只有约60%；如果每一步成功率降到90%，10步全部完成的概率就只剩约35%。
不是某一步特别复杂，而是不能在连续几十步中犯下无法恢复的错误。
Harness的价值，就是把“连续执行”变成“可监控、可回退、可修正”的过程。
四、真正有用的Harness，至少要解决四个问题
1. 它能不能让模型记住“已经做过什么”？
长任务最常见的问题不是模型不会，而是模型忘了。
比如一个Agent修改代码时，前面已经确认项目使用Vue，后面却突然按照React的写法继续开发。
或者它刚刚已经运行过测试，发现某个接口报错，下一轮又重复执行完全相同的操作。
因此，Harness需要维护的不只是聊天记录，还包括当前任务目标、已完成步骤、已尝试方案、失败原因、待处理事项和关键文件依赖关系。
聊天记录是“发生过什么”，任务状态则是“现在应该做什么”。两者并不是一回事。
2. 它能不能控制工具调用？
给Agent接入工具并不难，难的是限制它什么时候可以调用、调用后能做什么。
例如：查询数据库可以，但不能删除数据；修改代码可以，但必须限制目录；发送请求可以，但不能访问敏感地址；执行命令可以，但高风险操作必须人工确认。
成熟的Harness不会把所有权限一次性扔给模型，而是采用分层授权。
模型的能力越强，权限边界反而越重要。
3. 它能不能在失败后恢复？
真实任务不可能一次成功。
网络会超时，依赖会冲突，测试会失败，接口返回格式也可能变化。
低质量Agent遇到错误，通常只有两种反应：不断重复同一个动作，或者直接跳过错误，假装任务已经完成。
好的Harness需要把失败变成结构化信息：
第1次尝试：调用接口失败原因：返回字段缺失第2次尝试：检查接口定义发现：前端字段名与后端不一致第3次尝试：修正字段映射并重新测试结果：通过关键不是“永不出错”，而是：
出错之后，能知道错在哪里，并且不会沿着错误路径继续走。
4. 它能不能验证结果？
Agent最危险的时刻，往往不是报错，而是“没有报错但结果不对”。
代码能够运行，不代表功能正确；页面能够打开，也不代表用户流程完整。
因此，Harness必须设置结果验证环节：测试是否通过、输出是否符合格式、文件是否真的生成、数据是否写入正确、页面是否出现异常，以及任务目标是否全部完成。
如果没有验证，Agent只是把“我做完了”当成了“事情真的做完了”。
五、模型价格下降，反而会放大Harness的价值
最近大模型API价格持续下调，开发者调用模型的成本越来越低。
表面上看，这是模型厂商之间的价格竞争；但对企业来说，更重要的问题是：
完成一个任务，究竟需要调用多少次模型？
假设某个客服Agent每天处理1000个任务：
即使模型单价完全不变，仅通过更好的任务拆解、上下文复用和失败重试，也能把调用成本降低一半以上。
更关键的是，失败率下降后，人工返工成本也会同步下降。
可以用一个简单模型估算：
总成本= 模型调用成本+ 人工返工成本+ 错误造成的业务损失很多企业只盯着第一项，却忽视了后两项。
一个每次调用便宜几分钱、但经常把任务做错的模型，最终成本可能远高于一个调用价格稍高、但交付稳定的系统。
所以未来的模型采购，不能只比较“每百万Token多少钱”，更应该比较：
完成一个有效任务的综合成本= 总调用成本 ÷ 成功交付的任务数量六、开发者该如何判断一套Agent系统值不值得用？
不要只看模型名称，也不要只看演示视频。
可以从五个维度打分：
Agent适用度= 0.25 × 任务成功率+ 0.20 × 失败恢复能力+ 0.20 × 工具与权限管理+ 0.20 × 过程可观测性+ 0.15 × 综合成本其中：
• 任务成功率：是否能真正完成完整流程； • 失败恢复能力：出错后能否定位和重试； • 工具与权限管理：能否控制Agent的行动边界； • 过程可观测性：能否看到每一步做了什么； • 综合成本：模型、服务器和人工返工的总成本。
如果只是写摘要、改写文本、生成单段代码，模型本身可能已经够用。
但如果任务涉及多个工具、多轮决策、文件修改、数据库操作、长时间运行和自动化交付，那就应该优先考察Harness，而不是继续纠结模型排行榜上相差几分。
写在最后
过去几年，AI行业一直在追逐更大的模型、更高的参数和更强的单项能力。
但当模型能力逐渐接近之后，真正的差距会转移到另一个地方：
谁能让模型稳定地完成复杂任务，谁就拥有更高的商业价值。
模型是发动机，Harness是整辆车的变速箱、方向盘和刹车系统。
发动机再强，没有控制系统，也只能停在原地轰鸣。
下一轮Agent竞争，拼的可能不是谁的模型更聪明，而是谁能把模型组织成一支真正能干活的团队。
欢迎评论区聊聊：如果只能二选一，你更愿意使用“更强的模型”，还是“模型稍弱但执行系统更稳定的Agent”？
关注数据码农，用数据和技术视角重新理解科技圈。每周 2-3 篇硬核分析，不追热点，只追逻辑。