在人工智能领域，智能体（Agents）正处于蓬勃发展的阶段，众多新框架不断涌现。现代 AI 智能体逐渐克服了初期的不稳定，迅速取代传统技术成为开发首选。然而，开发人员在构建智能体时，面临着诸多决策，不仅要确定使用的模型、应用场景和技术架构，还要精心挑选合适的开发框架。是选择较为早期的 LangGraph，还是新兴的 LlamaIndex Workflows？亦或是走传统路线，自行编写全部代码？本文将通过对多种主流框架的实践对比，为您提供一份全面的选型指南，帮助您做出更明智的决策。

一、智能体框架

本次测试所采用的智能体具备多项功能，包括执行函数调用（function calling）、运用多种工具或技能、与外部资源建立连接，以及实现状态或记忆的共享。其核心能力涵盖基于知识库进行问题解答、针对 LLM 应用程序的数据进行问题解答以及对获取的数据进行更高层次的趋势和模式分析。为实现这些目标，智能体需要掌握结合产品文档的 RAG、在相关数据库上生成 SQL 语句以及数据分析等三项基本技能。智能体的用户界面借助 gradio 搭建，整体以聊天机器人的形式构建。

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

1. 纯代码架构

基于纯代码构建的智能体，核心是由 OpenAI 提供支持的技能路由器，通过函数调用来确定使用的技能。技能执行完毕后，控制权返回技能路由器，以便调用其他技能或直接回应用户。智能体会持续记录用户消息和自身响应，并在每次调用时传递完整列表给技能路由器，以保留上下文。各项技能定义在独立类中，存储于 SkillMap，技能路由器仅与 SkillMap 交互，添加新技能只需编写新类并加入 SkillMap，方便实现新技能的扩展。

2. 使用纯代码智能体面临的挑战

技能路由器的系统提示词设计困难，容易出现模型不按预期执行任务的情况，需要多次调试。同时，处理不同步骤产生的多种输出格式复杂，因未使用结构化输出，需为技能路由器和各项技能中模型调用准备多种应对策略。

3. 纯代码智能体的优点

这种方法提供了扎实基础和学习途径，能让人在不依赖框架教程的情况下理解智能体运作原理。虽然引导模型行为有难度，但代码结构简洁，在某些场景下是合理选择。

（二）LangGraph

1. LangGraph 架构

LangGraph 智能体与基于代码的智能体表面相似，但底层代码差异大。它使用 “路由器” 概念，通过代码函数调用 OpenAI 并依据响应推进步骤，程序在不同技能间的切换控制机制不同。其定义的图包含初始化 OpenAI 调用的 “agent” 节点和工具处理步骤的 “tools” 节点，内置 ToolNode 对象能根据 ChatMessage 响应触发工具，操作完成后返回 “agent” 节点。“state” 负责保存与 OpenAI 的交互消息和响应列表。

2. 使用 LangGraph 面临的挑战

使用 LangGraph 构建智能体时，必须借助 Langchain 对象确保流程顺畅。主要挑战包括函数调用的 validation 错误，因 ToolNode 对函数参数配置要求，导致技能代码需大规模重构；调试困难，错误信息混乱不清，框架抽象概念使追踪和查看变量复杂，如消息在 state [“messages”] 中的自动提取过程影响对消息内容的把握。

3. LangGraph 的优点

LangGraph 最大优势是易用性，图结构代码简洁易懂，对复杂节点逻辑场景能提供清晰图视图，便于把握智能体连接方式，还可直接转换以 LangChain 构建的现有应用程序。

4. 经验之谈

仅使用 LangGraph 框架相关功能时运行流畅，但尝试跳出框架则可能面临复杂调试。

（三）LlamaIndex Workflows

1. Workflows 架构

Workflows 旨在简化可循环智能体构建，强调异步执行能力，采用事件作为连接逻辑方式，智能体逻辑封装在 “步骤” 中，事件负责在不同步骤间传递信息。其架构配置状态信息并绑定技能到 LLM 对象，还定义了 “prepare_agent” 步骤，将用户输入转换为 ChatMessage 并存储到工作流记忆存储，避免重复添加用户信息。路由代码和工具调用处理代码实现方式更接近纯代码智能体，维护条件路由逻辑，且技能无需修改即可应用于 Workflows，简化了开发工作。

2. 使用 Workflows 面临的挑战

调试同步执行困难，虽异步执行对在线智能体更优，但将其改为同步执行需重新定义 Workflow 类内部方法。此外，也出现了类似 LangGraph 的 Pydantic Validation Errors 问题，不过相对容易解决，需更规范地创建 LlamaIndex FunctionTool 对象。

3. Workflows 的优点

与 LangGraph 相比，使用 Workflows 构建智能体更轻松，因其未提供内置功能，开发者需自行编写路由逻辑和工具操作代码，与纯代码智能体相似。基于事件的架构有助于管理复杂、异步触发且多事件的系统步骤，具有轻量级特性，结构限制少，基于事件的架构为函数调用提供有效替代方案，适用于复杂异步应用场景。

使用两个自定义事件在智能体中的各个步骤之间移动

二、框架比较与分析

1. 无框架方法

实施最为简单直接，开发者自行定义抽象层（如 SkillMap 对象），管理不同类型和对象相对容易。但代码可读性和易用性依赖开发者个人，缺乏智能体结构约束，随着智能体复杂性增加可能难以维护。

2. LangGraph

提供完整的智能体结构规范，智能体定义清晰，适合团队协作开发，对智能体结构新手有帮助。然而，框架限制较多，若不完全认同其理念，可能面临较多调试挑战，代码简洁但调试成本可能较高。

3. LlamaIndex Workflows

采用事件驱动架构，在框架约束和开发自由度之间取得平衡，对框架依赖较少。其固有的异步特性在某些项目中极具价值，且基于事件的架构有助于管理复杂系统步骤。但异步特性可能增加某些场景的复杂度，如调试难度。

三、框架选择关键问题

1. 项目集成情况

若项目已深度集成 LlamaIndex 或 LangChain，优先考虑与之紧密集成的框架，如 LangGraph 或 LlamaIndex Workflows，其额外优势可能使其成为合适选择。

2. 对智能体架构的熟悉程度

若开发者对智能体常见架构不熟悉，希望有框架指导构建结构，LangGraph 是较好选择；若希望在一定框架基础上有更多自由度，Workflows 可能更适合。

3. 参考样例情况

框架通常有大量教程和实例供参考，而纯代码构建智能体的参考实例相对较少。若构建智能体需要参考样例，框架会提供更多便利。

四、小结

选择智能体框架只是影响生成式人工智能系统在生产环境中表现的众多决策之一。在构建智能体时，除了框架选型，建立强大的安全保障和对大语言模型（LLM）的监控同样必要。同时，面对新智能体框架、研究成果和模型对传统技术的不断颠覆，开发者需保持灵活应对的态度，持续学习和适应新变化，以构建出高效、智能且可靠的智能体应用。

文中代码：
https://github.com/Arize-ai/phoenix/tree/main/examples/agent_framework_comparison

原文链接：
https://towardsdatascience.com/choosing-between-llm-agent-frameworks-69019493b259

参考链接：
https://mp.weixin.qq.com/s/0jB157hXY2AwIcji0jywBQ

本文，完。觉得本篇文章不错的，记得随手点个赞、收藏和转发三连，感谢感谢~如果想第一时间收到推送，请记得关注我们~