TRUEFOUNDRY ENTERPRISE AI GOVERNANCE
企業 AI 進入正式環境後，需要管理的不再只有模型，而是模型、工具與 AI Agent 的完整執行鏈。
TrueFoundry 透過 AI／LLM Gateway、MCP Gateway 與 Agent Gateway，分別處理模型路由、工具存取及 Agent 身分與執行治理。企業可依現有架構與風險逐步導入，不必在專案初期一次建置所有能力。
- 01 AI Gateway 管理模型
- 02 MCP Gateway 管理工具
- 03 Agent Gateway 管理 Agent
PRODUCTION GOVERNANCE
企業 AI 的難題，正從模型呼叫轉向生產治理
當 AI 應用從單一模型實驗發展為多模型、多工具與多 Agent 架構，企業需要管理的不只是 API 連線，而是模型路由、身分權限、成本歸屬、工具操作及完整執行軌跡。
AI 專案初期，開發人員可能只需要一組 API Key、少量程式碼與一個模型，就能完成問答機器人或內部知識助手。此時團隊通常關注模型回答品質、Prompt 設計與 RAG 資料召回效果。
但當應用開始服務真實使用者，並與企業資料、工單、CRM、程式碼平台及內部 API 連接後，問題會迅速擴大。
模型接入分散
不同應用分別維護模型名稱、SDK、API 位址與存取金鑰，切換模型時需要修改多套程式。
缺少容錯策略
主要模型發生限流、逾時或服務異常時，應用可能需要人工修改設定或重新部署。
模型升級難以驗證
新模型即使具備較佳效果，也需要先透過部分真實流量驗證品質、延遲及成本。
Agent 開始執行操作
Agent 不只產生文字，也可能查詢資料、更新工單或呼叫企業系統，錯誤判斷可能轉為實際操作。
成本與責任難以追蹤
管理者需要知道哪些團隊使用了哪些模型與工具、產生多少費用，以及異常操作如何發生。
因此，企業需要的是一個能集中治理模型、工具與 AI Agent 的入口，將原本散落在各應用中的重試、路由、存取權限、費用追蹤與稽核能力，整理成一致的治理策略。
THREE GOVERNANCE LAYERS
TrueFoundry 三層 Gateway 分別管理什麼？
AI／LLM Gateway 管理模型流量；MCP Gateway 管理 Agent 可使用的工具；Agent Gateway 管理 Agent 身分、入口、會話與執行紀錄。三者處理的治理對象不同，不能互相完全取代。
| 治理層 | 管理對象 | 主要處理問題 | 典型能力 |
|---|---|---|---|
| AI／LLM Gateway | 模型、模型供應服務與推論流量 | 應用使用哪個模型，以及如何穩定、安全且可控地呼叫 | 統一 API、模型路由、Fallback、限流、成本與 Guardrail |
| MCP Gateway | MCP Server、企業工具與資料來源 | Agent 可以呼叫哪些工具，以及使用什麼身分與權限 | 工具註冊、身分驗證、權限、憑證管理及稽核 |
| Agent Gateway | AI Agent、使用者、會話與執行流程 | 企業中有哪些 Agent、誰能呼叫，以及執行過什麼 | Agent 身分、統一入口、會話治理、執行追蹤與可觀測性 |
管理 Agent 使用哪個模型。
管理 Agent 可以使用哪些工具。
管理有哪些 Agent 及其執行過程。
MODEL GOVERNANCE
AI／LLM Gateway：統一管理 Agent 使用的模型
TrueFoundry AI Gateway 位於應用與模型服務之間，透過統一介面、Virtual Model、路由及治理策略，降低應用對特定模型名稱、供應來源與 API 位址的直接依賴。
Virtual Model 如何降低模型切換成本？
如果應用直接呼叫特定模型，模型名稱、API 位址與存取方式便會寫入應用設定。當企業更換模型、調整供應來源或新增備援模型時，可能需要逐一修改與重新部署應用。
TrueFoundry 的 Virtual Model 提供穩定的邏輯模型名稱。應用只需要呼叫例如
support/production-chat，實際連接的模型、供應來源、權重與路由規則則由 Gateway 管理。
常見模型路由策略
優先順序路由
優先呼叫主要模型；符合設定的錯誤條件時，再轉向備援模型。
權重路由
依比例分配模型流量，可用於新舊模型灰度驗證或不同服務間的流量配置。
延遲路由
依模型服務的回應延遲與健康狀態，選擇適合的後端目標。
複雜度路由
依請求複雜程度，將任務分配至不同層級與成本的模型。
模型接入後還需要哪些治理能力？
- 依使用者、團隊、應用或模型設定存取權限。
- 配置取用頻率限制、Token 額度與預算規則。
- 追蹤請求量、失敗率、延遲、Token 與推論成本。
- 在模型輸入與輸出套用 PII、Prompt Injection 與內容政策。
- 依企業政策決定日誌保留範圍及敏感內容遮罩方式。
若需要進一步評估模型接入、路由、容錯與成本治理，可前往 TrueFoundry AI／LLM Gateway 解決方案 。
TOOL GOVERNANCE
MCP Gateway：管理 Agent 可使用的工具與資料
MCP 解決模型與工具之間的標準連接問題；MCP Gateway 則補上企業正式環境需要的工具註冊、身分驗證、權限控管、憑證管理、操作稽核與敏感資料防護。
當 AI 應用只產生文字，風險主要停留在回答內容。但 AI Agent 需要完成任務，可能會讀取 CRM、查詢庫存、建立工單、操作資料庫，或呼叫 GitHub、Jira 與企業內部 API。
MCP 提供標準化的工具連接方式，但「可以連接」不等於「已具備企業治理」。當 MCP Server 與工具數量增加，企業仍需要回答下列問題：
哪些工具已獲准進入正式環境？
哪些 Agent 或團隊可以使用？
呼叫時採用使用者還是 Agent 身分？
第三方憑證應存放在哪裡？
哪些參數或操作需要阻擋？
異常工具呼叫如何還原與稽核？
工具執行前後都需要檢查
工具執行前
- 驗證使用者與 Agent 身分
- 確認工具及資料存取權限
- 檢查危險參數與越權要求
- 限制不允許的 SQL 或操作
工具執行後
- 檢查工具回傳資料
- 遮罩金鑰與個人資訊
- 阻擋敏感資料繼續傳給模型
- 保留工具呼叫與結果紀錄
進入 Agent 應用後，安全治理不能只檢查模型說了什麼，也要確認 Agent 準備執行什麼，以及工具實際回傳了哪些內容。更多工具註冊、認證與稽核能力可參考 TrueFoundry MCP Gateway 。
AGENT GOVERNANCE
Agent Gateway：管理 Agent 身分、入口與執行軌跡
Agent Gateway 面向的是 Agent 本身的治理，包括 Agent 身分、負責人、呼叫權限、統一入口、會話及執行追蹤；它不是替企業設計 Agent 決策邏輯，也不等同於新的 Agent 開發框架。
當企業只有一個實驗性 Agent，開發團隊通常可以直接維護。但當客服、研發、資料分析及維運 Agent 陸續進入正式環境後，企業需要建立一致的 Agent 資產與執行管理方式。
Agent 身分
辨識 Agent 名稱、用途、負責團隊、版本及授權範圍。
呼叫權限
管理哪些使用者、應用或其他 Agent 可以呼叫特定 Agent。
會話管理
追蹤一次會話經歷哪些模型判斷、工具呼叫與狀態變化。
執行追蹤
發生錯誤結果或異常操作時，還原 Agent 的完整執行軌跡。
如果企業已經有多個 AI Agent，並需要統一管理身分、呼叫入口與執行紀錄，可參考 TrueFoundry Agent Gateway 。
END-TO-END FLOW
三層 Gateway 如何形成完整治理鏈？
在一次完整 Agent 任務中，Agent Gateway 負責入口、身分與會話；AI Gateway 負責模型選擇與推論流量；MCP Gateway 負責工具存取。三層紀錄共同提供成本、操作與責任追蹤。
-
01
使用者呼叫售後 Agent
Agent Gateway 識別呼叫者、Agent 身分與授權範圍，並建立會話。
-
02
Agent 呼叫 Virtual Model
AI Gateway 依既定策略，將邏輯模型名稱路由至適合的實際模型。
-
03
處理模型限流或異常
主要模型發生特定錯誤時，Gateway 依設定執行重試或切換備援目標。
-
04
判斷需要查詢設備資料
Agent 透過 MCP Gateway，要求呼叫經過註冊的設備檔案或維修紀錄工具。
-
05
驗證工具權限與參數
MCP Gateway 檢查身分、工具權限與輸入參數，並在執行後檢查回傳內容。
-
06
取得授權後建立工單
Agent 根據資料產生建議，並依企業政策與授權流程建立或更新工單。
-
07
保留治理與可觀測資料
模型請求、工具呼叫、成本、策略命中與 Agent 執行軌跡分別留下紀錄。
模型路由無法解決工具越權；工具存取權限也無法取代 Agent 身分、會話及行為追蹤。三者需要在同一治理架構下協同，但仍各自負責不同對象。
PLATFORM STRATEGY
為什麼不把路由、限流與權限全部寫在應用程式裡？
單一實驗性應用可以自行實作重試、限流、日誌與權限；但當應用數量增加，各團隊獨立維護容易形成不同標準。Gateway 的價值，是將共用治理能力從業務程式中抽離並集中管理。
| 比較項目 | 各應用自行實作 | 集中式 Gateway |
|---|---|---|
| 模型切換 | 可能需要修改多套應用設定 | 由集中路由與 Virtual Model 調整 |
| 錯誤處理 | 每個團隊自行定義重試與切換條件 | 使用一致的重試與 Fallback 策略 |
| 權限標準 | 權限分散在不同應用與服務 | 集中管理模型、工具與 Agent 存取 |
| 成本歸屬 | 需要額外彙整不同應用與供應來源 | 依團隊、使用者、應用或模型追蹤 |
| 稽核追蹤 | 日誌格式、保留範圍與欄位可能不同 | 建立一致的可觀測與稽核入口 |
Gateway 不會取代應用本身的業務邏輯。Agent 如何判斷、何時需要人工核准，以及哪些操作屬於企業流程，仍應由應用與業務系統負責。
ADOPTION ROADMAP
企業應如何分階段導入三層 Gateway？
三層治理是一條架構演進路徑，不代表每個 AI 專案都必須一次導入完整平台。企業應從目前已經出現的治理問題開始，逐步增加需要的能力。
單模型與概念驗證
先確認使用情境、資料品質與模型效果，不必為尚未出現的規模問題過度設計。
優先工作：業務價值驗證多模型正式接入
開始處理模型切換、容錯、灰度驗證、成本歸屬與統一存取控制。
優先評估：AI／LLM GatewayAgent 開始使用工具
Agent 存取資料庫、SaaS 或企業 API，需要工具註冊、權限與稽核。
優先增加：MCP Gateway多個 Agent 進入生產
建立 Agent 身分、資產清單、統一入口、會話管理與執行追蹤。
進一步評估：Agent GatewayGateway 能解決與不能直接解決的問題
Gateway 可協助
- 模型與工具的統一接入
- 路由、重試與容錯切換
- 權限、限流與成本治理
- 模型、工具及 Agent 可觀測性
- 集中式安全政策與稽核
Gateway 不會取代
- RAG 資料品質與召回調整
- Prompt 設計與模型評測
- Agent 業務決策邏輯
- 人工核准與企業作業流程
- PoC、壓力測試與驗收標準
DEPLOYMENT OPTIONS
部署環境、資料邊界與治理策略
AI Gateway 的部署方式應配合企業網路、模型位置、資料敏感度及維運責任。VPC、地端與多雲部署並不是單純的功能選項，而是整體資安與資料治理設計的一部分。
企業雲端環境
將 Gateway 部署於企業控制的雲端網路，配合現有身分、網路與監控架構。
地端部署
適合需要控制資料流向、內部模型存取或既有地端系統整合的企業。
多雲與混合架構
統一管理不同雲端、模型服務及內部環境，同時維持一致的治理政策。
模型請求是否包含敏感資料、日誌是否記錄 Prompt 與回應、第三方模型位於哪個區域、憑證如何保存，以及 Gateway 故障時的備援與復原方式。
FAQ
TrueFoundry AI 閘道器常見問題
AI Gateway、MCP Gateway 與 Agent Gateway 有什麼差異？
AI Gateway 管理模型接入、路由、容錯、成本與模型安全政策；MCP Gateway 管理 Agent 可以使用的工具、身分、權限及工具呼叫稽核；Agent Gateway 則管理 Agent 身分、統一入口、會話及執行追蹤。
企業只有一個模型時需要導入 AI Gateway 嗎？
不一定。若仍處於低流量概念驗證，而且沒有模型切換、集中權限、成本歸屬或稽核需求，可以先驗證業務價值。當模型、應用與團隊數量增加，再評估集中式 Gateway。
AI Gateway 可以在主要模型故障時自動切換嗎？
可以依設定的錯誤碼、重試次數與 Fallback 條件切換至其他模型目標。但切換是否符合服務品質，仍需要針對模型相容性、回應格式、延遲與失敗條件進行 PoC。
MCP 已經是標準協定，為什麼還需要 MCP Gateway？
MCP 定義模型與工具的連接方式，但不會自動完成企業所需的工具註冊、身分整合、細部權限、憑證保存、敏感參數檢查及集中稽核。MCP Gateway 提供的是生產治理層。
Agent Gateway 等同於 Agent 開發框架嗎？
不等同。Agent 開發框架負責 Agent 邏輯、流程與工具使用方式；Agent Gateway 著重 Agent 身分、呼叫入口、會話、權限及執行追蹤，兩者處理的問題不同。
導入 Gateway 能直接改善 RAG 或模型回答品質嗎？
不能直接改善。Gateway 可以統一模型存取、路由、治理及觀測，但 RAG 資料品質、檢索策略、Prompt 設計與模型評測仍需要另外優化。
TrueFoundry 是否支援 VPC、地端與多雲部署？
TrueFoundry 可依企業需求規劃不同部署環境。實際架構仍需確認模型所在位置、企業網路、資料邊界、身分系統、日誌政策與高可用需求。
TRUEFOUNDRY AI GATEWAY
從現有 AI 架構開始規劃治理範圍
若企業正在面對多模型接入、模型容錯、Token 成本、MCP 工具安全或多 Agent 執行追蹤問題，可先整理目前架構、使用情境與治理缺口，再透過 Demo 或 PoC 驗證所需能力。
- 目前使用的模型與供應服務
- 應用、團隊與流量規模
- MCP Server 與工具清單
- 權限、日誌與資料邊界要求
- 容錯、延遲及成本驗收指標
