譯者 | 朱先忠

審校 | 重樓

本文旨在幫助你在使用自己定制的LLM代理還是使用現有LLM代理框架之間作出正確的選擇。

簡介

首先，要感謝John Gilhuly對本文的貢獻。

當下，人工智能代理暫時處在大休整時期。隨著多個新的AI開發框架的不斷出現和人們對該領域不斷進行新的投資，現代人工智能代理正在克服不穩定的初始階段，迅速取代RAG而成為實施重點。那么，2024年最終會成為什么樣的年份呢？是自主人工智能系統接管我們人工來書寫電子郵件、預訂航班、處理數據，還是與任何其他年份一樣以相似方式執行上述任務呢？

也許情況與前者一樣，但是要達到這種程度還有很多工作要做。任何構建LLM代理的開發人員不僅必須選擇基礎開發設施——使用哪種模型、使用場景和架構——還必須選擇要利用哪種開發框架。你是選擇長期使用的LangGraph，還是新進入市場的LlamaIndex工作流？還是你走傳統路線，自己編寫整個代碼呢？

這篇文章旨在讓這個選擇變得更容易一些。在過去的幾周里，我使用當前主流的人工智能開發框架構建了相同的LLM代理，以便在技術層面檢查每個框架的優缺點。本文中涉及的每個代理的所有源代碼都可以在倉庫地址處找到。

LLM代理類型

當前，業界主要用于測試目的的LLM代理開發涉及到很多方面的內容，例如函數調用、多種相關工具或技能、與外部資源的連接以及共享狀態或內存，等等。

歸納起來看，幾乎所有LLM代理都具有以下功能：

• 回答知識庫中的問題。
• 與數據對話：回答有關LLM應用程序遙測數據的問題。
• 分析數據：分析檢索到的遙測數據中的高級趨勢和模式。

為了完成這些任務，LLM代理需要具備三個基礎技能：使用產品文檔的RAG、在跟蹤數據庫上生成SQL和數據分析。一種典型的實現方案是，使用開源的Python包Gradio來快速構建一個代理用戶界面，而LLM代理本身被構造為聊天機器人。

基于定制代碼的代理（無框架方案）

開發LLM代理時，你的第一個選擇很可能是完全跳過市場上現有框架，而完全由自己來構建一個代理。在最開始著手做這種項目時，這是我采用的方法。

純代碼架構

下面展示的基于代碼的代理是由一個OpenAI驅動的路由器組成的，該路由器使用函數調用來選擇要使用的正確技能。該技能完成后，它將返回路由器以調用另一個技能或者是對用戶作出響應。

在這個代理中，始終保持一個持續的消息和響應列表，在每次調用時將其完全傳遞到路由器中，以便在循環中保留相應的上下文信息。

def router(messages):
if not any(
isinstance(message, dict) and message.get("role") == "system" for message in messages
):
system_prompt = {"role": "system", "content": SYSTEM_PROMPT}
messages.append(system_prompt)

response = client.chat.completions.create(
model="gpt-4o",
messages=messages,
tools=skill_map.get_combined_function_description_for_openai(),
)

messages.append(response.choices[0].message)
tool_calls = response.choices[0].message.tool_calls
if tool_calls:
handle_tool_calls(tool_calls, messages)
return router(messages)
else:
return response.choices[0].message.content

技能本身是在自己的類中定義的（例如GenerateSQLQuery），而所有這些技能信息共同保存在SkillMap類中。路由器本身只與SkillMap類交互，它使用SkillMap類實現來加載技能名稱、描述和可調用函數。這種方法意味著，向代理添加新技能就像將該技能編寫為自己的類一樣簡單，然后將其添加到SkillMap類中的技能列表中。這里的想法是，在不干擾路由器代碼的情況下輕松添加新技能。

class SkillMap:
def __init__(self):
skills = [AnalyzeData(), GenerateSQLQuery()]

