從提示詞到生產環境上線：智能體開發指南

作者 | Abhishek Goswami

譯者 | 張衛濱

大語言模型（LLM）能夠基于已學習的概率分布生成文本。它們本身不具備在現實世界中執行動作的能力。智能體 AI 是在 LLM 之外的一個封裝層，通過包含反思、工具使用、規劃和多智能體協作的迭代來優化流程，成為連接 LLM 核心技術（比如，GPT?5、Claude Opus 4.1）與現實業務價值的橋梁。因此，企業必須學會如何在生產環境中開發、上線并安全運營智能體 AI 應用。

本文是一份面向實踐者的指南，描述了如何構建智能體 AI 應用并在生產環境中實現規模化部署，重點介紹幫助開發者在生產環境落地并擴展智能體的開發實踐。

引 言

Google Brain 聯合創始人、AI 領域極具影響力的專家吳恩達（Andrew Ng）在其名為 “吳恩達來信”的博客中提到，智能體 AI 將主導 AI 領域的大部分進展，因為它擁有前所未有的實用價值。正如這篇智能體設計模式文章所述，它具有驅動業務流程的潛力。

智能體 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 智能體基于該領域的奠基性論文，是通用性最強的智能體模式之一。它由智能體、LLM 和工具調用之間的循環構成，直到滿足終止條件或由外部邏輯觸發中斷。

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

圖 1：ReAct 智能體循環

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

    return False

監管者智能體模式

在場景足夠復雜的多智能體環境中，通常需要先進行集中式規劃，再執行具體的任務。該模式包含一個用于集中規劃的監管者（supervisor）智能體，它會將任務分配給多個專用的工作者智能體。監管者會在每一步決定接下來調用哪個智能體，或在目標達成時結束工作流?，F實案例是 Anthropic 的多智能體研究系統，它使用多個智能體探索復雜研究主題，由中央智能體根據用戶查詢規劃研究流程，再使用專門的并行智能體執行計劃中的各個步驟。

圖 2 展示了監管者智能體模式的結構：圖 2：監管者智能體模式[點擊查看大圖] 分層的智能體模式當工作者智能體數量過多，單個監管者無法高效管理時，可以采用分層的系統，也就是創建多個智能體團隊，每個團隊有自己的監管者，再由更高層的監管者管理團隊級的監管者。

圖 2：監管者智能體模式

分層的智能體模式

當工作者智能體數量過多，單個監管者無法高效管理時，可以采用分層的系統，也就是創建多個智能體團隊，每個團隊有自己的監管者，再由更高層的監管者管理團隊級的監管者。

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

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

圖 3：分層的智能體模式

人工介入模式

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

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

圖 4：人工介入模式

其他可參考的模式

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

表 1：其他模式的參考表

規劃智能體實現

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

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

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

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

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

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

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

表 3：工作流能力矩陣

這種能力矩陣的方式有助于形成以下的關鍵結論：是否要從結構化 / 非結構化文本中進行非確定性推理，這是區分智能體與非智能體組件的清晰分界線。任何需要基于動態推理執行的動作（如理解用戶意圖、是否跟進問題）都應該實現為智能體，通常要創建函數調用工具，由智能體根據 LLM 推理進行調用。任何基于當前應用 / 系統狀態的動作，都應該且可編碼為傳統非智能體規則的實現。

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

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

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

順序編排圖片:

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

智能體按照預定義的線性順序執行，每個智能體處理上一階段的輸出。該模式最適合不同階段間存在質量門禁，對業務至關重要的文檔處理工作流。JPMorgan Chase 的 COiN（合同智能） 系統展示了順序文檔分析的強大能力，它能每秒處理 1.2 萬份商業信貸協議，錯誤率接近零，每年能節省 36 萬小時的法務工時。

并發編排

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

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

