NVIDIA：Agent胜负在Harness

NVIDIA 把 Agent 的真正变量指向了 Harness

**NVIDIA 在 8 月 21 日公开讨论的一项最新研究，正在动摇 Agent 开发中“底层模型决定一切”的惯性认知。**据 TechCrunch 当日报道，NVIDIA 的实验显示，即使基础模型并不特别擅长目标任务，只要配合合理的 Agent Harness、任务轨迹微调和确定性验证，智能体依然可以取得很强的表现，并显著减少失控、误操作和虚假成功。

**Agent Harness 是包裹在大模型外部、负责工具调用、状态管理、记忆、验证、权限和执行循环的一整套运行框架。**如果把大语言模型比作发动机，Harness 就是变速箱、方向盘、刹车、仪表盘和道路规则的总和；发动机马力当然重要，但没有后面这些东西，车既跑不快，也很难安全抵达目的地。

这不是一句为了强调工程价值而制造的口号。NVIDIA 展示的关键现象是：**同一个模型，仅仅更换 Harness，基准表现就可能出现两位数百分点的差距。**对已经部署 Agent 的团队来说，这个信号比“下个月还有一个更强模型”更值得重视，因为 Harness 是开发者能够直接控制、持续测试并形成产品壁垒的部分。

“Agent = LLM + Harness”不再只是一句架构描述

**NVIDIA 对 Agent 的定义正在变得非常明确：一个可工作的智能体，不是单独的 LLM，而是 LLM 与 Harness 的组合。**NVIDIA 开发者技术负责人 Nader Khalil 今年 6 月接受 The New Stack 采访时，就用“An agent is an LLM and a harness”概括这一判断；到了 8 月，这一说法已经有更具体的实验结果支撑。

**Harness 的价值在于把概率性的模型输出，约束成可以检查、重试和审计的工作流。**普通聊天场景允许模型给出一段“差不多正确”的回答，但代码修复、漏洞验证、财务操作或企业后台自动化不能接受这种模糊性。一个漏洞要么能够用输入稳定触发，要么就不能算有效发现；一个补丁要么通过测试，要么就必须继续修改。

**模型负责提出候选动作，Harness 负责决定候选动作能不能进入真实世界。**这一区分看似简单，却直接决定了 Agent 是演示产品，还是可以接入生产系统的工具。很多所谓 Agent 的问题并不是模型不会思考，而是系统没有保存正确状态、没有把工具返回值结构化、没有验证任务是否真的完成，也没有在异常时停止执行。

NOOA 的做法：让验证成为代码，而不是提示词

**NOOA 是 NVIDIA 用于研究开放式、面向对象智能体的一套实验框架。**它并不试图替代所有现有 Agent 框架，而是提供一个可检查的实验表面，把智能体的状态、动作、事件历史和验证逻辑放入类型化对象中，便于开发者测试和审计。

**NOOA 最值得关注的设计，是把确定性约束写成必须执行的方法，而不是塞进系统提示词。**提示词中的“请再次确认”“不要执行危险操作”和“只有成功后才能汇报”本质上仍是自然语言建议，模型可能遵守，也可能在长上下文、工具异常或多轮执行后忽略它们。代码中的布尔判断、类型检查和权限门则不同：条件不满足，流程就无法继续。

NVIDIA 在漏洞发现实验中实现了三个确定性关卡：

1. 崩溃判定关卡：把验证器的原始输出转换为明确的“崩溃”或“未崩溃”结果。
2. 漏洞匹配关卡：确认本次崩溃确实对应 Agent 声称发现的漏洞，而不是无关异常。
3. 复现关卡：重新运行触发输入，只有稳定复现后才接受结果。

**这三个关卡解决的是 Agent 最常见的“自我宣布成功”问题。**模型可能看到一段异常日志就认为漏洞已经成立，也可能把超时、环境错误或依赖崩溃误判为目标缺陷。NOOA 不让模型自己给自己打分，而是要求执行环境提供可复现证据。

**类型化对象也减少了多个组件之间传递自由格式文本所造成的信息损耗。**传统多 Agent 工作流经常让规划器、执行器和评审器互相发送自然语言消息，每多转一层，就多一次误解、遗漏或提示注入的机会。NOOA 把方法、状态和验证器集中在可查询对象中，让一次运行形成统一轨迹，更接近普通软件工程中的调用链，而不是几个聊天机器人开会。

86.8% 的结果，证明通用模型未必是短板

**NVIDIA 披露的最有说服力的数据，来自 CyberGym L1 漏洞重新发现基准。**CyberGym L1 是用于评估智能体能否在真实代码库中重新发现已知漏洞的测试；任务不仅要求找到可疑代码，还要求生成能够触发漏洞的输入并完成复现。

