LangChain vs. AutoGPT vs. CrewAI…快选吐了？AI Agent框架超详细总结，帮你一次搞定！

关注

原创最新推荐文章于 2026-11-11 11:39:44 发布 1.3k 阅读 AI 写同款· GEO 优化 ›

Agent框架选型决策地图：LangChain、LangGraph、AutoGen、CrewAI核心对比 Agent（智能体）是构建自主协作AI系统的核心范式，其本质是将大模型能力封装为可调度、可通信、可状态管理的运行单元。实现Agent系统需权衡抽象层级、状态一致性、调试可观测性与生产稳定性四大技术维度。LangChain以函数式管道提供灵活组件组装能力，适合线性RAG流程；LangGraph通过显式State与DAG图谱实现强约束流程编排，天然支持检查点与可视化追踪；AutoGen回归过程式控制，以ConversableAgent和chat_history赋予极致动态调度自由度；CrewAI则采用角色-任务阅读详情

从编写一次性的脚本到使用一个成熟的框架，是软件工程领域一次重要的思维跃迁。本文探讨如何利用业界主流的一些智能体框架，来高效、规范地构建可靠的智能体应用。我们将概览当前市面上主流的智能体框架，然后并对几个具有代表性的框架，分析它们之间的区别并给出选型建议。

为什么需要智能体框架？

在我们开始实战之前，首先需要明确为什么要使用框架。

一个框架的本质，是提供一套经过验证的“规范”。它将所有智能体共有的、重复性的工作（如主循环、状态管理、工具调用、日志记录等）进行抽象和封装，让我们在构建新的智能体时，能够专注于其独特的业务逻辑，而非通用的底层实现。

相比于直接编写独立的智能体脚本，使用框架的价值主要体现在以下几个方面：

提升代码复用与开发效率：这是最直接的价值。一个好的框架会提供一个通用的 Agent 基类或执行器，它封装了智能体运行的核心循环（Agent Loop）。无论是 ReAct 还是 Plan-and-Solve，都可以基于框架提供的标准组件快速搭建，从而避免重复劳动。
实现核心组件的解耦与可扩展性：一个健壮的智能体系统应该由多个松散耦合的模块组成。框架的设计会强制我们分离不同的关注点：

模型层 (Model Layer)：负责与大语言模型交互，可以轻松替换不同的模型（OpenAI, Anthropic, 本地模型）。
工具层 (Tool Layer)：提供标准化的工具定义、注册和执行接口，添加新工具不会影响其他代码。
记忆层 (Memory Layer)：处理短期和长期记忆，可以根据需求切换不同的记忆策略（如滑动窗口、摘要记忆）。这种模块化的设计使得整个系统极具可扩展性，更换或升级任何一个组件都变得简单。

标准化复杂的状态管理：我们在 ReflectionAgent 中实现的 Memory 类只是一个简单的开始。在真实的、长时运行的智能体应用中，状态管理是一个巨大的挑战，它需要处理上下文窗口限制、历史信息持久化、多轮对话状态跟踪等问题。一个框架可以提供一套强大而通用的状态管理机制，开发者无需每次都重新处理这些复杂问题。
简化可观测性与调试过程：当智能体的行为变得复杂时，理解其决策过程变得至关重要。一个精心设计的框架可以内置强大的可观测性能力。例如，通过引入事件回调机制（Callbacks），我们可以在智能体生命周期的关键节点（如 on_llm_start, on_tool_end, on_agent_finish）自动触发日志记录或数据上报，从而轻松地追踪和调试智能体的完整运行轨迹。这远比在代码中手动添加 print 语句要高效和系统化。

因此，从手动实现走向框架开发，不仅是代码组织方式的改变，更是构建复杂、可靠、可维护的智能体应用的必由之路。

主流框架的选型与对比

智能体框架的生态正在以前所未有的速度发展。如果说 LangChain 和 LlamaIndex 定义了第一代通用 LLM 应用框架的范式，那么新一代的框架则更加专注于解决特定领域的深层挑战，尤其是多智能体协作 (Multi-Agent Collaboration) 和 复杂工作流控制 (Complex Workflow Control)。

