來源：PaperAgent

2025新年伊始， 今年 將是 “Agentic系統(tǒng)之年 ”， “2025將會出現(xiàn)真正Agent ” ，時不我待， 請簽收 屬于你的 AI Agents技術(shù)棧 綜述 。

理解AI Agents生態(tài)

盡管我們看到了大量關(guān)于Agent棧和市場的分類圖，但我們往往不同意它們的分類方式，發(fā)現(xiàn)它們很少反映開發(fā)者實際使用的。 在過去幾個月中，隨著在內(nèi)存、工具使用、安全執(zhí)行和部署方面的進(jìn)步，Agent軟件生態(tài)系統(tǒng)有了顯著的發(fā)展，因此，能夠真正落地的“Agent技術(shù)棧（agent stack）”應(yīng)該是怎樣尼？

AI Agents技術(shù)棧，被組織成三個關(guān)鍵層：Agent托管/服務(wù)、Agent框架，以及LLM模型和存儲。

從LLM到LLM Agent

在2022年和2023年，我們看到了LLM框架和SDK的興起，比如LangChain（2022年10月發(fā)布）和LlamaIndex（2022年11月發(fā)布）。同時，我們也看到了幾個“標(biāo)準(zhǔn)”平臺的建立，這些平臺通過API消費LLMs以及自部署LLM推理（vLLM和Ollama）。

在2024年，我們看到了對AI“Agent”的興趣急劇轉(zhuǎn)變，更廣泛地說，是對復(fù)合系統(tǒng)的興趣。盡管“Agent”這個術(shù)語在AI中已經(jīng)存在了幾十年（特別是在強(qiáng)化學(xué)習(xí)中），但在后ChatGPT時代，“Agent”已經(jīng)成為一個松散定義的術(shù)語，通常指的是被賦予輸出動作（工具調(diào)用）并在自治設(shè)置中運行的LLM。從LLM到Agent所需的工具使用、自治執(zhí)行和內(nèi)存的結(jié)合，促使一個新的Agent棧發(fā)展。

Agent技術(shù)棧的獨特之處

與基本的LLM聊天機(jī)器人相比，Agent是一個更復(fù)雜的工程挑戰(zhàn)，因為它們需要狀態(tài)管理（保留消息/事件歷史記錄，存儲長期記憶，執(zhí)行多個LLM調(diào)用在一個Agent循環(huán)中）和工具執(zhí)行（安全執(zhí)行LLM輸出的動作并返回結(jié)果）。

因此，AI Agent棧與標(biāo)準(zhǔn)的LLM棧看起來非常不同。讓我們從模型服務(wù)層開始，分解今天的AI Agent棧：

模型服務(wù)

AI Agent的核心是LLM。 要使用LLM，模型需要通過推理引擎提供服務(wù)，通常運行在付費API服務(wù)后面。

OpenAI和Anthropic在基于封閉API的模型推理提供商中領(lǐng)先，擁有私有前沿模型。Together.AI、Fireworks和Groq是提供開放權(quán)重模型（例如Llama 3）背后的付費API的流行選項。在本地模型推理提供商中，我們最常見到vLLM領(lǐng)先于生產(chǎn)級GPU基礎(chǔ)服務(wù)負(fù)載。SGLang是一個新興項目，擁有類似的開發(fā)者受眾。在業(yè)余愛好者（“AI愛好者”）中，Ollama和LM Studio是兩個流行的選項，用于在您自己的計算機(jī)上運行模型（例如M系列Apple Macbooks）。

存儲

存儲是定義為有狀態(tài)的Agent的基本構(gòu)建塊——Agent由持久狀態(tài)定義，如他們的對話歷史記錄、記憶和外部數(shù)據(jù)源，他們用于RAG。 像Chroma、Weaviate、Pinecone、Qdrant和Milvus這樣的向量數(shù)據(jù)庫很受歡迎，用于存儲Agent的“外部記憶”，允許Agent利用數(shù)據(jù)源和對話歷史記錄，這些數(shù)據(jù)太大，無法放入上下文窗口。 Postgres是一個自80年代以來就存在的傳統(tǒng)數(shù)據(jù)庫，現(xiàn)在也通過pgvector擴(kuò)展支持向量搜索。 基于Postgres的公司如Neon（無服務(wù)器Postgres）和Supabase也為Agent提供基于嵌入的搜索和存儲。

工具和庫

標(biāo)準(zhǔn)AI聊天機(jī)器人和AI Agent之間的一個主要區(qū)別是Agent調(diào)用“工具”（或“功能”）的能力。在大多數(shù)情況下，這種動作的機(jī)制是LLM生成結(jié)構(gòu)化輸出（例如JSON對象），指定要調(diào)用的函數(shù)和提供的參數(shù)。Agent工具執(zhí)行的一個常見混淆點是，工具執(zhí)行_不是_由LLM提供商本身完成的——LLM只選擇要調(diào)用的工具和提供的參數(shù)。支持任意工具或任意參數(shù)輸入工具的Agent服務(wù)必須使用沙箱（例如Modal、E2B）以確保安全執(zhí)行。

Agent通過OpenAI定義的JSON模式調(diào)用工具——這意味著Agent和工具實際上可以跨不同框架兼容。Letta Agent可以調(diào)用LangChain、CrewAI和Composio工具，因為它們都是由相同的模式定義的。因此，對于常見工具，有一個不斷增長的工具提供商生態(tài)系統(tǒng)。Composio是一個流行的通用工具庫，還管理授權(quán)。Browserbase是一個專門用于網(wǎng)頁瀏覽的專用工具的例子，Exa提供了一個專門用于搜索網(wǎng)絡(luò)的專用工具。隨著越來越多的Agent被構(gòu)建，我們預(yù)計工具生態(tài)系統(tǒng)將增長，并提供現(xiàn)有新功能，如Agent的身份驗證和訪問控制。

