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