在本文的后续实战中，我们将聚焦于四个在这些前沿领域极具代表性的框架：AutoGen、AgentScope、CAMEL 和 LangGraph。它们的设计理念各不相同，分别代表了实现复杂智能体系统的不同技术路径，如图6.1所示。

表 6.1 四种智能体框架对比

AutoGen：AutoGen 的核心思想是通过对话实现协作[1]。它将多智能体系统抽象为一个由多个“可对话”智能体组成的群聊。开发者可以定义不同角色（如 Coder, ProductManager, Tester），并设定它们之间的交互规则（例如，Coder 写完代码后由 Tester 自动接管）。任务的解决过程，就是这些智能体在群聊中通过自动化消息传递，不断对话、协作、迭代直至最终目标达成的过程。
AgentScope：AgentScope 是一个专为多智能体应用设计的、功能全面的开发平台[2]。它的核心特点是易用性和工程化。它提供了一套非常友好的编程接口，让开发者可以轻松定义智能体、构建通信网络，并管理整个应用的生命周期。其内置的消息传递机制和对分布式部署的支持，使其非常适合构建和运维复杂、大规模的多智能体系统。
CAMEL：CAMEL 提供了一种新颖的、名为角色扮演 (Role-Playing) 的协作方法[3]。其核心理念是，我们只需要为两个智能体（例如，AI研究员和 Python程序员）设定好各自的角色和共同的任务目标，它们就能在“初始提示 (Inception Prompting)”的引导下，自主地进行多轮对话，相互启发、相互配合，共同完成任务。它极大地降低了设计多智能体对话流程的复杂度。
LangGraph：作为 LangChain 生态的扩展，LangGraph 另辟蹊径，将智能体的执行流程建模为图 (Graph)[4]。在传统的链式结构中，信息只能单向流动。而 LangGraph 将每一步操作（如调用LLM、执行工具）定义为图中的一个节点 (Node)，并用边 (Edge) 来定义节点之间的跳转逻辑。这种设计天然支持循环 (Cycles)，使得实现如 Reflection 这样的迭代、修正、自我反思的复杂工作流变得异常简单和直观。

在接下来的小节中，我们将逐一分析这四个框架，来直观地感受它们各自的优势和局限性。

智能体框架总结一：AutoGen

正如前文所述，AutoGen 的设计哲学根植于"以对话驱动协作"。它巧妙地将复杂的任务解决流程，映射为不同角色的智能体之间的一系列自动化对话。基于这一核心理念，AutoGen 框架持续演进。我们将以 0.7.4 版本为例，因为它是截止目前为止最新版本，代表了一次重要的架构重构，从类继承设计转向了更灵活的组合式架构。为了深入理解并应用这一框架，我们首先需要讲解其最核心的构成要素与底层的对话交互机制。

1、AutoGen 的核心机制

0.7.4 版本的发布是 AutoGen 发展的一个重要节点，它标志着框架在底层设计上的一次根本性革新。这次更新并非简单的功能叠加，而是对整体架构的重新思考，旨在提升框架的模块化、并发性能和开发者体验。

AutoGen架构图

1）框架结构的演进

如图所示，新架构最显著的变化是引入了清晰的分层和异步优先的设计理念。

分层设计： 框架被拆分为两个核心模块：

autogen-core：作为框架的底层基础，封装了与语言模型交互、消息传递等核心功能。它的存在保证了框架的稳定性和未来扩展性。
autogen-agentchat：构建于 core 之上，提供了用于开发对话式智能体应用的高级接口，简化了多智能体应用的开发流程。这种分层策略使得各组件职责明确，降低了系统的耦合度。

异步优先： 新架构全面转向异步编程 (async/await)。在多智能体协作场景中，网络请求（如调用 LLM API）是主要耗时操作。异步模式允许系统在等待一个智能体响应时处理其他任务，从而避免了线程阻塞，显著提升了并发处理能力和系统资源的利用效率。

2）核心智能体组件

智能体是执行任务的基本单元。在 0.7.4 版本中，智能体的设计更加专注和模块化。

