2025年，AI Agent 智能體開發(fā)框架如何優(yōu)雅選型？ 原創(chuàng)
1、Agent 智能體進入黃金發(fā)展期
AI Agent 智能體的發(fā)展正步入黃金時代。隨著眾多新框架的層出不窮和對該領(lǐng)域的持續(xù)投入，現(xiàn)在 AI Agent 智能體已逐步擺脫初期的動蕩，迅速崛起，成為開發(fā)者的首選，超越了 RAG。那么，2025年是否會成為 AI Agent 智能體系統(tǒng)全面接管報告生成、撰寫郵件、預訂航班、數(shù)據(jù)分析等任務的元年呢？
?
這或許有可能，但距離這一目標還有許多挑戰(zhàn)需要克服。在構(gòu)建 AI Agent 智能體的過程中，開發(fā)者們不僅要考慮選用哪種大模型、應用場景和技術(shù)架構(gòu)，還需要在眾多開發(fā)框架中做出抉擇。是繼續(xù)沿用較為成熟的 LangGraph，還是擁抱新興的 LlamaIndex Workflows？或者回歸傳統(tǒng)，親自編寫所有代碼？
本文旨在幫助您更輕松地做出決策。在過去幾周，我們利用多個主流框架構(gòu)建了相同的 AI Agent 智能體，并從技術(shù)角度對它們的優(yōu)勢和不足進行了分析。
2、Code-Based Agent（不使用智能體框架）
在著手開發(fā) AI Agent 智能體應用時，你可以選擇不依賴任何框架，而是完全自主構(gòu)建，整體流程如下所示：
以下 AI Agent 智能體應用完全由代碼構(gòu)建而成，其核心是一個由 OpenAI 技術(shù)支撐的技能調(diào)度器。該調(diào)度器通過函數(shù)調(diào)用機制來決定激活哪項技能。技能操作完成后，控制權(quán)將重新交還給技能調(diào)度器，以便于它能夠繼續(xù)調(diào)度其他技能或者直接對用戶進行反饋。
在整個交互過程中，AI Agent 智能體不斷記錄用戶的提問和自身的回答，并在每次技能調(diào)用時，將這一系列對話完整地傳遞給技能調(diào)度器，以此保證交互的連貫性和上下文的完整性。
3、LangGraph 開發(fā)框架
LangGraph 是眾多 AI Agent 智能體框架中最早出現(xiàn)的一個，它在 2024 年 1 月首次亮相。這個框架的創(chuàng)建目的是為了克服現(xiàn)有流程和鏈條中的非循環(huán)性挑戰(zhàn)，通過運用 Pregel 圖模型來應對這一難題。LangGraph 通過引入節(jié)點、邊以及條件邊的概念，簡化了在智能體內(nèi)部構(gòu)建循環(huán)流程的步驟，使得圖結(jié)構(gòu)的遍歷更為直觀易懂。LangGraph 是建立在 LangChain 之上的，它沿用了 LangChain 的對象和類型系統(tǒng)。
乍一看，LangGraph 智能體與傳統(tǒng)的基于代碼的智能體似乎有共通之處，然而它們的底層實現(xiàn)卻存在顯著差異。盡管 LangGraph 也采用了“路由器”這一術(shù)語，指的是通過函數(shù)調(diào)用與 OpenAI 交互并利用其輸出推動流程前進，但是它在不同技能間的切換邏輯卻是獨樹一幟的。
在所描述的圖結(jié)構(gòu)中，我們定義了一個用于啟動 OpenAI 調(diào)用的節(jié)點，即“agent”，以及一個用于執(zhí)行工具處理步驟的節(jié)點，即“tools”。LangGraph 提供了一個名為 ToolNode 的內(nèi)置對象，該對象能夠接收并調(diào)用一系列工具，根據(jù) ChatMessage 的反饋來激活這些工具，并在操作完成后返回到“agent”節(jié)點。
每當“agent”節(jié)點（在基于代碼的智能體中相當于技能路由器）被激活后，should_continue 這條邊將決定是將輸出直接傳送給用戶，還是傳遞給 ToolNode 以進行工具調(diào)用。
在每個節(jié)點內(nèi)部，“state” 負責存儲與 OpenAI 之間的交互消息和響應歷史，這一點與基于代碼的智能體在維持上下文方面有著相似的做法。
4、LlamaIndex Workflows 開發(fā)框架
LlamaIndex Workflows 是 AI Agent 智能體框架領(lǐng)域的新加入者，它在2024年夏天首次發(fā)布。與 LangGraph 相似，其設計目標是簡化循環(huán)智能體的構(gòu)建流程。此外，Workflows 特別突出了其異步操作的功能。
在 Workflows 的設計中，某些概念似乎是為了直接與 LangGraph 競爭，尤其是它使用事件而不是邊或條件邊作為邏輯連接的手段。在 Workflows 中，AI Agent 智能體的邏輯被封裝在“步驟”中（與 LangGraph 的“節(jié)點”相對應），而事件的觸發(fā)和監(jiān)聽則負責在不同步驟之間傳遞信息。
這兩個框架在結(jié)構(gòu)上有著顯著的相似性，但存在一個差異：為 Workflows 增加了一個專門的初始化步驟，用于設置智能體的環(huán)境上下文，這一點我將在后面詳細說明。盡管它們的結(jié)構(gòu)設計相近，但它們所依賴的代碼基礎卻完全不同。
以下代碼展示了 Workflow 的結(jié)構(gòu)。與 LangGraph 類似，在此部分，我設定了狀態(tài)信息，并將各種技能與 LLM 對象關(guān)聯(lián)起來。
此外，我還定義了一個附加步驟——“prepare_agent”。這個步驟負責將用戶的輸入轉(zhuǎn)換成 ChatMessage 格式，并將其存入工作流的歷史記憶中。將這一轉(zhuǎn)換過程獨立為一個單獨的步驟，意味著智能體在執(zhí)行工作流步驟時，能夠多次回到這個步驟，從而避免了重復將用戶信息加載到記憶存儲的必要性。
在 LangGraph 的實現(xiàn)中，我采用了位于圖結(jié)構(gòu)之外的 run_agent 方法來實現(xiàn)相同的目的。這種改變主要是基于個人編碼風格的偏好，但我認為，將這一邏輯融合到 Workflow 和圖中，會使整體結(jié)構(gòu)更加清晰和高效。
在完成了 Workflow 的配置之后，我繼續(xù)編寫了以下路由代碼：
以及工具調(diào)用的處理代碼：
5、三種開發(fā)框架比較
比較這三種方法，各有特色。
無框架方法最直接。所有抽象層由開發(fā)者自定義，管理類型和對象相對簡單。但隨著 Agent 智能體復雜性增加，缺乏結(jié)構(gòu)可能導致難以管理。
LangGraph 提供了明確的 Agent 智能體結(jié)構(gòu)，有利于團隊協(xié)作和規(guī)范統(tǒng)一。對結(jié)構(gòu)不熟悉的開發(fā)者也易于上手，但可能需要更多調(diào)試，若不適應框架則可能感到困擾。
LlamaIndex Workflows 則介于兩者之間，基于事件的架構(gòu)在特定項目中有優(yōu)勢，對 LlamaIndex 依賴性低，給開發(fā)者更多自由。
核心問題在于是否已使用 LlamaIndex 或 LangChain。LangGraph 和 Workflows 與依賴框架緊密集成，其額外優(yōu)勢可能不足以成為轉(zhuǎn)換的理由。
純代碼方法始終有吸引力。只要能嚴格記錄和執(zhí)行抽象概念，就能確保外部框架不會成為障礙。
6、三種開發(fā)框架如何選擇？
當然，僅僅說“視具體情況而定”并不能完全滿足我們的需求。以下三個問題可能有助于你為下一個智能體項目選擇合適的框架。
你的項目是否已經(jīng)與 LlamaIndex 或 LangChain 緊密集成？
如果是，那么這兩個框架應該是你的首選。
你是否熟悉 AI Agent 智能體的標準架構(gòu)，還是更希望得到構(gòu)建 AI Agent 智能體結(jié)構(gòu)的指導？
如果你偏向于得到指導，Workflows 可能是合適的選擇。如果你非常需要指導，LangGraph 可能更合適。
你是否有現(xiàn)成的 AI Agent 智能體示例作為參考？
框架的一大優(yōu)勢在于提供了豐富的教程和案例供你參考，而純代碼構(gòu)建的 AI Agent 智能體可能缺乏這樣的資源。
本文轉(zhuǎn)載自公眾號玄姐聊AGI 作者：玄姐
