提示詞漂移，智能體失控的元兇？黃金軌跡如何守護你的應用

引 言

智能體 AI 建立在推理、執行和再推理的理念之上，直到 LLM 判定某次執行的目標已完成為止。在針對多種智能體方法的研究中，使用 GPT?3.5 和 GPT?4 的零樣本方式在編碼基準測試中分別達到了約 48% 和 67% 的準確率，而基于 GPT?3.5 的迭代循環智能體 AI 則達到了 95.1% 的準確率。

即使使用相對老舊的模型，迭代式智能體的循環機制所帶來的提升也超過了從 GPT?3.5 到 GPT?4 的基礎模型升級。這對企業來說意味著什么呢？吳恩達在 Scale Up 的采訪中表示，這意味著對大多數企業而言，利用智能體 AI 構建實用應用程序應成為優先事項，而非追逐最新的基礎模型。

從原型到生產的鴻溝

在傳統軟件開發中，會首先通過原型來驗證概念，再使用類似但更大規模的流程構建應用程序并將其部署到生產環境。對智能體 AI 而言，整體概念基本一致，但存在一個本質區別：智能體不具備行為一致性，因此原型的受控環境無法代表真實的環境。智能體系統面臨的是非確定性行為、涌現能力（emergent capabilities）與自主決策。例如，對非確定性系統的測試，完全與成熟的軟件工程中“輸入—固定的預期輸出”的測試場景不同。

理解智能體開發

企業級團隊在不斷嘗試擴大智能體 AI 的應用范圍，在此過程中會面臨經典的產品市場適配問題。這一切均起源于兩個截然相反的問題：“目前，是否存在可通過智能體 AI 解決的問題？”

vs.“

既然我想應用智能體 AI，那么哪些現有的問題最適合作為切入點？”

有一點需要明確，幾乎不涉及任何主觀決策的確定性工作流，用傳統方法實現效果更好。智能體 AI 的優勢在于處理非確定性的決策，并基于這些決策執行現實的動作。

AI 系統的軟件開發生命周期（SDLC）具有本質不同的特性。A. Gill 的敏捷研究指出了 AI 系統區別于傳統軟件的六個屬性：自主性、自適應性、內容生成、決策能力、可預測性和推薦能力。這些屬性要求“在敏捷 SDLC 框架內集成決策科學”，從功能開發轉向行為編排。

同樣，國際標準化組織發布了 ISO/IEC 5338:2023“信息技術 — 人工智能 —AI 系統生命周期流程（Information technology – Artificial intelligence – AI system life cycle processes）”，建立了首個全面的 AI 系統開發框架。該標準強調全流程風險管理，并明確要解決自主系統行為驗證所面臨的挑戰。

這些范式都反映出，我們構建非確定性系統軟件的方式正在發生更深層次的變革。

架構與設計模式

在深入開發實踐之前，我們回顧一些對智能體應用開發有幫助的架構與設計模式。開發者可使用這些通用設計模式簡化智能體應用的開發。

智能體控制 LLM 的輸入與輸出，使 LLM 始終返回結構化的輸出，這可以被解析并轉換為一個或多個函數調用（稱為智能體的工具）。智能體只需要在工具引用池中查找對應的工具，并使用 LLM 輸出提供的參數進行調用即可。

這個過程可以僅執行一次，也可以按照各種設計模式循環執行。

智能體應用開發的核心架構模式

以下核心模式覆蓋了絕大多數的生產場景，智能體應用開發者需要熟練掌握這些核心概念。

ReAct 智能體

下圖展示了在宏觀層面上 ReAct 智能體循環中的單次交互流程，步驟從 1 到 8 編號，每次迭代會重復執行，直到滿足終止條件。圖 1：ReAct 智能體循環

圖 1：ReAct 智能體循環

ReAct 模式特別適合智能體需要迭代調查問題的工作流。例如，數據庫調試智能體可以執行查詢、分析性能緩慢的現象、檢查現有索引，并持續循環直到找到根本原因。以下是核心 ReAct 循環（推理→執行→觀察）的偽代碼片段：

監管者智能體模式

圖 2：監管者智能體模式

分層的智能體模式

例如，電商訂單的履約系統可使用分層模式：總履約智能體協調區域監管者（北美、歐洲、亞洲），每個區域監管者管理專用的倉庫智能體，負責庫存檢查、揀貨、打包和發貨。

下圖展示了分層的智能體模式：

圖 3：分層的智能體模式

人工介入模式

