為什麼優秀的人工智慧代理 (AI Agent) 會在正式環境中失敗：缺失的基礎架構層

第一個警示在 6:00上午 觸發。接著是第二個。然後是第三個。

值班工程師打開筆記型電腦，發現單一人工智慧代理程式有三個不相關的故障。該代理程式負責處理支援票證、執行帳單調整，並回答客戶問題。它在 LangChain 上執行。它在預備環境 (staging) 中通過了所有測試且運作正常——直到它出錯為止。

我曾見過許多團隊投入數個月的時間進行提示工程 (prompt engineering) 和模型選擇，最後卻得花掉整個週末來清理與這兩者都無關的事件。隨之而來的失敗並非虛構。當代理程式在缺乏必要基礎架構支援的情況下首次進入生產環境時，就會發生這類問題。而我尚未見過任何能提供這類基礎架構的框架——即生產部署所需的身分邊界、安全性執行以及營運治理。

43 張重複的支援票證

該代理程式（一種能針對目標進行推論、選擇工具並自主採取多步驟行動的人工智慧系統）當時正在監控支援佇列。客戶提交了一個案例。代理程式呼叫票證 API 以建立記錄，API 接受了請求並建立了票證。但隨後回應逾時。

從代理程式的角度來看，該呼叫失敗了。LangChain 執行了任何設計良好的框架在工具呼叫失敗時會做的動作：重試。重試建立了第二張票證。回應再次逾時。再次重試。另一張票證。

到 6:00上午，系統中已有 43 張重複的票證。每張票證都觸發了一封自動確認電子郵件，這意味著有 43 封訊息進入了客戶的收件匣。支援團隊花了一個上午的時間手動關閉重複項並致歉，而不是處理實際工作。

我想要準確說明這裡出了什麼問題，因為這至關重要。LangChain 正確處理了這個問題。框架偵測到失敗的回應並重試呼叫。這正是重試邏輯的用途。問題不在於重試，而是在於基礎架構中沒有任何機制追蹤原始請求是否成功。沒有冪等性包絡（一種確保重複請求產生與原始請求相同結果的機制，可防止重複）。沒有去重複層。平台層級無法感知到這是對已經完成操作的重試。

對於任何進行計算的決策者來說：這裡的成本不僅僅是一個令人難堪的早晨。成本包括支援人員用於清理工作的工時、因機器人發送重複電子郵件而受損的客戶信任，以及在人工稽核每張未結案工單之前，無法被信任的系統。對於任何閱讀重試邏輯的開發人員來說，程式碼是正確的。差距就在其底層。

該框架完成了任務。周圍的基礎架構根本不存在。

US$4,000 的金額記錯了帳戶

基礎架構的缺口可能震耳欲聾（像 43 張工單那樣吵雜），但也可能悄無聲息。同一個人工智慧 (AI) 代理程式處理了計費調整。它在部署期間可以存取使用服務帳戶佈建的計費 API。服務帳戶可以存取多個計費帳戶，因為這是讓代理程式在開發階段執行的最快方式。沒有人在將代理程式提升到生產環境之前先界定憑證範圍，因為沒有人建立身分界限——這是一種根據經過驗證的身分（而非僅僅是組態）來控制特定工作負載可存取哪些資源的基礎架構層。

代理程式需要處理帳戶 A 的扣款，其提示中包含了帳戶識別碼。模型選擇了帳戶 B，這對於任何大型語言模型 (LLM) 來說都是一個可能的錯誤。計費 API 接受了呼叫，導致 US$4,000 的費用扣到了錯誤的客戶身上。

這不是模型故障。LLM 會產生看似合理的輸出，但有時會出錯。可能的原因是同一個計費 API 使用了錯誤的帳戶參數，這是一個可能的選擇錯誤。

在傳統軟體中，路由錯誤的 API 呼叫所產生的潛在影響受限於兩個層級：憑證範圍界定限制了工作負載可以存取的服務，而下游 API 則會強制執行哪些參數對給定的呼叫者有效。開發人員永遠不會發布一個僅用一組憑證就能寫入所有客戶計費記錄的網頁應用程式，但這正是這裡發生的情況。

該代理程式獲配的憑證權限過大，足以存取系統中的任何帳號，且整個技術架構中——無論是平台本身還是下游 API——都沒有對該權限範圍進行任何限制。目前沒有框架提供憑證範圍界定。沒有框架提供加密工作負載身分，或根據基礎架構層級的原則（而非提示內容）強制執行代理程式可以存取的服務。

直到下週一有人審查發票時，才有人注意到這一點。我看過各種規模的此類失敗案例——雖然細節有所不同，但根本原因始終如一。代理程式擁有了不該持有的憑證，且堆疊中沒有任何機制來強化界限。

公司從未制定的退款政策

未強制執行的界限在當晚造成了 US$4,000 的錯誤，但第三個錯誤所付出的代價卻更難以量化。有位客戶向代理程式詢問所購買產品的退貨期限。模型產生了自信且明確的回應：退款政策允許在 90 天內退貨。實際的政策是 30 天。該回應條理清晰、樂於助人，但完全錯誤。

