AI代理協定和架構開發者指南

首页 » 蟒蛇 » AI代理協定和架構開發者指南

人工智慧代理正在將軟體從被動式助手轉變為主動助手。 自主協作者 它們能夠感知環境，推理複雜的目標，並代表我們採取行動。對於開發者而言，這種轉變徹底改變了一切：不再是圍繞生命週期模型建立靜態工作流程，而是設計由模型本身驅動控制流、協調工具並與其他代理和服務協作的系統。

如果你想認真地建立… 生產級代理系統了解新興協議已不再是可選項。代理存取工具（MCP）、相互通訊（A2A）以及透過自然語言與網路互動（NLWeb）的標準化方式正迅速成為「代理生態系統」的支柱。同時，您仍需要掌握代理本身的核心建構模組：模型、工具、指令、編排模式和防護機制。

AI代理究竟是什麼？它與普通LLM有何不同？

人工智慧代理最好被理解為圍繞邏輯邏輯模型（LLM）建構的完整系統，而不僅僅是模型本身。學術界普遍接受的定義（例如史丹佛大學 CS221 課程中的定義）將智能體描述為位於環境中的計算實體，能夠透過感測器感知環境，並透過執行器對環境採取行動，以最大限度地提高實現某個目標的成功幾率。

從實際軟體角度來看，現代人工智慧代理結合了四種要素。：“ 大型語言模型 為了進行推理、存取外部工具和API、具備某種形式的記憶功能以追蹤上下文隨時間的變化，以及擁有明確的目標或角色，智能體需要具備相應的能力。與只能回答問題的簡單聊天機器人不同，智能體可以進行規劃、調用工具、對工具的輸出做出反應，並迭代地推進工作流程，直到達成目標。

常見的混淆點在於將「模型」和「代理」混為一談。像 GPT-4 或 Llama 3 這樣的模型功能強大，但卻是被動的「大腦」：它不會主動行動，除非你發出指令，它本身也無法發送電子郵件、呼叫 API 或更新資料庫。而智能體則將模型封裝在一個感知、推理和行動的循環中。它利用模型的預測結果來選擇呼叫哪個工具、何時向使用者尋求澄清以及何時停止操作。

關鍵區別在於誰控制工作流程。在傳統軟體中，程式碼決定了執行順序：如果 A 則執行 B 再執行 C。而在智能體中，LLM（邏輯邏輯管理器）會根據目前狀態決定下一步操作。它可能會根據同一個高級請求，選擇查找訂單、建立支援工單或將案件轉交給其他智慧體。

智能體的複雜程度也各不相同，從簡單的反應式系統到學習型、目標驅動型架構。Russell 和 Norvig 的經典分類法仍然有助於理解現狀：你可以獲得簡單的反應式智能體（純粹的 if-then 規則）、基於模型的反應式智能體（具有最小的內部狀態）、基於目標的智能體（朝著期望的結果進行規劃）、基於效用的智能體（在多種策略可能的結果中優化數字值得分）和學習型智能體（根據其策略可能的結果中優化數字值得分）和學習模型。

為什麼在人工智慧代理時代協議至關重要

隨著智慧體的功能越來越強大、應用越來越廣泛，三個問題很快就顯現出來：整合成本、互通性和安全性。為每個 API 或合作夥伴系統編寫臨時黏合程式碼無法擴充。專有的、一次性的格式會阻礙不同供應商的工具和代理商之間的協作。而且，每次新的整合都會增加安全漏洞。

以代理為中心的協議旨在解決這些痛點。 透過定義開放標準，來規範：主機如何向 LLM 公開工具和上下文（模型上下文協議，或 MCP），代理如何跨越組織和技術邊界與其他代理進行通信（代理到代理，或 A2A），以及網站如何以自然語言優先的方式向人類和代理公開其內容和操作（自然語言網絡，或 NLWeb）。