AssistantAgent (助理智能体)： 这是任务的主要解决者，其核心是封装了一个大型语言模型（LLM）。它的职责是根据对话历史生成富有逻辑和知识的回复，例如提出计划、撰写文章或编写代码。通过不同的系统消息（System Message），我们可以为其赋予不同的“专家”角色。
UserProxyAgent (用户代理智能体)： 这是 AutoGen 中功能独特的组件。它扮演着双重角色：既是人类用户的“代言人”，负责发起任务和传达意图；又是一个可靠的“执行器”，可以配置为执行代码或调用工具，并将结果反馈给其他智能体。这种设计清晰地区分了“思考”（由 AssistantAgent 完成）与“行动”。

3）从 GroupChatManager 到 Team

当任务需要多个智能体协作时，就需要一个机制来协调对话流程。在早期版本中，GroupChatManager 承担了这一职责。而在新架构中，引入了更灵活的 Team 或群聊概念，例如 RoundRobinGroupChat。

轮询群聊 (RoundRobinGroupChat)： 这是一种明确的、顺序化的对话协调机制。它会让参与的智能体按照预定义的顺序依次发言。这种模式非常适用于流程固定的任务，例如一个典型的软件开发流程：产品经理先提出需求，然后工程师编写代码，最后由代码审查员进行检查。
工作流：

首先，创建一个 RoundRobinGroupChat 实例，并将所有参与协作的智能体（如产品经理、工程师等）加入其中。
当一个任务开始时，群聊会按照预设的顺序，依次激活相应的智能体。
被选中的智能体根据当前的对话上下文进行响应。
群聊将新的回复加入对话历史，并激活下一个智能体。
这个过程会持续进行，直到达到最大对话轮次或满足预设的终止条件。

通过这种方式，AutoGen 将复杂的协作关系，简化为一个流程清晰、易于管理的自动化“圆桌会议”。开发者只需定义好每个团队成员的角色和发言顺序，剩下的协作流程便可由群聊机制自主驱动。

AutoGen 的优势与局限性分析

任何技术框架都有其特定的适用场景和设计权衡。在本节中，我们将客观地分析 AutoGen 的核心优势及其在实际应用中可能面临的局限性与挑战。后文的案例请查看：https://github.com/datawhalechina/hello-agents的6.2.2节。

1）优势

如案例所示，我们无需为智能体团队设计复杂的状态机或控制流逻辑，而是将一个完整的软件开发流程，自然地映射为产品经理、工程师和审查员之间的对话。这种方式更贴近人类团队的协作模式，显著降低了为复杂任务建模的门槛。开发者可以将更多精力聚焦于定义“谁（角色）”以及“做什么（职责）”，而非“如何做（流程控制）”。
框架允许通过系统消息（System Message）为每个智能体赋予高度专业化的角色。在案例中，ProductManager 专注于需求，而 CodeReviewer 则专注于质量。一个精心设计的智能体可以在不同项目中被复用，易于维护和扩展。
对于流程化任务，RoundRobinGroupChat 这样机制提供了清晰、可预测的协作流程。同时，UserProxyAgent 的设计为“人类在环”（Human-in-the-loop）提供了天然的接口。它既可以作为任务的发起者，也可以是流程的监督者和最终的验收者。这种设计确保了自动化系统始终处于人类的监督之下。

2）局限性

虽然 RoundRobinGroupChat 提供了顺序化的流程，但基于 LLM 的对话本质上具有不确定性。智能体可能会产生偏离预期的回复，导致对话走向意外的分支，甚至陷入循环。
当智能体团队的工作结果未达预期时，调试过程可能非常棘手。与传统程序不同，我们得到的不是清晰的错误堆栈，而是一长串的对话历史。这被称为“对话式调试”的难题。

3）非 OpenAI 模型的配置补充

如果你想使用非 OpenAI 系列的模型（如 DeepSeek、通义千问等），在 0.7.4 版本中需要在 OpenAIChatCompletionClient 的参数中传入模型信息字典。以 DeepSeek 为例：