在这一基准上，NOOA 增强的研究工具使用通用模型、且不开放网络访问，完成了 86.8% 的任务。这个结果不能直接推出“任何普通模型套上 NOOA 都能达到 86.8%”，因为模型选择、任务集、工具权限和评估协议仍会影响最终成绩；但它至少说明，在一个强调真实执行和可复现证据的任务上，底层模型并不是唯一决定因素。

| 实验或指标 | NVIDIA 披露结果 | 说明 | |---|---:|---| | CyberGym L1 任务完成率 | 86.8% | 使用通用模型、无网络访问，并加入 NOOA Harness | | 同模型更换 Harness 的成绩差距 | 两位数百分点 | 说明框架设计足以改变基准结论 | | ARC-AGI-3 测试环境 | 25 个未知网格游戏 | Agent 需要通过动作与观察自行发现规则 | | ARC-AGI-3 单场成本 | 两套 Agent fleet 均低于 20 美元 | 体现复杂执行循环的成本仍可控制 | | 已检查运行日志 | 13,335 条与 10,107 条 | 用于检查规则泄露和执行合规性 | | 外部模型审核运行 | GPT-5.5 18 次、GPT-5.6-sol 9 次 | 用不同审核器检查测试过程 |

**这些数字的意义不在于宣布某个框架“解决了 Agent”，而在于把讨论从模型印象分拉回可验证系统。**如果同一个模型在 Harness A 上完成率是 60%，在 Harness B 上达到 72%，这 12 个百分点通常比把模型替换成更昂贵版本更有工程价值，因为它可能同时带来更低成本、更稳定输出和更清晰的失败原因。

六类能力，决定 Harness 是外壳还是操作系统

**从 NVIDIA 已公开的 NOOA 材料中，可以把高性能 Harness 的核心能力归纳为六类。**这不是简单堆叠几个工具，而是在模型与环境之间建立完整的控制面。

1. 结构化动作与对象接口

**结构化动作是让模型操作明确方法和参数，而不是用自然语言描述“我想做什么”。**工具输入、工具输出、错误类型和状态变化都应有稳定结构，模型负责选择动作，系统负责验证动作是否合法。

这种设计类似数据库查询与口头指令的区别。让模型说“帮我找一下最近失败的任务”很容易产生歧义；让它调用一个具有固定字段、范围和返回类型的方法，后续流程才有机会进行可靠判断。

2. 可查询状态与事件历史

**状态管理是 Harness 记录智能体当前处境、已完成步骤和环境变化的能力。**没有状态管理的 Agent，只能反复把历史对话塞回上下文窗口，并期待模型自己从大量文本中找出关键进度。

NOOA 强调人类可读状态和可查询事件历史，这意味着开发者可以回答几个生产系统必须回答的问题：Agent 为什么调用这个工具、调用前看到了什么、调用后哪些字段发生变化，以及最终结论来自哪一条证据。

3. 确定性验证与完成条件

**验证器是判断任务是否真正成功的程序化组件。**它不应依赖模型写一句“任务已完成”，而应检查测试结果、文件差异、数据库状态、返回码或可复现输入。

漏洞发现中的三道关卡就是典型案例。对代码 Agent 来说，同样的原则可以转换为测试是否通过、静态检查是否新增错误、补丁是否只改动允许的文件，以及问题能否在修改前复现、修改后消失。

4. 受控工具与最小权限

**权限控制是限制 Agent 只能访问完成任务所需资源的安全机制。**NVIDIA 的实验使用分层沙盒，包括进程内单元守卫、每次运行时降低操作系统权限、游戏身份匿名化和内核强制隔离；生产部署则可与 OpenShell 安全运行时配合。

这一点尤其重要，因为“模型更聪明”并不会自动让系统更安全。能力更强的模型通常也更会组合工具、探索边界和寻找替代路径，错误授权的风险反而更高。Agent 的安全上限首先由它能碰到什么决定，其次才由提示词中写了什么决定。

5. 反馈、重试与轨迹微调

**闭环反馈是把工具结果和验证失败转换为下一步行动，而不是让模型从头猜一次。**失败轨迹可以用于调整策略、筛选高质量示例，并进一步微调模型在特定 Harness 中的行动方式。

这里的关键不是把基础模型训练成无所不知，而是让它更熟悉当前环境的动作空间。一个通用模型可能不擅长漏洞复现，但如果 Harness 能稳定提供“候选位置—生成输入—执行—分类失败—再次尝试”的反馈，它就能在较小且明确的搜索空间内不断修正。

6. 可观测性与安全审计

**可观测性是把每次规划、工具调用、状态变化和验证结果记录成统一追踪数据。**没有可观测性，团队看到的只是一次失败和一笔账单；有了完整轨迹，团队才能区分问题来自模型推理、工具描述、上下文裁剪、环境异常还是验证器误判。

NVIDIA 对超过两万条日志进行规则泄露检查，说明安全评估不能只看最终得分。一个 Agent 即使赢得游戏或找到漏洞，如果它通过意外读取答案、跨任务共享身份或利用环境泄露完成任务，这个成绩也没有部署价值。

