Production AI Agents Have a Stack Problem

原始來源與檔名：2026-06-09T094412+0800-Production AI Agents Have a Stack Problem.md

NAPKIN | 餐巾纸

餐巾纸公式

Fragmented Stack = (Router) + (Runtime) + (Evals) + (Observability) -> Integration Tax & Trust Gap 71% 的工程師不再信任生產環境中的 AI 代理，問題不在模型，而在於拼湊而成的技術棧缺乏端到端的上下文聯繫。

一句话

生產環境中的 AI 代理面臨「技術棧碎裂」問題，唯有建立包含路由、運行時、評估與可觀察性於一體的「整合型平台」，才能解決黑箱與維運風險。

餐巾纸草图

[ Layer 1: Model Router ] (Cost, Fallbacks, Keys)
          ↓
[ Layer 2: Agent Runtime ] (Orchestration, Memory, Tools)
          ↓
[ Layer 3: Evaluation ] (Tied strictly to deployed versions)
          ↓
[ Layer 4: Observability ] (Traceability across all layers)

ROUND 1: SKELETON | 骨架扫描

“这本书在说什么”

• 核心问题: 當 AI 代理投入生產環境後，常常發生不可預期的崩潰、無限循環（如 LangGraph 記憶體洩漏）及高昂帳單。多數人怪罪模型，但真正的原因是底層技術棧（Stack）過度碎片化。
• 核心答案: 解決之道不是單純的「加上 Evals（評估）」，而是要改用或建立一套「整合式架構」，讓模型路由、運行時邏輯、評估與監控四個層級能共享相同的上下文與生命週期。
• 论证结构: 點出信任危機不是模型問題 -> 剖析碎片化棧的崩潰順序 -> 詳述導致失敗的四個根本原因 -> 提出重構後的四層代理工程架構 -> 給出何時該用整合平台 vs 單點工具的決策框架。

章节骨架

1. The Trust Gap: 71% 的從業者對部署的 AI 缺乏信心。團隊為了串接不同工具，付出巨大的整合稅。
2. What Actually Breaks First: 點出失敗順序：一致性消失 -> 所有權歸屬混亂 -> 監控變黑箱 -> 部署風險劇增。（舉例 CrewAI 卡死、Klarna 裁員後遺症）。
3. Why “Just Add Evals” Doesn’t Fix It: 評估若沒有與運行時及部署環境的資料流綁定，就只是在測試環境自嗨。
4. The Four Layers: 深入解析 Model Router, Agent Runtime, Evaluation, Monitoring 四層架構。
5. Decision Framework: 單點方案（Point solutions）與全棧平台（Full-stack platforms）的適用場景比較。

ROUND 2: DISSECTION | 血肉解剖

“凭什么这么说”

论证链

原型開發用單點工具很順 --> 投入生產後，環境變因增加 --> 單點工具彼此無法共享狀態（如 Eval 無法得知 Runtime 的具體路由決策） --> 變成黑箱，產生巨額整合成本與除錯困難 --> 唯有一體化架構能追溯從 Input 到 Output 的完整因果

关键证据

1. 實例災情: CrewAI 卡在 THINKING 模式無法除錯；LangGraph 長期運行產生嚴重記憶體洩漏；AutoGen 陷入死循環造成 API 帳單爆增。
2. 四大根本痛點: 1. 黑箱執行、2. 過度抽象化（被強迫用框架思維而非業務邏輯）、3. 錯誤處理薄弱、4. 資源洩漏（Token/記憶體）。
3. MCP 安全性: Multi-agent context protocols 若只是事後掛載，沒有在 Runtime 層級進行沙箱與輸入過濾，將是安全惡夢。

隐形假设与边界

• 隐形假设: 企業的開發團隊正面臨協作壁壘，且 AI 應用的複雜度已經超越單一 LLM API Call（具有多步驟、多工具、狀態保存）。
• 边界条件: 如果你的應用只是簡單的一次性文本生成（如翻譯工具），那麼輕量級的單點方案依舊是最佳解，不需要套用龐大的四層架構。

ROUND 3: SOUL | 靈魂提取

“还能怎么用”

• 作者盲点: 鼓吹「整合型平台」（如作者提及的 Orq.ai），但過度依賴單一供應商可能會帶來嚴重的 Vendor Lock-in (供應商鎖定) 風險，文章對此避而不談。
• 知识连接: 與微服務架構發展史極為相似；早期微服務野蠻生長導致維運困難，後來促使了 Kubernetes 與 Service Mesh 的誕生來統一基礎設施層。
• 行动触发: 檢視團隊目前的 AI 專案，盤點 Router、Runtime、Evals 與 Observability 分別使用什麼工具，以及這些工具之間是否需要人工手寫 Glue Code 來傳遞 Trace ID。

跨域映射

• 在 軟體基礎設施領域，這叫 打破技術孤島與建立可觀測性閉環 (Closed-loop Observability)。

Production AI Agents Have a Stack Problem (Architectural Deep Dive)

前言/背景

高達 71% 的工程師不再信任他們部署的 AI 代理。當代理失敗時，大家習慣責怪模型或 Prompt，但事實上，真正的罪魁禍首是底層支離破碎的技術棧（Stack）。

章節詳細總結

碎片化架構的崩潰路徑

在原型階段，隨意拼湊編排框架（如 LangChain）、評估庫與監控工具感覺很有效率。但進入生產環境後，崩潰會依序發生：

1. 一致性破裂：Prompt 更新了，但 Eval 沒跟上。
2. 所有權混亂：編排、評估、部署分屬不同團隊，出錯時無人能端到端負責。
3. 監控盲區：只能看到「任務失敗」，無法追溯是哪個 Prompt、哪個 Tool 或哪次路由判斷出錯。 這導致像 CrewAI 卡在 THINKING 黑箱，或 AutoGen 無限循環燒光 API 額度等真實災情。

不要只喊「加上 Evals」

單純在流程外掛載一個評估系統是無效的。測試環境的 Eval 無法預測代理在生產環境中遇到不穩定 API 或是錯誤上下文時的行為。Evals 必須與部署及監控管線深度融合，共享上下文生命週期。

AI 代理工程的四大分層架構

作者提出一個健康的生產級平台必須包含深度整合的四層：

1. Model Router (基礎層)：決定呼叫哪個模型，負責成本控制、容錯切換 (Fallbacks) 與金鑰管理，使每次呼叫具有確定性與可追溯性。
2. Agent Runtime：代理執行的核心，包含多代理編排、工具呼叫、記憶體與防護欄。此層必須內建安全沙箱 (如針對 MCP 的防護)。
3. Evaluation：綁定具體部署版本的評估，讓平台清楚知道哪次分數下降對應到哪行 Prompt 變更。
4. Monitoring & Observability：不僅是回報錯誤，而是深入 LLM 層級的追蹤（Traces），共享相同的識別碼以串接前三層。

總結與結論

• 生產環境中 AI 代理的問題不是模型能力不足，而是「基礎設施債 (Infrastructure Debt)」。
• 對於小型實驗或單一功能的應用，單點工具 (Point solutions) 依然適用。
• 當開始遇到嚴重的「整合稅 (Integration Tax)」，例如花費大量時間核對日誌、處理版本落差時，就必須考慮轉向端到端整合的全棧 AI 平台。