引 言

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

即使使用相對(duì)老舊的模型，迭代式智能體的循環(huán)機(jī)制所帶來的提升也超過了從 GPT?3.5 到 GPT?4 的基礎(chǔ)模型升級(jí)。這對(duì)企業(yè)來說意味著什么呢？吳恩達(dá)在 Scale Up 的采訪中表示，這意味著對(duì)大多數(shù)企業(yè)而言，利用智能體 AI 構(gòu)建實(shí)用應(yīng)用程序應(yīng)成為優(yōu)先事項(xiàng)，而非追逐最新的基礎(chǔ)模型。

從原型到生產(chǎn)的鴻溝

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

理解智能體開發(fā)

企業(yè)級(jí)團(tuán)隊(duì)在不斷嘗試擴(kuò)大智能體 AI 的應(yīng)用范圍，在此過程中會(huì)面臨經(jīng)典的產(chǎn)品市場適配問題。這一切均起源于兩個(gè)截然相反的問題：“目前，是否存在可通過智能體 AI 解決的問題？”

vs.“

既然我想應(yīng)用智能體 AI，那么哪些現(xiàn)有的問題最適合作為切入點(diǎn)？”

有一點(diǎn)需要明確，幾乎不涉及任何主觀決策的確定性工作流，用傳統(tǒng)方法實(shí)現(xiàn)效果更好。智能體 AI 的優(yōu)勢在于處理非確定性的決策，并基于這些決策執(zhí)行現(xiàn)實(shí)的動(dòng)作。

AI 系統(tǒng)的軟件開發(fā)生命周期（SDLC）具有本質(zhì)不同的特性。A. Gill 的敏捷研究指出了 AI 系統(tǒng)區(qū)別于傳統(tǒng)軟件的六個(gè)屬性：自主性、自適應(yīng)性、內(nèi)容生成、決策能力、可預(yù)測性和推薦能力。這些屬性要求“在敏捷 SDLC 框架內(nèi)集成決策科學(xué)”，從功能開發(fā)轉(zhuǎn)向行為編排。

同樣，國際標(biāo)準(zhǔn)化組織發(fā)布了 ISO/IEC 5338:2023“信息技術(shù) — 人工智能 —AI 系統(tǒng)生命周期流程（Information technology – Artificial intelligence – AI system life cycle processes）”，建立了首個(gè)全面的 AI 系統(tǒng)開發(fā)框架。該標(biāo)準(zhǔn)強(qiáng)調(diào)全流程風(fēng)險(xiǎn)管理，并明確要解決自主系統(tǒng)行為驗(yàn)證所面臨的挑戰(zhàn)。

這些范式都反映出，我們構(gòu)建非確定性系統(tǒng)軟件的方式正在發(fā)生更深層次的變革。

架構(gòu)與設(shè)計(jì)模式

在深入開發(fā)實(shí)踐之前，我們回顧一些對(duì)智能體應(yīng)用開發(fā)有幫助的架構(gòu)與設(shè)計(jì)模式。開發(fā)者可使用這些通用設(shè)計(jì)模式簡化智能體應(yīng)用的開發(fā)。

智能體控制 LLM 的輸入與輸出，使 LLM 始終返回結(jié)構(gòu)化的輸出，這可以被解析并轉(zhuǎn)換為一個(gè)或多個(gè)函數(shù)調(diào)用（稱為智能體的工具）。智能體只需要在工具引用池中查找對(duì)應(yīng)的工具，并使用 LLM 輸出提供的參數(shù)進(jìn)行調(diào)用即可。

這個(gè)過程可以僅執(zhí)行一次，也可以按照各種設(shè)計(jì)模式循環(huán)執(zhí)行。

智能體應(yīng)用開發(fā)的核心架構(gòu)模式

以下核心模式覆蓋了絕大多數(shù)的生產(chǎn)場景，智能體應(yīng)用開發(fā)者需要熟練掌握這些核心概念。

ReAct 智能體

