NVIDIA发布AI Factory Operations Agent，用多智能体协查GPU集群故障
NVIDIA技术博客介绍其内部用于DGX SuperPOD运维的多智能体框架：子智能体通过MCP通信，在聊天界面中跨计算、网络、硬件和调度层关联故障原因。该框架以实验性开源软件形式提供，NVIDIA称其为内部生产使用，但未公开根因分析准确率等效果数据。
AI解读：NVIDIA技术博客介绍了自研的AI Factory Operations Agent，用于内部DGX SuperPOD集群运维，目标是减少站点可靠性工程师（SRE）在多个仪表盘之间手工排查训练性能下降原因的工作量。
架构上，面向用户的智能体运行时接收SRE的自然语言提问，再分派给各领域子智能体；子智能体通过Model Context Protocol（MCP）通信，每个MCP只暴露一组经批准的操作工具。
内部部署包含Job Recovery、Hardware、Observability、Research、Kubernetes、Cluster Management等子智能体，分别覆盖训练作业失败与goodput下降的根因分析、设备级硬件故障排查、日志与指标查询、文档检索和只读集群状态查看。
安全设计上，Kubernetes操作经由服务端run_kubectl工具执行，绑定只读凭据，OpenShell运行时本身不持有kubectl和Kubernetes凭据；博客示例显示智能体可以读取pods和configmaps，但不能读取secrets，也不能创建或更新pods。
NVIDIA建议为大规模AI工厂设置独立于生产集群的GPU加速控制平面，生产集群只提供遥测数据；多租户场景下用沙箱和命名空间权限隔离各租户可见的数据与节点。
该编排框架以实验性开源软件发布，NVIDIA说明API、配置和部署要求可能随版本变化；对根因分析准确率的衡量仍在进行中，博客未给出具体数字。
NVIDIA在技术博客中介绍了AI Factory Operations Agent：一个用于其内部NVIDIA DGX SuperPOD集群运维的多智能体框架。NVIDIA称，该框架让SRE通过单一聊天界面查询跨计算、网络、硬件和调度层的故障原因，而不是逐个检查各层仪表盘。
博客由Shara Tibken撰写，定位为分享经验并指导他人在自有工作流中实现该智能体。文中描述的内部生产使用情况来自NVIDIA自述；框架以实验性开源软件提供，API和部署要求可能随版本变化。
架构：中心运行时加领域子智能体
AI Factory Operations Agent围绕NVIDIA NemoClaw blueprint构建。中心是面向用户的智能体运行时，通过聊天界面接收SRE查询，并调用相应的领域智能体和工具。智能体经OpenClaw插件和MCP服务器连接基础设施，每个MCP暴露一组聚焦且经批准的操作工具。
用户可以使用内置Web UI，也可以通过API接入现有编码智能体界面。NVIDIA称这种模块化设计允许在不改动已有智能体的前提下增加新智能体和基础设施集成。框架基于NVIDIA OpenShell构建，可完全本地部署；智能体推理使用本地服务的NVIDIA Nemotron开源模型，运行在内部DGX H100、DGX B200和DGX GB300生产集群上。
部署方式与权限边界
该智能体作为Kubernetes控制平面应用运行，Helm将UI、OpenClaw网关、MCP工具服务器、推理端点和OpenShell运行时部署为Kubernetes服务。聊天UI将请求发给NemoClaw，由其路由到相应领域智能体。需要执行shell命令时，OpenShell为每个会话创建Kubernetes沙箱，而不是在主网关Pod中运行命令。
安全按层实施。Kubernetes检查使用服务端run_kubectl工具，调用固定版本的kubectl二进制文件和已注册的只读凭据；OpenShell本身不持有kubectl和Kubernetes凭据。Kubernetes服务账户和RBAC定义工具可检查的集群资源。博客给出的示例中，智能体对pods和configmaps的读取权限为yes，对secrets的读取以及创建、更新pods的权限为no。
内部使用的领域智能体
NVIDIA内部部署使用一组数据中心领域智能体，每个智能体给出各自的建议。Job Recovery Agent检测训练作业失败和goodput下降，在调度器、应用、硬件和网络层做多层根因分析，并在确认根因后建议恢复步骤。Hardware Agent在设备级排查PCIe错误、ECC错误、GPU问题、NVMe故障和温度异常，追踪到具体组件。
Observability Agent查询历史Prometheus、遥测数据和集成的Grafana Loki日志，动态创建仪表盘并显示在Web UI中。Research Agent检索预加载文档，包括NVIDIA Mission Control手册和DGX SuperPOD参考架构与部署指南，也支持上传自有运行手册。Kubernetes Agent提供Pod、服务、部署、GPU资源、节点状态和调度状态的只读视图。Cluster Management Agent通过诊断MCP工具调用NVIDIA Base Command Manager API，用于咨询式集群管理和故障排查。框架还集成网页搜索、代码执行和Grafana仪表盘等跨领域MCP工具，并允许接入自有的MCP服务器和API。
NVIDIA总结的五条使用经验
NVIDIA表示正在通过衡量根因分析准确率和跟踪SRE认可度来改进框架，并扩展智能体生态。博客列出从生产使用中总结的五条经验：明确智能体边界，职责重叠会制造噪音；先做只读，准确排查建立信任后再自动化；跨层关联，把工作负载、硬件和网络信号连起来，找出孤立工具遗漏的根因；精确的MCP工具定义，改善路由并减少误选工具；推理透明，SRE需要先看到工具调用、证据和结论再采取行动。
部署建议与获取方式
对大规模运行AI工厂的组织，NVIDIA建议采用独立于生产集群的专用GPU加速控制平面：控制平面负责智能体编排和推理，生产集群只提供遥测，不占用训练GPU或干扰工作负载。NVIDIA内部部署在专用GPU容量上运行模型推理，运行时服务使用现有控制平面的CPU Kubernetes管理空间。其他部署可按数据主权、集群规模和可用GPU容量选择本地或云端推理端点，较小部署可使用RTX PRO Workstation或DGX Spark。
多租户场景下，范围限定的智能体、工具、沙箱和Kubernetes权限控制每个租户可用的集群数据、工具和节点。租户SRE只能看到自己的命名空间、作业和节点，中央运维保留更广的集群可见性。OpenShell通过在内核级受限的隔离沙箱中运行每个租户的智能体和工具来实施这些边界。
该编排框架已在GitHub以实验性开源软件发布，NVIDIA提示API、配置和部署要求可能在不同版本间变化。NVIDIA客户可联系客户经理申请访问NVIDIA开发的集群运维智能体。