許多工作流存在一些特殊的決策點，這些決策點必須要由人工監督和審批才能推進。這類場景可以結合 AI 驅動的高效率與人工的決策 / 審核，實現巨大的生產力提升。微軟的 Magentic-UI 研究了專門聚焦人工介入（human-in-the-loop）的智能體系統。

我們以貸款審批工作流為例說明該模式。

圖 4：人工介入模式

其他可參考的模式

下表列出了其他的智能體 AI 模式及鏈接，供進一步學習。

表 1：其他模式的參考表

規劃智能體實現

第一步，通過多輪迭代回答幾個簡單問題，找出應用中適合智能體 AI 的組成部分。答案在多輪迭代中的演進有助于簡化決策。

表 2：智能體 AI 組件的迭代評估示例

完成以上宏觀層面的分析后，我們就可以開始設計各工作流的能力矩陣（參見表 3），或規劃其他的開發活動了。

認真執行上述流程可以作為后續開發的指導清單。例如，上表中的第三個問題（即“是否為每個工作流準備了能力矩陣？”）可以用來為應用的每個工作流創建能力矩陣（參見下一節的表 3），這樣就能將每個工作流范圍拆分為智能體與非智能體部分。需要記住，智能體涉及 LLM 調用與工具調用，可能以循環方式運行。從基于 LangSmith 的智能體追蹤圖中可以看到（參見圖 5），LLM 調用會引入顯著延遲，因此我們不希望用智能體實現確定性或固定規則的組件。這里的指導原則是，如果代碼可以基于固定規則做出清晰無歧義的決策，那么應用中的這些部分就不需要智能體推理，因為通過 LLM 實現的智能體推理會犧牲簡潔性與性能。

實現智能體的功能（能力矩陣法）

智能體應用開發中最常見的一個反模式就是試圖將所有內容都智能體化。基于我們上述的原則，智能體應用的需求分析必須包含一個系統化的流程，識別應用的哪些部分應利用非確定性的 LLM 推理，哪些部分應采用確定性的規則。對某些更適合確定性實現的任務，必須避免這種反模式。我們以一個智能體客服系統為例，該系統編排了端到端的客服工作流。表 3 列出了該示例工作流的每一步，并說明實現目標的正確方式。

我們將每個工作流步驟進行拆解，分析其應為確定性的（基于規則、可預測）還是非確定性的（需要 LLM 推理）。核心要點就是，大多數生產應用會同時包含確定性（固定規則）與非確定性（基于推理）的能力。

表 3：工作流能力矩陣

大多數應用即便適合采用智能體方案，仍然會有相當一部分功能應基于規則而非智能體來實現。

架構與開發應該由可靠的需求來驅動。沒有模糊解釋，或者會導致明確失敗并阻塞功能的場景，必須要使用確定性方式的實現，例如，SLA 應基于工單類型設置為固定的值，或者，工單 ID 的生成要遵循固定邏輯。存在多種合理解釋的功能可以從 LLM 推理中獲益，例如，基于當前方案與用戶個性化生成不同的措辭、不同的 API 調用或查詢。

成本優化也應該考慮進來，因為 LLM 調用成本較高，應該僅用于真正的非確定性任務。因此，任何智能體工作流或用例都應定義如下的內容：宏觀層面的確定性容器，定義工作流的邊界每個工作流步驟的映射基于推理需求的工作流步驟分類開發工作流開發者工作流 — 實現智能體角色與規劃邏輯智能體的編排方式沒有限制，可順序、并發或使用任意的協調策略。但大多數的應用可歸入某個標準的編排模式。微軟 Azure 的智能體編排研究指出了五種主要的協調模式，每種都針對不同的運營需求進行了優化：

圖 5：順序編排（參考微軟的編排模式）

并發編排

多個智能體并發執行任務并匯總結果。該模式能夠降低獨立子任務的延遲。Google Cloud 的 Agent Assist 體現了并發處理優勢，客服對話處理量提升了 28%，響應速度加快了 15%。

圖 6：并發編排（參考微軟的編排模式）分層編排

自主級別設計

開發者工作流 — 版本管理智能體系統帶來了更復雜的版本管理需求。與典型非智能體后端應用的標準版本管理相比，智能體系統引入了多個新的交叉節點，從而產生了新的故障點，例如，系統提示詞、工具、LLM 配置和其他資源。我們逐一評估這些組件的版本管理方式。

工具清單