为什么换模型经常没有想象中有效

**很多团队把 Agent 失败归因于模型能力不足，是因为更换模型比调试系统更容易解释。**模型 A 不行就换模型 B，模型 B 超时就换推理版本，短期内确实可能得到更高成功率，但工具返回格式混乱、状态丢失和错误完成条件仍然存在。

| 方案 | 短期效果 | 成本变化 | 可解释性 | 生产稳定性 | |---|---|---|---|---| | 更强模型 + 弱 Harness | 可能改善单次推理 | 通常上升 | 低，失败原因仍模糊 | 中低 | | 普通模型 + 强 Harness | 特定任务可显著改善 | 可控 | 高，可定位到具体步骤 | 高 | | 更强模型 + 强 Harness | 上限最高 | 最高 | 高 | 高 | | 多 Agent 自由讨论 | 部分复杂任务有效 | Token 消耗明显增加 | 容易出现责任链不清 | 取决于验证层 | | 单 Agent + 确定性关卡 | 结果更容易复现 | 通常更低 | 高 | 适合边界明确任务 |

**更强模型的主要优势仍然是更好的先验知识、推理深度和跨领域迁移，而不是替代系统工程。**在需求模糊、信息开放、需要长链推理的任务中，模型能力依然决定上限；但在代码修复、数据处理、网络安全和企业流程等可执行任务中，Harness 往往决定这些能力能否转化为稳定结果。

**NVIDIA 的结论不能被简化成“模型不重要”。**目前公开数据主要来自适合设置环境反馈和确定性检查的任务，而且优秀 Harness 本身也可能针对基准特征做过优化。当任务跨越多个会话、需要数周记忆、涉及大量隐性人类偏好时，状态压缩、长期记忆污染和目标漂移依然没有被彻底解决。

对开发团队最现实的启示：先做错误预算，再做模型榜单

**Agent 团队现在更应该建立 Harness 评测矩阵，而不是只维护模型排行榜。**同一批任务至少要交叉测试不同模型、不同提示策略、不同工具接口和不同验证器，否则团队无法判断一次提升究竟来自模型能力，还是来自框架偶然适配。

一个可操作的评估顺序是：

• 先定义完成条件：什么证据出现后，任务才算成功。
• 再定义失败分类：区分推理失败、工具失败、权限失败、环境失败和验证失败。
• 固定任务集做 Harness 对照实验：同一模型、同一温度和同一预算下，只更换 Harness。
• 记录端到端成本：不仅统计模型消耗，也统计重试次数、工具运行时间和人工复核时间。
• 测试异常路径：主动制造工具超时、空结果、脏数据和权限拒绝，观察 Agent 是否安全停止。
• 最后再升级模型：只有当失败确实来自知识、推理或上下文能力时，换模型才是针对性优化。

**一套优秀 Harness 还应允许模型替换，而不是把业务逻辑绑死在某个模型的表达习惯上。**如果更换模型后需要重写全部提示词、工具解析器和状态管理，说明团队构建的不是 Agent 平台，而是一次性的模型脚本。

真正的 Agent 护城河，可能从模型层上移

**NVIDIA 这项研究对行业最直接的影响，是 Agent 产品的竞争重心正在从模型选择上移到执行系统。**基础模型会持续变强，模型之间的差距也会不断变化，但企业积累的工具定义、权限策略、失败轨迹、验证规则和领域评测集不会随着榜单更新而自动贬值。

**Harness 也可能成为未来 Agent 基础设施最有价值的一层。**模型厂商提供通用智力，企业负责把通用智力限制在明确角色中：微波炉里的 Agent 不需要理解整个互联网，漏洞分析 Agent 也不应该拥有生产数据库写权限。越专业的 Agent，越依赖围绕任务设计的动作空间和验证边界。

**对开发者而言，最值得带走的判断是：当 Agent 表现不好时，不要第一时间怪模型。**先检查它是否看到了正确状态、是否拿到了结构化反馈、是否能区分失败类型、是否有权执行不该执行的动作，以及“成功”究竟由模型宣布，还是由代码证明。

模型决定 Agent 能想到什么，Harness 决定它能做什么、做错后会发生什么，以及最终结果是否值得相信。NVIDIA 这次给出的答案并不浪漫，却很符合软件工程的历史：真正进入生产环境的智能，从来不只是一个更聪明的大脑，而是一整套不会轻易失控的系统。

参考来源

• NVIDIA GitHub 官方组织：NVIDIA 开源项目与智能体基础设施相关代码的官方汇总入口。
• NVIDIA NeMo Agent Toolkit：用于了解 NVIDIA 在 Agent 编排、工具集成、追踪和评估方面的公开实现。
• NVIDIA OpenShell：NVIDIA 面向智能体工作负载的安全运行时项目，可用于了解沙盒、权限隔离和受控执行设计。