`from autogen_ext.models.openai import OpenAIChatCompletionClient

model_client = OpenAIChatCompletionClient(
model=“deepseek-chat”,
api_key=os.getenv(“DEEPSEEK_API_KEY”),
base_url=“https://api.deepseek.com/v1”,
model_info={
“function_calling”: True,
“max_tokens”: 4096,
“context_length”: 32768,
“vision”: False,
“json_output”: True,
“family”: “deepseek”,
“structured_output”: True,
}
)`

这个 model_info 字典帮助 AutoGen 了解模型的能力边界，从而更好地适配不同的模型服务。

智能体框架总结二：AgentScope

如果说 AutoGen 的设计哲学是"以对话驱动协作"，那么 AgentScope 则代表了另一种技术路径：工程化优先的多智能体平台。AgentScope 由阿里巴巴达摩院开发，专门为构建大规模、高可靠性的多智能体应用而设计。它不仅提供了直观易用的编程接口，更重要的是内置了分布式部署、容错恢复、可观测性等企业级特性，使其特别适合构建需要长期稳定运行的生产环境应用。

1、AgentScope 的设计

与 AutoGen 相比，AgentScope 的核心差异在于其消息驱动的架构设计和工业级的工程实践。如果说 AutoGen 更像是一个灵活的"对话工作室"，那么 AgentScope 就是一个完整的"智能体操作系统"，为开发者提供了从开发、测试到部署的全生命周期支持。与许多框架采用的继承式设计不同，AgentScope 选择了组合式架构和消息驱动模式。这种设计不仅增强了系统的模块化程度，也为其出色的并发性能和分布式能力奠定了基础。

1）分层架构体系

如图所示，AgentScope 采用了清晰的分层模块化设计，从底层的基础组件到上层的应用编排，形成了一个完整的智能体开发生态。

AgentScope架构图

在这个架构中，最底层是基础组件层 (Foundational Components)，它为整个框架提供了核心的构建块。Message 组件定义了统一的消息格式，支持从简单的文本交互到复杂的多模态内容；Memory 组件提供了短期和长期记忆管理；Model API 层抽象了对不同大语言模型的调用；而 Tool 组件则封装了智能体与外部世界交互的能力。

在基础组件之上，智能体基础设施层 (Agent-level Infrastructure) 提供了更高级的抽象。这一层不仅包含了各种预构建的智能体（如浏览器使用智能体、深度研究智能体），还实现了经典的 ReAct 范式，支持智能体钩子、并行工具调用、状态管理等高级特性。特别值得注意的是，这一层原生支持异步执行与实时控制，这是 AgentScope 相比其他框架的一个重要优势。

多智能体协作层 (Multi-Agent Cooperation) 是 AgentScope 的核心创新所在。MsgHub 作为消息中心，负责智能体间的消息路由和状态管理；而 Pipeline 系统则提供了灵活的工作流编排能力，支持顺序、并发等多种执行模式。这种设计使得开发者可以轻松构建复杂的多智能体协作场景。

最上层的**开发与部署层 (Deployment & Devvelopment)**则体现了 AgentScope 对工程化的重视。AgentScope Runtime 提供了生产级的运行时环境，而 AgentScope Studio 则为开发者提供了完整的可视化开发工具链。

2）消息驱动

AgentScope 的核心创新在于其消息驱动架构。在这个架构中，所有的智能体交互都被抽象为消息的发送和接收，而不是传统的函数调用。

`from agentscope.message import Msg

消息的标准结构

message = Msg(
name=“Alice”, # 发送者名称
content=“Hello, Bob!”, # 消息内容
role=“user”, # 角色类型
metadata={ # 元数据信息
“timestamp”: “2024-01-15T10:30:00Z”,
“message_type”: “text”,
“priority”: “normal”
}
)`

将消息作为交互的基础单元，带来了几个关键优势：

异步解耦: 消息的发送方和接收方在时间上解耦，无需相互等待，天然支持高并发场景。
位置透明: 智能体无需关心另一个智能体是在本地进程还是在远程服务器上，消息系统会自动处理路由。
可观测性: 每一条消息都可以被记录、追踪和分析，极大地简化了复杂系统的调试与监控。
可靠性: 消息可以被持久化存储和重试，即使系统出现故障，也能保证交互的最终一致性，提升了系统的容错能力。

