本文從以下4個方面詳細剖析：

• AI Agent 到底是什么？
• 構建 AI Agent 的難點是什么？
• AI Agent 框架種類和選型
• AI Agent 架構設計模式

1、AI Agent 到底是什么？

并沒有一個一致的 AI Agent 定義，它們通常通過不同的視角來定義。

OpenAI 采用了一種更高層次、更思想引領式的方法來定義 AI Agent：

AI Agent 是獨立為您完成任務的系統。

這是一個模糊的表述，它并沒有真正幫助理解什么是 AI Agent。這只是一種思想引領，并不實用。

與之相比，Anthropic 的定義是這樣的：

“AI Agent”可以有幾種不同的定義方式。一些客戶將 AI Agent 定義為能夠在較長時間內獨立運行的完全自主系統，使用各種工具來完成復雜任務。還有些人用這個詞來描述更規范的實現，它們遵循預定義的工作流。在 Anthropic，我們將所有這些變體都歸類為 AI Agent 系統，但我們在工作流和 AI Agent 之間畫出了一個重要的架構區別：

工作流是通過預定義的代碼路徑編排 LLM 和工具的系統。

AI Agent 則是 LLM 動態指導自身流程和工具使用，控制它們完成任務的方式的系統。

Anthropic 對 AI Agent 的定義更加精確和具有技術性。

他們也提到了“AI Agent 系統”這個概念，并將工作流和 AI Agent 都歸類為它的變體。我們看到的幾乎所有生產中的“AI Agent 系統”都是“工作流”和“AI Agent”的組合。

Anthropic 將 AI Agent 定義為“本質上只是基于環境反饋在循環中使用工具的 LLM”。

這些類型的 AI Agent 由以下參數確定：

• 要使用的模型
• 要使用的指令（系統提示詞）
• 要使用的工具

你在一個循環中調用模型。如果/當它決定調用一個工具時，你運行那個工具，獲取一些觀察/反饋，然后將其傳回 LLM。你一直運行，直到 LLM 決定不調用工具（或者它調用一個觸發停止條件的工具）。

OpenAI 和 Anthropic 都明確指出，工作流是一種與 AI Agent 不同的設計模式。在那里，LLM 的控制權更小，流程更具確定性。

OpenAI 和 Anthropic 也都明確指出，你并不總是需要 AI Agent。在許多情況下，工作流更簡單、更可靠、更便宜、更快且性能更好。Anthropic 文章中有一句很棒的話：

在使用 LLM 構建應用程序時，我們建議尋找盡可能簡單的解決方案，并且只有在需要時才增加復雜性。這可能意味著根本不需要構建 AI Agent 系統。AI Agent 系統通常會在延遲和成本方面做出權衡以換取更好的任務性能，你應該考慮這種權衡在何時是合理的。

當需要更多復雜性時，工作流為定義良好的任務提供了可預測性和一致性，而當需要在大規模情況下實現靈活性和模型驅動的決策時，AI Agent 是更好的選擇。

2、構建 AI Agent 的難點是什么？

我想大多數人都會同意構建 AI Agent 是困難的。或者更準確地說--構建 AI Agent 的原型很容易，但可靠的和企業級的 AI Agent，能夠支持關鍵業務應用的 AI Agent，這是很難的！

棘手的部分正是這個--使其可靠。你可以輕松制作一個看起來不錯的 Demo 演示。但你能用它來支持關鍵業務應用嗎？沒有大量工程架構設計和優化工作是不行的。

幾個月前，LangChain 對 AI Agent 構建者做了一項調查，問他們：“將更多 AI Agent 投入生產使用的最大限制是什么？”遠遠超過其他答案的第一位回答是“性能質量”——讓這些 AI Agent 正常工作仍然非常困難。

第一、是什么導致 AI Agent 有時表現不佳？

LLM 搞砸了。

第二、為什么 LLM 會搞砸？

兩個原因：（1）模型不夠好；（2）傳遞給模型的上下文錯誤（或不完整）。

