編者按： 本文通過作者的實踐對比發現，框架的選擇應基于項目具體需求和團隊特點，而不是簡單追求某個特定框架。不同框架各有優勢：

1. 無框架方案實施最為簡單直接，代碼結構清晰，適合理解智能體原理，但隨著項目復雜度增加可能變得難以維護。
2. LangGraph提供完整的智能體結構規范，特別適合團隊協作和智能體結構新手，但框架限制較多，如不認同其理念可能面臨較大調試挑戰。
3. LlamaIndex Workflows采用事件驅動架構，在框架約束和開發自由度之間取得平衡，對框架依賴較少，但其固有的異步特性可能增加某些場景的復雜度。

框架選擇需要考慮三個關鍵因素：項目是否已深度集成了特定框架、團隊對智能體架構的熟悉程度、是否有可供參考的相似項目案例。

作者 | Aparna Dhinakaran

編譯 | 岳揚

Image by author

智能體（Agents）正迎來輝煌時刻。伴隨著眾多新框架的涌現和對該領域的持續投資[1]，現代 AI 智能體正在跨越起初的不穩定階段[2]，迅速取代 RAG 成為開發首選。那么，2024 年是否會成為 autonomous AI 系統全面接管撰寫郵件、預訂航班、數據分析等任務的一年呢？

也許吧，但要實現這一點還有很多工作要做。開發人員在構建智能體時，不僅要決定使用何種模型、應用場景和技術架構，還要挑選合適的開發框架。是堅持較為早期的 LangGraph，還是轉向新興的 LlamaIndex Workflows？或者走傳統路線，自己編寫全部代碼呢？

這篇文章的目的就是讓您更輕松地做出選擇。在過去幾周里，我使用多個主流框架構建了相同的智能體，并從技術角度分析了它們各自的優缺點。每個智能體的所有代碼都可以在此代碼倉庫[3]中找到。

本文測試用智能體的基本概述

本次測試所采用的智能體整合了多項功能，包括執行函數調用（function calling）、使用多種工具或技能、與外部資源建立連接，以及實現狀態或記憶的共享。

該智能體具備以下幾項核心能力：

1. 基于知識庫進行問題解答
2. 數據交互：針對 LLM 應用程序的數據進行問題解答
3. 數據洞察：對獲取的數據進行更高層次的趨勢和模式分析

為了達成上述目標，智能體需要掌握三項基本技能：結合產品文檔的 RAG、在相關數據庫上生成 SQL 語句的能力，以及數據分析技巧。智能體的用戶界面使用 gradio 搭建，而智能體本身則以聊天機器人（chatbot）的形式構建。

01 Code-Based Agent（不使用智能體框架）

在著手開發智能體時，您可以選擇不依賴任何框架，而是完全自主構建。在啟動這個項目之初，我首先采用了這種方法。

Image by author

1.1 純代碼架構

下面是基于純代碼構建的智能體，其核心是一個由 OpenAI 提供支持的技能路由器，它通過函數調用來確定使用哪項技能。技能執行完畢后，控制權將返回給技能路由器，以便調用其他技能或直接向用戶作出回應。

智能體會持續記錄用戶消息和智能體響應，并在每次調用時將這一完整列表傳遞給技能路由器，確保在整個交互過程中保留上下文。

各項技能均在獨立的類中進行定義（例如“GenerateSQLQuery”類），這些類都保存在 SkillMap 中。技能路由器僅與 SkillMap 進行交互，通過它來加載技能的名稱、描述以及可調用的函數。這種設計理念使得向智能體中添加新技能變得非常簡單：只需將該技能編寫為一個獨立的類，并將其加入到 SkillMap 的技能列表即可。這樣做的目的是為了在不影響技能路由器代碼的前提下，輕松實現新技能的添加。

總的來說，這種實現方式雖然簡單易行，但仍然存在一些需要克服的難題。

1.2 使用純代碼智能體面臨的挑戰

第一個困難在于如何設計技能路由器的系統提示詞（system prompt）。 在上面的例子中，技能路由器往往傾向于自行生成 SQL 語句，而不是交給相應的技能模塊去處理。如果你有過試圖讓大語言模型停止執行某項任務的經歷，那你可能深知這其中的挫敗感；為了找到合適的提示詞，我不得不進行了多次調試。此外，處理每個步驟產生的不同輸出格式也是一項復雜的工作。 由于我選擇不使用結構化輸出，因此必須為技能路由器和各項技能中大語言模型的調用準備多種格式的應對策略。

