AI Agent失效？模型可能不是根源

随着 AI 代理进入生产环境，从请求到结果之间的路径变得越来越不可预测。代理可以自主选择工具并在工作过程中改变方向，这让失败诊断变得更加困难——当没有明显的错误可以追溯时，问题很难定位。

在近期一次接受 The New Stack 采访时，Nvidia 产品副总裁 Adel el Hallak 描述了开发者随着代理承担更复杂的工作将需要怎样的额外可见性。

Nvidia 同时也在推进行业内的共享努力，分享各公司在这些系统失败时学到的经验。安全代理发现交换协议（Secure Agent Findings Exchange，简称 SAFE）获得了约 140 家公司的支持，旨在创建报告代理失败的共享基础设施，借用了传统软件中的漏洞披露机制。

"当我们发现这些漏洞时，不仅仅是为了某一家公司，" el Hallak 告诉 The New Stack。"而是为了让所有人都能打上补丁。"

但代理失败并不一定能追溯到单一组件，这就给开发者提出了一个更基本的问题：当一个代理失败了，你究竟要调试什么？

"当我们发现这些漏洞时，不仅仅是为了某一家公司。而是为了让所有人都能打上补丁。"

传统可观测性为何不够用

在传统软件中，当出现问题时开发者通常有一个起点，无论是异常、失败的请求还是宕机的服务。而代理可以在朝着错误方向前进的同时继续运行，将早期的错误一路携带到后续任务中，却不会产生任何看起来像传统软件失败的东西——或者如 el Hallak 所说，只是在不该"发挥创意"的时候自作主张地"发挥创意"了。

即使表现最好的编码代理，在从真实代码库中提取的任务上失败率也超过 60%。知道代理失败了是一回事，知道为什么失败则是另一回事。

"仅仅查看日志、输入和输出是不够的，" el Hallak 告诉 The New Stack。"重要的是弄清楚它是如何得到答案的。推理轨迹是什么？它使用了哪些工具？在哪里卡住了？在哪里决定尝试新方法的？"

这可能需要重放代理的执行过程，以查看它在哪里偏离了轨道。看起来像是模型失败的问题可能起始于堆栈的其他地方。这正是让开发者头疼的部分。代理的 bug 不一定是模型的 bug。

"仅仅查看日志、输入和输出是不够的。重要的是弄清楚它是如何得到答案的。推理轨迹是什么？它使用了哪些工具？在哪里卡住了？在哪里决定尝试新方法的？"

运行时作为收集点

Nvidia 认为运行时是捕获大部分这类信息的合理位置。其 OpenShell 代理运行时位于 NemoClaw 平台之下，负责管理沙箱、策略执行，同时提供对代理执行过程的可见性。

El Hallak 称 OpenShell 是 Nvidia 参考架构中唯一一个不可妥协的组件。

"你可以更换任何你需要的 harness。我甚至开放地接受使用任何你需要的模型，" el Hallak 告诉 The New Stack。"但治理、我们始终希望利用的安全开放的运行时是 OpenShell。"

Nvidia 将代理堆栈分为三层：模型提供智能，harness 编排其工作，运行时governs执行。当代理失败时，模型本身可能并不是出问题的地方。

例如，Nvidia 的 NOAH 研究表明，在保持底层模型不变的情况下更换 harness 可以提升代理性能，这也意味着一个匹配不好的 harness 可以拖累一个本来能力足够的模型。

"每个模型都不同。有些可能比其他的更话多，" el Hallak 告诉 The New Stack。"确保这两者要么共同开发，要么有针对模型特定的配置文件，这是一个新的突破点。"

安全作为系统工程

Nvidia CEO 黄仁勋将 AI 安全描述为一个工程问题，el Hallak 将这种方法比作传统软件测试。

"如果你的软件有 bug，你不会发布它，" el Hallak 告诉 The New Stack。"你会一直工作直到它被修复并通过所有测试。"

代理让这种模式变得更加复杂，因为复现一个失败可能需要重建整个系统发生了什么。这需要检测手段，而这是有代价的。OpenAI 发现，对其最具能力的持久代理来说，监控大约增加 20% 的推理计算成本。

Nvidia 的方法结合了受治理的 harness、沙箱化运行时和机密计算，旨在保护模型和用户数据。

"有办法让你一直到底层硅片都做出保证，" el Hallak 告诉 The New Stack。

SAFE 通过为企业创建共享基础设施来扩展这种工程方法，让他们能够分享代理失败时学到的经验。

"如果你的软件有 bug，你不会发布它。你会一直工作直到它被修复并通过所有测试。"

代理调试其他代理

CrowdStrike 正在基于多年的安全数据对 Nvidia 的 Nemotron 模型进行微调，以创建配对代理——一个发现漏洞，另一个修补它们。

如果其中任一代理出了问题，最终输出可能无法揭示原因。例如，一个糟糕的补丁可能追溯到模型、代理的执行路径或它一路上使用的工具。

"对于给定任务，我不需要通用能力。我需要的是专业化，" el Hallak 告诉 The New Stack。

随着各公司围绕越来越专业化的工作流构建代理，这些失败可能不会出现在通用模型基准测试或安全测试中，这给开发者带来了更大压力，要求他们理解执行过程中发生了什么。

迈向共享失败报告

对于平台团队来说，发现失败是一个问题。重建足够的代理执行过程以理解其成因是另一个问题。

SAFE 旨在让这些发现在发现它们的公司之外也能发挥作用。传统软件已经建立了分享漏洞和修复方案的系统，但代理失败方面还没有可比较的东西。目标是避免每个团队都必须自己发现同样的失败。