3）智能体生命周期管理

在 AgentScope 中，每个智能体都有明确的生命周期（初始化、运行、暂停、销毁等），并基于一个统一的基类 AgentBase 来实现。开发者通常只需要关注其核心的 reply 方法。

`from agentscope.agents import AgentBase

class CustomAgent(AgentBase):
def init(self, name: str, **kwargs):
super().init(name=name, **kwargs)
# 智能体初始化逻辑

def reply(self, x: Msg) -> Msg:  
    # 智能体的核心响应逻辑  
    response = self.model(x.content)  
    return Msg(name=self.name, content=response, role="assistant")  
  
def observe(self, x: Msg) -> None:  
    # 智能体的观察逻辑（可选）  
    self.memory.add(x)`

这种设计模式分离了智能体的内部逻辑与外部通信，开发者只需在 reply 方法中定义智能体“思考和回应”的方式即可。

4）消息传递机制

AgentScope 内置了一个消息中心 (MsgHub)，它是整个消息驱动架构的中枢。MsgHub 不仅负责消息的路由和分发，还集成了持久化和分布式通信等高级功能，它有以下这些特点。

灵活的消息路由: 支持点对点、广播、组播等多种通信模式，可以构建灵活复杂的交互网络。
消息持久化: 能够将所有消息自动保存到数据库（如 SQLite, MongoDB），确保了长期运行任务的状态可以被恢复。
原生分布式支持: 这是 AgentScope 的标志性特性。智能体可以被部署在不同的进程或服务器上，MsgHub 会通过 RPC（远程过程调用）自动处理跨节点的通信，对开发者完全透明。

这些由底层架构提供的工程化能力，使得 AgentScope 在处理需要高并发、高可靠性的复杂应用场景时，比传统的对话驱动框架更具优势。当然，这也要求开发者理解并适应消息驱动的异步编程范式。

2、AgentScope 的优势与局限性分析

通过这个"三国狼人杀"案例，我们深度体验了 AgentScope 框架的核心优势。案例地址：https://github.com/datawhalechina/hello-agents的6.3.2节。

该框架以其消息驱动的架构为核心，将复杂的游戏流程优雅地映射为一系列并发、异步的消息传递事件，从而避免了传统状态机的僵硬与复杂。结合其强大的结构化输出能力，我们将游戏规则直接转化为代码层面的约束，极大地提升了系统的稳定性和可预测性。这种设计范式不仅在性能上展现了其原生并发的优势，更在容错处理上保证了即使单个智能体出现异常，整体流程也能稳健运行。

然而，AgentScope 的工程化优势也带来了一定的复杂性成本。其消息驱动架构虽然强大，但对开发者的技术要求较高，需要理解异步编程、分布式通信等概念。对于简单的多智能体对话场景，这种架构可能显得过于复杂，存在"过度工程化"的风险。此外，作为相对较新的框架，其生态系统和社区资源还有待进一步完善。因此，AgentScope 更适合需要构建大规模、高可靠性的生产级多智能体系统，而对于快速原型开发或简单应用场景，选择更轻量级的框架可能更为合适。

智能体框架总结三：CAMEL

与 AutoGen 和 AgentScope 这样功能全面的框架不同，CAMEL最初的核心目标是探索如何在最少的人类干预下，让两个智能体通过“角色扮演”自主协作解决复杂任务。

1、CAMEL 的自主协作

CAMEL 实现自主协作的基石是两大核心概念：角色扮演 (Role-Playing) 和 引导性提示 (Inception Prompting)。

1）角色扮演

在 CAMEL 最初的设计中，一个任务通常由两个智能体协作完成。这两个智能体被赋予了互补的、明确定义的“角色”。一个扮演**“AI 用户” (AI User)，负责提出需求、下达指令和构思任务步骤；另一个则扮演“AI 助理” (AI Assistant)**，负责根据指令执行具体操作和提供解决方案。