1.3 純代碼智能體的優點

基于代碼的方法提供了一個扎實的基礎和出發點，是一種絕佳的學習途徑，讓我們可以在不依賴現成框架提供的智能體教程的情況下，了解智能體的運作原理。雖然引導大語言模型按既定行為模式運作確實存在難度，但代碼結構本身簡潔明了，易于操作，對于某些使用場景而言，這種做法是完全合理的（具體分析將在下文展開）。

02 LangGraph

LangGraph 是眾多智能體框架中歷史最為悠久的之一，它于 2024 年 1 月首次發布。該框架的設計初衷是為了解決現有流程和鏈條的非循環性問題，它通過采用 Pregel 圖結構來解決這一問題。 LangGraph 通過引入節點（nodes）、邊（edges）以及條件邊（conditional edges）的概念，簡化了在智能體中創建循環流程的過程，使得圖的遍歷變得更加直觀。LangGraph 是基于 LangChain 構建的，它繼承了后者的對象（objects）和類型（types）。

Image by author

2.1 LangGraph 架構

從表面上看，LangGraph 智能體與基于代碼的智能體有相似之處，但它們的底層代碼卻有大不相同。雖然 LangGraph 在技術上也使用了“路由器（router）”這一概念，即通過代碼函數調用 OpenAI 并利用其響應來推進到下一個步驟，但程序在不同技能之間的切換控制機制卻完全不同。

在此定義的圖（graph）中，包含了一個用于初始化 OpenAI 調用的節點，即上文中提到的“agent”，以及一個用于工具處理步驟節點，即“tools”。LangGraph 內置了一個名為 ToolNode 的對象，它能夠接收一系列可調用的工具，并根據 ChatMessage 的響應來觸發這些工具，完成操作后再次回到“agent”節點。

每當“agent”節點（也可以理解為基于代碼的智能體中的技能路由器（router））被調用之后，should_continue 這條邊將判斷是將響應直接返回給用戶，還是轉給 ToolNode 來處理工具調用。

在每個節點中，“state” 負責保存與 OpenAI 的交互消息和響應列表，這一點與基于代碼的智能體保持上下文的方式相似。

2.2 使用 LangGraph 面臨的挑戰

在處理 LangGraph 構建的智能體示例時，遇到的主要難題在于必須借助 Langchain 對象才能確保流程的順暢。

挑戰 1：函數調用的 validation 錯誤

為了能夠使用 ToolNode 對象，我不得不對 Skill 代碼進行大規模的重構。ToolNode 需要一組可調用的函數列表，我本以為可以直接使用現成的函數，但是函數參數配置出了問題，導致流程受阻。

這些技能（skills）是以類形式定義的，每個類都有一個可調用的成員函數，其中“self”是首個參數。GPT-4o 足夠智能，能夠在生成函數調用（function call）時自動排除“self”參數，但 LangGraph 卻因此認為缺少了必要參數，從而拋出了 validation 錯誤。

這個問題讓我摸索了好幾小時才搞清楚，因為錯誤信息把函數里的第三個參數（數據分析技能中的“args”）錯誤地標記為缺失參數（missing parameter）：

需要指出的是，這個誤導性的錯誤信息其實來自 Pydantic，而非 LangGraph。

最后，我下定決心，改用 Langchain 的 @tool 裝飾器將我的技能（skills）重新編寫為基本方法，這樣程序就能正常運行了。

挑戰 2：Debugging

正如前文所述，在框架中調試非常困難。主要是因為錯誤信息混亂不清，以及框架中的抽象概念，它們使得追蹤和查看變量變得非常復雜。

抽象概念主要體現在嘗試跟蹤智能體間傳遞的消息時。LangGraph 會將消息保存在 state[“messages”] 里。Graph 中的一些節點會自動從這些消息（messages）中提取信息，這樣的自動化過程可能會讓節點在訪問消息（messages）時，我們難以把握消息（messages）的具體內容。

智能體行動的順序視圖（圖片由作者提供）

2.3 LangGraph 的優點

LangGraph 的最大優勢在于其易用性。它的圖結構代碼簡潔且易于理解。對于那些擁有復雜節點邏輯的場景，LangGraph 能夠提供一個清晰的圖視圖，讓我們更輕松地把握智能體的連接方式。此外，LangGraph 還可以直接轉換以 LangChain 構建的現有應用程序。

