為什么95%的智能體都部署失敗了？這個圓桌討論出了一些常見陷阱

選自Motive Notes

作者：Oana Olteanu

機器之心編譯

「95% 的 AI 智能體在生產環境中部署時都失敗了。」在硅谷近期的一個圓桌論壇中，有位嘉賓給出了這樣一個數字。

這個論壇由 EntreConnect（一個企業家、投資者社區）組織，來自 Uber、WisdomAI、EvenUp 和 Datastrato 的工程師及 ML 負責人參與了討論。他們認為，多數 AI 智能體之所以部署時失敗，不是因為模型不夠智能，而是因為圍繞它們的基礎框架、上下文工程、安全性和記憶設計尚未成熟

EntreConnect組織的論壇「Beyond the Prompt: AI Inference x Context Engineering with Uber, Wisdom AI, EvenUp and Datastrato」

他們進一步指出，真正的差距在于上下文工程，「大多數創始人以為自己在構建 AI 產品，實際上他們在構建的是上下文選擇系統。」成功的團隊不是在優化提示詞，而是在構建語義層、元數據過濾、特征選擇和上下文可觀察性。正如論壇上的一個比喻所說：「基礎模型是土壤，上下文才是種子。」

當然，技術挑戰還不是全部。即便系統在功能上表現完美，如果無法追溯輸出來源、無法遵守權限控制、無法讓用戶真正信任它處理敏感數據，部署依然會失敗。一位與會者分享了他妻子拒絕使用特斯拉自動駕駛的故事 —— 不是因為它不好用，而是因為缺乏信任。這個問題同樣存在于企業 AI 智能體中。成功部署的那 5% 智能體都有一個共同點：人機協作設計，讓 AI 扮演助手而非自主決策者。

這篇文章由論壇主持人 Oana Olteanu 撰寫，深入探討了這次圓桌論壇的核心洞見：從上下文工程的最佳實踐、記憶架構設計、多模型編排，到治理框架和用戶體驗設計。如果你正在構建 AI 產品、基礎設施或智能體系統，這些來自一線工程師的實戰經驗，或許能幫你避開一些失敗陷阱。

上下文工程，不是提示詞黑科技

這場討論中，幾位嘉賓不約而同地提到：微調往往并非必要。

在多數場景中，一個構建良好的 RAG（檢索增強生成）系統已足夠高效 —— 但現實是，絕大多數 RAG 系統都太過粗糙。

它們常見的失敗模式包括：

• 盲目索引一切 → 模型被無用信息淹沒
• 索引太少 → 模型缺乏信號支撐
• 混合結構化與非結構化數據 → 打破嵌入空間一致性

那么，「高級的上下文工程」究竟長什么樣？

上下文層參考資料：https://www.wisdom.ai/ai-for-business-intelligence/semantic-layer

1、面向 LLM 的特征工程

一位嘉賓提出了一個極具啟發的框架：

把上下文工程看作 LLM 的原生特征工程（feature engineering）。

• 選擇性上下文剪枝 = 特征選擇
• 上下文驗證 = 類型 / 時間 / 模式校驗
• 上下文可觀測性 = 追蹤哪些輸入改善或削弱輸出質量
• 嵌入增強 + 元數據 = 類型化特征 + 條件信號

這意味著：上下文不再是「字符串拼接」，而是一個可測試、可版本化、可審計的數據工件。

2、語義層 + 元數據層的雙層結構

一些團隊分享了他們的「雙層架構」實踐：

• 語義層：負責經典的向量檢索
• 元數據層：基于文檔類型、時間戳、訪問權限、領域本體等執行過濾

這種設計能在混亂的數據源之間建立秩序（PDF、日志、音頻、指標等），確保檢索結果不是簡單的「相似內容」，而是真正的「相關知識」。

換句話說，它讓 AI 能理解語義，也能尊重結構。

3、text-to-SQL 的現實檢驗

當場上問觀眾「有誰把 text-to-SQL 做到生產環境里」時，一個舉手的都沒有。原因不是這個問題小，而是把自然語言穩定、可靠地映射到業務級查詢比想象中難得多。自然語言本身模糊、歧義重；企業術語又常常有上下文依賴 ——「營收」「活躍用戶」在不同公司、不同團隊的定義可能完全不同。

成功的團隊不會把數據庫 schema 生搬給模型然后指望它猜對。他們做的是工程化的抽象與保護措施，包括：

• 業務詞典與術語映射
• 受約束的查詢模板
• 執行前的語義校驗層

能夠隨時間提升理解的反饋循環可參見：https://www.wisdom.ai/ai-for-business-intelligence/text-to-sql

為什么「信任」與「治理」是核心問題

安全、權限、數據溯源這些詞，在現場被反復提到。

它們不是合規清單上的「打鉤項」，而是 AI 系統落地的關鍵阻力。

垂直領域創業者要注意做到以下幾點：

• 要能追蹤哪個輸入導致了哪個輸出
• 必須遵守行級、基于角色的訪問權限
• 即使提示詞相同，也必須支持用戶專屬的輸出結果