self.skill_map = {}
for skill in skills:
self.skill_map[skill.get_function_name()] = (
skill.get_function_dict(),
skill.get_function_callable(),
)

def get_function_callable_by_name(self, skill_name) -> Callable:
return self.skill_map[skill_name][1]

def get_combined_function_description_for_openai(self):
combined_dict = []
for _, (function_dict, _) in self.skill_map.items():
combined_dict.append(function_dict)
return combined_dict

def get_function_list(self):
return list(self.skill_map.keys())

def get_list_of_function_callables(self):
return [skill[1] for skill in self.skill_map.values()]

def get_function_description_by_name(self, skill_name):
return str(self.skill_map[skill_name][0]["function"])

總體而言，這種方法實施起來相當簡單，不過也存在一些挑戰。

純代碼代理方案的挑戰

第一個難點在于構建路由器系統提示。通常，上述示例中的路由器堅持自己生成SQL，而不是將其委托給合適的技能。如果你曾經試圖不讓LLM做某事，你就會知道這種經歷有多么令人沮喪；找到一個可用的提示需要進行多輪調試。考慮到每個步驟的不同輸出格式也是很棘手的。由于我選擇不使用結構化輸出，因此我必須為路由器和技能中每個LLM調用的多種不同格式做好準備。

純代碼代理方案的優點

基于代碼的方法提供了一個很好的基礎架構和起點，提供了一種學習代理如何工作的好方法，而不是依賴于主流框架中的現成的代理教程。盡管說服LLM的行為可能具有挑戰性，但代碼結構本身足夠簡單，可以使用，并且可能對某些使用場景也極有意義。有關這些使用場景的更多信息，請參閱接下來的分析。

LangGraph

LangGraph是歷史最悠久的代理框架之一，于2024年1月首次發布。該框架旨在通過采用Pregel圖結構來解決現有管道和鏈的非循環性。LangGraph通過添加節點、邊和條件邊的概念來遍歷圖，使得在代理中定義循環變得更加容易。LangGraph構建在LangChain之上，并使用LangChain框架中的對象和類型。

LangGraph架構

LangGraph代理看起來與其原論文中的基于代碼的代理相似，但它后臺的實現代碼卻截然不同。LangGraph在技術上仍然使用“路由器”，因為它通過函數調用OpenAI，并使用響應繼續進行新的步驟。然而，程序在技能之間移動的方式完全不同。

tools = [generate_and_run_sql_query, data_analyzer]
model = ChatOpenAI(model="gpt-4o", temperature=0).bind_tools(tools)

def create_agent_graph():
workflow = StateGraph(MessagesState)

tool_node = ToolNode(tools)
workflow.add_node("agent", call_model)
workflow.add_node("tools", tool_node)

workflow.add_edge(START, "agent")
workflow.add_conditional_edges(
"agent",
should_continue,
)
workflow.add_edge("tools", "agent")

checkpointer = MemorySaver()
app = workflow.compile(checkpointer=checkpointer)
return app

這里定義的圖有一個用于初始OpenAI調用的節點，上面稱為“agent”，還有一個用于工具處理步驟的節點，稱為“tools”。LangGraph提供了一個名為ToolNode的內置對象，它負責獲取可調用工具的列表，并根據ChatMessage響應觸發它們，然后再次返回“agent”節點。

def should_continue(state: MessagesState):
messages = state["messages"]
last_message = messages[-1]
if last_message.tool_calls:
return "tools"
return END

def call_model(state: MessagesState):
messages = state["messages"]
response = model.invoke(messages)
return {"messages": [response]}

在每次調用“agent”節點（換句話說：基于代碼的代理中的路由器）后，should_concontinue邊決定是將響應返回給用戶還是傳遞給ToolNode來處理工具調用。

在每個節點中，“state”存儲來自OpenAI的消息和響應列表，這一點類似于基于代碼的代理的方法。

LangGraph方案的挑戰

示例中LangGraph實現的大部分困難在于LangChain對象的使用，此方案需要借助這個對象來使事情順利進行。