例如，在一个“开发股票交易策略分析工具”的任务中：

AI 用户 的角色可能是一位“资深股票交易员”。它懂市场、懂策略，但不懂编程。
AI 助理 的角色则是一位“优秀的 Python 程序员”。它精通编程，但对股票交易一无所知。

通过这种设定，任务的解决过程就被自然地转化为一场两位“跨领域专家”之间的对话。交易员提出专业需求，程序员将其转化为代码实现，两者协作完成任何一方都无法独立完成的复杂任务。

2）引导性提示

仅仅设定角色还不够，如何确保两个 AI 在没有人类持续监督的情况下，能始终“待在自己的角色里”，并且高效地朝着共同目标前进呢？这就是 CAMEL 最核心的技术，引导性提示发挥作用的地方。“引导性提示”是在对话开始前，分别注入给两个智能体的一段精心设计的、结构化的初始指令（System Prompt）。这段指令就像是为智能体植入的“行动纲领”，它通常包含以下几个关键部分：

明确自身角色：例如，“你是一位资深的股票交易员…”
告知协作者角色：例如，“你正在与一位优秀的 Python 程序员合作…”
定义共同目标：例如，“你们的共同目标是开发一个股票交易策略分析工具。”
设定行为约束和沟通协议：这是最关键的一环。例如，指令会要求 AI 用户“一次只提出一个清晰、具体的步骤”，并要求 AI 助理“在完成上一步之前不要追问更多细节”，同时规定双方需在回复的末尾使用特定标志（如）来标识任务的完成。

这些约束条件确保了对话不会偏离主题、不会陷入无效循环，而是以一种高度结构化、任务驱动的方式向前推进，如下图所示。

CAMEL创建股票机器人交易

2、CAMEL 的优势与局限性分析

通过电子书创作案例，我们深度体验了 CAMEL 框架独特的角色扮演范式。现在让我们客观地分析这种设计理念的优势与局限性，以便在实际项目中做出明智的技术选型。案例地址：https://github.com/datawhalechina/hello-agents的6.4.2节。

1）优势

CAMEL 最大的优势在于其"轻架构、重提示"的设计哲学。相比 AutoGen 的复杂对话管理和 AgentScope 的分布式架构，CAMEL 通过精心设计的初始提示就能实现高质量的智能体协作。这种自然涌现的协作行为，往往比硬编码的工作流更加灵活和高效。

值得注意的是，CAMEL 框架正在经历快速的发展和演进。从其 GitHub 仓库可以看到，CAMEL 已经远不止是一个简单的双智能体协作框架，目前已经具备：

多模态能力：支持文本、图像、音频等多种模态的智能体协作
工具集成：内置了丰富的工具库，包括搜索、计算、代码执行等
模型适配：支持 OpenAI、Anthropic、Google、开源模型等多种 LLM 后端
生态联动：与 LangChain、CrewAI、AutoGen 等主流框架实现了互操作性

2）主要局限性

对提示工程的高度依赖

CAMEL 的成功很大程度上取决于初始提示的质量。这带来了几个挑战：

提示设计门槛：需要深入理解目标领域和 LLM 的行为特性
调试复杂性：当协作效果不佳时，很难定位是角色定义、任务描述还是交互规则的问题
一致性挑战：不同的 LLM 对相同提示的理解可能存在差异

协作规模的限制

虽然 CAMEL 在双智能体协作上表现出色，但在处理大规模多智能体场景时面临挑战：

对话管理：缺乏像 AutoGen 那样的复杂对话路由机制
状态同步：没有 AgentScope 那样的分布式状态管理能力
冲突解决：当多个智能体意见分歧时，缺乏有效的仲裁机制

任务适用性的边界

CAMEL 特别适合需要深度协作和创造性思维的任务，但在某些场景下可能不是最优选择：

严格流程控制：对于需要精确步骤控制的任务，LangGraph 的图结构更合适
大规模并发：AgentScope 的消息驱动架构在高并发场景下更有优势
复杂决策树：AutoGen 的群聊模式在多方决策场景下更加灵活