2.4 經驗之談

當我們只使用 LangGraph 框架的相關功能時，一切都會運行得非常流暢；但一旦我們嘗試跳出框架，就要準備好進行一些令人頭疼的調試了。

03 LlamaIndex Workflows

Workflows 是智能體框架領域的新晉成員，它于今年夏初首次亮相。與 LangGraph 類似，它的設計宗旨是簡化可循環智能體的構建過程。此外，Workflows 特別強調其異步執行的能力。

在 Workflows 中，某些設計元素似乎是為了直接對標 LangGraph，尤其是它采用事件（events）而非邊（edges）或條件邊（conditional edges）作為連接邏輯的方式。在 Workflows 中，智能體邏輯被封裝在“步驟（steps）”中（與 LangGraph 中的“節點（nodes）”相對應），而事件（events）的發出和接收則負責在不同的步驟（steps）間傳遞信息。

Image by author

上述框架與 LangGraph 的結構頗為相似，但有一點不同：我給 Workflow 增加了一個初始化步驟，用于準備智能體的環境上下文，稍后我會詳細介紹這一點。盡管兩者的結構相似，但它們所依賴的代碼實現卻截然不同。

3.1 Workflows 架構

以下代碼段描繪了 Workflow 的架構。與 LangGraph 相仿，在這一部分，我配置了狀態信息（state），并將各項技能（skills）綁定到了 LLM 對象上。

在這里，我還定義了一個額外的步驟——“prepare_agent”。該步驟負責將用戶輸入轉換成 ChatMessage，并將其存儲到工作流的記憶存儲中。將這一過程作為一個獨立的步驟分離出來，意味著智能體在遍歷工作步驟（steps）時可以重復回到這一步，從而避免反復將用戶信息加入到記憶存儲中。

在 LangGraph 的實現案例中，我通過一個位于圖（graph）之外的 run_agent 方法實現了相同的功能。這一改變主要是出于風格上的考慮，但我認為，將這一邏輯整合到 Workflow 和圖（graph）中，會更加整潔和高效。

在 Workflow 配置完成后，我繼續編寫了路由代碼：

以及工具調用處理代碼：

它們的實現方式似乎更接近于純代碼的智能體，而非 LangGraph 智能體。這主要是因為 Workflows 選擇在各步驟（steps）中維護條件路由（conditional routing）邏輯，而不是像 LangGraph 那樣使用條件邊（conditional edge）（第 18-24 行在 LangGraph 中是條件邊，而現在它們只是路由步驟的一部分）。另外，LangGraph 中的 ToolNode 對象能夠在 tool_call_handler 方法中自動處理大部分任務。

在路由步驟之后，我們能夠將 SkillMap 以及基于純代碼的智能體中已有的技能（skills）直接應用于 Workflows。這些技能（skills）無需任何修改即可與 Workflows 配合使用，這大大簡化了我的工作。

3.2 使用 Workflows 面臨的挑戰

挑戰 1：Sync vs Async

盡管對于在線運行的智能體來說，異步執行是更優的選擇，但調試同步執行的智能體通常更為簡便。Workflows 本身是為了異步操作而設計的，因此嘗試將其改為同步執行非常困難。

起初，我以為只需去掉“async”方法標識，并將函數名“achat_with_tools”改為“chat_with_tools”即可。但是，由于 Workflow 類內部的方法同樣采用了異步標記，為了實現同步運行，我不得不重新定義這些方法。盡管如此，我最終還是選擇了異步處理方式，幸運的是，這并沒有增加調試的難度。

智能體行動的順序視圖（圖片由作者提供）

挑戰 2：Pydantic Validation Errors

與 LangGraph 的問題類似，在智能體的技能（skills）處也出現了令人困惑的 Pydantic Validation Errors。幸運的是，由于 Workflows 能夠很好地處理成員函數，這些問題這次比較容易解決。最終，我不得不更加規范地為智能體技能（skills）創建 LlamaIndex FunctionTool 對象：

從構建 FunctionTools 的 AgentFlow.init 文件中摘錄

3.3 Workflows 的優點

與 LangGraph 相比，我在使用 Workflows 構建智能體時要輕松得多，主要原因是 Workflows 并未提供內置功能，而是需要我自己編寫路由邏輯和工具操作代碼。 這也使得我的 Workflow 智能體與基于純代碼的智能體看起來極為相似。

