大型語言模型能夠根據(jù)所學(xué)到的概率分布生成文本，但它們本身并不具備采取實際行動的能力。智能體技術(shù)正是將這類模型包裹在一種迭代式的改進機制中的一種技術(shù)——這種機制包括自我反思、工具使用、規(guī)劃制定以及多智能體之間的協(xié)作。智能體技術(shù)正是連接大型語言模型的核心技術(shù)（如GPT-5、Claude Opus 4.1等）與實際商業(yè)價值之間的橋梁。因此，企業(yè)迫切需要學(xué)習(xí)如何開發(fā)、部署、保障安全并運營這些智能體應(yīng)用。

本文為實踐者提供了構(gòu)建智能體應(yīng)用并將其投入生產(chǎn)環(huán)境進行擴展的具體指導(dǎo)。文章重點介紹了那些能夠幫助開發(fā)者順利實現(xiàn)智能體應(yīng)用規(guī)模化部署的開發(fā)方法。

引言

Google Brain的聯(lián)合創(chuàng)始人之一、人工智能領(lǐng)域最具影響力的專家之一吳恩達，在他的博客《Andrew Ng的信件》中提到，由于智能體技術(shù)具有前所未有的實際應(yīng)用價值，它將在人工智能發(fā)展的諸多領(lǐng)域發(fā)揮主導(dǎo)作用。正如這篇關(guān)于“智能體設(shè)計模式”的文章所指出的那樣，智能體技術(shù)有潛力推動各種商業(yè)流程的優(yōu)化。

智能代理AI的核心理念在于通過不斷進行推理、采取行動，然后再重新進行推理，直到確保特定任務(wù)的目標(biāo)得以實現(xiàn)。因此，在針對各種智能代理方法開展的研究中，雖然使用GPT-3.5和GPT-4在編碼測試中分別取得了約48%和67%的準(zhǔn)確率，但智能代理AI通過迭代機制與GPT-3.5結(jié)合使用后，其準(zhǔn)確率竟然達到了95.1%。

從GPT-3.5到GPT-4的基礎(chǔ)模型改進，其效果都被這種基于迭代機制的智能代理技術(shù)所掩蓋了——即使使用相對較老的模型，也能取得這樣的成果。這對企業(yè)來說意味著什么呢？根據(jù)Andrew Ng在這段采訪中的觀點，對于大多數(shù)企業(yè)而言，開發(fā)基于智能代理AI的實際應(yīng)用應(yīng)該才是首要任務(wù)，而不是一味追求最新的基礎(chǔ)模型。

從原型到量產(chǎn)的差距

傳統(tǒng)的軟件開發(fā)過程通常包括先進行原型設(shè)計來驗證相關(guān)概念，隨后再按照規(guī)模更大的類似流程來完成軟件的開發(fā)與部署工作。對于具有自主行為能力的智能系統(tǒng)而言，其開發(fā)原理大體上仍然相同，但存在一個根本性的區(qū)別：這類系統(tǒng)的行為并不具有確定性，因此原型測試所模擬的環(huán)境并不能真實反映現(xiàn)實世界的情況。在處理這類系統(tǒng)時，我們需要面對非確定性的行為模式、新出現(xiàn)的功能以及自主決策機制。例如，對于具有非確定性行為的系統(tǒng)而言，進行測試的方法與傳統(tǒng)的軟件工程實踐截然不同——傳統(tǒng)方法是通過輸入數(shù)據(jù)及預(yù)期的輸出結(jié)果來設(shè)計測試用例，而針對這類系統(tǒng)，則必須采用其他不同的測試方式。

理解智能體的發(fā)展機制

企業(yè)團隊一直在努力擴大其智能體人工智能的應(yīng)用范圍，在這一過程中，他們面臨著產(chǎn)品與市場匹配這一經(jīng)典問題。這個問題的根源在于兩個截然相反的問題：

“是否存在現(xiàn)實世界中可以通過應(yīng)用智能體人工智能來解決的問題？”

versus

“既然我想使用智能體人工智能，那么我現(xiàn)有的哪些問題最適合用這種方法來解決？”

關(guān)鍵在于要明白：如果整個流程完全由固定的、確定性的步驟構(gòu)成，且?guī)缀醪恍枰魏沃饔^判斷，那么使用傳統(tǒng)方法反而會更有效。而當(dāng)需要做出非確定性決策，并根據(jù)這些決策采取實際行動時，智能體人工智能才能發(fā)揮其優(yōu)勢。

人工智能系統(tǒng)的軟件開發(fā)生命周期具有本質(zhì)上的不同特性。A. Gill進行的敏捷性研究指出了六個能夠?qū)⑷斯ぶ悄芟到y(tǒng)與傳統(tǒng)軟件區(qū)分開來的特征：自主性、適應(yīng)性、內(nèi)容生成能力、決策能力、可預(yù)測性以及推薦功能。這些特性要求在敏捷的軟件開發(fā)生命周期框架中融入“決策科學(xué)”的理念，從而使開發(fā)過程超越單純的功能實現(xiàn)階段，轉(zhuǎn)向行為層面的協(xié)調(diào)與優(yōu)化。

同樣，國際標(biāo)準(zhǔn)化組織也發(fā)布了首個針對人工智能系統(tǒng)開發(fā)的綜合性框架，即ISO/IEC 5338:2023標(biāo)準(zhǔn)——“信息技術(shù)——人工智能——人工智能系統(tǒng)的生命周期流程”。該標(biāo)準(zhǔn)強調(diào)了在整個開發(fā)過程中進行風(fēng)險管理的重要性，并明確指出了驗證自主系統(tǒng)行為的各項挑戰(zhàn)。