Agent框架

Agent框架協(xié)調(diào)LLM調(diào)用并管理Agent狀態(tài)。不同的框架將為以下方面有不同的設(shè)計：

• 管理Agent的狀態(tài)：大多數(shù)框架引入了一些“序列化”狀態(tài)的概念，允許Agent通過將序列化狀態(tài)（例如JSON、字節(jié)）保存到文件中，在稍后的時間加載回相同的腳本——這包括狀態(tài)如對話歷史記錄、Agent記憶和執(zhí)行階段。在Letta中，所有狀態(tài)都由數(shù)據(jù)庫支持（例如消息表、Agent狀態(tài)表、內(nèi)存塊表），沒有“序列化”的概念，因為Agent狀態(tài)始終被持久化。這允許輕松查詢Agent狀態(tài)（例如，按日期查找過去的信息）。狀態(tài)的表示和管理方式?jīng)Q定了Agent應(yīng)用程序?qū)⑷绾坞S著更長的對話歷史記錄或更多的Agent數(shù)量進(jìn)行擴(kuò)展，以及如何靈活地訪問或修改狀態(tài)。

• Agent的上下文窗口結(jié)構(gòu)：每次調(diào)用LLM時，框架將“編譯”Agent的狀態(tài)到上下文窗口。不同的框架將以不同的方式將數(shù)據(jù)放入上下文窗口（例如指令、消息緩沖區(qū)等），這可能會改變性能。我們建議選擇一個使上下文窗口透明的框架，因為這最終是您可以控制您的Agent行為的方式。

• 跨Agent通信（即多Agent）：Llama Index通過消息隊列讓Agent通信，而CrewAI和AutoGen有明確的抽象器用于多Agent。Letta和LangGraph都支持Agent直接相互調(diào)用，這允許集中式（通過監(jiān)督Agent）和跨Agent的分布式通信。大多數(shù)框架現(xiàn)在支持多Agent和單Agent，因為一個設(shè)計良好的單Agent系統(tǒng)應(yīng)該使跨Agent協(xié)作易于實現(xiàn)。

• 內(nèi)存方法：LLM的基本限制是它們有限的上下文窗口，這就需要管理隨時間的記憶。一些框架內(nèi)置了內(nèi)存管理，而其他框架則期望開發(fā)者自己管理內(nèi)存。CrewAI和AutoGen完全依賴基于RAG的內(nèi)存，而phidata和Letta使用額外的技術(shù)，如自我編輯內(nèi)存（來自MemGPT）和遞歸總結(jié)。Letta Agent自動配備了一套內(nèi)存管理工具，允許Agent通過文本或數(shù)據(jù)搜索先前的消息，編寫記憶，并編輯Agent自己的上下文窗口（您可以在這里閱讀更多）。

• 支持開放模型：模型提供商實際上做了很多幕后技巧，讓LLM以正確的格式生成文本（例如用于工具調(diào)用）——例如，當(dāng)它們沒有生成適當(dāng)?shù)墓ぞ邊?shù)時，重新采樣LLM輸出，或在提示中添加提示（例如“請輸出JSON”）。支持開放模型需要框架處理這些挑戰(zhàn)，所以一些框架限制對主要模型提供商的支持。

在今天構(gòu)建Agent時，正確的框架選擇取決于您的應(yīng)用程序，例如您是否正在構(gòu)建會話Agent或工作流程，您是否希望在筆記本或作為服務(wù)運行Agent，以及您對開放權(quán)重模型支持的要求。

我們預(yù)計框架之間的主要區(qū)別將出現(xiàn)在它們的部署工作流程中，狀態(tài)/內(nèi)存管理和工具執(zhí)行的設(shè)計選擇變得更加重要。

Agent托管和Agent服務(wù)

今天的大多數(shù)Agent框架都是為那些不存在于它們編寫的Python腳本或Jupyter筆記本之外的Agent設(shè)計的。我們相信Agent的未來是將Agent視為一個_服務(wù)_，該服務(wù)被部署到本地或云基礎(chǔ)設(shè)施上，可以通過REST API訪問。就像OpenAI的ChatCompletion API成為與LLM服務(wù)交互的行業(yè)標(biāo)準(zhǔn)一樣，我們預(yù)計最終會有一個贏家為Agent API。但還沒有一個……。

部署Agent作為服務(wù)比部署LLM作為服務(wù)要復(fù)雜得多，因為狀態(tài)管理和安全工具執(zhí)行的問題。工具及其所需的依賴項和環(huán)境需求需要明確存儲在數(shù)據(jù)庫中，因為運行它們的環(huán)境需要由服務(wù)重新創(chuàng)建（這不是一個問題，當(dāng)您的工具和Agent在同一個腳本中運行時）。應(yīng)用程序可能需要運行數(shù)百萬Agent，每個Agent都累積了越來越多的對話歷史記錄。當(dāng)從原型轉(zhuǎn)移到生產(chǎn)時，Agent狀態(tài)不可避免地必須經(jīng)歷一個數(shù)據(jù)規(guī)范化過程，Agent交互必須由REST API定義。今天，這個過程通常是通過開發(fā)者編寫自己的FastAPI和數(shù)據(jù)庫代碼來完成的，但我們預(yù)計隨著Agent的成熟，這個功能將更多地嵌入到框架中。

結(jié)論

Agent技術(shù)棧仍然非常早期，我們對生態(tài)系統(tǒng)如何擴(kuò)展和演變感到興奮。對未來Agent技術(shù)棧發(fā)展你還有什么補(bǔ)充嗎？

https://www.letta.com/blog/ai-agents-stack