從我們的經驗來看，通常是第（2）種情況。是什么導致了這種情況？

• 系統提示詞不完整或簡短
• 用戶輸入模糊
• 無法訪問正確的工具
• 工具描述不佳
• 沒有傳入正確的上下文
• 工具響應格式不佳

構建可靠的 AI Agent 系統的難點是確保在每一步中，LLM 都有合適的上下文。這包括控制輸入到 LLM 的確切內容，以及運行適當的步驟來生成相關內容。

在我們討論 AI Agent 框架時，記住這一點很有幫助。任何使控制確切傳入 LLM 的內容變得更困難的框架，只是在給你添麻煩。

3、AI Agent 框架種類和選型

AI Agent 框架在幾個維度上有所不同。理解這些維度是正確選型 AI Agent 框架的關鍵。

第一、工作流與 AI Agent

大多數框架包含更高層次的 AI Agent 抽象。一些框架包含了常見工作流的某種抽象。LangGraph 是一個用于構建 AI Agent 系統的低層次編排框架。LangGraph 支持工作流、AI Agent 以及兩者之間的任何東西。我們認為這是至關重要的。如上所述，大多數生產中的 AI Agent 系統是工作流和 AI Agent 的組合。一個生產就緒的框架需要同時支持兩者。

讓我們記住構建可靠 AI Agent 的難點--確保 LLM 有正確的上下文。工作流有用的部分原因是它們使向 LLM 傳遞正確上下文變得容易。你決定數據流動的確切方式。

當你思考要在 AI 應用中使用“工作流”還是“AI Agent”，需要考慮兩件事：

• 可預測性與代理性
• 低門檻，高上限

第二、可預測性與代理性

隨著你的系統變得更加具有代理性，它將變得不那么可預測。

有時你希望或需要你的系統是可預測的——為了用戶信任、監管原因或其他原因。

可靠性并不完全與可預測性一致，但在實踐中它們可以密切相關。

你希望在這條曲線上的位置相當具體于你的 AI 應用程序。LangGraph 可以用于構建位于這條曲線任何位置的應用程序，允許你移動到你想要的位置。

第三、低門檻，高上限

當思考框架時，考慮它們的門檻和上限是有幫助的：

• 低門檻：一個低門檻框架對初學者友好，易于上手。
• 高門檻：一個有高門檻的框架意味著它有陡峭的學習曲線，需要相當多的知識或專業知識才能有效地開始使用。
• 低上限：一個有低上限的框架意味著它在能做的事情上有局限性（你會很快超出它的能力）。
• 高上限：一個高上限框架為高級用例提供廣泛的能力和靈活性（它會隨著你一起成長）。

工作流框架提供了高上限，但也帶來了高門檻--你需要自己編寫大量的代理邏輯。

AI Agent 框架低門檻，但上限低--易于上手，但對于非平凡的用例則不夠用。

LangGraph 旨在具有易于上手（內置的 AI Agent 抽象使上手變得容易）和高上限（底層功能以實現高級用例）的特點。

第四、聲明式與非聲明式

聲明式框架有其好處。也有缺點。這是程序員之間看似無休止的辯論，每個人都有自己的偏好。

當人們說非聲明式時，他們通常暗示命令式是替代品。

大多數人會將 LangGraph 描述為一個聲明式框架。這只部分正確。

首先，盡管節點和邊之間的連接是以聲明式的方式完成的，但實際的節點和邊無非是 Python 或 TypeScript 函數。因此，LangGraph 是一種介于聲明式和命令式之間的混合體。

其次，實際上支持除了推薦的聲明式 API 之外的其他 API。具體來說，支持函數式和事件驅動 API。雖然我們認為聲明式 API 是一個有用的思維模型，但我們認識到它并不適合每個人。

關于 LangGraph 的一個常見評論是它類似于 Tensorflow（一個聲明式深度學習框架），而像 Agents SDK 這樣的框架則類似于 Pytorch（一個命令式深度學習框架）。