這些發(fā)展理念反映了我們在為非確定性系統(tǒng)設(shè)計軟件時思維方式的深刻變化。

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

在進一步探討具體的開發(fā)實踐之前，讓我們先來看看一些對智能體應(yīng)用程序的開發(fā)有幫助的架構(gòu)與設(shè)計模式。開發(fā)者可以利用這些通用設(shè)計模式來簡化智能體應(yīng)用程序的開發(fā)流程。

智能體會控制與大型語言模型的輸入/輸出過程，確保模型始終返回結(jié)構(gòu)化的輸出結(jié)果，而這些輸出結(jié)果可以被解釋并轉(zhuǎn)化為一個或多個函數(shù)調(diào)用（這些函數(shù)調(diào)用被稱為智能體的“工具”）。智能體會從自身的工具庫中查找相應(yīng)的工具，并使用大型語言模型提供的參數(shù)來調(diào)用這些工具。

這個過程可以只執(zhí)行一次，也可以通過多種設(shè)計模式循環(huán)執(zhí)行。

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

有一些核心架構(gòu)模式能夠覆蓋大多數(shù)實際應(yīng)用場景。開發(fā)智能體應(yīng)用程序的開發(fā)者需要熟悉這些模式。

ReAct智能體

ReAct智能體的設(shè)計理念源于一篇相關(guān)的基礎(chǔ)研究論文，該論文的鏈接為ReAct Agent。ReAct是一種非常靈活的智能體設(shè)計模式，它由智能體、大型語言模型以及函數(shù)調(diào)用這三個部分組成，會形成一個循環(huán)結(jié)構(gòu)，直到滿足某個終止條件或通過外部邏輯觸發(fā)停止機制為止。

下圖展示了ReAct代理循環(huán)的基本工作流程，說明了在單次循環(huán)交互中會發(fā)生哪些步驟。這些步驟按順序編號為1到8，在每次迭代中都會重復(fù)執(zhí)行，直到滿足終止條件為止。

圖1：ReAct代理循環(huán)

ReAct模式特別適用于那些需要代理通過迭代方式來解決問題的工作流程。例如，一個用于調(diào)試數(shù)據(jù)庫的代理可能會執(zhí)行查詢操作、分析性能瓶頸、檢查現(xiàn)有的索引結(jié)構(gòu)，并持續(xù)進行這樣的循環(huán)，直到找到問題的根本原因。

以下是ReAct核心循環(huán)的偽代碼示例（推理 → 行動 → 觀察）