挑戰#1：函數調用驗證

為了使用ToolNode對象，我必須重構我現有的大部分Skill代碼。ToolNode接受一個可調用函數列表，這最初讓我認為我可以使用現有的函數，但由于我設計的函數參數方面的原因，事情發生了一些變化。

這些技能都被定義為具有可調用成員函數的類。這意味著，它們的第一個參數是“self”。GPT-4o足夠聰明，不會在生成的函數調用中包含“self”參數，但不幸的是LangGraph將其解讀為由于缺少參數而導致的驗證錯誤。

這花了我幾個小時才弄清楚，因為錯誤消息將函數中的第三個參數（數據分析技能上的“args”）標記為缺少的參數：

pydantic.v1.error_wrappers.ValidationError: 1 validation error for data_analysis_toolSchema
args field required (type=value_error.missing)

值得一提的是，錯誤消息來自Pydantic，而不是LangGraph。

最終，我咬緊牙關，用Langchain的@tool裝飾器將我的技能重新定義為一些基本方法，終于使得代碼正常進行。

@tool
def generate_and_run_sql_query(query: str):
"""根據提示符生成并運行一個SQL查詢。

參數:
query (str): 一個包含原始用戶提示符的字符串。

返回值:
str: SQL查詢的結果。
"""

挑戰#2：調試

正如前文所述，在框架內進行調試是頗為困難的事情。這主要歸結為令人困惑的錯誤消息和抽象概念，使查看變量變得更加困難。

抽象概念主要出現在嘗試調試代理周圍發送的消息時。LangGraph將這些消息存儲在狀態[“messages”]中。圖中的一些節點會自動從這些消息中提取信息，這可能會使節點訪問消息時難以理解消息的含義。

代理動作的順序視圖

LangGraph方案的優點

LangGraph的主要優點之一是易于使用，因為圖形結構代碼干凈且易于訪問。特別是如果你有復雜的節點邏輯時，只通過圖的單一視圖有助于更容易地理解代理是如何連接在一起的。LangGraph方案也使得轉換現有的基于LangChain構建的應用程序變得非常簡單。

小結

如果你僅使用LangGraph框架中的所有內容，那么LangGraph會順利地工作。但是，如果你還想使用框架外的一些內容進行開發的話，那么你需要為調試一些難題做好準備。

LlamaIdex工作流

工作流是LLM代理框架領域的新方案，于今年夏天早些時候首次亮相。與LangGraph一樣，它旨在使循環代理更容易構建。另外，LLM工作流還特別關注異步運行方式。

LLM工作流的一些元素似乎是對LangGraph的直接響應，特別是它使用事件而不是邊和條件邊。工作流使用步驟（類似于LangGraph中的節點）來容納邏輯，并且在步驟之間發送和接收事件。

上面的結構看起來與LangGraph結構相似，只是增加了一點內容。我在工作流中添加了一個設置步驟來負責準備代理上下文，下面將進一步介紹這方面內容。值得注意的是，盡管這兩種方案的結構相似，但是驅動它們的代碼卻大不相同。

工作流架構

下面的代碼定義了一個工作流結構。與LangGraph方案中代碼類似，這是我準備狀態并將技能附加到LLM對象的地方。

class AgentFlow(Workflow):
def __init__(self, llm, timeout=300):
super().__init__(timeout=timeout)
self.llm = llm
self.memory = ChatMemoryBuffer(token_limit=1000).from_defaults(llm=llm)
self.tools = []
for func in skill_map.get_function_list():
self.tools.append(
FunctionTool(
skill_map.get_function_callable_by_name(func),
metadata=ToolMetadata(
name=func, description=skill_map.get_function_description_by_name(func)
),
)
)

@step
async def prepare_agent(self, ev: StartEvent) -> RouterInputEvent:
user_input = ev.input
user_msg = ChatMessage(role="user", content=user_input)
self.memory.put(user_msg)