這是不正確的。像 Agents SDK（以及原始 LangChain、CrewAI 等）這樣的框架既不是聲明式的，也不是命令式的——它們只是抽象。它們有一個 AI Agent 抽象（一個 Python 類），它包含運行 AI Agent 的大量內部邏輯。它們不是真正的編排框架。它們只是抽象。

第五、AI Agent 抽象

大多數 AI Agent 框架包含一個 AI Agent 抽象。它們通常從一個涉及提示詞、模型和工具的類開始。然后它們添加一些更多的參數……然后更多……然后甚至更多。最終，你得到了一長串參數，這些參數控制著多種行為，所有這些都抽象在一個類后面。如果你想查看發生了什么，或者改變邏輯，你必須進入類并修改源代碼。

這些抽象最終使得很難理解或控制在所有步驟中到底有什么進入 LLM。這很重要--擁有這種控制對于構建可靠 AI Agent 至關重要（如上所述）。這是 AI Agent 抽象的危險。

我們在這方面吃了不少苦頭。這是原始 LangChain 鏈和 AI Agent 的問題。它們提供了阻礙的抽象。兩年前的一個原始抽象是一個 AI Agent 類，它接受模型、提示詞和工具。這不是一個新概念。當時它沒有提供足夠的控制，現在也沒有。

說清楚，這些 AI Agent 抽象確實有一些價值。它們使上手變得容易。但我不認為這些 AI Agent 抽象足以構建可靠的 AI Agent（也許永遠不夠）。

我們認為，最好將這些 AI Agent 抽象視為 Keras。它們提供了更高層次的抽象，以便輕松上手。但至關重要的是要確保它們是建立在更低層次的框架之上的，這樣你就不會超出它的能力。

這就是為什么在 LangGraph 之上構建了 AI Agent 抽象。這提供了一種輕松上手 AI Agent 的方式，但如果你需要逃脫到底層 LangGraph，你可以輕松做到。

第六、多 AI Agent

通常，AI Agent 系統不會只包含一個 AI Agent，它們會包含多個。OpenAI 在他們的報告中說：

對于許多復雜的工作流，將提示詞和工具分配到多個 AI Agent 中可以提高性能和可擴展性。當你的 AI Agent 無法遵循復雜指令或始終選擇錯誤的工具時，你可能需要進一步分解你的系統并引入更多的不同 AI Agent。

多 AI Agent 系統的關鍵部分是它們如何通信。同樣，構建 AI Agent 的難點是將正確的上下文傳遞給 LLM。這些 AI Agent 之間的通信很重要。

有很多方法可以做到這一點！交接是一種方式。這是 Agents SDK 的一個 AI Agent 抽象。

但這些 AI Agent 之間通信的最佳方式有時可能是工作流。這種工作流和 AI Agent 的混合通常能提供最佳的可靠性。

同樣 AI Agent 系統不僅僅是工作流，或者只是一個 AI Agent。它們可以是而且通常是兩者的組合。

總之，以上 AI Agent 的6個種類，在實際的業務場景中可以自由組合，正如 Anthropic 在他們的博客文章中指出的：

組合和定制這些模式

這些構建塊并不是規定性的。它們是開發者可以根據不同用例塑造和組合的常見模式。

4、AI Agent 架構設計模式

根據我多年的架構設計經驗，整理總結了一些針對 AI Agent 6種架構模式，以下詳細剖析。

第一、 AI Agent 路由分發架構模式

當用戶輸入一個 Prompt 查詢時，該查詢會被發送到路由轉發模塊，而路由轉發模塊則扮演著對輸入 Prompt 進行分類的角色。

如果 Prompt 查詢是可以識別的，那么它會被路由到小模型進行處理，這通常是一個更準確、響應更快且成本更低的操作。然而，如果 Prompt 查詢無法被識別，那么它將由大模型來處理。盡管大模型的運行成本較高，但它能夠成功返回更多種類型查詢的答案。通過這種方式，大模型應用產品可以在成本、性能和用戶體驗之間實現平衡。

