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