跳到主要内容

FactVerse AI Agent 核心概念

FactVerse AI Agent 不是把工业数据接到自由聊天界面上。它是受治理的工具和上下文层。每个有效工作流都依赖租户上下文、资产上下文、scope、来源引用和审批边界。

运行模型​

客户端请求
  -> MCP endpoint
  -> API key 解析租户和 scope
  -> 可用工具
  -> FactVerse Platform、DFS、Designer、Inspector、知识或仿真服务
  -> 带来源上下文和治理边界的响应

客户端应在运行时发现可用工具。生成的参考文档描述了当前构建的公开目录，但实际可调用工具由部署配置和客户 scope 决定。

租户和资产上下文​

API key 解析租户。客户端不应发送租户标识来替代授权。租户解析后，每个工作流都应附带相关资产、站点、设施、产线、房间、设备或场景上下文。

好的 Agent 输出通常包含：

  • 正在讨论的资产或场景；
  • 使用了哪些来源系统；
  • 数据时间戳或新鲜度；
  • 缺失证据或质量提示；
  • 输出类型是草稿、分析、建议还是已批准动作。

Endpoint、slice 和 scope​

FactVerse 通过受治理的 slice 暴露工具。每个 slice 有独立 endpoint。Scope 决定可以调用哪些工具。

SliceEndpointScope 示例说明
Base/mcp/base/base.read, base.compute.run, base.action.write通用资产读取、知识、数据质量、仿真、优化和受控写操作。
预测性维护/mcp/pdm/pdm.read设备健康度、摘要、异常和组件智能。
交通运营/mcp/trafficops/trafficops.read人流、车流、检查点和交通运营工具。
通信运营/mcp/telcoops/telcoops.read网络健康和容量工具。
半导体运营/mcp/semiops/semiops.read洁净室、厂务、utility、SMT 和环境工具。
航空/mcp/aviation/aviation.analysis.read航空可靠性分析工具。

已退役的 physical endpoint 不应再用于新工作。Physical AI 工作流应使用当前 endpoint，以及 Designer、SimReady asset 和仿真工具链。

工具调用和来源引用​

工具调用应被视为对产品能力的受控访问，而不是直接数据库访问。工作流应保留足够来源上下文，让人工复核者理解 Agent 为什么生成这个结果。

例如：

  • 设施运营应引用资产、表计、巡检记录和工单。
  • 预测性维护应引用信号历史、数据质量、资产历史和维护证据。
  • Physical AI 应引用场景版本、资产版本、仿真假设和验证说明。

数据就绪度​

Agent 质量受来源数据就绪度限制。承诺工作流前，需要确认：

领域问题
Platform 资产资产、位置、责任人和权限是否建模？
DFS 数据来源系统是否已接入、转换并完成质量检查？
Inspector 记录巡检、告警、工单和操作员备注是否可用？
Designer 场景场景、资产和关系是否有版本并可使用？
文档手册、SOP 和流程资料是否对该租户和 scope 可访问？

如果数据缺失，Agent 应报告缺口，而不是用无依据假设补齐。

读取、计算和写操作边界​

调查使用 read scope。仿真、优化、预测和对比使用 compute scope。只有在部署策略允许时，才使用 write scope 执行受控动作。

写操作需要额外控制：

  • 写操作必须明确，不能隐藏在分析步骤里；
  • 除非客户批准自动化，否则应先创建草稿；
  • 应记录在 Inspector 或客户运营系统中；
  • 应包含足够证据，供负责的操作者或主管审批。

数字孪生和仿真上下文​

Agent 工作流中的数字孪生不只是视觉参考。它承载空间上下文、资产关系、行为假设和运营含义。

Physical AI 和面向仿真的工作流应保留这些版本：

  • Designer 场景；
  • SimReady asset；
  • 运营约束；
  • 仿真配置；
  • 验证结果；
  • 现场反馈。

这样可以发挥快速仿真的价值，同时避免夸大确定性。真实现场变更仍然需要工程评审和客户批准。

治理模式​

完整工作流应遵循以下模式：

  1. 解析租户、资产、endpoint 和 scope。
  2. 获取允许访问的数据、文档、场景和工具。
  3. 生成带来源引用和假设说明的分析。
  4. 写操作保留审批和审计。
  5. 记录完成的工作和现场反馈。
  6. 用反馈改进后续分析。

后续编写工作流指南、集成指南和故障排查页时，应以这个模式为基线。