這或許有可能，但距離這一目標還有許多挑戰需要克服。在構建 Agent 智能體的過程中，開發者們不僅要考慮選用哪種大模型、應用場景和技術架構，還需要在眾多開發框架中做出抉擇。是繼續沿用較為成熟的 LangGraph，還是擁抱新興的 LlamaIndex Workflows？或者回歸傳統，親自編寫所有代碼？

本文旨在幫助您更輕松地做出決策。在過去幾周，我們利用多個主流框架構建了相同的智能體，并從技術角度對它們的優勢和不足進行了分析。

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

在著手開發 Agent 智能體應用時，你可以選擇不依賴任何框架，而是完全自主構建，整體流程如下所示：

以下 Agent 智能體應用完全由代碼構建而成，其核心是一個由 OpenAI 技術支撐的技能調度器。該調度器通過函數調用機制來決定激活哪項技能。技能操作完成后，控制權將重新交還給技能調度器，以便于它能夠繼續調度其他技能或者直接對用戶進行反饋。

在整個交互過程中，Agent 智能體不斷記錄用戶的提問和自身的回答，并在每次技能調用時，將這一系列對話完整地傳遞給技能調度器，以此保證交互的連貫性和上下文的完整性。

LangGraph

LangGraph 是眾多 Agent 智能體框架中最早出現的一個，它在 2024 年 1 月首次亮相。這個框架的創建目的是為了克服現有流程和鏈條中的非循環性挑戰，通過運用 Pregel 圖模型來應對這一難題。LangGraph 通過引入節點、邊以及條件邊的概念，簡化了在智能體內部構建循環流程的步驟，使得圖結構的遍歷更為直觀易懂。LangGraph 是建立在 LangChain 之上的，它沿用了 LangChain 的對象和類型系統。

乍一看，LangGraph 智能體與傳統的基于代碼的智能體似乎有共通之處，然而它們的底層實現卻存在顯著差異。盡管 LangGraph 也采用了“路由器”這一術語，指的是通過函數調用與 OpenAI 交互并利用其輸出推動流程前進，但是它在不同技能間的切換邏輯卻是獨樹一幟的。

在所描述的圖結構中，我們定義了一個用于啟動 OpenAI 調用的節點，即“agent”，以及一個用于執行工具處理步驟的節點，即“tools”。LangGraph 提供了一個名為 ToolNode 的內置對象，該對象能夠接收并調用一系列工具，根據 ChatMessage 的反饋來激活這些工具，并在操作完成后返回到“agent”節點。

每當“agent”節點（在基于代碼的智能體中相當于技能路由器）被激活后，should_continue 這條邊將決定是將輸出直接傳送給用戶，還是傳遞給 ToolNode 以進行工具調用。

在每個節點內部，“state” 負責存儲與 OpenAI 之間的交互消息和響應歷史，這一點與基于代碼的智能體在維持上下文方面有著相似的做法。

LlamaIndex Workflows

Workflows 是 Agent 智能體框架領域的新加入者，它在今年夏天初首次發布。與 LangGraph 相似，其設計目標是簡化循環智能體的構建流程。此外，Workflows 特別突出了其異步操作的功能。

在 Workflows 的設計中，某些概念似乎是為了直接與 LangGraph 競爭，尤其是它使用事件而不是邊或條件邊作為邏輯連接的手段。在 Workflows 中，智能體的邏輯被封裝在“步驟”中（與 LangGraph 的“節點”相對應），而事件的觸發和監聽則負責在不同步驟之間傳遞信息。

這兩個框架在結構上有著顯著的相似性，但存在一個差異：為 Workflows 增加了一個專門的初始化步驟，用于設置智能體的環境上下文，這一點我將在后面詳細說明。盡管它們的結構設計相近，但它們所依賴的代碼基礎卻完全不同。

以下代碼展示了 Workflow 的結構。與 LangGraph 類似，在此部分，我設定了狀態信息，并將各種技能與 LLM 對象關聯起來。

此外，我還定義了一個附加步驟——“prepare_agent”。這個步驟負責將用戶的輸入轉換成 ChatMessage 格式，并將其存入工作流的歷史記憶中。將這一轉換過程獨立為一個單獨的步驟，意味著智能體在執行工作流步驟時，能夠多次回到這個步驟，從而避免了重復將用戶信息加載到記憶存儲的必要性。

在 LangGraph 的實現中，我采用了位于圖結構之外的 run_agent 方法來實現相同的目的。這種改變主要是基于個人編碼風格的偏好，但我認為，將這一邏輯融合到 Workflow 和圖中，會使整體結構更加清晰和高效。

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

以及工具調用的處理代碼：

三種開發框架的比較

比較這三種方法，各有特色。

無框架方法最直接。所有抽象層由開發者自定義，管理類型和對象相對簡單。但隨著 Agent 智能體復雜性增加，缺乏結構可能導致難以管理。

LangGraph 提供了明確的 Agent 智能體結構，有利于團隊協作和規范統一。對結構不熟悉的開發者也易于上手，但可能需要更多調試，若不適應框架則可能感到困擾。

Workflows 則介于兩者之間，基于事件的架構在特定項目中有優勢，對 LlamaIndex 依賴性低，給開發者更多自由。

核心問題在于是否已使用 LlamaIndex 或 LangChain。LangGraph 和 Workflows 與依賴框架緊密集成，其額外優勢可能不足以成為轉換的理由。

純代碼方法始終有吸引力。只要能嚴格記錄和執行抽象概念，就能確保外部框架不會成為障礙。

三種開發框架如何選擇？

當然，僅僅說“視具體情況而定”并不能完全滿足我們的需求。以下三個問題可能有助于你為下一個智能體項目選擇合適的框架。

你的項目是否已經與 LlamaIndex 或 LangChain 緊密集成？

如果是，那么這兩個框架應該是你的首選。

你是否熟悉 Agent 智能體的標準架構，還是更希望得到構建 Agent 智能體結構的指導？

如果你偏向于得到指導，Workflows 可能是合適的選擇。如果你非常需要指導，LangGraph 可能更合適。

你是否有現成的 Agent 智能體示例作為參考？

框架的一大優勢在于提供了豐富的教程和案例供你參考，而純代碼構建的智能體可能缺乏這樣的資源。

文章轉自微信公眾號@玄姐聊AGI