第二、AI Agent 代理架構模式

在任何一個生態系統中，都會有多個針對特定任務領域的專家，并行工作以處理特定類型的查詢，然后將這些響應整合在一起，形成一個全面的答案。

這樣的架構模式非常適合復雜的問題解決場景，在這種場景中，問題的不同方面需要不同的專業知識，就像一個由專家組成的小組，每個專家負責處理更大問題的一個方面。

更大的模型（比如：Qwen3-235B）負責理解上下文，并將其分解為特定的任務或信息請求，這些任務或信息請求被傳遞給更小的代理模型。這些代理模型可能是較小模型，它們已經接受過特定任務的訓練，或者是具有特定功能的通用模型，比如：BERT、Qwen3-7B、上下文提示和函數調用。

第三、基于緩存的微調 AI Agent 架構模式

我們將緩存和微調引入到 AI Agent 應用架構中，可以解決成本高、推理速度慢以及幻覺等組合問題。

通過緩存初始結果，能夠在后續查詢中迅速提供答案，從而顯著提高了效率。

當我們累積了足夠的數據后，微調層將啟動，利用早期交互的反饋，進一步完善一個更為專業化的私有大模型。

專有私有大模型不僅簡化了操作流程，也使專業知識更好地適應特定任務，使其在需要高度精確性和適應性的環境中，比如：客戶服務或個性化內容創建，表現得更為高效。

對于剛入門的用戶，可以選擇使用預先構建的服務，比如：GPTCache，或者使用常見的緩存數據庫：Redis、Cassandra、Memcached 來運行自己的服務。

第四、面向目標的 AI Agent 架構模式

對于用戶的 Prompt 提示詞，AI Agent 會基于大模型先做規劃（Planning），拆解成若干子任務，然后對每個子任務分別執行（Action），同時對每一步的執行結果進行觀測（Observation），如果觀測結果合格，就直接返回給用戶最終答案，如果觀測結果不合格或者執行出錯，會重新進行規劃（Replanning）。

這種面向目標的 AI Agent 架構模式非常常見，也是 AGI 大模型時代，每一個程序員同學都需要掌握的架構設計模式。

第五、AI Agent 智能體組合架構模式

該架構設計模式強調了靈活性，通過模塊化 AI 系統，能自我重新配置以優化任務性能。這就像一個多功能工具，可以根據需求選擇和激活不同的功能模塊，對于需要為各種客戶需求或產品需求定制解決方案的企業來說，這是非常有效的。

我們可以通過使用各種自主代理框架和體系結構來開發每個 AI Agent，比如：CrewAI、Langchain、LLamaIndex、Microsoft Autogen 和 superAGI等。

通過組合不同的模塊，一個 AI Agent 可以專注于預測，一個處理預約查詢，一個專注于生成消息，一個 AI Agent 來更新數據庫。將來，隨著專業 AI 公司提供的特定服務的增多，我們可以將一個模塊替換為外部或第三方服務，以處理特定的任務或領域的問題。

第六、AI Agent 雙重安全架構設計模式

圍繞大模型的核心安全性至少包含兩個關鍵組件：一是用戶組件，我們將其稱為用戶 Proxy 代理；二是防火墻，它為大模型提供了保護層。

用戶 Proxy 代理在查詢發出和返回的過程中對用戶的 Prompt 查詢進行攔截。該代理負責清除個人身份信息和知識產權信息，記錄查詢的內容，并優化成本。

防火墻則保護大模型及其所使用的基礎設施。盡管我們對人們如何操縱大模型以揭示其潛在的訓練數據、潛在功能以及當今惡意行為知之甚少，但我們知道這些強大的大模型是脆弱的。

在安全性相關的技術棧中，可能還存在其他安全層，但對于用戶的查詢路徑來說，Proxy 代理和防火墻是最關鍵的。

?? 輪到你了：你認為 AI Agent 企業級落地還有哪些注意點？

本文轉載自??玄姐聊AGI??  作者：玄姐