如果兩名員工問了同一個問題，AI 的答案應該不同。因為他們的權限不同、上下文不同。沒有這樣的訪問與策略控制，AI 的答案可能「技術上正確」，但「組織上錯誤」—— 泄露信息、違反合規。

領先團隊的做法是：在結構化與非結構化數據的統一目錄（metadata catalog）中，嵌入訪問策略，在索引和查詢階段同時生效。

信任問題并非技術瓶頸，而是人性瓶頸。 一位嘉賓講了一個故事 —— 他太太拒絕讓他開自動駕駛。不是因為它不好用，而是因為她不信任。AI 若要處理金錢、醫療、或安全相關決策，必須先贏得這種信任。那些真正成功的 5% 的系統，都有一個共通點：人機協同（human-in-the-loop）。AI 被設計為助手，而非決策者；能被監督、能被糾正、能被解釋。

記憶，不是功能，而是系統結構

每個團隊都說想給 AI 加記憶。但真正懂系統的人知道 —— 記憶不是一個 feature，而是一個涉及用戶體驗、隱私和系統影響的設計決策。

記憶有三個層面：

• 用戶層面：偏好（如圖表類型、風格、寫作語氣）
• 團隊層面：循環查詢、儀表盤、運行手冊
• 組織層面：組織知識、政策、先前的決策

大多數初創公司將記憶硬編碼到應用邏輯或本地存儲中，但頂尖團隊會將記憶抽象為一個「上下文層 + 行為層」的組合，可版本化、可復用。

他們的定義是：

• 語義記憶 + 分類體系 + 運行手冊 = 上下文；
• 用戶偏好 = 記憶

記憶即個性化

在應用層面，記憶服務于兩個目的：

• 針對個體用戶定制行為：適配其寫作風格、偏好格式、領域專長
• 基于事件和元數據的主動輔助：而非僅僅被動響應聊天

有團隊分享了在 Uber 構建對話式 BI 工具的經驗。冷啟動問題是什么？用戶不知道該問什么。解決方案是從用戶的歷史查詢日志中構建記憶，然后推薦相關問題作為對話起點 —— 就像一個記得你上次聊天內容的人。

但問題在于：有用的個性化何時會越界成為令人不安的監控？

一位與會者描述，他向 ChatGPT 詢問適合全家觀看的電影推薦，結果 ChatGPT 給出了針對他孩子 Claire 和 Brandon 的個性化建議。他不喜歡這個答案，說「你為什么對我的兒子和女兒了解得這么清楚？別碰我的隱私」。

在設計時，你需要考慮：

• 記憶改善用戶體驗和 AI 流暢度
• 但過度個性化很快會侵犯隱私領域
• 共享記憶可能打破訪問控制，除非仔細劃定范圍

這里缺失一個關鍵原語：一個安全、可移植的記憶層，可跨應用工作，由用戶使用，而非鎖定在服務商內部。目前還沒人真正解決這個問題。一位與會者說，如果他不做現在的創業項目，這會是他的下一個目標。

多模型推理與編排模式

另一個新興設計模式是模型編排。

在生產環境中，你不能對所有任務都調用 GPT-4。團隊越來越多地基于以下因素運行模型路由邏輯：

• 任務復雜度
• 延遲限制
• 成本敏感度
• 數據本地化 / 監管要求
• 查詢類型（如摘要 vs 語義搜索 vs 結構化問答）

以下是一些可能的情況：

• 簡單查詢 → 本地模型（無網絡調用）
• 結構化查詢 → 調用 DSL → SQL 轉換器
• 復雜分析 → 調用 OpenAI/Anthropic/Gemini
• 兜底或驗證 → 雙模型冗余（評判者 + 響應者）

這更接近編譯器設計而非網頁應用路由。你不只是「發送給 LLM」，而是在異構模型、工具和驗證之間運行一個決策 DAG（有向無環圖）。

為什么這點很重要？如果你的系統隨著使用量增長而變得更慢或更貴，這是首先需要重新審視的層面。如果你希望 AI 對用戶感覺無縫，路由就不能永遠依賴脆弱的手工調優。你需要自適應策略。

有團隊分享了他們的方法：簡單問題交給小型快速模型，復雜推理任務路由到前沿模型。這里的關鍵在于：通過追蹤哪些查詢在哪些模型上能夠成功執行，模型選擇這一過程本身可以隨著時間的推移不斷學習優化。

聊天界面究竟何時才適用？

并非每個任務都需要聊天機器人。一位觀眾直接挑戰了這個前提：「我不確定自然語言總是優于圖形界面。如果我要叫 Uber，我不想對著手機說話。我只想點、點、點，車就來了。」

的確，不是所有任務都適合自然語言交互。

專家小組的共識是：當對話能降低學習門檻時，它才具備實用價值。