對於開發者而言，這些協定就像是代理和服務的「通用適配器」和「名片」。無需編寫數十個集成程式碼，只需與 MCP 伺服器、A2A 相容的對等方或 NLWeb 網站進行一次集成，即可讓協定自動處理發現、功能和身份驗證。這顯著減少了自訂整合邏輯，並允許您在不重寫所有底層程式碼的情況下切換模型或工具。

同時，協議級安全性變得至關重要。協議層的存取控制、標準化身份驗證和清晰的功能描述，使得人們更容易理解誰可以在什麼地方、在什麼限制下執行什麼操作——這在企業環境中至關重要，因為代理可能被允許接觸庫存、支付或敏感的客戶資料。

模型上下文協定 (MCP)：一種用於工具和資料的通用適配器

模型上下文協定是一個開放標準，它定義了應用程式如何向基於LLM的代理提供工具和上下文資料。從概念上講，MCP 位於您的代理程式和您現有的系統（資料庫、SaaS API、內部服務）之間，並將它們變成一套統一的、可發現的功能。

MCP 採用客戶端-伺服器架構，具有三個主要角色：發起連線的主機（LLM 應用程序，例如 IDE、聊天用戶端或代理程式執行時間）、主機內部與 MCP 伺服器保持一對一連接的用戶端元件，以及伺服器本身（即公開特定功能的輕量級程式）。

在MCP內部，伺服器會通告三個核心原語。 代理可以以一致的方式使用的工具、資源和提示。工具是離散的操作，例如“獲取天氣”、“購買產品”、“搜尋航班”，它們具有名稱、描述和輸入/輸出模式。資源是唯讀資料項，例如檔案、資料庫行或日誌，可以是文字或二進位資料。提示是預先定義的模板，封裝了提示工程模式或多步驟流程。

動態工具發現是MCP最大的成功之一。與其硬編碼旅行助手必須具備特定簽名的「searchFlights」函數，不如讓代理商連接到航空公司的MCP伺服器並請求其功能清單。伺服器會傳回工具、其參數和預期回應的機器可讀描述。當航空公司新增「upgrade_booking」工具時，只要您遵守MCP協議，您的代理商無需更改程式碼即可發現該工具。

MCP 也刻意保持與模型無關。由於該協定關注的是功能和上下文，而非任何特定供應商的 API，因此同一個 MCP 伺服器可以被不同的 LLM 或代理框架使用。這允許您嘗試模型替換或多模型策略（例如，使用小型、低成本的模型處理簡單的流程，而使用功能強大的模型處理複雜的推理），而無需重新進行整合。

另一個好處是標準化安全措施。MCP 可以包含一致的身份驗證機制，這比為每個第三方 API 維護一套繁雜的客製化身分驗證流程要容易得多。對於企業而言，這意味著可以從“測試環境中的一個整合”更輕鬆地擴展到“生產環境中數百台 MCP 伺服器”，而不會丟失對密鑰和權限的控制。

一個具體的例子能更清楚說明MCP的作用。想像一下，用戶向人工智慧旅行助理詢問「幫我尋找從波特蘭到檀香山的航班並預訂」。該助手作為 MCP 用戶端，連接到航空公司的 MCP 伺服器，枚舉諸如“search_flights”和“book_flight”之類的工具，使用正確的參數調用“search_flights”，接收 JSON 結果，將其呈現給用戶，然後根據用戶選擇的選項調用“book_flight”。該助理從不直接呼叫航空公司的內部 API；它只使用 MCP 進行通訊。

智慧體間協作（A2A）：一種多智能體協作協議

MCP 專注於將代理與工具和資料連接起來，而代理到代理協定則專注於將代理彼此連接起來。一旦你超越了單一的「超級代理」模式，進入到一個 專業代理人的生態系統 （旅行、計費、物流、支援…），你需要一種清晰的方式讓他們能夠相互發現、交流資訊並協作完成共同的任務。

