作者注：以 NVIDIA FOX 的 SMT 产线参考示例为例，讲清多智能体落地生产现场时，管理智能体、专业智能体与人工审核点如何划分。
一块电路板在 AOI 工位报警后，团队要查检测图像、翻生产记录、调度返修，还要追查炉温是否异常。证据散落在多个系统里，真正耗时的往往是协调。2026 年 11 月 4 日，NVIDIA 公开介绍了 Factory Operations Blueprint（简称 FOX），给出 管理智能体 + 专业智能体 + 人工审核点 的参考架构。
这不是又一篇多智能体概念科普。 本文以官方公开的 SMT（表面贴装）产线示例为事实基础，并把其中的分工方法整理成可执行的落地步骤。文中的审核判定方法和上线节奏属于我们的实践建议，会与 FOX 的官方能力分开说明。
核心价值：读完本文，你将学会按职责边界拆分智能体，按风险等级设置人工审核点，并完成从影子运行到受控执行的落地规划。
多智能体落地生产现场的核心要点
划分多智能体的关键，是先明确谁负责统筹、谁负责专业判断、谁承担最终责任。下表是三类角色的基本分工，后文的步骤都围绕它展开。
| 角色 | 主要职责 | 不应承担的职责 | 落地价值 |
|---|---|---|---|
| 管理智能体 | 理解任务、制定计划、委派任务、汇总结果 | 替代专业模型做细分判断 | 串联跨系统证据，减少人工协调 |
| 专业智能体 | 在限定上下文内完成检测、调度、分析，并返回证据 | 越权决定整体流程或修改全局策略 | 判断可验证，也便于单独替换 |
| 人工审核点 | 处理不确定结论，审批高风险动作，确认整改方案 | 逐条复核所有低风险结果 | 守住安全和质量责任边界 |
多智能体中的管理智能体负责什么
FOX 的管理智能体由三部分组成：大语言模型（LLM）负责解读任务、关联数据、制定计划和评估结果；Agent Harness 负责连接工具、技能、持久记忆和专业智能体，默认使用 NemoClaw，也支持替代方案；NVIDIA OpenShell 负责隔离执行环境，并管控文件、命令和网络目的地的访问策略。
这种设计说明，管理智能体不只是一段提示词，而是一个长期运行的执行环境。它要在处理后台任务和定时任务时持续响应操作员，还要记住调查进度。因此，划分时应把任务状态、委派逻辑和完成标准放在管理层，不要分散到各个专业智能体中。
多智能体中的专业智能体如何划分边界
FOX 中的专业智能体同样基于 LLM，并各自拥有指令、上下文、技能和工具。它们可以调用专用模型，例如用 NVIDIA Cosmos 做视觉检查，用 Kumo 做时序异常检测，再把发现交回管理智能体，由后者决定下一步。
判断是否需要拆出专业智能体，可以看三点：是否需要专属数据或模型，是否有独立的验收标准，以及是否可能调用高权限工具。如果三项都不满足，把它做成管理智能体的一项技能通常更简单。
如何拆分管理智能体与专业智能体：SMT 产线示例
官方示例从一条 AOI 告警开始。管理智能体通过 MCP 服务器或 API 取得电路板标识、受影响元件和检测图像，再发起二次判定。电路板标识是贯穿全流程的关键字段，适配器需要保留标识、时间戳、单位和来源引用，这样后续智能体才能追溯生产历史和机台状态。
| 专业智能体 | 输入 | 调用能力 | 输出 | 交接规则 |
|---|---|---|---|---|
| 视觉检测智能体 | 板卡图像、参考样例、已批准的判定标准 | NVIDIA Cosmos | 发现、证据、不确定性 | 确认缺陷转入处理和调查；结论不明转人工 |
| 车队管理智能体 | 已确认缺陷的板卡标识和目的地 | 示例中使用 NVIDIA Isaac Sim 与 ROS 2 | 权限与能力检查结果、完成状态 | 初期部署在搬运前需要操作员批准 |
| 根因分析智能体 | 板卡标识、加工历史、检测和测试记录 | Kumo Anomaly、Elasticsearch | 含来源记录、可疑测量值、可能原因和整改建议的 PDF 报告 | 交由产线经理审阅 |
这里有两个细节值得借鉴。第一，视觉检测智能体不仅输出“良品”或“不良品”，还要返回证据和不确定性，管理智能体才能据此决定走哪条路径。第二，根因分析可以由功能测试失败触发，即使光学检测没有发现可见缺陷，也不必依赖上一个专业智能体的结论。
根因分析智能体的取证过程同样清晰。对于疑似焊接缺陷，它先用回流焊进出炉时间定位炉温读数，再用 Kumo Anomaly 查找异常模式，并与其他批次、检测结果和机台手册比对。历史调查可以引导检索方向，但结论必须建立在当前程序和记录之上，这一点能降低沿用过时经验的风险。
还要注意，车队管理在参考流程中是在数字孪生环境里演示的。接入真实机器人和 AMR（自主移动机器人）时，必须另外完成工厂专属的设备集成，不能把仿真通过直接等同于产线可用。
如何设置多智能体的人工审核点
人工审核点不是越多越好。审核过密，操作员很快会疲劳并习惯性点“通过”；审核过少，错误动作又可能直接影响实体产线。结合 FOX 示例，可以用下表作为初版审核矩阵。
| 决策场景 | 示例中的处理 | 建议审核方式 | 建议审核人 |
|---|---|---|---|
| 疑似缺陷属于可接受偏差 | 返回证据，按工厂策略继续生产 | 策略放行，留存记录并抽查 | 质量工程师 |
| 视觉判定结论不明确 | 转人工复核 | 人工逐项判定 | 质检人员 |
| 已确认缺陷，需要搬运返修 | 初期部署要求操作员先批准 | 动作前审批 | 现场操作员 |
| 板卡维修与复测 | 由操作员完成后再包装 | 人工执行并记录结果 | 返修操作员 |
| 根因结论和整改建议 | 输出报告供产线经理审阅 | 报告审阅后再决定 | 产线经理 |
上表前两列来自官方示例，后两列是我们的落地建议。遇到矩阵之外的新决策时，可以依次问三个问题：
- 动作是否可逆？ 只读查询和生成报告容易撤销，移动实体板卡和修改工艺参数则代价更高。
- 影响范围有多大？ 影响单块板卡和影响整条产线，审批级别应当不同。
- 证据是否充分？ 证据冲突、数据缺失或模型明确表示不确定时，应转人工而不是继续推断。
审核规则最好不要只写在提示词里。FOX 用 OpenShell 这类策略层定义允许的操作和需要操作员审核的时机，这样即使模型判断有误，也不能绕过执行边界。提示词可以指导行为，真正的权限控制应由运行环境来兜底。
多智能体落地生产现场快速上手：6 步实施
FOX 目前以早期访问的形式提供，蓝图已包含不少模式，但工厂专属部分仍要由开发者完成。开始前先看清责任边界，可以避免把参考架构误认为开箱即用的产品。
| 模块 | 蓝图提供 | 开发者负责 |
|---|---|---|
| 管理智能体 | 含技能、工具、记忆和委派能力的持久环境 | 任务定义、完成标准、应用集成 |
| 工厂知识 | 数据接入与检索模式 | 标识、时间戳、单位和来源权限映射 |
| 专业智能体 | 检测、根因分析、报告、车队管理示例 | 工厂判定标准、新增角色、输出校验 |
| 设备集成 | MCP 与 API 模式，ROS 2 和 Isaac Sim 连接 | 实体设备连接和搬运策略 |
| 部署 | 服务、模型端点和可选仿真单元配置 | 资源选择、端点配置、访问边界检查 |
无论是否采用 FOX，都可以按以下 6 步推进：
- 选定单一闭环场景：从一个触发条件明确的流程开始，例如“AOI 告警到返修与根因报告”，同时写清完成标准。
- 统一数据主键：把 MES、ERP 和机台数据库映射到同一套标识，并保留时间戳、单位与来源引用，手册和 SOP 也要纳入可检索的知识库。
- 定义智能体输出契约：要求专业智能体至少返回结论、证据来源和不确定性，字段名可以自定，但必须能被程序校验。
- 落实最小权限：按角色分配工具和网络访问权限，例如根因分析只读生产记录，车队管理才可发起搬运，且需先通过权限和能力检查。
- 先在仿真或影子模式运行：让智能体给出建议但不实际动作，由人工结论作为对照，重点复盘误报、漏报和证据缺失。
- 逐步放开自动化：先采用动作前审批，等指标稳定且责任人确认后，再把低风险、可逆的动作改为策略放行和抽查。
每一步都建议留下审计记录，包括输入数据版本、调用工具、模型结论和审批人。官方示例让报告附带来源记录和可疑测量值，也是为了让审阅人能够验证结论，而不是只能选择相信或不相信。
多智能体的模型选型与接口配置
FOX 允许按部署要求选择前沿模型或开放模型，官方提到的例子包括 GPT-6 Astra 和 NVIDIA Nemotron。实际选型时，可以按角色拆开评估，不必让所有智能体共用同一个模型。
| 角色 | 模型关注点 | 官方示例能力 | 原型验证渠道 | 计费依据 |
|---|---|---|---|---|
| 管理智能体 | 规划能力、工具调用、长上下文 | GPT-6 Astra、NVIDIA Nemotron | 工厂内部端点、API易 apiyi.com 等 | 以实际端点的计费规则为准 |
| 专业智能体 | 按任务控制精度与成本 | 基于 LLM，并调用专用模型 | 工厂内部端点、API易等 | API易渠道以价格页为准 |
| 视觉与时序模型 | 领域精度、部署方式 | NVIDIA Cosmos、Kumo Anomaly | 优先按蓝图方案部署 | 按实际部署方案核算 |
接入建议：如果想先用脱敏数据验证 LLM 层的分工和提示词，可以通过 API易 调用本文涉及的模型。API易 兼容 OpenAI 与 Anthropic 接口格式，通常只需配置
api_key、base_url和model三项，具体地址和可用模型请查阅文档：https://docs.apiyi.com 。价格说明：模型价格、计费口径、输入输出单价和缓存价格，均以 API易 价格页的实际数据为准：https://docs.apiyi.com/models 。本文不列具体数字，建议估算时按管理层和专业层分别统计调用量。
常见问题 FAQ
Q1: 什么是多智能体中的管理智能体？
它是负责理解任务、制定计划、委派专业智能体并汇总结果的协调者。在 FOX 中，它还连接记忆、技能和工具，并在访问策略约束下长期运行。
Q2: 管理智能体和专业智能体有什么区别？
管理智能体关注“下一步做什么”，专业智能体关注“这件事的专业结论是什么”。前者掌握全局流程，后者只用限定的上下文、技能和工具完成聚焦任务，并把证据交回管理层。
Q3: 多智能体系统中哪些决策必须保留人工审核？
建议优先覆盖结论不明确的判定、实体设备动作、工艺参数变更和整改决策。官方示例明确要求不确定结果转人工，初期搬运前由操作员批准，根因报告交由产线经理审阅。
Q4: 工厂多智能体可以完全本地部署吗？
可以。FOX 支持在 NVIDIA DGX Station 上本地托管智能体环境、模型和数据存储。但完全本地部署要求所有模型与服务端点都位于工厂网络内，这样生产记录、图像、提示词和调查结果才能留在本地。
Q5: 如何通过 API 快速验证多智能体的分工设计？
可以先用脱敏样例搭建管理和专业两个角色，比较不同模型的任务拆解和工具调用效果。通过 API易 apiyi.com 能以 OpenAI 或 Anthropic 兼容格式接入，配置方法见 docs.apiyi.com。
Q6: 使用外部托管模型有哪些限制？如何估算成本？
使用外部模型时，必须评估哪些数据会发送到端点，涉及敏感生产数据的流程应先脱敏或改用本地模型。成本取决于调用次数和上下文长度，通过 API易 调用时，单价和缓存价格以 https://docs.apiyi.com/models 为准。
多智能体落地生产现场核心要点 Key Takeaways
- 管理智能体管流程：统一负责计划、委派、状态跟踪和结果汇总。
- 专业智能体管判断：按数据、验收标准和工具权限划分独立角色。
- 输出要带证据：结论必须附来源和不确定性，便于下游校验。
- 审核按风险设置：依据可逆性、影响范围和证据充分度分级。
- 权限靠策略兜底：把访问边界放在运行环境，不只依赖提示词。
- 仿真不等于量产：真实设备接入需要工厂专属集成和审批流程。
- 原型先验证分工：可用脱敏数据通过 API易 对比模型后，再确定部署方案。
总结
多智能体落地生产现场时，划分的核心是责任边界，而不是智能体数量：
- 管理智能体：掌握全局目标和任务状态，负责协调跨系统证据与下一步行动。
- 专业智能体：围绕明确任务调用专属模型和工具，并返回可验证的发现。
- 人工审核点：放在不确定结论、高风险动作和最终整改决策上，并由策略层强制执行。
建议先选一条触发明确的闭环流程，在影子模式下跑通数据、证据和审批链路，再逐步放开自动化。如果需要快速比较 LLM 层方案，可以通过 API易 apiyi.com 用统一接口做原型验证，生产阶段再按数据边界确定最终部署方式。
📚 参考资料
- NVIDIA 技术博客：How NVIDIA Factory Operations Blueprint Coordinates AI Agents to Investigate Production Issues
- 链接：
developer.nvidia.com/blog/how-nvidia-factory-operations-blueprint-coordinates-ai-agents-to-investigate-production-issues/ -
说明：本文中 FOX 架构、SMT 示例和部署方式的事实来源，发布于 2026 年 11 月 4 日。
-
API易 文档中心：接口接入说明
- 链接：
docs.apiyi.com -
说明：查询 OpenAI 与 Anthropic 兼容格式的具体配置方法。
-
API易 价格页：模型列表与计费数据
- 链接：
docs.apiyi.com/models - 说明：核实模型可用性、计费口径、输入输出单价和缓存价格。
作者：API易 技术团队
技术交流：欢迎在 API易 apiyi.com 网站首页联系我们，更多资料可访问 docs.apiyi.com 文档中心。