對于商業智能（BI）儀表盤、數據分析這類傳統上需要專業知識才能操作的復雜工具，自然語言能降低使用門檻。但一旦用戶獲得所需答案，通常更傾向于使用圖形用戶界面控件 —— 比如將餅圖切換為柱狀圖，根本無需額外輸入文字。

混合模式的核心邏輯是：

• 以聊天功能開啟零學習門檻的初始操作
• 提供圖形用戶界面（GUI）控件用于后續的精準調整與反復優化
• 允許用戶根據具體任務需求和個人使用偏好選擇交互模式

一位與會者列舉了自然語言處理的兩個理想應用場景：

• 偶發且帶有情緒屬性的任務，例如客戶服務場景 —— 用戶此時可能心懷不滿，只想傾訴訴求或獲取幫助，而非在層層菜單中艱難導航；
• 探索性、開放式的查詢任務，例如「幫我找一處加州附近的愛彼迎房源，要前排位置，能看到海景和藍天」這類需求復雜且包含上下文信息的場景。

核心洞見在于：我們應當理解人們使用自然語言交互的深層原因，并圍繞這一核心意圖進行設計，而非將所有交互都強行套入聊天模式。

仍存在的缺口

會上提出了幾個尚未得到充分探索的方向，這些都是亟待產品化的核心基礎能力：

1、上下文可觀測性

哪些輸入能持續優化輸出效果？哪些類型的上下文會導致模型產生幻覺？如何像測試模型提示詞那樣測試上下文？目前，大多數團隊都在盲目摸索 —— 他們缺乏系統的方法來衡量哪些上下文對模型性能真正有幫助，哪些反而會產生負面影響。

2、可組合記憶

記憶能否歸屬于用戶（而非應用程序），實現可移植性與安全性？同時設置可選的權限層級，以區分組織、團隊和個人層面的記憶狀態？

這一設計能解決兩個核心問題：

• 用戶無需在每個新工具中重新構建自己的上下文信息
• 隱私與安全性由用戶自主掌控，而非受服務商鎖定

這是當前技術棧中最關鍵的缺失的基礎能力。

3、領域感知型 DSL

企業用戶的需求大多具備結構化和重復性特征。既然如此，我們為何仍執著于將自然語言解析為穩定性極差的結構化查詢語言（SQL），而非定義更高級、受約束且安全的領域特定語言（DSL）呢？

有團隊提出，與其開發文本到結構化查詢語言（text-to-SQL）的工具，不如構建語義化的業務邏輯層，例如 「展示第四季度營收」這類需求，應當直接映射到經過驗證的計算流程，而非生成原始的結構化查詢語言（SQL）代碼。

4、延遲感知型用戶體驗（UX）

一位專家組成員提到了一款記憶增強型聊天機器人，它的響應速度雖慢，卻能給用戶帶來驚喜體驗。原因在于：它能基于用戶上周的提問內容，給出一系列智能的后續跟進內容。

這一設計為異步、主動式人工智能的用戶體驗開辟了新可能 —— 其應用場景絕非僅限于聊天功能。試想這樣的場景：智能體在你開會前準備好簡報、在你打開文檔時呈現相關上下文信息，或是在你主動詢問前就提醒你數據中出現的異常情況。

核心洞見在于：不同任務對延遲的要求存在差異。一個笑話需要即時響應；而深度分析即便耗時 10 秒也無妨，只要能實時展示進度且體現出智能性即可。

值得持續關注的方向

作者表示，參與完這場專家小組討論后，她更加堅信：一波基礎設施工具浪潮即將到來，包括記憶組件、編排層、上下文可觀測性工具等。事后看來，這些工具的出現似乎順理成章，但如今它們仍處于混亂且尚未解決的狀態。

生成式人工智能領域下一個真正的競爭壁壘，不會源于模型訪問權限，而將來自以下四個方面：

• 上下文質量
• 記憶系統設計
• 編排可靠性
• 信任導向型用戶體驗（Trust UX）

如果你是一名正在開發基礎設施、應用程序或智能體的創業者：你的產品路線圖中，有多少內容是明確針對這四個方向展開的？

創業者必看：5 個需直面的硬核問題

如果你正在構建上下文系統或智能體，不妨問問自己這 5 個問題：

1. 我的應用程序的上下文預算是多少？（理想的上下文窗口規模為多大？我又在如何優化其中的內容構成？）
2. 我的記憶系統邊界在哪里？（哪些記憶歸屬于用戶層面、團隊層面以及組織層面？存儲位置在哪？用戶能否查看這些記憶內容？）
3. 我能追蹤輸出的溯源信息嗎？（當需要調試大語言模型的響應結果時，我能否明確知曉是哪些輸入內容導致了該輸出？）
4. 我使用的是單一模型還是多個模型？（我是如何根據任務復雜度、延遲要求或成本預算來分配路由請求的？）
5. 用戶會愿意將資金或醫療數據托付給我的系統嗎？（如果不愿意，我的安全機制或反饋循環中還缺少哪些關鍵環節？）

原文鏈接：https://www.motivenotes.ai/p/what-makes-5-of-ai-agents-actually