总的来说，CAMEL 代表了一种独特而优雅的多智能体协作范式。它通过"以人为本"的角色扮演设计，将复杂的系统工程问题转化为直观的人际协作模式。随着其生态系统的不断完善和功能的持续扩展，CAMEL 正在成为构建智能协作系统的重要选择之一。

智能体框架总结四：LangGraph

1、LangGraph 的结构梳理

LangGraph 作为 LangChain 生态系统的重要扩展，代表了智能体框架设计的一个全新方向。与前面介绍的基于“对话”的框架（如 AutoGen 和 CAMEL）不同，LangGraph 将智能体的执行流程建模为一种状态机（State Machine），并将其表示为有向图（Directed Graph）。在这种范式中，图的**节点（Nodes）代表一个具体的计算步骤（如调用 LLM、执行工具），而边（Edges）**则定义了从一个节点到另一个节点的跳转逻辑。这种设计的革命性之处在于它天然支持循环，使得构建能够进行迭代、反思和自我修正的复杂智能体工作流变得前所未有的直观和简单。

要理解 LangGraph，我们需要先掌握它的三个基本构成要素。

首先，是全局状态（State）。整个图的执行过程都围绕一个共享的状态对象进行。这个状态通常被定义为一个 Python 的 TypedDict，它可以包含任何你需要追踪的信息，如对话历史、中间结果、迭代次数等。所有的节点都能读取和更新这个中心状态。

`from typing import TypedDict, List

定义全局状态的数据结构

class AgentState(TypedDict):
messages: List[str] # 对话历史
current_task: str # 当前任务
final_answer: str # 最终答案
# … 任何其他需要追踪的状态`

其次，是节点（Nodes）。每个节点都是一个接收当前状态作为输入、并返回一个更新后的状态作为输出的 Python 函数。节点是执行具体工作的单元。

`# 定义一个“规划者”节点函数
def planner_node(state: AgentState) -> AgentState:
“”“根据当前任务制定计划，并更新状态。”“”
current_task = state[“current_task”]
# … 调用LLM生成计划 …
plan = f"为任务 ‘{current_task}’ 生成的计划…"

# 将新消息追加到状态中  
state["messages"].append(plan)  
return state

定义一个“执行者”节点函数

def executor_node(state: AgentState) -> AgentState:
“”“执行最新计划，并更新状态。”“”
latest_plan = state[“messages”][-1]
# … 执行计划并获得结果 …
result = f"执行计划 ‘{latest_plan}’ 的结果…"

state["messages"].append(result)  
return state`

最后，是边（Edges）。边负责连接节点，定义工作流的方向。最简单的边是常规边，它指定了一个节点的输出总是流向另一个固定的节点。而 LangGraph 最强大的功能在于条件边（Conditional Edges）。它通过一个函数来判断当前的状态，然后动态地决定下一步应该跳转到哪个节点。这正是实现循环和复杂逻辑分支的关键。

def should_continue(state: AgentState) -> str: """条件函数：根据状态决定下一步路由。""" # 假设如果消息少于3条，则需要继续规划 if len(state["messages"]) < 3: # 返回的字符串需要与添加条件边时定义的键匹配 return "continue_to_planner" else: state["final_answer"] = state["messages"][-1] return "end_workflow"

在定义了状态、节点和边之后，我们可以像搭积木一样将它们组装成一个可执行的工作流。

`from langgraph.graph import StateGraph, END

初始化一个状态图，并绑定我们定义的状态结构

workflow = StateGraph(AgentState)

将节点函数添加到图中

workflow.add_node(“planner”, planner_node)
workflow.add_node(“executor”, executor_node)

设置图的入口点

workflow.set_entry_point(“planner”)

添加常规边，连接 planner 和 executor

workflow.add_edge(“planner”, “executor”)

添加条件边，实现动态路由

workflow.add_conditional_edges(
# 起始节点
“executor”,
# 判断函数
should_continue,
# 路由映射：将判断函数的返回值映射到目标节点
{
“continue_to_planner”: “planner”, # 如果返回"continue_to_planner"，则跳回planner节点
“end_workflow”: END # 如果返回"end_workflow"，则结束流程
}
)

编译图，生成可执行的应用

app = workflow.compile()

运行图

inputs = {“current_task”: “分析最近的AI行业新闻”, “messages”: []}
for event in app.stream(inputs):
print(event)`