下圖展示了在宏觀層面上 ReAct 智能體循環(huán)中的單次交互流程，步驟從 1 到 8 編號(hào)，每次迭代會(huì)重復(fù)執(zhí)行，直到滿足終止條件。圖 1：ReAct 智能體循環(huán)

圖 1：ReAct 智能體循環(huán)

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

監(jiān)管者智能體模式

圖 2：監(jiān)管者智能體模式

分層的智能體模式

例如，電商訂單的履約系統(tǒng)可使用分層模式：總履約智能體協(xié)調(diào)區(qū)域監(jiān)管者（北美、歐洲、亞洲），每個(gè)區(qū)域監(jiān)管者管理專用的倉庫智能體，負(fù)責(zé)庫存檢查、揀貨、打包和發(fā)貨。

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

圖 3：分層的智能體模式

人工介入模式

許多工作流存在一些特殊的決策點(diǎn)，這些決策點(diǎn)必須要由人工監(jiān)督和審批才能推進(jìn)。這類場景可以結(jié)合 AI 驅(qū)動(dòng)的高效率與人工的決策 / 審核，實(shí)現(xiàn)巨大的生產(chǎn)力提升。微軟的 Magentic-UI 研究了專門聚焦人工介入（human-in-the-loop）的智能體系統(tǒng)。

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

圖 4：人工介入模式

其他可參考的模式

下表列出了其他的智能體 AI 模式及鏈接，供進(jìn)一步學(xué)習(xí)。

表 1：其他模式的參考表

規(guī)劃智能體實(shí)現(xiàn)

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

表 2：智能體 AI 組件的迭代評(píng)估示例

完成以上宏觀層面的分析后，我們就可以開始設(shè)計(jì)各工作流的能力矩陣（參見表 3），或規(guī)劃其他的開發(fā)活動(dòng)了。

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

實(shí)現(xiàn)智能體的功能（能力矩陣法）

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

我們將每個(gè)工作流步驟進(jìn)行拆解，分析其應(yīng)為確定性的（基于規(guī)則、可預(yù)測）還是非確定性的（需要 LLM 推理）。核心要點(diǎn)就是，大多數(shù)生產(chǎn)應(yīng)用會(huì)同時(shí)包含確定性（固定規(guī)則）與非確定性（基于推理）的能力。

表 3：工作流能力矩陣

大多數(shù)應(yīng)用即便適合采用智能體方案，仍然會(huì)有相當(dāng)一部分功能應(yīng)基于規(guī)則而非智能體來實(shí)現(xiàn)。

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

成本優(yōu)化也應(yīng)該考慮進(jìn)來，因?yàn)?LLM 調(diào)用成本較高，應(yīng)該僅用于真正的非確定性任務(wù)。因此，任何智能體工作流或用例都應(yīng)定義如下的內(nèi)容：宏觀層面的確定性容器，定義工作流的邊界每個(gè)工作流步驟的映射基于推理需求的工作流步驟分類開發(fā)工作流開發(fā)者工作流 — 實(shí)現(xiàn)智能體角色與規(guī)劃邏輯智能體的編排方式?jīng)]有限制，可順序、并發(fā)或使用任意的協(xié)調(diào)策略。但大多數(shù)的應(yīng)用可歸入某個(gè)標(biāo)準(zhǔn)的編排模式。微軟 Azure 的智能體編排研究指出了五種主要的協(xié)調(diào)模式，每種都針對(duì)不同的運(yùn)營需求進(jìn)行了優(yōu)化：

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

并發(fā)編排

多個(gè)智能體并發(fā)執(zhí)行任務(wù)并匯總結(jié)果。該模式能夠降低獨(dú)立子任務(wù)的延遲。Google Cloud 的 Agent Assist 體現(xiàn)了并發(fā)處理優(yōu)勢，客服對(duì)話處理量提升了 28%，響應(yīng)速度加快了 15%。

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

自主級(jí)別設(shè)計(jì)