A2A旨在支援這種分散式、跨組織的編排。它允許來自不同公司、不同技術堆疊和不同託管環境的代理程式協同處理使用者請求，而無需預先硬編碼每個互動路徑。一個與​​ A2A 相容的「旅行代理」可以調用由完全不同的團隊建立的「航空公司代理」、「飯店代理」和「租車代理」。

每個 A2A 代理程式都會展示一張機器可讀的代理卡。 它的作用類似於 MCP 的功能列表，但它是在代理層級而非工具層級上進行操作的。代理卡片包含代理名稱、其處理功能的自然語言描述、技能清單（附有呼叫時機的說明）、當前端點 URL、版本資訊以及諸如是否支援串流回應或推播通知等標誌。

在呼叫方，代理執行器負責傳遞上下文並管理互動。當本機代理決定委託子任務時，其執行器會將目前對話、相關狀態和任何約束打包，並透過 A2A 協定將其傳送給遠端代理程式。遠端代理程式運行其內部工具和 LLM 循環，然後傳回結果，而呼叫方無需了解其內部機制。

遠端任務完成後，結果將以工件的形式傳回。一個工件通常包含任務輸出、對所做工作的簡要描述以及協議中涉及的文本上下文。工件交付後，A2A 連接即可關閉，因此在確保每次互動範圍明確、成本低廉的同時，仍能實現豐富的協作。

對於長時間運行或非同步任務，A2A 通常依賴事件佇列。事件佇列無需像傳統方式那樣，讓遠端代理程式長時間保持連線開啟狀態以處理資料或等待外部系統回應，而是負責訊息傳遞和更新。這在生產級多代理系統中尤其重要，因為這類系統對網路彈性、重試機制和反壓機制的要求非常高。

A2A 的益處與 MCP 的益處類似，但它是在生態系統層面實現的。這樣一來，您可以獲得異質代理之間更有效率的協作、為每個代理程式選擇最佳生命週期管理 (LLM) 或微調策略的靈活性，以及​​內建的身份驗證功能，從而確保代理間呼叫的安全性和可審計性。建構跨多個供應商的「代理團隊」成為可能，而無需將所有功能塞進單一的單體系統中。

自然語言網路（NLWeb）：讓網路對代理程式友好

網路是圍繞著文件和HTML建構的，而不是圍繞對話和代理程式建構的。用戶長期以來一直透過選單和搜尋框從網站提取訊息，而自動化存取通常依賴不穩定的抓取技術或自訂 API。 NLWeb 提出了不同的模式：網站能夠原生支援自然語言，供人類和人工智慧代理使用。

NLWeb部署的核心是一個中央NLWeb應用程式。—接收自然語言問題、連接到儲存和模型並返回結構化答案的核心服務代碼。您可以將其視為網站的“語言引擎”，負責協調詞嵌入、向量搜尋和LLM推理。

NLWeb協定本身就定義了這種自然語言互動的基本規則。它規範了問題的發送方式和答案的返回方式，通常採用 JSON 格式，並使用 Schema.org 等詞彙表。正如 HTML 規範了文件共享一樣，NLWeb 旨在規範基於語言的網站內容和操作訪問，從而為「人工智慧網路」鋪平道路。

每個 NLWeb 實例也充當 MCP 伺服器。這意味著它可以透過 MCP 將工具（例如「提問」方法）和資料資源暴露給外部 AI 系統。從代理的角度來看，您的網站就變成了另一個 MCP 端點：它可以調用“提問”功能提出問題，接收與您產品目錄中的真實條目關聯的結構化回复，從而避免產生不存在的產品或頁面。

NLWeb 的底層大量依賴嵌入模型和向量資料庫。當您匯入網站內容（例如產品清單、飯店描述、部落格文章）時，NLWeb 會將其轉換為向量嵌入，並儲存在相容的向量儲存庫中，例如 Qdrant、Milvus、Azure AI Search、Snowflake 或 Elasticsearch。當使用者查詢時，NLWeb 會檢索最相似的條目，並將其與使用者的問題一起傳遞給 LLM（生命週期管理模型），以產生基於實際內容的答案。