def react_agent_loop(user_query, available_tools, max_iterations=5):
? ? """
? ? ReAct模式：通過迭代進行推理和行動，直至達成目標(biāo)
? ? ```
? ? conversation_history = []
? ? conversation_history.append({"role": "user", "content": user_query})
? ??
? ? for iteration in range(maxiterations):
? ? ? ? # 第一步：推理 – 大語言模型決定下一步該采取什么行動
? ? ? ? llm_response = llm_client.generate(
? ? ? ? ? ? messages=conversation_history,
? ? ? ? ? ? tools=available_tools,
? ? ? ? ? ? temperature=0.7
? ? ? ? )
? ? ? ??
? ? ? ? # 第二步：行動 – 如果大語言模型建議使用某種工具，就執(zhí)行該工具
? ? ? ? if llm_response.has_tool_call():
? ? ? ? ? ? tool_name = llm_response.tool_call.name
? ? ? ? ? ? tool_args = llm_response/tool_call.arguments
? ? ? ? ? ??
? ? ? ? ? ? # 執(zhí)行選定的工具
? ? ? ? ? ? tool_result = execute_tool-tool_name, tool_args, available_tools)
? ? ? ? ? ??
? ? ? ? ? ? # 將工具執(zhí)行結(jié)果添加到對話記錄中
? ? ? ? ? ? conversation_history.append({
? ? ? ? ? ? ? ? "role": "assistant",
? ? ? ? ? ? ? ? "content": None,
? ? ? ? ? ? ? ? "tool_calls": [llm_response.tool_call]
? ? ? ? ? ? })
? ? ? ? ? ? conversation_history.append({
? ? ? ? ? ? ? ? "role": "tool",
? ? ? ? ? ? ? ? "content": tool_result,
? ? ? ? ? ? ? ? "tool_call_id": llm_response/tool_call.id
? ? ? ? ? ? })
? ? ? ? ? ??
? ? ? ? ? ? # 第三步：觀察 – 判斷是否應(yīng)該繼續(xù)迭代
? ? ? ? ? ? if should_terminate-tool_result, user_query):
? ? ? ? ? ? ? ? break
? ? ? ? else:
? ? ? ? ? ? # 如果大語言模型直接給出了最終答案，就返回該答案
? ? ? ? ? ? return llm_response.content
? ??
? ? # 在所有迭代結(jié)束后生成最終回復(fù)
? ? final_response = llm_client.generate(
? ? ? ? messages=conversation_history + [{
? ? ? ? ? ? "role": "user",
? ? ? ? ? ? "content": "根據(jù)以上討論結(jié)果，提供最終答案"
? ? ? ? }]
? ? )
? ? return final_response.content


def should_terminate-tool_result, original_query):
? ? """
? ? 終止循環(huán)的條件：
? ? – 大語言模型發(fā)出了明確的完成信號。
? ? – 達到了預(yù)定的置信度閾值。
? ? – 出現(xiàn)了需要人工干預(yù)的錯誤情況。
? ? ```
? ? if "COMPLETE" in tool_result:
? ? ? ? return True
? ? if "ERROR" in tool_result and "ESCALATE" in tool_result:
? ? ? ? return True
? ? return False

監(jiān)督者代理模式

在那些用例足夠復(fù)雜的多智能體環(huán)境中，在執(zhí)行各項任務(wù)之前進行集中規(guī)劃往往會很有幫助。這種模式包含一個負責(zé)集中規(guī)劃的監(jiān)督者代理，它會將工作分配給多個專門的工作者代理。監(jiān)督者會在每一步?jīng)Q定接下來應(yīng)該調(diào)用哪個代理來執(zhí)行任務(wù)，或者如果目標(biāo)已經(jīng)實現(xiàn)，則結(jié)束整個工作流程。現(xiàn)實世界中的一個例子是Anthropic的多智能體研究系統(tǒng)，該系統(tǒng)利用多個智能體來探索復(fù)雜的科研課題，其中有一個中央代理會根據(jù)用戶的請求來規(guī)劃研究流程，然后使用專門的并行智能體來執(zhí)行計劃中的各個步驟。

下圖展示了監(jiān)督者代理的具體結(jié)構(gòu)：

圖2：監(jiān)督者代理模式

[點擊此處將上圖放大到全尺寸]

分層智能體模式

當(dāng)某個監(jiān)督者需要管理過多的工作者代理時，整個智能體系統(tǒng)就會變得效率低下。而采用分層結(jié)構(gòu)就可以解決這個問題——通過創(chuàng)建由多個代理組成的團隊，每個團隊都有自己的監(jiān)督者，同時還有一個更高層次的監(jiān)督者來管理這些團隊級的監(jiān)督者。

例如，在電子商務(wù)訂單履行系統(tǒng)中，可能會使用分層模式：一個主履行代理負責(zé)協(xié)調(diào)各個區(qū)域的監(jiān)督者（比如北美、歐洲、亞洲），而這些區(qū)域監(jiān)督者則分別管理負責(zé)庫存檢查、揀選、包裝和發(fā)貨等工作的具體倉庫代理。

下圖展示了分層智能體模式的具體結(jié)構(gòu)：

圖3：分層智能體結(jié)構(gòu)

[點擊此處將上圖放大到全尺寸]

人類參與其中的模式

許多工作流程中都存在這樣的決策點：只有經(jīng)過人類的審核和批準(zhǔn)，這些節(jié)點才能被解除阻塞。在這種場景下，結(jié)合人工智能帶來的效率提升與人類的決策或?qū)徍耍軌蝻@著提高工作效率。Microsoft的Magentic-UI研究專門針對這種人類參與其中的智能系統(tǒng)進行了探討。

我們以貸款審批工作流程為例來說明這一模式。

圖4：人類參與其中的模式

其他相關(guān)模式的參考信息

其他智能系統(tǒng)相關(guān)的模式列在下表中，每一種模式都提供了進一步探索的鏈接。

模式名稱	描述	權(quán)威來源	適用場景
順序協(xié)調(diào)模式	線性流程處理	Microsoft AI智能系統(tǒng)的協(xié)調(diào)模式	適用于工作流程中存在明確的步驟依賴關(guān)系的情況。
并發(fā)協(xié)調(diào)模式	并行任務(wù)執(zhí)行	Microsoft AI智能系統(tǒng)的協(xié)調(diào)模式	適用于工作流程中包含獨立且可并行執(zhí)行的任務(wù)的情況。
任務(wù)交接模式	智能系統(tǒng)之間的任務(wù)傳遞	Microsoft AI智能系統(tǒng)的協(xié)調(diào)模式	當(dāng)某項任務(wù)最適合由哪個智能系統(tǒng)來完成尚不明確時，可以在工作流程進行中再進行分配。
事件驅(qū)動模式	異步協(xié)同處理	Confluent：事件驅(qū)動的多智能體系統(tǒng)	適用于可擴展的分布式系統(tǒng)。
調(diào)度器-智能體-監(jiān)督者模式	企業(yè)級工作流程管理	Microsoft的調(diào)度器-智能體-監(jiān)督者模式	適用于復(fù)雜的業(yè)務(wù)流程管理場景。
黑板模式	共享知識下的協(xié)同工作	Confluent：事件驅(qū)動的多智能體系統(tǒng)	適合需要大量知識輸入的任務(wù)。
市場機制模式	基于經(jīng)濟規(guī)律的協(xié)調(diào)機制	Confluent：事件驅(qū)動的多智能體系統(tǒng)	適用于資源分配相關(guān)的場景。

表1：其他模式的參考表格

規(guī)劃你的智能體實現(xiàn)方案

作為第一步，可以通過提出一些簡單的問題并反復(fù)回答這些問題，來有針對性地識別出應(yīng)用程序中適合應(yīng)用智能體技術(shù)的部分。在多次迭代中不斷調(diào)整答案，有助于優(yōu)化決策過程。

問題	目的	第一次迭代	第二次迭代	第三次迭代
我的應(yīng)用程序中是否有明確定義的工作流程？	在確定智能體組件之前，先明確應(yīng)用程序的范圍和邊界。	是的。有些工作流程已經(jīng)有了明確的定義，其中的具體步驟也都能被清晰地識別出來。 但也有一些工作流程還需要進一步明確。	是的。我的所有工作流程都已經(jīng)完成并且定義得很清楚（可提供相關(guān)文檔鏈接）。	所有工作流程都已記錄在案。
哪些工作流程中的步驟涉及非確定性決策？	明確哪些地方需要使用大語言模型的推理能力，哪些地方則適合使用確定性邏輯。	目前已經(jīng)明確的包括： 工作流程1的第3步 工作流程3的第2步 ……	清單已經(jīng)完整。補充了：工作流程2的第1步；工作流程4的第5步。	所有涉及推理的工作流程都已完成了映射記錄。
我們是否為每個工作流程都準(zhǔn)備好了能力矩陣（參見表3）？	區(qū)分確定性組件和智能體組件，以便優(yōu)化成本和可靠性。	工作流程1的能力矩陣已經(jīng)準(zhǔn)備完成。	所有工作流程的能力矩陣都已經(jīng)準(zhǔn)備好。	所有的能力矩陣都已經(jīng)過審核和驗證。
我們是否為每個智能體組件確定了所需的工具？	確定相應(yīng)的架構(gòu)模式（如ReAct、Supervisor）以及集成復(fù)雜性。	初步列出的工具包括：工作流程1所需的數(shù)據(jù)庫訪問功能、電子郵件API和支付網(wǎng)關(guān)。	所有工具的清單都已完整編制，并明確了相應(yīng)的權(quán)限要求（可提供文檔鏈接）。	已經(jīng)創(chuàng)建了工具清單，同時也定義了MCP（模型上下文協(xié)議）的相關(guān)規(guī)范。
我們是否為每個智能體組件確定了輸入/輸出接口？	明確界定接口，以便進行測試并減少出現(xiàn)意外行為的可能性。	已經(jīng)為7個智能體組件中的3個制定了接口規(guī)范草案。	所有的接口規(guī)范都已經(jīng)制定完成。還需要進一步驗證數(shù)據(jù)格式是否正確。	已經(jīng)使用樣本數(shù)據(jù)對接口規(guī)范進行了驗證（可提供文檔鏈接）。
我們是否為智能體組件制定了明確的成功標(biāo)準(zhǔn)？	制定可量化的質(zhì)量評估標(biāo)準(zhǔn)和行為測試方案。	初步確定的指標(biāo)包括：準(zhǔn)確性和響應(yīng)時間。	還補充了其他綜合性的評估標(biāo)準(zhǔn)，如行為一致性、故障處理能力以及升級觸發(fā)條件等。	成功標(biāo)準(zhǔn)已經(jīng)明確了可量化的閾值（可提供文檔鏈接）。
我們是否制定了追蹤機制，以便跟蹤智能體組件的各種操作，比如大語言模型的調(diào)用、工具的調(diào)用等等？	這樣的追蹤機制對于實現(xiàn)調(diào)試、審計以及行為回歸測試非常必要。特別是在非確定性系統(tǒng)中，運行時的大語言模型決策必須能夠被清晰地追蹤起來。	已經(jīng)確定需要使用LangSmith/OpenTelemetry等工具進行追蹤。目前正在評估不同的追蹤平臺。	已經(jīng)選定了追蹤框架，并為所有智能體組件確定了相應(yīng)的追蹤點。	追蹤機制已經(jīng)實施完成，同時也建立了數(shù)據(jù)保留策略和基準(zhǔn)軌跡記錄系統(tǒng)。

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

一旦獲得了這些高層次的分析結(jié)果，你就可以著手設(shè)計各個工作流程的能力矩陣（詳見表3），或者規(guī)劃其他開發(fā)活動。

如果能夠認真執(zhí)行上述流程，它將會成為后續(xù)開發(fā)的指導(dǎo)性清單。例如，表格中的第三個問題（比如“我們是否為每個工作流程都準(zhǔn)備了一份能力矩陣？詳見表3”）就可以用來為你的應(yīng)用程序的每個工作流程創(chuàng)建相應(yīng)的能力矩陣（具體內(nèi)容見下一節(jié)的表3）。通過這些能力矩陣，我們可以將每個工作流程的范圍分解成智能體部分和非智能體部分。需要記住的是，智能體通常涉及大語言模型的調(diào)用以及各種工具的運用，而這些操作可能會在循環(huán)中執(zhí)行。從圖5中可以看出（該圖展示了使用LangSmith進行智能體追蹤的過程），大語言模型的調(diào)用會帶來較大的延遲，因此，在那些適用于確定性規(guī)則或固定規(guī)則的場景中，我們就不應(yīng)該使用智能體來實現(xiàn)相關(guān)功能。一般來說，如果我的代碼能夠根據(jù)某些固定的規(guī)則做出明確、無歧義的決策，那么在應(yīng)用程序的這些部分就沒有必要使用智能體進行推理了——因為通過大語言模型進行智能體推理往往會犧牲程序的簡潔性和性能。

實現(xiàn)智能體特性（能力矩陣方法）

在智能體應(yīng)用開發(fā)中，最常見的反模式之一就是試圖讓所有功能都具備智能體的特性。根據(jù)上述原則，對智能體應(yīng)用的需求分析必須包括一個系統(tǒng)化的流程，用于確定應(yīng)用程序的哪些部分應(yīng)該運用非確定性的大語言模型推理機制，哪些部分則應(yīng)遵循確定性規(guī)則。當(dāng)某些任務(wù)更適合以確定性的方式來完成時，避免這種反模式就顯得尤為重要了。下面我們來看一個簡單的示例：一個能夠協(xié)調(diào)端到端客戶服務(wù)工作流程的智能體客戶支持系統(tǒng)。下表3列出了這樣一個示例工作流程中的每個步驟，并試圖說明實現(xiàn)其目標(biāo)的正確方法。

我們會逐一分析每個工作流程步驟，判斷它們應(yīng)該是確定性的（基于規(guī)則、可預(yù)測的）還是非確定性的（需要運用大語言模型進行推理的）。關(guān)鍵在于要認識到，大多數(shù)實際應(yīng)用都會同時包含確定性功能和非確定性功能。

支持流程：客戶提交支持請求，表示無法訪問自己的賬戶或下載發(fā)票。
流程步驟	執(zhí)行內(nèi)容	確定性環(huán)節(jié)	非確定性環(huán)節(jié)
初始工單接收	系統(tǒng)應(yīng)創(chuàng)建工單并確定客戶使用的聯(lián)系渠道。	生成工單編號。 確認客戶使用的聯(lián)系渠道（電子郵件/IVR/網(wǎng)站）。 查詢客戶信息。 ：在工單上設(shè)置SLA計時器。	通過分析請求內(nèi)容了解客戶的真實需求。 )識別核心問題，如“無法訪問賬戶”或“無法下載發(fā)票”等。
分類與路由分配	系統(tǒng)應(yīng)確定工單所屬類別，并將其分配到相應(yīng)的處理組或隊列中。	根據(jù)上一步中非確定性環(huán)節(jié)的分類結(jié)果進行分組/排隊。	確定問題類別及處理方向（分類階段）。 >結(jié)合請求內(nèi)容中的緊急程度信息及業(yè)務(wù)規(guī)則來評估優(yōu)先級。 >判斷問題的復(fù)雜性（是獨立問題還是關(guān)聯(lián)問題）。
知識庫搜索與解決方案匹配	系統(tǒng)應(yīng)查找現(xiàn)有的解決方案。	在數(shù)據(jù)庫中查詢相關(guān)知識庫信息。 >對于頻繁查詢的內(nèi)容，可進行緩存處理。 >從知識庫中檢索合適的解決方案。	生成用于查詢的SQL語句。 >判斷搜索到的解決方案是否適用于當(dāng)前問題。 >如果可能，將多個解決方案整合成一條可行的解決方案。
可選解決方案的實施	系統(tǒng)應(yīng)判斷是否可以應(yīng)用某種解決方案。	執(zhí)行必要的操作來應(yīng)用該解決方案，例如查詢數(shù)據(jù)庫或執(zhí)行相關(guān)命令。	根據(jù)目前掌握的信息決定是否采用該解決方案。
生成回復(fù)內(nèi)容	系統(tǒng)應(yīng)為客戶生成合適的回復(fù)。	回復(fù)內(nèi)容的生成流程包括： ：使用回復(fù)模板。 >替換模板中的占位符（如客戶名稱、工單編號等）。 >確定回復(fù)的發(fā)送渠道。	在回復(fù)內(nèi)容上做出一些定性決策，例如： >根據(jù)客戶情況進行個性化處理。 >根據(jù)問題的緊急程度調(diào)整回復(fù)的語氣。
解決方案或回復(fù)的發(fā)送	系統(tǒng)應(yīng)將回復(fù)內(nèi)容發(fā)送給客戶。	回復(fù)發(fā)送流程包括： )確定客戶偏好的接收渠道（如電子郵件）。 >記錄發(fā)送過程并生成相關(guān)數(shù)據(jù)。 >通過客戶選定的渠道發(fā)送回復(fù)。	一些非確定性的決策環(huán)節(jié)，例如： >決定是否需要進一步聯(lián)系客戶。 >評估解決方案的實際效果。
解決方案的管理與關(guān)閉	系統(tǒng)應(yīng)管理工單的整個生命周期，直至問題得到解決。	向客戶發(fā)送通知和提醒信息。 >跟蹤SLA執(zhí)行情況。 >確定需要溝通的相關(guān)人員，并通知他們問題已解決。	提供關(guān)閉建議。 >總結(jié)處理過程，并在必要時改進現(xiàn)有的解決方案步驟。

表3：工作流能力矩陣

這種能力矩陣的方法有助于揭示以下關(guān)鍵要點：從非結(jié)構(gòu)化/結(jié)構(gòu)化文本內(nèi)容中進行非確定性推理，是區(qū)分“智能型”應(yīng)用組件與“非智能型”應(yīng)用組件的重要依據(jù)。任何需要基于動態(tài)推理來決定的操作——比如理解用戶的意圖，或者是否需要對某個問題采取進一步行動——都應(yīng)當(dāng)被設(shè)計為“智能型”功能；為此，可以創(chuàng)建相應(yīng)的函數(shù)調(diào)用工具，讓智能體根據(jù)大語言模型的推理結(jié)果來執(zhí)行這些操作。而那些基于當(dāng)前應(yīng)用/系統(tǒng)狀態(tài)來執(zhí)行的操作，則完全可以、也應(yīng)該被編碼為傳統(tǒng)的“非智能型”規(guī)則來實現(xiàn)。

盡管大多數(shù)應(yīng)用都適合采用“智能型”設(shè)計方式，但其中仍會有相當(dāng)一部分功能需要通過規(guī)則來驅(qū)動，而非依賴智能體進行判斷。

應(yīng)用程序的架構(gòu)及開發(fā)過程應(yīng)當(dāng)以可靠性要求作為指導(dǎo)原則。那些不存在多種解釋可能性的功能，如果出現(xiàn)錯誤，必然會導(dǎo)致整個應(yīng)用程序無法正常運行；因此，這類功能的實現(xiàn)方式必須是確定性的。例如，服務(wù)水平協(xié)議應(yīng)該根據(jù)工單類型來確定固定的值，或者工單編號的生成規(guī)則也必須是一成不變的。而對于那些可能存在多種解釋可能性的功能來說，利用大語言模型的推理能力反而會帶來好處——比如可以根據(jù)當(dāng)前的解決方案及用戶需求來生成不同的響應(yīng)內(nèi)容，或者選擇不同的API調(diào)用方式、查詢執(zhí)行策略等。

成本優(yōu)化也是設(shè)計考慮的重要因素之一，因為調(diào)用大語言模型往往會產(chǎn)生較高的成本，因此這類技術(shù)只應(yīng)該用于那些確實需要非確定性推理的任務(wù)中。

因此，任何“智能型”工作流或應(yīng)用場景都應(yīng)當(dāng)明確以下內(nèi)容：

• 定義工作流邊界的高層確定性框架；
• 為每個工作流步驟指定具體的執(zhí)行方式；
• 根據(jù)推理需求對各類工作流步驟進行分類。

開發(fā)工作流

開發(fā)者工作流——實現(xiàn)智能體角色與規(guī)劃邏輯

在智能體的調(diào)度方式上并沒有嚴(yán)格限制，它們可以按順序執(zhí)行、同時運行，或者采用任意協(xié)調(diào)策略來進行調(diào)度。不過，大多數(shù)應(yīng)用其實都可以歸入某種標(biāo)準(zhǔn)的調(diào)度模式之中。微軟Azure在智能體調(diào)度領(lǐng)域的研究確定了五種主要的協(xié)調(diào)模式，每種模式都是針對不同的運營需求進行優(yōu)化的：

順序調(diào)度

圖5：順序編排模式（參考：Microsoft編排模式）

各代理按預(yù)定義的線性順序執(zhí)行任務(wù)，每個代理都會處理前一個階段產(chǎn)生的結(jié)果。這種模式在那些各個階段之間需要經(jīng)過嚴(yán)格質(zhì)量審核的文檔處理工作中表現(xiàn)得尤為有效。摩根大通的COiN（合同智能系統(tǒng)）就展示了順序文檔分析技術(shù)的強大功能：它能在幾秒鐘內(nèi)處理一萬兩千份商業(yè)信貸協(xié)議，且錯誤率幾乎為零，從而每年為該公司節(jié)省三十六萬個小時的法律工作時間。

并發(fā)編排模式

多個代理同時執(zhí)行任務(wù)，并對結(jié)果進行合并處理。這種模式能夠顯著降低那些由獨立子任務(wù)組成的任務(wù)的延遲。谷歌云的Agent Assist就體現(xiàn)了并發(fā)處理的優(yōu)勢：它使客戶服務(wù)工作流程中處理的對話數(shù)量增加了28%，響應(yīng)時間也縮短了15%。

圖6：并發(fā)編排模式（參考：Microsoft編排模式）

分層編排模式

主管代理負責(zé)協(xié)調(diào)各個專業(yè)工作代理，從而實現(xiàn)復(fù)雜的任務(wù)分解。張等人的最新研究表明，AgentOrchestra的分層架構(gòu)在各種測試中都明顯優(yōu)于扁平結(jié)構(gòu)的設(shè)計；劉等人的獨立驗證也證實，三層分層架構(gòu)能使任務(wù)成功率相比現(xiàn)有最佳方法提高32%。

除了這些例子之外，選擇單次執(zhí)行、循環(huán)執(zhí)行還是多代理協(xié)作模式，主要取決于任務(wù)的復(fù)雜程度以及對于可靠性的要求。如Max Pavlov的文章所介紹的，單次執(zhí)行系統(tǒng)非常適合那些具有明確成功標(biāo)準(zhǔn)的簡單任務(wù)，比如數(shù)據(jù)驗證或API調(diào)用；類似地，循環(huán)執(zhí)行系統(tǒng)（可參考谷歌的代理開發(fā)工具包）能夠?qū)崿F(xiàn)迭代優(yōu)化，但需要設(shè)置復(fù)雜的終止條件來避免無限循環(huán)，比如設(shè)定質(zhì)量閾值、迭代次數(shù)上限或提前終止策略；而多代理協(xié)作模式則為復(fù)雜任務(wù)提供了最強的支持，不過這種架構(gòu)要求有精妙的協(xié)調(diào)機制，而且相關(guān)系統(tǒng)平均會消耗多出15倍的計算資源（可參考Anthropic的研究型代理系統(tǒng)）。

自主性等級設(shè)計
這種類型的協(xié)調(diào)機制需要針對人類監(jiān)督功能的整合做出明確的決策。該框架將這類機制分為四種類型：人工干預(yù)型（直接參與控制）、人工輔助型（提供有意義的指導(dǎo)）、戰(zhàn)略管理型（進行宏觀決策）以及事后分析型（在操作結(jié)束后進行分析），更多相關(guān)信息可參考Pawel Rzeszucinski關(guān)于AI與人類協(xié)作機制的文章。同樣，Amazon Bedrock的多智能體協(xié)作框架也證明了：將不同的協(xié)調(diào)方法與內(nèi)置的安全機制相結(jié)合，才能在自動化效率與運營安全性之間實現(xiàn)最佳平衡。

開發(fā)人員的工作流程——版本控制

智能體系統(tǒng)帶來了更為復(fù)雜的新版本控制需求。與傳統(tǒng)的非智能體后端應(yīng)用程序相比，智能體系統(tǒng)引入了許多新的管理環(huán)節(jié)，這些環(huán)節(jié)也會成為潛在的故障點，例如系統(tǒng)提示信息、相關(guān)工具、大語言模型的配置設(shè)置等。接下來，我們就來逐一分析這些因素，探討如何對這些組件的版本進行有效管理。

微軟的Azure AI平臺指出，某些關(guān)鍵類型的智能體組件確實需要實施版本控制：

提示模板或系統(tǒng)提示信息
研究表明，對于相同的輸入，不同智能體的執(zhí)行路徑可能存在高達63%的變化幅度^{Mark Hornbeek}。因此，必須對提示模板進行版本控制，這樣不僅能夠追蹤其中的變更情況，還能在修改導(dǎo)致系統(tǒng)行為異常時及時恢復(fù)到之前的正常狀態(tài)。現(xiàn)代的提示管理工具通常提供基于Git的版本控制系統(tǒng)，并具備性能監(jiān)控功能^{PortKey的版本控制指南}；同時，這些工具還支持為生產(chǎn)環(huán)境中的智能體提供運行時的提示控制功能^{Launch Darkly}，并且具備完善的可觀測性分析框架^LangSmith。此外，Model Context Protocol (MCP)也為智能體工具的集成提供了標(biāo)準(zhǔn)化接口，從而確保了智能體運行環(huán)境中的版本控制與數(shù)據(jù)一致性。利用這些工具，我們甚至可以在運行時修改提示內(nèi)容，同時依然保持有效的版本管理機制。

工具清單
JSON/YAML格式的文件用于定義各種工具的可用功能、參數(shù)以及授權(quán)要求。由于工具的添加或修改會直接影響智能體的功能表現(xiàn)，因此需要對這類工具進行類似軟件包那樣的依賴關(guān)系管理^LangSmith。例如，某個工具的輸出結(jié)果如果被用于后續(xù)的大語言模型請求中，就可能會影響整個智能體工作流程的運行結(jié)果。

下圖展示了在典型的通用版本控制流程中所涉及的各種組件。

圖7：智能體的版本控制組件

[點擊此處將上圖放大到全尺寸]

受版本控制的提示與策略

毋庸置疑，提示是控制智能體系統(tǒng)中大型語言模型行為及決策過程的最直接手段，因此必須對其進行精細的管理，以避免任何形式的偏差（無論是有意還是無意的）。事實上，在RisingWave開展的一項研究中，提示的偏差被認定為最嚴(yán)重的故障類型。大多數(shù)生產(chǎn)環(huán)境中的智能體故障都是由于提示內(nèi)容被擅自修改，而這些修改會與系統(tǒng)更新或數(shù)據(jù)變化產(chǎn)生不可預(yù)測的交互作用所導(dǎo)致的。

因此，應(yīng)該將提示視為“代碼即基礎(chǔ)設(shè)施”（IaC），并將它們存儲在Git倉庫中，同時建立正式的變更審批流程。采用這種做法的組織會使用漸進式交付模式，包括對提示內(nèi)容的A/B測試，并設(shè)置自動回滾機制，以便在行為指標(biāo)超出可接受范圍時及時進行恢復(fù)（詳見Open Policy Agent）。

“黃金軌跡”作為回歸測試工具

那么，在智能體AI領(lǐng)域，行為回歸測試的基礎(chǔ)是什么呢？我認為就是“黃金軌跡”這一概念。所謂“黃金軌跡”，指的是經(jīng)過驗證的智能體交互序列——這些序列不僅記錄了最終的輸出結(jié)果，還包含了完整的推理過程、所使用的工具以及決策節(jié)點等信息。像LangChain和LangSmith這樣的框架，能夠幫助我們對智能體使用的工具功能及其他代碼部分進行追蹤分析。這種可追溯性為我們審核智能體與工具、大型語言模型以及其他接口之間的交互提供了有力手段。下圖展示了一個此類系統(tǒng)在工作流程執(zhí)行過程中所發(fā)生的所有智能體交互行為。

圖8：使用LangSmith追蹤平臺展示的“黃金路徑”分析結(jié)構(gòu)。

[點擊此處將上圖放大到全尺寸]

圖中所示的生產(chǎn)追蹤數(shù)據(jù)來自一個用于修復(fù)安全漏洞的代理程序，它完整地展示了進行行為回歸測試所需的所有信息：包括多次大語言模型調(diào)用所形成的完整推理鏈條、帶有參數(shù)的工具調(diào)用過程、防止無限循環(huán)出現(xiàn)的決策機制，以及包含Git版本信息的系統(tǒng)狀態(tài)記錄。當(dāng)修改該代理程序的提示語句后，其新的執(zhí)行結(jié)果可以與這個基準(zhǔn)數(shù)據(jù)進行對比；一旦出現(xiàn)任何顯著差異，系統(tǒng)就會自動回滾到之前的配置狀態(tài)。

智能體的自動化測試

測試智能體系統(tǒng)與測試傳統(tǒng)應(yīng)用程序有何不同？無論采用何種測試方法，測試智能體應(yīng)用都必須基于對確定性系統(tǒng)與非確定性系統(tǒng)在架構(gòu)上的差異的深刻理解。智能體應(yīng)用屬于非確定性系統(tǒng)，因為它們會利用大語言模型來進行推理，并通過調(diào)用工具來執(zhí)行具體操作。

測試方法

這里介紹的各種測試方法借鑒了論文《重新思考大語言模型應(yīng)用的測試策略`中的觀點，即智能體系統(tǒng)大致可由三層結(jié)構(gòu)組成：