開發(fā)者工作流 — 版本管理智能體系統(tǒng)帶來了更復(fù)雜的版本管理需求。與典型非智能體后端應(yīng)用的標(biāo)準(zhǔn)版本管理相比，智能體系統(tǒng)引入了多個(gè)新的交叉節(jié)點(diǎn)，從而產(chǎn)生了新的故障點(diǎn)，例如，系統(tǒng)提示詞、工具、LLM 配置和其他資源。我們逐一評(píng)估這些組件的版本管理方式。

工具清單

使用 JSON/YAML 規(guī)范定義可用函數(shù)、參數(shù)與權(quán)限需求。工具清單（tool manifest）需要類似軟件包那樣的依賴管理功能，因?yàn)楣ぞ咛砑踊蛐薷目赡軓母旧细淖冎悄荏w的能力。例如，如果將工具調(diào)用的輸出加入下一次 LLM 調(diào)用的提示詞中，這可能會(huì)影響智能體工作流下一步的 LLM 決策行為。

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

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

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

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

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

回歸測試的黃金軌跡

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

圖 8：使用 LangSmith 追蹤平臺(tái)的黃金軌跡剖析

智能體的自動(dòng)化測試

智能體系統(tǒng)的測試與傳統(tǒng)應(yīng)用的測試方法有何差異呢？智能體應(yīng)用（無論是否自動(dòng)化）的測試必須要基于對(duì)確定性系統(tǒng)與非確定性系統(tǒng)之間架構(gòu)差異的深入理解來開展。智能體應(yīng)用是非確定性的，因?yàn)樗鼈兪褂?LLM 進(jìn)行推理，并通過工具調(diào)用采取行動(dòng)。

測試方式

系統(tǒng)調(diào)用（System Shell）

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

編排

負(fù)責(zé)使用當(dāng)前應(yīng)用的狀態(tài)、用戶輸入與其他變量來構(gòu)建 LLM 運(yùn)行時(shí)的輸入提示詞。該提示詞來自智能體的靜態(tài)系統(tǒng)提示詞模板，包含運(yùn)行時(shí)值占位符，這些值可能來自用戶輸入或應(yīng)用狀態(tài)計(jì)算的結(jié)果。

LLM 推理核心

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

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

行為測試工具（Behavioral Test Harnesses）

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

蛻變測試（Metamorphic Testing）

測試類型、范圍、檢查項(xiàng)與工具的映射

如下的表格展示適用于所有智能體應(yīng)用的各類測試方法、適用范圍、相關(guān)檢查項(xiàng)與識(shí)別的框架 / 工具。

表 4：智能體應(yīng)用的測試類型

結(jié)論智能體 AI 應(yīng)用開發(fā)在生產(chǎn)環(huán)境大規(guī)模鋪開時(shí)會(huì)面臨獨(dú)特的挑戰(zhàn)，這些挑戰(zhàn)涵蓋了識(shí)別智能體組件，以及實(shí)現(xiàn)、部署、測試與追蹤。實(shí)際上，使用智能體 AI 的應(yīng)用很少是完全智能體化的，這意味著應(yīng)用程序很可能包含一部分非智能體的組件。因此，每項(xiàng)開發(fā)實(shí)踐都會(huì)因智能體的引入而變得更加復(fù)雜，這會(huì)影響實(shí)現(xiàn)、測試與應(yīng)用的其他方面。例如，為測試定義預(yù)期輸出不再那么直觀，因?yàn)橄嗤斎朐诓煌瑫r(shí)機(jī)運(yùn)行時(shí)，智能體可能產(chǎn)生不同但同樣可接受的行為（這源于 LLM 輸出的差異）。我們試圖追蹤這些影響開發(fā)實(shí)踐的因素，并使用在真實(shí)生產(chǎn)環(huán)境部署智能體 AI 應(yīng)用的過程中積累的實(shí)用解決方案來應(yīng)對(duì)這些挑戰(zhàn)。