随着 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 编排其工作，运行时治理执行。当智能体失败时，模型本身可能并非问题所在。
例如，Nvidia 的 NOAH 研究表明，在保持底层模型不变的情况下更换 harness 可以提升智能体性能，这也意味着不匹配的 harness 可能会拖累原本能力很强的模型。
“每个模型都不同。有些可能比其他更健谈，”el Hallak 对 The New Stack 表示。“确保这两者要么协同开发，要么拥有针对特定模型的配置文件，这是一项新的突破。”
安全作为系统工程
Nvidia CEO Jensen Huang 将 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 旨在让这些发现能在发现它们的公司之外也有用。传统软件已有用于共享漏洞和修复的成熟系统，但在智能体失败方面还没有类似机制。目标是避免每个团队都不得不自行发现同样的失败。
转载声明：本文为转载整理，原文版权归原作者及原站点所有。
原文来源：The New Stack
原文作者：Amanda Caswell；如有侵权，请联系管理员删除。