系統(tǒng)外殼層

這一層包含API接口、集成組件以及工具調(diào)用模塊等確定性元素。

編排層

該層負責(zé)根據(jù)當(dāng)前的應(yīng)用程序狀態(tài)、用戶輸入等其他變量，為大語言模型生成執(zhí)行指令。這些指令雖然具體內(nèi)容會因環(huán)境而異，但它們都是基于智能體的靜態(tài)提示模板生成的，其中包含了一些用于存儲運行時數(shù)據(jù)的占位符，這些數(shù)據(jù)可能來源于用戶輸入或應(yīng)用程序的狀態(tài)計算結(jié)果。

大語言模型推理核心層

大語言模型本身被視為一個“黑盒”，但其行為仍會受到提示內(nèi)容調(diào)整和/或當(dāng)前應(yīng)用程序狀態(tài)的影響。

基于上述理解，讓我們來看看這篇綜合性指南中探討的一些針對非確定性軟件進行測試的基本方法。

基于屬性的測試

基于屬性的測試旨在驗證系統(tǒng)在面對隨機生成的輸入時，其行為是否滿足特定的邏輯規(guī)則^{(參見論文QuickCheck)。}Hypothesis這一領(lǐng)先的基于屬性的測試框架證明，與傳統(tǒng)的單元測試方法相比，它能夠更有效地檢測出人工智能系統(tǒng)中的錯誤。行為測試框架
行為測試框架提供了模擬API、仿真的用戶交互機制以及可控的故障場景。

