東南亞領先的乘車與外送平台 Grab 在將 AI Agent（AI 代理，指能自主使用工具完成複雜任務的 AI 系統）推向生產環境時，發現了一個關鍵的工程痛點：開發一個 AI 代理的推理邏輯（Reasoning Loop）可能只需要一個下午，但將其封裝成可生產的服務，包含處理機密資訊、追蹤日誌、服務發現與評估機制，卻往往需要兩週甚至更長時間。這種現象揭示了 AI 應用開發中，真正的成本不在於模型本身，而是在於周邊的基礎設施建設。
為了打破這種重複造輪子的困境，Grab 開發了一套內部框架 LLM-Kit。這套框架的核心目標並非創造一種新的 AI 抽象層或特定領域語言，而是將公司現有的基礎設施進行標準化整合，將原本分散在各個服務中的重複性工作集中化。透過 LLM-Kit，Grab 已經將超過 500 個內部代理服務標準化，這些服務每天服務數百萬名商家、司機與消費者。
LLM-Kit 的運作方式是提供一套預先配置好的腳手架。工程師只需填寫申請表單，系統便會自動生成一個 GitLab 儲存庫，其中包含一個基於 FastAPI（一個高效能的 Python 網頁框架）的服務。這個服務在初始提交時就已經內建了 LangGraph（用於構建循環圖結構的 AI 代理框架）模組、OpenTelemetry（一套標準化的可觀測性框架，用於追蹤分散式系統的請求路徑）、Vault（用於安全管理機密金鑰與憑證的工具）以及服務發現機制。此外，它還內建了評估端點，能利用 ROUGE 和 BLEU 等文本相似度指標，以及由另一個模型擔任評分員的機制，即時評估 AI 回答的品質。
在功能擴展與模型管理上，LLM-Kit 採取了高度解耦的設計。首先，它引入了 Model Context Protocol（MCP，模型上下文協定），這是一種讓 AI 模型能以標準化方式存取外部數據與工具的協定。代理服務不需要在程式碼中預先寫死工具，而是在執行時從超過 50 個已註冊的 MCP 伺服器中動態獲取能力。這意味著一旦某個新功能被註冊到 MCP 伺服器，所有使用該框架的代理都能立即獲得該能力，無需重新部署。
其次，為了避免被特定模型供應商綁定，Grab 建立了 GrabGPT Gateway。所有模型調用都必須通過這個相容於 OpenAI API 的統一閘道器。該閘道器對接了五個不同的模型供應商，並在後端自動注入憑證。開發人員在撰寫應用程式碼時，完全不需要接觸供應商的金鑰或特定 API 格式，只需透過配置即可切換模型，極大地提升了系統的靈活性。
Grab 在設計時刻意選擇開發框架（Framework）而非封閉平台（Platform）。他們認為，平台往往會強加僵化的假設，隨著技術演進很快會過時；而框架則能在不限制開發者習慣的前提下，提供必要的基礎設施支援。這種策略有效地降低了所謂的代理鎖定（Agentic AI Lock-in）風險。分析師曾指出，AI 代理的鎖定比單純的 API 鎖定更嚴重，因為它同時發生在模型、框架、執行環境與開發模式等多個層面。Grab 透過閘道器解決模型層鎖定，透過 LLM-Kit 標準化執行環境，將複雜度從單個服務移轉到集中管理的基礎設施層。
此外，Grab 的資安團隊還推出了 Palana 系統，讓團隊在實驗自主代理時，仍能維持對身分識別、機密資訊、網路存取與操作可視性的控制，確保 AI 代理在自動化執行任務時不會造成安全漏洞。
從 LLM-Kit 的實踐中可以發現，當 AI 代理的數量從個位數成長到 500 個時，挑戰會從如何構建單個代理，轉移到如何管理整個代理生態系。目前的解決方案已從單純的框架演進為平台化管理：透過閘道器管控模型使用、透過 MCP 實現工具共享、透過評估平台監控提示詞（Prompt）變更的效果。
對於許多企業而言，Grab 的經驗提供了一個重要的啟示：如果開發 AI 功能的核心邏輯只需要一天，而部署周邊的基礎設施卻需要兩週，那麼研發的重點不應放在選擇哪個 AI 函式庫，而應放在誰來管理機密資訊、追蹤日誌與品質評估。目前市場上如 Amazon Bedrock AgentCore 或 Google Agent Runtime 等產品，正試圖將這些基礎設施能力商品化，讓企業能更快速地將 AI 代理從實驗室推向生產環境。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。