構(gòu)建企業(yè)級高可靠 AI Agent 系統(tǒng)架構(gòu)設(shè)計的關(guān)鍵要素 原創(chuàng)
本文從以下4個方面詳細(xì)剖析:
- AI Agent 到底是什么?
- 構(gòu)建 AI Agent 的難點是什么?
- AI Agent 框架種類和選型
- AI Agent 架構(gòu)設(shè)計模式
1、AI Agent 到底是什么?
并沒有一個一致的 AI Agent 定義,它們通常通過不同的視角來定義。
OpenAI 采用了一種更高層次、更思想引領(lǐng)式的方法來定義 AI Agent:
AI Agent 是獨立為您完成任務(wù)的系統(tǒng)。
這是一個模糊的表述,它并沒有真正幫助理解什么是 AI Agent。這只是一種思想引領(lǐng),并不實用。
與之相比,Anthropic 的定義是這樣的:
“AI Agent”可以有幾種不同的定義方式。一些客戶將 AI Agent 定義為能夠在較長時間內(nèi)獨立運行的完全自主系統(tǒng),使用各種工具來完成復(fù)雜任務(wù)。還有些人用這個詞來描述更規(guī)范的實現(xiàn),它們遵循預(yù)定義的工作流。在 Anthropic,我們將所有這些變體都?xì)w類為 AI Agent 系統(tǒng),但我們在工作流和 AI Agent 之間畫出了一個重要的架構(gòu)區(qū)別:
工作流是通過預(yù)定義的代碼路徑編排 LLM 和工具的系統(tǒng)。
AI Agent 則是 LLM 動態(tài)指導(dǎo)自身流程和工具使用,控制它們完成任務(wù)的方式的系統(tǒng)。
Anthropic 對 AI Agent 的定義更加精確和具有技術(shù)性。
他們也提到了“AI Agent 系統(tǒng)”這個概念,并將工作流和 AI Agent 都?xì)w類為它的變體。我們看到的幾乎所有生產(chǎn)中的“AI Agent 系統(tǒng)”都是“工作流”和“AI Agent”的組合。
Anthropic 將 AI Agent 定義為“本質(zhì)上只是基于環(huán)境反饋在循環(huán)中使用工具的 LLM”。
這些類型的 AI Agent 由以下參數(shù)確定:
- 要使用的模型
- 要使用的指令(系統(tǒng)提示詞)
- 要使用的工具
你在一個循環(huán)中調(diào)用模型。如果/當(dāng)它決定調(diào)用一個工具時,你運行那個工具,獲取一些觀察/反饋,然后將其傳回 LLM。你一直運行,直到 LLM 決定不調(diào)用工具(或者它調(diào)用一個觸發(fā)停止條件的工具)。
OpenAI 和 Anthropic 都明確指出,工作流是一種與 AI Agent 不同的設(shè)計模式。在那里,LLM 的控制權(quán)更小,流程更具確定性。
OpenAI 和 Anthropic 也都明確指出,你并不總是需要 AI Agent。在許多情況下,工作流更簡單、更可靠、更便宜、更快且性能更好。Anthropic 文章中有一句很棒的話:
在使用 LLM 構(gòu)建應(yīng)用程序時,我們建議尋找盡可能簡單的解決方案,并且只有在需要時才增加復(fù)雜性。這可能意味著根本不需要構(gòu)建 AI Agent 系統(tǒng)。AI Agent 系統(tǒng)通常會在延遲和成本方面做出權(quán)衡以換取更好的任務(wù)性能,你應(yīng)該考慮這種權(quán)衡在何時是合理的。
當(dāng)需要更多復(fù)雜性時,工作流為定義良好的任務(wù)提供了可預(yù)測性和一致性,而當(dāng)需要在大規(guī)模情況下實現(xiàn)靈活性和模型驅(qū)動的決策時,AI Agent 是更好的選擇。
2、構(gòu)建 AI Agent 的難點是什么?
我想大多數(shù)人都會同意構(gòu)建 AI Agent 是困難的?;蛘吒鼫?zhǔn)確地說--構(gòu)建 AI Agent 的原型很容易,但可靠的和企業(yè)級的 AI Agent,能夠支持關(guān)鍵業(yè)務(wù)應(yīng)用的 AI Agent,這是很難的!
棘手的部分正是這個--使其可靠。你可以輕松制作一個看起來不錯的 Demo 演示。但你能用它來支持關(guān)鍵業(yè)務(wù)應(yīng)用嗎?沒有大量工程架構(gòu)設(shè)計和優(yōu)化工作是不行的。
幾個月前,LangChain 對 AI Agent 構(gòu)建者做了一項調(diào)查,問他們:“將更多 AI Agent 投入生產(chǎn)使用的最大限制是什么?”遠(yuǎn)遠(yuǎn)超過其他答案的第一位回答是“性能質(zhì)量”——讓這些 AI Agent 正常工作仍然非常困難。
第一、是什么導(dǎo)致 AI Agent 有時表現(xiàn)不佳?
LLM 搞砸了。
第二、為什么 LLM 會搞砸?
兩個原因:(1)模型不夠好;(2)傳遞給模型的上下文錯誤(或不完整)。
從我們的經(jīng)驗來看,通常是第(2)種情況。是什么導(dǎo)致了這種情況?
- 系統(tǒng)提示詞不完整或簡短
- 用戶輸入模糊
- 無法訪問正確的工具
- 工具描述不佳
- 沒有傳入正確的上下文
- 工具響應(yīng)格式不佳
構(gòu)建可靠的 AI Agent 系統(tǒng)的難點是確保在每一步中,LLM 都有合適的上下文。這包括控制輸入到 LLM 的確切內(nèi)容,以及運行適當(dāng)?shù)牟襟E來生成相關(guān)內(nèi)容。
在我們討論 AI Agent 框架時,記住這一點很有幫助。任何使控制確切傳入 LLM 的內(nèi)容變得更困難的框架,只是在給你添麻煩。
3、AI Agent 框架種類和選型
AI Agent 框架在幾個維度上有所不同。理解這些維度是正確選型 AI Agent 框架的關(guān)鍵。
第一、工作流與 AI Agent
大多數(shù)框架包含更高層次的 AI Agent 抽象。一些框架包含了常見工作流的某種抽象。LangGraph 是一個用于構(gòu)建 AI Agent 系統(tǒng)的低層次編排框架。LangGraph 支持工作流、AI Agent 以及兩者之間的任何東西。我們認(rèn)為這是至關(guān)重要的。如上所述,大多數(shù)生產(chǎn)中的 AI Agent 系統(tǒng)是工作流和 AI Agent 的組合。一個生產(chǎn)就緒的框架需要同時支持兩者。
讓我們記住構(gòu)建可靠 AI Agent 的難點--確保 LLM 有正確的上下文。工作流有用的部分原因是它們使向 LLM 傳遞正確上下文變得容易。你決定數(shù)據(jù)流動的確切方式。
當(dāng)你思考要在 AI 應(yīng)用中使用“工作流”還是“AI Agent”,需要考慮兩件事:
- 可預(yù)測性與代理性
- 低門檻,高上限
第二、可預(yù)測性與代理性
隨著你的系統(tǒng)變得更加具有代理性,它將變得不那么可預(yù)測。
有時你希望或需要你的系統(tǒng)是可預(yù)測的——為了用戶信任、監(jiān)管原因或其他原因。
可靠性并不完全與可預(yù)測性一致,但在實踐中它們可以密切相關(guān)。
你希望在這條曲線上的位置相當(dāng)具體于你的 AI 應(yīng)用程序。LangGraph 可以用于構(gòu)建位于這條曲線任何位置的應(yīng)用程序,允許你移動到你想要的位置。
第三、低門檻,高上限
當(dāng)思考框架時,考慮它們的門檻和上限是有幫助的:
- 低門檻:一個低門檻框架對初學(xué)者友好,易于上手。
- 高門檻:一個有高門檻的框架意味著它有陡峭的學(xué)習(xí)曲線,需要相當(dāng)多的知識或?qū)I(yè)知識才能有效地開始使用。
- 低上限:一個有低上限的框架意味著它在能做的事情上有局限性(你會很快超出它的能力)。
- 高上限:一個高上限框架為高級用例提供廣泛的能力和靈活性(它會隨著你一起成長)。
工作流框架提供了高上限,但也帶來了高門檻--你需要自己編寫大量的代理邏輯。
AI Agent 框架低門檻,但上限低--易于上手,但對于非平凡的用例則不夠用。
LangGraph 旨在具有易于上手(內(nèi)置的 AI Agent 抽象使上手變得容易)和高上限(底層功能以實現(xiàn)高級用例)的特點。
第四、聲明式與非聲明式
聲明式框架有其好處。也有缺點。這是程序員之間看似無休止的辯論,每個人都有自己的偏好。
當(dāng)人們說非聲明式時,他們通常暗示命令式是替代品。
大多數(shù)人會將 LangGraph 描述為一個聲明式框架。這只部分正確。
首先,盡管節(jié)點和邊之間的連接是以聲明式的方式完成的,但實際的節(jié)點和邊無非是 Python 或 TypeScript 函數(shù)。因此,LangGraph 是一種介于聲明式和命令式之間的混合體。
其次,實際上支持除了推薦的聲明式 API 之外的其他 API。具體來說,支持函數(shù)式和事件驅(qū)動 API。雖然我們認(rèn)為聲明式 API 是一個有用的思維模型,但我們認(rèn)識到它并不適合每個人。
關(guān)于 LangGraph 的一個常見評論是它類似于 Tensorflow(一個聲明式深度學(xué)習(xí)框架),而像 Agents SDK 這樣的框架則類似于 Pytorch(一個命令式深度學(xué)習(xí)框架)。
這是不正確的。像 Agents SDK(以及原始 LangChain、CrewAI 等)這樣的框架既不是聲明式的,也不是命令式的——它們只是抽象。它們有一個 AI Agent 抽象(一個 Python 類),它包含運行 AI Agent 的大量內(nèi)部邏輯。它們不是真正的編排框架。它們只是抽象。
第五、AI Agent 抽象
大多數(shù) AI Agent 框架包含一個 AI Agent 抽象。它們通常從一個涉及提示詞、模型和工具的類開始。然后它們添加一些更多的參數(shù)……然后更多……然后甚至更多。最終,你得到了一長串參數(shù),這些參數(shù)控制著多種行為,所有這些都抽象在一個類后面。如果你想查看發(fā)生了什么,或者改變邏輯,你必須進(jìn)入類并修改源代碼。
這些抽象最終使得很難理解或控制在所有步驟中到底有什么進(jìn)入 LLM。這很重要--擁有這種控制對于構(gòu)建可靠 AI Agent 至關(guān)重要(如上所述)。這是 AI Agent 抽象的危險。
我們在這方面吃了不少苦頭。這是原始 LangChain 鏈和 AI Agent 的問題。它們提供了阻礙的抽象。兩年前的一個原始抽象是一個 AI Agent 類,它接受模型、提示詞和工具。這不是一個新概念。當(dāng)時它沒有提供足夠的控制,現(xiàn)在也沒有。
說清楚,這些 AI Agent 抽象確實有一些價值。它們使上手變得容易。但我不認(rèn)為這些 AI Agent 抽象足以構(gòu)建可靠的 AI Agent(也許永遠(yuǎn)不夠)。
我們認(rèn)為,最好將這些 AI Agent 抽象視為 Keras。它們提供了更高層次的抽象,以便輕松上手。但至關(guān)重要的是要確保它們是建立在更低層次的框架之上的,這樣你就不會超出它的能力。
這就是為什么在 LangGraph 之上構(gòu)建了 AI Agent 抽象。這提供了一種輕松上手 AI Agent 的方式,但如果你需要逃脫到底層 LangGraph,你可以輕松做到。
第六、多 AI Agent
通常,AI Agent 系統(tǒng)不會只包含一個 AI Agent,它們會包含多個。OpenAI 在他們的報告中說:
對于許多復(fù)雜的工作流,將提示詞和工具分配到多個 AI Agent 中可以提高性能和可擴(kuò)展性。當(dāng)你的 AI Agent 無法遵循復(fù)雜指令或始終選擇錯誤的工具時,你可能需要進(jìn)一步分解你的系統(tǒng)并引入更多的不同 AI Agent。
多 AI Agent 系統(tǒng)的關(guān)鍵部分是它們?nèi)绾瓮ㄐ?。同樣,?gòu)建 AI Agent 的難點是將正確的上下文傳遞給 LLM。這些 AI Agent 之間的通信很重要。
有很多方法可以做到這一點!交接是一種方式。這是 Agents SDK 的一個 AI Agent 抽象。
但這些 AI Agent 之間通信的最佳方式有時可能是工作流。這種工作流和 AI Agent 的混合通常能提供最佳的可靠性。
同樣 AI Agent 系統(tǒng)不僅僅是工作流,或者只是一個 AI Agent。它們可以是而且通常是兩者的組合。
總之,以上 AI Agent 的6個種類,在實際的業(yè)務(wù)場景中可以自由組合,正如 Anthropic 在他們的博客文章中指出的:
組合和定制這些模式
這些構(gòu)建塊并不是規(guī)定性的。它們是開發(fā)者可以根據(jù)不同用例塑造和組合的常見模式。
4、AI Agent 架構(gòu)設(shè)計模式
根據(jù)我多年的架構(gòu)設(shè)計經(jīng)驗,整理總結(jié)了一些針對 AI Agent 6種架構(gòu)模式,以下詳細(xì)剖析。
第一、 AI Agent 路由分發(fā)架構(gòu)模式
當(dāng)用戶輸入一個 Prompt 查詢時,該查詢會被發(fā)送到路由轉(zhuǎn)發(fā)模塊,而路由轉(zhuǎn)發(fā)模塊則扮演著對輸入 Prompt 進(jìn)行分類的角色。
如果 Prompt 查詢是可以識別的,那么它會被路由到小模型進(jìn)行處理,這通常是一個更準(zhǔn)確、響應(yīng)更快且成本更低的操作。然而,如果 Prompt 查詢無法被識別,那么它將由大模型來處理。盡管大模型的運行成本較高,但它能夠成功返回更多種類型查詢的答案。通過這種方式,大模型應(yīng)用產(chǎn)品可以在成本、性能和用戶體驗之間實現(xiàn)平衡。
第二、AI Agent 代理架構(gòu)模式
在任何一個生態(tài)系統(tǒng)中,都會有多個針對特定任務(wù)領(lǐng)域的專家,并行工作以處理特定類型的查詢,然后將這些響應(yīng)整合在一起,形成一個全面的答案。
這樣的架構(gòu)模式非常適合復(fù)雜的問題解決場景,在這種場景中,問題的不同方面需要不同的專業(yè)知識,就像一個由專家組成的小組,每個專家負(fù)責(zé)處理更大問題的一個方面。
更大的模型(比如:Qwen3-235B)負(fù)責(zé)理解上下文,并將其分解為特定的任務(wù)或信息請求,這些任務(wù)或信息請求被傳遞給更小的代理模型。這些代理模型可能是較小模型,它們已經(jīng)接受過特定任務(wù)的訓(xùn)練,或者是具有特定功能的通用模型,比如:BERT、Qwen3-7B、上下文提示和函數(shù)調(diào)用。
第三、基于緩存的微調(diào) AI Agent 架構(gòu)模式
我們將緩存和微調(diào)引入到 AI Agent 應(yīng)用架構(gòu)中,可以解決成本高、推理速度慢以及幻覺等組合問題。
通過緩存初始結(jié)果,能夠在后續(xù)查詢中迅速提供答案,從而顯著提高了效率。
當(dāng)我們累積了足夠的數(shù)據(jù)后,微調(diào)層將啟動,利用早期交互的反饋,進(jìn)一步完善一個更為專業(yè)化的私有大模型。
專有私有大模型不僅簡化了操作流程,也使專業(yè)知識更好地適應(yīng)特定任務(wù),使其在需要高度精確性和適應(yīng)性的環(huán)境中,比如:客戶服務(wù)或個性化內(nèi)容創(chuàng)建,表現(xiàn)得更為高效。
對于剛?cè)腴T的用戶,可以選擇使用預(yù)先構(gòu)建的服務(wù),比如:GPTCache,或者使用常見的緩存數(shù)據(jù)庫:Redis、Cassandra、Memcached 來運行自己的服務(wù)。
第四、面向目標(biāo)的 AI Agent 架構(gòu)模式
對于用戶的 Prompt 提示詞,AI Agent 會基于大模型先做規(guī)劃(Planning),拆解成若干子任務(wù),然后對每個子任務(wù)分別執(zhí)行(Action),同時對每一步的執(zhí)行結(jié)果進(jìn)行觀測(Observation),如果觀測結(jié)果合格,就直接返回給用戶最終答案,如果觀測結(jié)果不合格或者執(zhí)行出錯,會重新進(jìn)行規(guī)劃(Replanning)。
這種面向目標(biāo)的 AI Agent 架構(gòu)模式非常常見,也是 AGI 大模型時代,每一個程序員同學(xué)都需要掌握的架構(gòu)設(shè)計模式。
第五、AI Agent 智能體組合架構(gòu)模式
該架構(gòu)設(shè)計模式強(qiáng)調(diào)了靈活性,通過模塊化 AI 系統(tǒng),能自我重新配置以優(yōu)化任務(wù)性能。這就像一個多功能工具,可以根據(jù)需求選擇和激活不同的功能模塊,對于需要為各種客戶需求或產(chǎn)品需求定制解決方案的企業(yè)來說,這是非常有效的。
我們可以通過使用各種自主代理框架和體系結(jié)構(gòu)來開發(fā)每個 AI Agent,比如:CrewAI、Langchain、LLamaIndex、Microsoft Autogen 和 superAGI等。
通過組合不同的模塊,一個 AI Agent 可以專注于預(yù)測,一個處理預(yù)約查詢,一個專注于生成消息,一個 AI Agent 來更新數(shù)據(jù)庫。將來,隨著專業(yè) AI 公司提供的特定服務(wù)的增多,我們可以將一個模塊替換為外部或第三方服務(wù),以處理特定的任務(wù)或領(lǐng)域的問題。
第六、AI Agent 雙重安全架構(gòu)設(shè)計模式
圍繞大模型的核心安全性至少包含兩個關(guān)鍵組件:一是用戶組件,我們將其稱為用戶 Proxy 代理;二是防火墻,它為大模型提供了保護(hù)層。
用戶 Proxy 代理在查詢發(fā)出和返回的過程中對用戶的 Prompt 查詢進(jìn)行攔截。該代理負(fù)責(zé)清除個人身份信息和知識產(chǎn)權(quán)信息,記錄查詢的內(nèi)容,并優(yōu)化成本。
防火墻則保護(hù)大模型及其所使用的基礎(chǔ)設(shè)施。盡管我們對人們?nèi)绾尾倏v大模型以揭示其潛在的訓(xùn)練數(shù)據(jù)、潛在功能以及當(dāng)今惡意行為知之甚少,但我們知道這些強(qiáng)大的大模型是脆弱的。
在安全性相關(guān)的技術(shù)棧中,可能還存在其他安全層,但對于用戶的查詢路徑來說,Proxy 代理和防火墻是最關(guān)鍵的。
?? 輪到你了:你認(rèn)為 AI Agent 企業(yè)級落地還有哪些注意點?
本文轉(zhuǎn)載自??玄姐聊AGI?? 作者:玄姐
