跳至主要内容

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. 用回饋改進後續分析。

後續編寫工作流指南、整合指南和故障排查頁時，應以這個模式為基線。