編者按： 本文通過作者的實踐對比發(fā)現(xiàn)，框架的選擇應(yīng)基于項目具體需求和團(tuán)隊特點，而不是簡單追求某個特定框架。不同框架各有優(yōu)勢：

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

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

作者 | Aparna Dhinakaran

編譯 | 岳揚

Image by author

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

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

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

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

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

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

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

為了達(dá)成上述目標(biāo)，智能體需要掌握三項基本技能：結(jié)合產(chǎn)品文檔的 RAG、在相關(guān)數(shù)據(jù)庫上生成 SQL 語句的能力，以及數(shù)據(jù)分析技巧。智能體的用戶界面使用 gradio 搭建，而智能體本身則以聊天機器人（chatbot）的形式構(gòu)建。

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

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

Image by author

1.1 純代碼架構(gòu)

下面是基于純代碼構(gòu)建的智能體，其核心是一個由 OpenAI 提供支持的技能路由器，它通過函數(shù)調(diào)用來確定使用哪項技能。技能執(zhí)行完畢后，控制權(quán)將返回給技能路由器，以便調(diào)用其他技能或直接向用戶作出回應(yīng)。

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

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

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

1.2 使用純代碼智能體面臨的挑戰(zhàn)

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

1.3 純代碼智能體的優(yōu)點

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

02 LangGraph

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

Image by author

2.1 LangGraph 架構(gòu)

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

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

每當(dāng)“agent”節(jié)點（也可以理解為基于代碼的智能體中的技能路由器（router））被調(diào)用之后，should_continue 這條邊將判斷是將響應(yīng)直接返回給用戶，還是轉(zhuǎn)給 ToolNode 來處理工具調(diào)用。

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

2.2 使用 LangGraph 面臨的挑戰(zhàn)

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

挑戰(zhàn) 1：函數(shù)調(diào)用的 validation 錯誤

為了能夠使用 ToolNode 對象，我不得不對 Skill 代碼進(jìn)行大規(guī)模的重構(gòu)。ToolNode 需要一組可調(diào)用的函數(shù)列表，我本以為可以直接使用現(xiàn)成的函數(shù)，但是函數(shù)參數(shù)配置出了問題，導(dǎo)致流程受阻。

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

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

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

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

挑戰(zhàn) 2：Debugging

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

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

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

2.3 LangGraph 的優(yōu)點

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

2.4 經(jīng)驗之談

當(dāng)我們只使用 LangGraph 框架的相關(guān)功能時，一切都會運行得非常流暢；但一旦我們嘗試跳出框架，就要準(zhǔn)備好進(jìn)行一些令人頭疼的調(diào)試了。

03 LlamaIndex Workflows

Workflows 是智能體框架領(lǐng)域的新晉成員，它于今年夏初首次亮相。與 LangGraph 類似，它的設(shè)計宗旨是簡化可循環(huán)智能體的構(gòu)建過程。此外，Workflows 特別強調(diào)其異步執(zhí)行的能力。

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

Image by author

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

3.1 Workflows 架構(gòu)

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

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

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

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

以及工具調(diào)用處理代碼：

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

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

3.2 使用 Workflows 面臨的挑戰(zhàn)

挑戰(zhàn) 1：Sync vs Async

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

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

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

挑戰(zhàn) 2：Pydantic Validation Errors

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

從構(gòu)建 FunctionTools 的 AgentFlow.init 文件中摘錄

3.3 Workflows 的優(yōu)點

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

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

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

對于那些步驟（steps）更為復(fù)雜、異步觸發(fā)且可能產(chǎn)生多個事件（events）的系統(tǒng)來說，這種架構(gòu)就非常有助于干凈利落地管理這些步驟。

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

04 對這些方法進(jìn)行比較

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

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

LangGraph 提供了豐富的智能體結(jié)構(gòu)支持，使得智能體的定義非常清晰。對于多人協(xié)作開發(fā)的智能體來說，這種智能體結(jié)構(gòu)設(shè)定有助于統(tǒng)一架構(gòu)規(guī)范。LangGraph 也為那些對智能體結(jié)構(gòu)不太熟悉的開發(fā)者提供了幫助。不過，這樣做也有代價 —— 由于 LangGraph 為你做了許多工作，如果你不完全認(rèn)同這個框架，它可能會讓你頭疼不已；代碼可能會非常簡潔，但你可能要為此進(jìn)行更多的調(diào)試工作。

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

Image created by author

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

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

05 在選擇智能體框架時需要考慮的關(guān)鍵問題

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

你的項目是否已經(jīng)深度集成了 LlamaIndex 或 LangChain？

如果是的話，不妨優(yōu)先考慮這兩個選項。

你對智能體的常見架構(gòu)是否熟悉，還是更希望有人告訴你應(yīng)該如何構(gòu)建智能體結(jié)構(gòu)？

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

你要構(gòu)建的智能體是否有參考樣例？

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

Image created by author

06 Conclusion

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

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

本期互動內(nèi)容 ??

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

??文中鏈接??

[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??