旅遊預訂網站是 NLWeb 實際應用的絕佳範例。您需要匯入航班、飯店和旅遊套裝行程的結構化資料（理想情況下使用 Schema.org 或 RSS 來源），建立嵌入並儲存它們。當使用者在聊天框中輸入「下週在檀香山找一家有游泳池的親子飯店」時，NLWeb 會查詢向量儲存中的相關飯店，讓 LLM 解析「親子」和其他軟約束條件，並傳回一個基於真實飯店庫存的自然語言答案。同一個 NLWeb 實例，透過其 MCP 接口，還可以讓外部旅行社查詢例如這些飯店附近的素食餐廳，並獲得一致且機器可讀的 JSON 資料。

什麼時候才有必要建構人工智慧代理？

並非所有問題都需要代理；有時，簡單的確定性服務反而更好。當工作流程難以用一套嚴格的規則來概括，當嚴重依賴非結構化數據，或者當例外情況和邊緣情況的數量使得規則維護變得痛苦時，代理就能發揮作用。

有三類用例特別適合使用代理。複雜的決策（例如，在細緻的政策下決定是否批准客戶退款）、難以維護的規則集（例如，複雜的供應商安全審查或合規性檢查）以及以自然語言為主的流程（索賠處理、自由格式的客戶請求、研究任務）。

一個有用的啟發式方法是觀察那些透過無止盡的修補程式和特殊規則而發展出來的系統。如果連資深工程師都難以預測行為或在不破壞其他功能的情況下編寫新的戰略變更程式碼，那麼根本問題就很可能出在語義上，而非純粹的邏輯上。這正是基於邏輯邏輯模型（LLM）的智能體發揮作用的理想領域，它可以對文本、策略和範例進行推理。

相較之下，對於輸入輸出明確的高度確定性任務，傳統程式碼通常更便宜、更快捷、更可靠。如果你的工作是“將此數字轉換為另一種格式”或“運行此 SQL 查詢並返回行”，那麼在此基礎上添加代理循環可能會增加不必要的複雜性。

人工智慧代理的核心組成部分

儘管媒體大肆宣傳，但設計良好的智能體的內部結構其實相當簡單。幾乎所有模式都可歸結為三大支柱：進行推理的模型、連結外在世界的工具、約束和指導行為的指令。

此模型即決策引擎不同的邏輯邏輯模型（LLM）在推理品質、延遲和成本之間進行權衡。一個常見且務實的策略是：首先使用強大的模型來建立品質基準，並了解在你的領域中「優秀」的標準是什麼，然後逐步測試規模更小或成本更低的模型，用於分類或檢索等對推理能力要求不高的子任務。

工具將代理的功能擴展到純文字之外。它們是代理可以呼叫的函數、API 或服務：例如查詢資料庫、發送電子郵件、搜尋網路、透過電腦使用模型與傳統使用者介面互動等等。設計良好的工具應具備完善的文檔，能夠在不同代理之間重複使用，並且最好透過 MCP 等標準協議公開。

指示是代理人中最被低估的部分。僅僅「提供幫助」是不夠的。高品質的指導手冊應該詳細說明如何分解任務、在資訊缺失時如何應對、在哪些情況下應該優先選擇哪些工具、成功的標準是什麼以及應該避免哪些問題。許多團隊成功地將現有的標準作業程序 (SOP)、幫助中心文件或內部操作手冊重新利用，將其轉換為 LLM 可以遵循的、編號明確的指南。

使用LLM本身自動產生或改進指令的做法越來越普遍。例如，您可以將說明中心文章作為元提示輸入，要求模型將其重寫為一組清晰、編號的代理指令，包括對特殊情況的明確處理。這樣可以確保代理行為與不斷更新的文件保持一致。