使用 JSON/YAML 規范定義可用函數、參數與權限需求。工具清單（tool manifest）需要類似軟件包那樣的依賴管理功能，因為工具添加或修改可能從根本上改變智能體的能力。例如，如果將工具調用的輸出加入下一次 LLM 調用的提示詞中，這可能會影響智能體工作流下一步的 LLM 決策行為。

下圖描述了通用版本管理流程中所涉及的版本化組件。圖 7：智能體版本管理組件點擊查看大圖 版本化控制的提示詞與策略需要說明的是，提示詞是控制智能體系統中 LLM 行為與決策的最直接的方式，因此需要精細管理以避免出現（有意或無意的）漂移。事實上，RisingWave 的研究將提示詞漂移列為最關鍵的故障模式。大多數生產環境的智能體故障都可追溯到不受控制的提示詞修改，這些修改與系統更新或數據變化產生了不可預測的交互。

圖 7：智能體版本管理組件

版本化控制的提示詞與策略

需要說明的是，提示詞是控制智能體系統中 LLM 行為與決策的最直接的方式，因此需要精細管理以避免出現（有意或無意的）漂移。事實上，RisingWave 的研究將提示詞漂移列為最關鍵的故障模式。大多數生產環境的智能體故障都可追溯到不受控制的提示詞修改，這些修改與系統更新或數據變化產生了不可預測的交互。

因此，提示詞應被視為基礎設施即代碼（Infrastructure as Code，IaC），存儲在 Git 倉庫中，并遵循正式的變更審批流程。采用這種方式的組織使用漸進式的交付模式，包括提示詞變更的 A/B 測試，當行為指標漂移超出可接受閾值時自動回滾（參見 Open Policy Agent）。

回歸測試的黃金軌跡

那么，智能體 AI 行為回歸測試的基礎是什么？我認為是 “黃金軌跡（golden trajectories）” 的概念。黃金軌跡指的是經過驗證的智能體交互序列，本質是追蹤記錄，不僅捕獲最終輸出，還包括完整的推理鏈、工具調用與決策點。LangChain 和 LangSmith 等框架允許我們對智能體的工具函數和代碼的其他部分進行埋點以實現可追蹤性。這種可追蹤性提供了審計智能體與工具、LLM 及其他接口交互的方法。以下系統示例展示了工作流執行期間的所有智能體交互。

圖 8：使用 LangSmith 追蹤平臺的黃金軌跡剖析

智能體的自動化測試

智能體系統的測試與傳統應用的測試方法有何差異呢？智能體應用（無論是否自動化）的測試必須要基于對確定性系統與非確定性系統之間架構差異的深入理解來開展。智能體應用是非確定性的，因為它們使用 LLM 進行推理，并通過工具調用采取行動。

測試方式

系統調用（System Shell）

包含確定性的組件，如 API 接口、集成組件與工具調用模塊。

編排

負責使用當前應用的狀態、用戶輸入與其他變量來構建 LLM 運行時的輸入提示詞。該提示詞來自智能體的靜態系統提示詞模板，包含運行時值占位符，這些值可能來自用戶輸入或應用狀態計算的結果。

LLM 推理核心

核心 LLM 服務被視為黑盒，但可以通過提示詞操作和 / 或當前應用狀態對其施加影響。基于這一理解，我們來看一下在 全面指南 中探索非確定性軟件必備的測試范式。

基于屬性的測試（Property-Based Testing）

行為測試工具（Behavioral Test Harnesses）

行為測試工具提供 mock API、模擬用戶交互與受控的故障場景。

蛻變測試（Metamorphic Testing）

測試類型、范圍、檢查項與工具的映射

如下的表格展示適用于所有智能體應用的各類測試方法、適用范圍、相關檢查項與識別的框架 / 工具。

表 4：智能體應用的測試類型

結論智能體 AI 應用開發在生產環境大規模鋪開時會面臨獨特的挑戰，這些挑戰涵蓋了識別智能體組件，以及實現、部署、測試與追蹤。實際上，使用智能體 AI 的應用很少是完全智能體化的，這意味著應用程序很可能包含一部分非智能體的組件。因此，每項開發實踐都會因智能體的引入而變得更加復雜，這會影響實現、測試與應用的其他方面。例如，為測試定義預期輸出不再那么直觀，因為相同輸入在不同時機運行時，智能體可能產生不同但同樣可接受的行為（這源于 LLM 輸出的差異）。我們試圖追蹤這些影響開發實踐的因素，并使用在真實生產環境部署智能體 AI 應用的過程中積累的實用解決方案來應對這些挑戰。