變形測試
在《重新思考測試》這篇論文中描述的變形測試方法，側(cè)重于輸入與輸出之間的關(guān)系，而非單個輸出的正確性。這種方法尤其適用于人工智能系統(tǒng)，因為在這些系統(tǒng)中，判斷標(biāo)準(zhǔn)往往具有主觀性。

根據(jù)范圍、檢查項及工具來劃分測試類型

下表展示了各類適用于各種智能體應(yīng)用的測試方法，包括其適用范圍、相關(guān)的檢查項以及相應(yīng)的測試框架/工具。

測試類型	適用范圍	檢查項	工具/框架
單元測試	單個智能體功能的測試（相關(guān)工具）	提示語解析的正確性。 工具調(diào)用的正確性。 響應(yīng)格式的合法性驗證。	使用PyTest和Hypothesis進行測試。 )針對JavaScript智能體的Jest框架。 基于屬性的測試方法。
集成測試	智能體與系統(tǒng)之間的交互測試。	API連接的正確性。 數(shù)據(jù)庫訪問邏輯的驗證。 認證流程的合理性檢查。	Testcontainers框架。 WireMock工具。 )智能體測試專用框架。
行為測試	智能體的端到端行為檢測。	任務(wù)執(zhí)行順序的合理性。 推理邏輯的一致性及輸出結(jié)果的結(jié)構(gòu)驗證。 工具選擇的合理性檢查。 )整體行為是否與任務(wù)目標(biāo)相符。	Microsoft智能體測試框架。 )自定義的行為測試環(huán)境。
場景測試	實際應(yīng)用場景的模擬測試。	特定領(lǐng)域的工作流程驗證。 邊緣情況的處理能力檢測。 )多輪對話功能的測試。	目標(biāo)行為的正確性驗證。 )智能體交互過程的追蹤（例如使用LangSmith工具）。 )變形測試套件（詳見《重新思考測試》論文）。
混沌測試	在逆境下的抗干擾能力檢測。	對惡意輸入的抵抗能力。 工具故障時的處理機制。 )資源耗盡情況下的系統(tǒng)表現(xiàn)測試。	針對人工智能系統(tǒng)的Chaos Monkey工具。 )自定義的對抗性測試環(huán)境。