chat_history = self.memory.get()
return RouterInputEvent(input=chat_history)

這也是我定義額外步驟“prepare_agent”的地方。此步驟根據用戶輸入創建ChatMessage并將其添加到工作流內存中。將其拆分為一個單獨的步驟意味著，當代理循環執行步驟時，我們確實會返回它，這樣就避免了將用戶消息重復添加到內存中。

在LangGraph的例子中，我用一個位于圖外的run_agent方法完成了同樣的事情。這種變化主要是風格上的，但在我看來，像我們在這里所做的那樣，用工作流和圖形來容納這種邏輯會更清晰。

設置好工作流后，我定義了路由代碼：

@step
async def router(self, ev: RouterInputEvent) -> ToolCallEvent | StopEvent:
messages = ev.input

if not any(
isinstance(message, dict) and message.get("role") == "system" for message in messages
):
system_prompt = ChatMessage(role="system", content=SYSTEM_PROMPT)
messages.insert(0, system_prompt)

with using_prompt_template(template=SYSTEM_PROMPT, version="v0.1"):
response = await self.llm.achat_with_tools(
model="gpt-4o",
messages=messages,
tools=self.tools,
)

self.memory.put(response.message)

tool_calls = self.llm.get_tool_calls_from_response(response, error_on_no_tool_call=False)
if tool_calls:
return ToolCallEvent(tool_calls=tool_calls)
else:
return StopEvent(result=response.message.content)

以及工具調用處理代碼：

@step
async def tool_call_handler(self, ev: ToolCallEvent) -> RouterInputEvent:
tool_calls = ev.tool_calls

for tool_call in tool_calls:
function_name = tool_call.tool_name
arguments = tool_call.tool_kwargs
if "input" in arguments:
arguments["prompt"] = arguments.pop("input")

try:
function_callable = skill_map.get_function_callable_by_name(function_name)
except KeyError:
function_result = "Error: Unknown function call"

function_result = function_callable(arguments)
message = ChatMessage(
role="tool",
content=function_result,
additional_kwargs={"tool_call_id": tool_call.tool_id},
)

self.memory.put(message)

return RouterInputEvent(input=self.memory.get())

上面兩部分代碼看起來都比LangGraph代理更類似于基于代碼的代理。這主要是因為工作流將條件路由邏輯保留在步驟中，而不是保留在條件邊中——其中的部分代碼行以前是對應于LangGraph中的條件邊，而現在它們只是路由步驟的一部分——而且LangGraph有一個ToolNode對象，它幾乎可以自動執行tool_call_handler方法中的所有操作。

經過路由步驟，我很高興看到的一件事是，我可以將我的SkillMap和基于代碼的代理中的現有技能與工作流一起使用。這些不需要更改即可使用工作流，這讓我的工作變得更加輕松。

工作流程方案的挑戰

挑戰#1：同步與異步

雖然異步執行更適合實時代理，但調試同步代理要容易得多。工作流被設計為異步工作；因此，試圖強制同步執行變得非常困難。

我最初以為我可以刪除“async”方法名稱，并從“achat_with_tools”切換到“chat_with_tools”。然而，由于Workflow類中的底層方法也被標記為異步，因此有必要重新定義這些方法以便同步運行。我最終堅持使用異步方法，但這并沒有使調試變得更加困難。

代理動作的順序視圖

在LangGraph方案的困境重演過程中，圍繞技能上令人困惑的Pydantic驗證錯誤出現了類似的問題。幸運的是，這次這些問題更容易解決，因為工作流能夠很好地處理成員函數。最終，我不得不更加規范地為我的技能創建LlamaIndex FunctionTool對象：

for func in skill_map.get_function_list(): 
self.tools.append(FunctionTool(
skill_map.get_function_callable_by_name(func), 
metadata=ToolMetadata(name=func, description=skill_map.get_function_description_by_name(func))))

這段代碼摘自構建FunctionTools工具類的函數AgentFlow__init__。

工作流方案的優點