監管者智能體需要協調專門的工作者智能體，實現復雜任務的分解。Zhang 等人的最新研究表明，AgentOrchestra 的分層框架能夠持續優于扁平的智能體架構，在復雜基準測試中達到了 95.3% 準確率。Liu 等人的獨立驗證顯示，三層分層架構相比此前的最優方法，任務成功率絕對提升了 32%。

除以上示例外，一次性（single-shot）、循環（looped）與多智能體編排的選擇取決于任務復雜度與可靠性的需求。Max Pavlov文章 中描述的一次性系統適合邊界清晰、成功標準明確的任務，如簡單數據校驗或 API 調用。循環系統（參見 谷歌的智能體開發工具包）支持迭代優化，但需要成熟的終止條件以避免無限循環，如質量閾值、迭代上限或提前終止策略。多智能體編排為復雜任務提供最強的能力，但需要精細的協調機制，系統平均 Token 消耗最高可達其他方式的 15 倍（參見 Anthropic 對智能體的研究）。

自主級別設計

這類編排需要明確決策人工監督的集成方式。該框架定義了四種類型：Human-in-the-Loop（直接干預）、Human-on-the-Loop（有效控制）、Human-above-the-Loop（戰略治理）、Human-behind-the-Loop（運營后分析），參見 Pawel Rzeszucinski 名為“AI, Human and Loop”的文章”的文章。同樣，Amazon Bedrock 的多智能體協作框架 表明，將不同編排方式與內置護欄結合，可在自動化效率與運營安全之間實現最優的平衡。

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

微軟 Azure AI 平臺指出了需要版本化管理的關鍵智能體制品的類別：提示詞模板或系統提示詞研究表明，在相同輸入的情況下，智能體執行路徑的變異系數最高可達 63%（Mark Hornbeek）。因此，提示詞必須進行版本化，這不僅可以用于追蹤變更，還可以在變更引入行為漂移時進行回滾?，F代提示詞管理平臺提供基于 Git 的版本控制和性能監控（參見 PortKey 的版本指南）、生產環境中智能體運行時的提示詞控制（Launch Darkly）和全面的可觀測框架（比如，LangSmith）。模型上下文協議（MCP） 為智能體?工具集成提供了標準化的接口，確保智能體運維環境的版本與一致性。使用這些工具，我們還可在運行時修改提示詞并保證完善的版本控制。

工具清單

使用 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 追蹤平臺的黃金軌跡剖析

在圖 8 的生產環境跟蹤數據中，展示了一個 CVE 補丁智能體的執行過程，包含了行為回歸測試所需的所有內容：跨多個 LLM 調用的完整推理鏈、帶參數的工具調用、阻止無限循環的決策門禁以及包括 git 上下文在內的完整狀態捕獲。當修改這個智能體的提示詞時，可以將新的執行過程與這個基線進行比較，任何明顯偏離都會觸發自動回滾。

智能體的自動化測試

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

測試方式

這里描述的多種方法借鑒了“重新思考 LLM 應用測試”論文中的觀點：智能體系統大致可分為三層：

系統調用（System Shell）

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

編排

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

LLM 推理核心

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

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

基于屬性的測試需要驗證系統在隨機生成的輸入下是否滿足邏輯屬性（參見 QuickCheck 的論文）。主流的基于屬性的測試框架 Hypothesis 顯示，相比傳統單元測試，它對 AI 系統的缺陷檢出率要高得多。

行為測試工具（Behavioral Test Harnesses）

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

蛻變測試（Metamorphic Testing）

按照“反思測試”論文中的描述，蛻變方法關注輸入與輸出之間的關系，而非單個輸出的正確性，這對于真實答案可能具有主觀性的 AI 系統尤其有效。

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

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

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

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

查看英文原文：

From Prompts to Production: A Playbook for Agentic Development(https://www.infoq.com/articles/prompts-to-production-playbook-for-agentic-development/)

聲明：本文為 InfoQ 翻譯，未經許可禁止轉載。