從單一應用到平台基礎設施
InfoQ 於 2026 年 10 月刊登的《The Platform Engineering Playbook for Production LLMs》，作者 Aditya Mulik 整理了大型零售企業庫存準確度平台的實作經驗。該平台以多代理 LLM 系統分析數百萬個庫存單位（SKU）的差異訊號，並從數十億筆歷史庫存紀錄產生修正建議，服務庫存稽核、補貨審查與差異分流等場景。上線第一個月，約百分之十五的代理回應是幻覺，也就是聽來自信卻毫無事實依據的輸出。六個月後降到百分之一點五，而真正推動變化的不是更強的基礎模型，而是團隊決定不再把 LLM 堆疊當成應用內部問題，改以平台基礎設施的方式經營。
這個轉變的核心主張是，幻覺率是平台可控的指標。把模型包進能即時攔截格式、接地與基礎設施錯誤的自動重試迴圈，即使不動基礎模型，生產環境的幻覺率也能大幅下降。
生產環境才浮現的三類失敗
beta 測試期間出現三類問題，每一類都對應原型從未壓力測試過的部分。首先是模型供應商的 API 限流，在真實請求量下開始被擋。其次是脈絡品質：當系統推薦不合適的商品，根因幾乎都在餵給模型的資料，而非模型本身，這讓穩健的資料工程管線成為修復重點。第三是幻覺，個別發生很罕見，但在生產流量下會變成穩定比率。
這些問題說明了為何它們屬於平台層。幻覺不是堆疊追蹤，它會通過所有傳統健康檢查，被下游服務消費並據以行動，很久之後才有人發現建議內容不存在。缺乏逐請求歸屬時，Token 帳單只是供應商寄來的一行數字，無法判斷哪個應用或團隊在燒錢。行為層面同樣沒有可觀測性：延遲儀表板顯示 p99 正常、錯誤率接近零，模型卻可能默默產出語法正確、品質下滑的內容。作者指出，建置平台的決策點不是第一個 LLM 應用，而是第二個；等到十個團隊各自出貨才補平台，就會變成漫長的遷移工程。
平台架構與結構化輸出
平台以單一閘道為唯一入口，負責驗證呼叫者、簽發攜帶角色的 JWT（JSON Web Token，可自我描述身分與權限的權杖）、提供個人與團隊指標，以及托管僅限管理員的提示回復路由。閘道之後是以 Google Agent Development Kit（ADK，代理與子代理的編排框架）建構的根協調者，逐輪分類意圖並委派給專門代理。每個專門代理綁定由註冊表解析的提示與結構化輸出綱要，並持有工具連線。
工具以多個獨立 MCP 伺服器（Model Context Protocol，讓模型以標準介面呼叫外部工具的協定）形式存在，依團隊切分，每台伺服器自行驗證權杖、檢查授權政策後才執行工具。模型存取統一經過 LiteLLM，這是讓供應商可替換的接縫：同一份代理程式碼在本機執行由 Ollama 提供的 llama3.1，在生產環境執行 Gemini 或 GPT，差別只在模型識別碼，因此整個堆疊能在零 API 成本下端到端執行。沒有任何單一框架擁有整個堆疊，模型層、工具層與編排層都位於穩定介面之後，可個別替換。
團隊認為最具成本效益的改動，是在平台邊界而非應用邊界強制結構化輸出。每次呼叫宣告目標綱要（以 Python 的 Pydantic 描述），平台驗證後才交還呼叫者；失敗就把驗證錯誤當成額外脈絡重新提示，直到可設定上限。如此一來，一次實作處理所有綱要不符，策略改善全體受惠；只要呼叫有回傳，回應形狀就有保證；綱要違規成為平台指標，而非埋在日誌裡的例外。文件代理的綱要包含 answer、sources、grounded 與 out_of_scope，後兩個旗標成本為零，卻迫使模型以機器可讀形式表態答案是否有檢索到的脈絡支撐。
接地不是提示技巧而是管線。工具結果是模型唯一被允許使用的證據：文件代理必須先用解析工具把函式庫名稱換成識別碼，再抓取官方文件，且每一項主張、範例與參數名稱都須來自抓取內容，文件沒涵蓋就必須明說。工具取證、提示限制、綱要宣告與驗證計數，構成完整的鏈路。
分級重試：幻覺率從 15% 降到 1.5%
大多數降幅來自這一層。盲目重跑失敗的呼叫是有害的：重複已產生幻覺的提示只會得到另一個幻覺，服務中斷期間的無腦重試則會製造流量風暴。因此必須先分類失敗：綱要違規、幻覺訊號（低信心、缺乏接地或偏離意圖），或基礎設施錯誤（逾時、限流、模型不可用）。三類要有三種反應。綱要違規把錯誤附加後重新提示；幻覺訊號用更強的接地脈絡重新提示；基礎設施錯誤採指數退避。
重試預算須逐請求設上限，否則單一壞請求可能無限重試、拉高帳單。最簡單是固定次數，團隊用三次，因為結構化輸出若到第三次仍未修好，第四次幾乎不會修好；也可限制單一請求的總 token 數，控制的是實際成本；或用時間上限，適合速度優先的情境。重點是上限存在且被強制執行。
實作上，代理包裹自己的執行迴圈，攔截驗證錯誤、記錄為幻覺，重試到上限後才重新拋出例外，確保呼叫者不會收到靜默損壞的內容。工具呼叫失敗走另一套機制：MCP 工具出錯時，原始失敗訊息直接餵回模型脈絡讓它自我修正，這段交由 ADK 內建外掛處理。這一層追蹤兩個指標：復原率確認重試有效，放大係數確保成本仍可負擔。
提示版本、意圖閘門與授權
提示是可執行的文字。兩段只差一句的提示，可能有明顯不同的幻覺率、延遲與 token 成本，而且沒有編譯器會警告新版本更糟。平台要求每個提示都有 ID 與版本，能獨立於應用程式碼部署，應用只以 ID 引用。回復不是刪除，而是把生效指標重指舊版本，歷史完整保留。真正讓回復免重新部署的細節在代理端：代理在執行期才向註冊表解析指令，因此管理者呼叫回復端點後，下一個請求的行為就改變，而該端點同樣受角色權限保護。作者坦言記憶體版註冊表只適合展示與本機開發，生產環境須在相同介面後接上資料庫，並為開發、預備與正式環境各自綁定版本。
意圖驗證閘門在昂貴的模型呼叫前先回答：這個請求是否落在平台能服務的範圍內，該由哪個專門代理處理？生產環境使用小型分類器，儲存庫則刻意以確定性的關鍵字規則實作。最關鍵的行為是，沒有規則達標時回傳「unclassified」，而不是預設挑選最高分的代理。一般路由器即使只有微弱匹配也硬塞請求，正是代理處理不該處理的問題而產生幻覺的途徑。明確標示未分類，讓平台能拒絕、請使用者釐清，或退回嚴格受限的搜尋；同時因為事先挑對工具與提示，縮小了模型的搜尋空間，脈絡也更精簡具體。
多團隊部署中，比提示注入更重要的問題是：哪個呼叫者可以呼叫哪個工具？這是 RBAC（角色為基礎的存取控制），屬於平台層，且應在資源伺服器端執行。平台以 PyJWT 簽發無狀態 JWT，權杖以 claim 攜帶角色，任何持有共享密鑰的服務都能自行驗證。權限放在 YAML 設定檔並採預設拒絕，安全調整只需改設定。作者最堅持的是執行位置：每台以 FastMCP 建構的 MCP 伺服器都是獨立資源伺服器，在每次工具執行前自行驗證權杖與政策；若只在閘道檢查一次就信任下游，編排器裡任何一個小 bug 都可能一次暴露所有連接的工具。
可觀測性、評估與限制
標準 APM 是最昂貴的錯誤。延遲、錯誤率與吞吐量只能說明模型是否可達，無法說明它是否行為正確。生產 LLM 系統需要的是：幻覺率（格式違規加接地失敗），依應用與提示版本追蹤；提示漂移，也就是跨版本的行為變化率；依團隊、應用與場景拆解的 token 支出；工具呼叫模式，即哪些代理以什麼順序呼叫哪些工具、失敗與拒絕率如何；以及針對抽樣生產流量的離線行為評估。
讓「依團隊」可行的關鍵，是團隊維度必須從第一次呼叫就存在，事後無法從日誌重建。收集器從已驗證角色推導團隊，並在請求入口以脈絡變數承載，因此每筆紀錄都可歸屬。Token 成本在每一處模型呼叫點記錄，一個扇出到四個專門代理的請求會把四次呼叫都歸給同一使用者與團隊；本地 token 估算與實際計費資料分開追蹤，指標以 OpenTelemetry 輸出但包在自訂方法裡，以便不碰應用程式碼就替換後端。
單元與契約測試能釘住確定性路徑，卻回答不了最重要的問題：模型還在正常行為嗎？評估層由黃金集、執行器、評分指標與通過門檻組成。黃金集是資料而非程式碼，每個案例固定使用者請求、應遵循的工具軌跡、應回傳的回應與請求角色；在生產環境中它是成長最快的資產，每次觸及使用者的故障都成為新案例。執行器是 ADK 的 AgentEvaluator，每案重複多次取平均，因為模型具隨機性。儲存庫要求跨次執行的工具軌跡平均分數至少零點八，低於此即失敗，而該數字刻意放在三行設定檔中，使收緊標準成為可審查的變更。評估在持續整合中分兩條路徑：快速封閉測試於每次推送時把關合併，需要真實模型與工具伺服器的評估則作為獨立觸發的工作，把關提示的晉升。
作者最後給出六項依優先順序排列的決策：在第一次生產部署前就建好可觀測性，而非等第一次事故；在第二個應用前就採用平台思維，而非第十個；從第一天為提示加上版本；在第一次呼叫就在平台邊界強制綱要；從一開始就標記成本歸屬；在第一次修改提示前就為每個專門代理建立黃金集。貫穿其中的主線是，LLM 系統允許你以傳統系統辦不到的方式延後基礎設施決策，它們不會崩潰、不會回傳 500 錯誤，只會安靜地產出稍微差一點的輸出。錯誤決策與可見後果之間的落差，正是平台思維必須提前投入、事後補救代價高昂的原因。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。