編排模式：單智能體系統與多智能體系統

在底層，代理程式會循環執行。觀察當前狀態，決定要做什麼，執行操作（通常透過工具），更新上下文，並重複此過程，直到滿足停止條件（目標達成、出錯、使用者介入或觸發安全機制）。這種「代理循環」將一次性的 LLM 呼叫轉換為持續的工作流程引擎。

最簡單的架構是帶有工具的單一代理。它接收用戶訊息，分析訊息內容，決定呼叫哪些工具，並傳回結果。框架通常會提供一個運行器元件，該元件會持續呼叫模型，直到滿足某些終止條件——例如「沒有更多有用的工具呼叫」或「已產生結構化輸出」。這種模式非常適合早期版本和範圍明確的問題。

隨著複雜性的增加，團隊通常會轉向多智能體拓樸結構。主要有兩種模式。在管理者模式下，一個中央「協調者」代理將子任務委派給以工具形式呈現的專門代理——例如，不同語言的翻譯者、研究代理和評論代理。管理者保持全域控制，並將所有功能整合在一起。

第二種模式更加分散。在這裡，當客服人員偵測到請求超出自身職責範圍時，會將工作轉交給其他同事。例如，分診客服人員可以將客戶訊息路由至技術支援、銷售或訂單管理客服人員，每個客服人員都有各自的指示和工具。控制流在客服人員之間跳轉，沒有單一的中央規劃器。

這兩種模式都可以在更大範圍內與A2A自然結合。在產品或微服務邊界內，您可以使用協調器加專家的模型，而在公司或部門之間，您可以依靠 A2A 與外部擁有的代理進行通信，這些代理透過代理卡宣傳其能力。

護欄：確保自主代理的安全性和可靠性

賦予代理人自主權也意味著接受新的風險它們可能會洩漏敏感資料、進行未經授權的更改，或採取會對財務或聲譽造成影響的行動。防護機制就像一層保護層，可以在不削弱代理功能的前提下管理這些風險。

防禦性設計通常包括多層護欄。有些操作針對輸入（阻止或清理惡意或超出範圍的請求），有些操作針對中間模型決策（在執行操作之前檢查是否允許該操作），有些操作針對輸出（在回應離開系統之前過濾安全性、合規性或資料外洩）。

在許多實現中，護欄與智能體的樂觀進展「並行」運行。代理程式循環繼續運行，但某些特定步驟（例如可能編輯資料的工具呼叫）都受到防護檢查的保護。如果防護檢查偵測到違規行為，它可以停止操作、拋出異常或將問題回報給人工操作員。

有些護欄本身是由專注於以下方面的LLM所驅動的： 限制和風險 甚至代理人例如，您可以維護一個專門的客戶流失偵測代理，用於評估收到的客戶訊息，並標記那些顯示客戶取消風險較高的訊息。然後，更高層級的防護機制會利用此訊號觸發客戶挽留工作流程，或要求在結束互動前進行強制性的人工審核。

操作防護措施還包括硬性限制和逃脫艙口。最大步數以避免無限循環、基於風險的閾值強制對敏感操作進行人工批准，以及在模型置信度較低時明確的回退方案，這些都有助於在現實世界環境中安全部署。

從理論到實踐：訂單支援代理的逐步設計

為了更好地理解這些觀點，不妨考慮一下網路商店訂單支援系統的演變過程。初始版本通常只是一個響應式端點：給定一個訂單 ID，從資料庫中取得其狀態並傳回。它不包含推理、記憶體管理或工作流程——這還不是一個代理。

第一個主動步驟是讓模型控制工作流程。與其假設使用者已經提供了訂單 ID，不如將完整的對話內容傳遞給模型，讓模型決定下一步。例如，如果使用者詢問「我的包裹在哪裡？」但沒有提供訂單 ID，模型可以選擇執行「詢問訂單 ID」的操作，提示使用者提供更多資訊。