表4：具有智能行為特性的應(yīng)用程序的測試類型

結(jié)論

在將具有智能行為特性的人工智能應(yīng)用推向?qū)嶋H生產(chǎn)環(huán)境時，會面臨一系列獨特的挑戰(zhàn)。這些挑戰(zhàn)涉及從識別這些智能組件，到實現(xiàn)、部署、測試以及追蹤這些組件的整個過程。實際上，使用這類智能技術(shù)的應(yīng)用程序很少能夠完全具備智能行為特性，這意味著這些應(yīng)用程序通常會包含一些非智能組件。因此，每當(dāng)這些智能組件被納入應(yīng)用程序中時，相關(guān)的開發(fā)流程就會變得更為復(fù)雜，因為它們會影響到應(yīng)用程序的實現(xiàn)方式、測試過程以及其他各個方面。例如，現(xiàn)在要為這類應(yīng)用程序定義明確的測試目標(biāo)已經(jīng)不再那么容易了，因為在不同的環(huán)境下，即使使用相同的輸入條件，這些智能組件也可能產(chǎn)生不同的行為結(jié)果（這主要是由于大型語言模型產(chǎn)生的輸出可能存在差異所致）。我們嘗試分析了這種影響對各種主要開發(fā)流程的影響，并通過在實際開發(fā)過程中積累的經(jīng)驗，提出了相應(yīng)的解決方案來應(yīng)對這些問題。