我構建工作流代理比構建LangGraph代理容易得多，主要是因為工作流仍然要求我自己編寫路由邏輯和工具處理代碼，而不是提供內置函數。這也意味著，我的工作流代理看起來與我的基于代碼的代理非常相似。

最大的區別在于事件的使用。我使用了兩個自定義事件在代理中的步驟之間移動：

class ToolCallEvent(Event):
tool_calls: list[ToolSelection]

class RouterInputEvent(Event):
input: list[ChatMessage]

基于事件的“發射器-接收器”架構取代了直接調用代理中的一些方法，如工具調用處理程序。

如果你有更復雜的系統，其中有多個異步觸發的步驟的話，可能會發出多個事件，那么這種架構對于清晰地管理這些步驟非常有幫助。

工作流的其他好處包括：此方案非常輕量級，不會給你強加太多的結構（除了使用某些LlamaIdex對象），而且它基于事件的架構為直接函數調用提供了一種有用的替代方案，特別是對于復雜的異步應用程序而言。

框架比較

縱觀上述三種方法，每種方法都各有其優點。

無框架方法是最容易實現的。因為任何抽象都是由開發人員自己定義的（即上例中的SkillMap對象），所以保持各種類型和對象的簡潔是很容易的。然而，代碼的可讀性和可訪問性完全取決于單個開發人員。很容易看出，在沒有采用一些強制的結構定義的情況下，越來越復雜的代理會變得一團糟。

LangGraph框架本身提供了相當多的結構，這使得代理的定義非常清晰。如果一個更大的團隊正在合作開發一個代理，這種結構將提供一種有助于實施架構的方法。LangGraph也可能為那些不熟悉結構的人提供一個很好的代理起點。然而，有一個權衡——由于LangGraph為你做了很多工作，如果你不完全接受該框架，可能會感覺有些頭痛；代碼可能非常干凈，但你可能會為其付出更多的調試代價。

在上述三種方法中，工作流方案位于中間。基于事件的架構可能對某些項目非常有幫助；事實上，在使用LlamaIdex類型方面所需的編碼量更少，這為那些在應用程序中沒有完全使用過該框架的人提供了更大的靈活性。

最終，核心問題可能歸結為“你已經在使用LlamaIndex或LangChain來編排你的應用程序了嗎？”LangGraph和工作流都與各自的底層框架緊密相連，以至于每個特定于代理的框架的額外好處可能不會讓你只憑優點來切換它們。

不過，純代碼方法可能永遠是一個具有吸引力的選擇。如果你有足夠的嚴謹性來記錄和執行任何創建的抽象的話，那么就很容易確保外部框架中沒有任何設置會減緩你的開發速度。

選擇代理框架的關鍵問題

當然，“視情況而定”從來不是一個令人滿意的答案。下面的三個問題可以幫助你決定在下一個代理項目中使用哪個框架。

• 你是否已經在項目的重要部分使用LlamaIndex或LangChain？

如果是，請先優先分析這種選擇方案。

• 你熟悉常見的代理結構嗎？還是想知道你應該如何構建代理？

如果你大致屬于后一種情形，請嘗試工作流方案。不過，如果你真的屬于后一種情形，試試LangGraph方案吧。

• 以前構建過你自己的代理嗎？

框架方案的好處之一是，每個框架都有許多教程和示例。相比而言，可用于構建純代碼代理的示例代碼要少得多。

結論

無論如何，選擇一個代理框架只是影響生成式人工智能系統生產結果的眾多選擇之一。與往常一樣，構建強大的保護措施并進行LLM跟蹤是非常值得推薦的做法，并且隨著新的代理框架、研究成果和模型不斷顛覆既定技術，這樣做也變得更為機動靈活。

譯者介紹

朱先忠，51CTO社區編輯，51CTO專家博客、講師，濰坊一所高校計算機教師，自由編程界老兵一枚。

原文標題：Choosing Between LLM Agent Frameworks，作者：Aparna Dhinakaran