「95% 的 AI 智能體在生產(chǎn)環(huán)境中部署時都失敗了?！乖诠韫冉诘囊粋€圓桌論壇中，有位嘉賓給出了這樣一個數(shù)字。

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

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

他們進一步指出，真正的差距在于上下文工程，「大多數(shù)創(chuàng)始人以為自己在構(gòu)建 AI 產(chǎn)品，實際上他們在構(gòu)建的是上下文選擇系統(tǒng)?！钩晒Φ膱F隊不是在優(yōu)化提示詞，而是在構(gòu)建語義層、元數(shù)據(jù)過濾、特征選擇和上下文可觀察性。正如論壇上的一個比喻所說：「基礎(chǔ)模型是土壤，上下文才是種子?！?/span>

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

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

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

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

在多數(shù)場景中，一個構(gòu)建良好的 RAG（檢索增強生成）系統(tǒng)已足夠高效 —— 但現(xiàn)實是，絕大多數(shù) RAG 系統(tǒng)都太過粗糙。

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

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

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

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

1、面向 LLM 的特征工程

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

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

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

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

2、語義層 + 元數(shù)據(jù)層的雙層結(jié)構(gòu)

一些團隊分享了他們的「雙層架構(gòu)」實踐：

• 語義層：負責經(jīng)典的向量檢索
• 元數(shù)據(jù)層：基于文檔類型、時間戳、訪問權(quán)限、領(lǐng)域本體等執(zhí)行過濾

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

換句話說，它讓 AI 能理解語義，也能尊重結(jié)構(gòu)。

3、text-to-SQL 的現(xiàn)實檢驗

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

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

• 業(yè)務(wù)詞典與術(shù)語映射
• 受約束的查詢模板
• 執(zhí)行前的語義校驗層

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

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

安全、權(quán)限、數(shù)據(jù)溯源這些詞，在現(xiàn)場被反復提到。

它們不是合規(guī)清單上的「打鉤項」，而是 AI 系統(tǒng)落地的關(guān)鍵阻力。

垂直領(lǐng)域創(chuàng)業(yè)者要注意做到以下幾點：

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

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

領(lǐng)先團隊的做法是：在結(jié)構(gòu)化與非結(jié)構(gòu)化數(shù)據(jù)的統(tǒng)一目錄（metadata catalog）中，嵌入訪問策略，在索引和查詢階段同時生效。

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

記憶，不是功能，而是系統(tǒng)結(jié)構(gòu)

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

記憶有三個層面：

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

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

他們的定義是：

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

記憶即個性化

在應(yīng)用層面，記憶服務(wù)于兩個目的：

• 針對個體用戶定制行為：適配其寫作風格、偏好格式、領(lǐng)域?qū)ｉL
• 基于事件和元數(shù)據(jù)的主動輔助：而非僅僅被動響應(yīng)聊天

有團隊分享了在 Uber 構(gòu)建對話式 BI 工具的經(jīng)驗。冷啟動問題是什么？用戶不知道該問什么。解決方案是從用戶的歷史查詢?nèi)罩局袠?gòu)建記憶，然后推薦相關(guān)問題作為對話起點 —— 就像一個記得你上次聊天內(nèi)容的人。

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

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

在設(shè)計時，你需要考慮：

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

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

多模型推理與編排模式

另一個新興設(shè)計模式是模型編排。

在生產(chǎn)環(huán)境中，你不能對所有任務(wù)都調(diào)用 GPT-4。團隊越來越多地基于以下因素運行模型路由邏輯：

• 任務(wù)復雜度
• 延遲限制
• 成本敏感度
• 數(shù)據(jù)本地化 / 監(jiān)管要求
• 查詢類型（如摘要 vs 語義搜索 vs 結(jié)構(gòu)化問答）

以下是一些可能的情況：

• 簡單查詢 → 本地模型（無網(wǎng)絡(luò)調(diào)用）
• 結(jié)構(gòu)化查詢 → 調(diào)用 DSL → SQL 轉(zhuǎn)換器
• 復雜分析 → 調(diào)用 OpenAI/Anthropic/Gemini
• 兜底或驗證 → 雙模型冗余（評判者 + 響應(yīng)者）

這更接近編譯器設(shè)計而非網(wǎng)頁應(yīng)用路由。你不只是「發(fā)送給 LLM」，而是在異構(gòu)模型、工具和驗證之間運行一個決策 DAG（有向無環(huán)圖）。

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

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

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

并非每個任務(wù)都需要聊天機器人。一位觀眾直接挑戰(zhàn)了這個前提：「我不確定自然語言總是優(yōu)于圖形界面。如果我要叫 Uber，我不想對著手機說話。我只想點、點、點，車就來了?！?/span>

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

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

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

混合模式的核心邏輯是：

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

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

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

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

仍存在的缺口

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

1、上下文可觀測性

哪些輸入能持續(xù)優(yōu)化輸出效果？哪些類型的上下文會導致模型產(chǎn)生幻覺？如何像測試模型提示詞那樣測試上下文？目前，大多數(shù)團隊都在盲目摸索 —— 他們?nèi)狈ο到y(tǒng)的方法來衡量哪些上下文對模型性能真正有幫助，哪些反而會產(chǎn)生負面影響。

2、可組合記憶

記憶能否歸屬于用戶（而非應(yīng)用程序），實現(xiàn)可移植性與安全性？同時設(shè)置可選的權(quán)限層級，以區(qū)分組織、團隊和個人層面的記憶狀態(tài)？

這一設(shè)計能解決兩個核心問題：

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

這是當前技術(shù)棧中最關(guān)鍵的缺失的基礎(chǔ)能力。

3、領(lǐng)域感知型 DSL

企業(yè)用戶的需求大多具備結(jié)構(gòu)化和重復性特征。既然如此，我們?yōu)楹稳詧?zhí)著于將自然語言解析為穩(wěn)定性極差的結(jié)構(gòu)化查詢語言（SQL），而非定義更高級、受約束且安全的領(lǐng)域特定語言（DSL）呢？

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

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

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

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

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

值得持續(xù)關(guān)注的方向

作者表示，參與完這場專家小組討論后，她更加堅信：一波基礎(chǔ)設(shè)施工具浪潮即將到來，包括記憶組件、編排層、上下文可觀測性工具等。事后看來，這些工具的出現(xiàn)似乎順理成章，但如今它們?nèi)蕴幱诨靵y且尚未解決的狀態(tài)。

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

• 上下文質(zhì)量
• 記憶系統(tǒng)設(shè)計
• 編排可靠性
• 信任導向型用戶體驗（Trust UX）

如果你是一名正在開發(fā)基礎(chǔ)設(shè)施、應(yīng)用程序或智能體的創(chuàng)業(yè)者：你的產(chǎn)品路線圖中，有多少內(nèi)容是明確針對這四個方向展開的？

創(chuàng)業(yè)者必看：5 個需直面的硬核問題

如果你正在構(gòu)建上下文系統(tǒng)或智能體，不妨問問自己這 5 個問題：

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