2、LangGraph 的优势与局限性分析

任何技术框架都有其特定的适用场景和设计权衡。在本节中，我们将客观地分析 LangGraph 的核心优势及其在实际应用中可能面临的局限性。后文的案例请查看：https://github.com/datawhalechina/hello-agents的6.5.2节。

1）优势

如我们的智能搜索助手案例所示，LangGraph 将一个完整的实时问答流程，显式地定义为一个由状态、节点和边构成的“流程图”。这种设计的最大优势是高度的可控性与可预测性。开发者可以精确地规划智能体的每一步行为，这对于构建需要高可靠性和可审计性的生产级应用至关重要。其最强大的特性在于对循环（Cycles）的原生支持。通过条件边，我们可以轻松构建“反思-修正”循环，例如在我们的案例中，如果搜索失败，可以设计一个回退到备用方案的路径。这是构建能够自我优化和具备容错能力的智能体的关键。
此外，由于每个节点都是一个独立的 Python 函数，这带来了高度的模块化。同时，在流程中插入一个等待人类审核的节点也变得非常直接，为实现可靠的“人机协作”（Human-in-the-loop）提供了坚实的基础。

2）局限性

与基于对话的框架相比，LangGraph 需要开发者编写更多的前期代码（Boilerplate）。定义状态、节点、边等一系列操作，使得对于简单任务而言，开发过程显得更为繁琐。开发者需要更多地思考“如何控制流程（how）”，而不仅仅是“做什么（what）”。由于工作流是预先定义的，LangGraph 的行为虽然可控，但也缺少了对话式智能体那种动态的、“涌现”式的交互。它的强项在于执行一个确定的、可靠的流程，而非模拟开放式的、不可预测的社会性协作。
调试过程同样存在挑战。虽然流程比对话历史更清晰，但问题可能出在多个环节：某个节点内部的逻辑错误、在节点间传递的状态数据发生异变，或是边跳转的条件判断失误。这要求开发者对整个图的运行机制有全局性的理解。

智能体框架的设计思路总结

本文我们感受了目前最前沿的一些智能体框架。我们看到，每一个框架都有自己实现智能体构建的思路：

AutoGen 将复杂的协作抽象为一场由多角色参与的、可自动进行的“群聊”，其核心在于“以对话驱动协作”。
AgentScope 则着眼于工业级应用的健壮性与可扩展性，为构建高并发、分布式的多智能体系统提供了坚实的工程基础。
CAMEL 以其轻量级的“角色扮演”和“引导性提示”范式，展示了如何用最少的代码激发两个专家智能体之间深度、自主的协作。
LangGraph 则回归到更底层的“状态机”模型，通过显式的图结构赋予开发者对工作流的精确控制，尤其是其循环能力，为构建可反思、可修正的智能体铺平了道路。

通过对这些框架的深入分析，我们可以提炼出一个设计的权衡：“涌现式协作”与“显式控制”之间的选择。AutoGen 和 CAMEL 更多地依赖于定义智能体的“角色”和“目标”，让复杂的协作行为从简单的对话规则中“涌现”出来，这种方式更贴近人类的交互模式，但有时难以预测和调试。而 LangGraph 要求开发者明确地定义每一个步骤和跳转条件，牺牲了一部分“涌现”的惊喜，换来了高度的可靠性、可控性和可观测性。同时，AgentScope 则揭示了第二个同样重要的维度：工程化。无论我们选择哪种协作范式，要将其从实验原型推向生产应用，都必须面对并发、容错、分布式部署等工程挑战。AgentScope 正是为解决这些问题而生，它代表了从“能运行”到“能稳定服务”的关键跨越。

总而言之，智能体并非只有一种构建方式。深入理解本章探讨的框架设计哲学，能让我们不仅仅成为更优秀的“工具使用者”，更能理解框架设计中的各种优劣与权衡。