最大的區別在于事件（events）的使用上。我使用兩個自定義事件在智能體中的各個步驟之間移動：

這種基于事件的發射器-接收器架構（emitter-receiver），取代了直接調用智能體中某些方法的做法，例如工具調用處理（tool call handler）。

對于那些步驟（steps）更為復雜、異步觸發且可能產生多個事件（events）的系統來說，這種架構就非常有助于干凈利落地管理這些步驟。

Workflows 的其他優點還包括其輕量級特性，不會施加過多的結構限制（除了必須使用特定的 LlamaIndex 對象外），并且其基于事件（event-based）的架構為直接函數調用提供了一種有效的替代方案，這對于處理復雜、異步的應用場景尤為有益。

04 對這些方法進行比較

對比這三種方法，各有其獨到之處。

無框架方法實施起來最簡單。由于所有抽象層都是由開發者自行定義（如前例中的 SkillMap 對象），因此管理不同類型（types）和對象（objects）相對簡單。但是，代碼的可讀性和易用性完全取決于開發者個人，可以預見，如果沒有一定的智能體結構約束，智能體的復雜性增加后可能會變得難以駕馭。

LangGraph 提供了豐富的智能體結構支持，使得智能體的定義非常清晰。對于多人協作開發的智能體來說，這種智能體結構設定有助于統一架構規范。LangGraph 也為那些對智能體結構不太熟悉的開發者提供了幫助。不過，這樣做也有代價 —— 由于 LangGraph 為你做了許多工作，如果你不完全認同這個框架，它可能會讓你頭疼不已；代碼可能會非常簡潔，但你可能要為此進行更多的調試工作。

Workflows 則處于兩者之間。基于事件（event-based）的架構在某些項目中可能極具價值，而且因為它對 LlamaIndex 類型的使用要求不高，對于那些沒有在應用程序中完全使用該框架的開發者來說，提供了更大的自由度。

Image created by author

歸根結底，關鍵問題可能在于“你是否已經在使用 LlamaIndex 或 LangChain 來組織應用程序？” LangGraph 和 Workflows 都與它們所依賴的框架緊密集成，因此每個特定智能體框架的額外優勢可能不足以成為轉換使用的理由。

純代碼方法可能永遠是一個有吸引力的選擇。如果你能夠嚴格地記錄并執行所創建的任何抽象概念，那么確保外部框架不會成為你的阻礙就很容易了。

05 在選擇智能體框架時需要考慮的關鍵問題

當然，單純一句“具體情況具體分析”這樣的回答總是讓人不太滿意。以下三個問題或許能幫你選擇下一個智能體項目應該采用哪個框架。

你的項目是否已經深度集成了 LlamaIndex 或 LangChain？

如果是的話，不妨優先考慮這兩個選項。

你對智能體的常見架構是否熟悉，還是更希望有人告訴你應該如何構建智能體結構？

如果你傾向于后者，那么 Workflows 可能是個不錯的選擇。如果你非常傾向于后者，那么 LangGraph 或許更適合你。

你要構建的智能體是否有參考樣例？

框架的一個優勢在于，每個框架都有大量的教程和實例供你參考。而純代碼構建智能體的參考實例相對較少。

Image created by author

06 Conclusion

選擇一個智能體框架只是影響生成式人工智能系統在生產環境中表現眾多決策中的一項，建立強大的安全保障和對大語言模型（LLM）的監控[4]是必要的 —— 同時，面對新智能體框架、研究成果和模型對傳統技術的顛覆，我們還需保持靈活應對的態度。

Thanks for reading!

Hope you have enjoyed and learned new things from this blog!

About the authors

Aparna Dhinakaran

Co-Founder and CPO of Arize AI. Formerly Computer Vision PhD at Cornell, Uber Machine Learning, UC Berkeley AI Research.

END

本期互動內容 ??

?請分享一下你最常使用的智能體開發方式？為什么？

??文中鏈接??

[1]??https://foundationcapital.com/goodbye-aiops-welcome-agentsres-the-next-100b-opportunity/??

[2]??https://arxiv.org/html/2405.13966v1??

[3]??https://github.com/Arize-ai/phoenix/tree/main/examples/agent_framework_comparison??

[4]??https://docs.arize.com/phoenix/tracing/llm-traces??

原文鏈接：

??https://towardsdatascience.com/choosing-between-llm-agent-frameworks-69019493b259??