接下來，將這個推理過程封裝在一個循環中，並引入狀態。每次收到用戶訊息或工具呼叫後，代理程式都會重新評估情況。它可能會獲取訂單、更新上下文、檢查是否有足夠的資訊進行回應，或提出後續問題。只有當發送了明確的回應或滿足終止條件時，循環才會停止。

隨著範圍擴大到狀態檢查之外，代理人開始根據意圖動態選擇工具。例如，發貨問題可能會路由到“open_incident”，退款請求可能會路由到“initiate_refund”，簡單的訂單狀態查詢可能會路由到“get_order_status”。您無需編寫固定的 if-else 分支樹；相反，模型會從您定義的或透過 MCP 發現的工具選單中選擇操作。

此時，您需要針對敏感工具引入防護措施和風險評估。只讀操作可以直接執行，但任何改變狀態的操作（例如退款、取消訂單、修改地址）都必須經過風險感知機制的審核。高風險操作需要人工批准；中度風險操作可能需要額外的確認；低風險操作可以自動執行。

最後，您需要設定操作邊界和人員交接規則。如果智能體嘗試失敗次數達到上限、遇到矛盾資訊或面臨超出其權限範圍的高風險決策，它會將所有累積的上下文資訊轉交給人工支援人員。這種混合方法既能讓您安全地部署自主功能，又能有效控制極端情況。

高階推理框架與現代智能體工具

在這些架構基礎之上，高階推理框架有助於邏輯邏輯模型（LLM）表現得更像有意識的智能體，而不是黑箱預言機。兩種流行的模式是思維鏈（CoT）和反應（理性+行動）。

思維鏈模型要求模型依步驟思考。它將複雜問題分解為中間推理步驟，然後再得出最終答案。研究表明，這可以顯著提高大型模型在推理密集型任務上的性能，並且與智能體循環自然契合：每次工具調用都融入更廣泛的推理鏈中。

ReAct 將推理與工具使用緊密結合。該智能體會在思考、行動和觀察之間交替進行：它會解釋自己的意圖，調用工具，檢查輸出結果，並更新計劃。這種模式是許多早期自主智能體系統（例如 AutoGPT 和 BabyAGI）的基礎，它們能夠動態產生待辦事項清單並根據使用者目標進行優先排序。

現代框架和SDK將這些概念封裝成對開發者友善的抽象概念。諸如 LangChain、LangGraph、CrewAI 或更小的“小型代理”風格工具包之類的庫為工具調用、基於圖的工作流程、多代理編排和持久內存提供了構建模組。許多此類工具鏈也包含相關指南。 VS Code 中的自訂代理來自雲端供應商和 OpenAI 等公司的專有平台為代理商、防護措施和評估添加了更高層級的結構。

重要的是，這些框架越來越多地與 MCP、A2A 和 NLWeb 等協定整合。代理程式不再需要整合一次性連接器，而是可以接入標準化的功能層，透過代理卡與外部代理程式通信，並將支援 NLWeb 的網站視為一流的自然語言 API。這種協議與工具的融合正是建​​構大規模、可互通代理生態系統的關鍵。

所有這些都處於從無程式碼解決方案到高程式碼解決方案的連續譜系中。無程式碼領域的視覺化平台允許非開發人員透過拖放介面和自然語言配置來建立代理工作流程和工具。另一方面，高程式碼環境使工程師能夠精確控制編排、評估和部署，通常會將框架與 AWS、Azure 或類似雲端平台上的自訂基礎架構結合。

在這個過程中，最終獲勝的組織是那些學會建立代理而非僅僅消費代理的組織。理解協議、模式和防護措施，能讓你超越「試用聊天機器人」的實驗階段，邁向強大且可擴展的自動化：從內部分析代理和開發人員輔助工具，到實時協調庫存、支付和客戶體驗的多代理系統。隨著代理商的不斷成熟，這些設計技能將成為真正的競爭優勢。