LangChain 將模型的輸出傳遞給面向客戶的回應管道。此外，該框架再次精確執行了其設計功能：將模型的輸出路由到鏈中的下一個步驟。推論界限（即模型輸出進入現實世界的時刻，無論是傳送給客戶、寫入資料庫還是用於觸發動作）缺乏防護機制。沒有驗證層將輸出內容與文件化的政策進行比對。在回應送達客戶之前，沒有任何機制能檢查代理程式的回應是否與已知事實矛盾。輸出內容直接從模型傳遞到客戶，中間沒有任何過濾。

該客戶引用代理程式的回應，在第 47 天退回了價值 US$280 的產品。團隊接受了該項退貨。成本不僅是退款本身，還有法律風險：人工智慧 (Artificial Intelligence) 代理程式對客戶做出了未經授權的合約表述，且公司沒有稽核追蹤來顯示採取了哪些控制措施來防止這種情況。

計費錯誤有具體的美元金額。重複的工單有數量可循。傳送給客戶的虛假政策更難以量化，也更難以控制。這是一種會加劇的負債：代理程式在未經驗證的情況下傳送的每一個回應，都是您的法務團隊從未核准的另一個潛在合約承諾。每個執行與客戶通訊之代理程式的組織都面臨這種風險，且大多數組織是在不知情的情況下承擔風險。

代理程式運作正常

在開發環境中運作完美的代理程式，在一個晚上內發生了三次失敗。

觀察其中的模式。在每個案例中，框架的運作都是正確的。LangChain 協調工具呼叫、路由輸出，並在失敗時重試。代理程式迴路（推理、規劃、工具呼叫、調度）均按設計運作。

每次失敗的發生都是因為缺乏生產環境基礎架構。第一個失敗需要在平台層級具備冪等性與重複資料刪除功能。第二個失敗則需要具有範圍憑證和加密工作負載身分的身分界限。第三種情況需要在推論邊界設立護欄——也就是在回應傳遞給客戶之前，根據記錄在案的事實進行輸出驗證。

這些並非框架層面的考量事項。身分認證、工具治理（控制代理程式可以存取哪些工具以及在什麼條件下存取）、可觀測性（追蹤代理程式的每一個動作，以便進行稽核和偵錯）以及安全執行都是平台層面的考量事項——任何框架的設計初衷都無法解決這些問題。

我已經與正在 LangChain、CrewAI、LangGraph 以及自訂框架上執行代理程式的團隊談過。選擇的框架各不相同。但差距依然存在。他們都碰到了相同的瓶頸：「在開發環境運作」與「在生產環境執行」之間的差距並非框架問題，而是基礎架構問題；在問題未解決前，這會耗費龐大的資金、損害客戶信任並耗費工程時間。

如何填補差距

該基礎架構問題具有特定的樣貌。代理程式框架解決了代理程式迴圈的問題。它們的設計初衷並非為了解決生產環境的基礎架構問題，且本就不該如此。我不會指望網路框架會附帶自己的傳輸層安全性 (TLS) 憑證授權單位。這些屬於不同類別的工程。

Red Hat AI 提供了框架所缺乏的生產環境基礎架構。 Red Hat OpenShift AI 作為基礎。其運作原則是 BYOA（自備代理程式），讓平台可以運作任何代理程式執行環境（無論是 LangChain、CrewAI、LangGraph 或自訂程式碼），而無需對代理程式進行任何變更。您對框架的投資得以保留。您的代理程式碼不會改變。平台在底層注入了身分認證、安全性、治理和可觀測性層。

您已面臨的落差

在 6:00上午 故障的代理程式並非寫得不好的代理程式。它是一個優質的代理程式，只是在缺乏底層支撐的情況下執行。每個框架都提供推理迴圈、工具呼叫和協調編排。沒有任何框架能提供基礎架構，以決定這些功能在現實世界中執行是否安全。這種區別——即框架處理的部分與平台必須處理的部分——就是所謂的生產環境差距。這並非您的框架設計初衷所要填補的差距。

如果您目前有開發中的代理程式，我敢打賭它們也面臨著同樣缺乏底層支撐的問題。這並非因為您構建錯誤，而是因為框架本身並不包含這種底層支撐。我們的 下一篇文章页面当前以 English (英文) 显示（暂无 Chinese, Traditional 选项） 會介紹組成該底層支撐的特定元件，以及如何將這些元件安裝到位。

開始使用

準備好見識生產就緒的代理程式基礎架構呈現出的樣貌了嗎？從這裡開始：

• 在 Developer Sandbox 中免費試用 OpenShift AI页面当前以 English (英文) 显示（暂无 Chinese, Traditional 选项）：用於實驗人工智慧 (artificial intelligence) 工作負載的預先設定環境
• 探索 Red Hat AI 互動式示範：Red Hat AI 實作簡介
• 從自備代理程式 (BYO Agent) 入門套組開始：LangGraph、CrewAI、LlamaIndex、Langflow、Google ADK 等工具的預先設定範本
• 閱讀 Red Hat AI 文件：完整的平台文件
• 在 Red Hat AI 上將 BYOA 投入運作：OpenClaw 版本页面当前以 English (英文) 显示（暂无 Chinese, Traditional 选项）：關於在該平台上部署真實代理程式的實作文章