之前做 Agent 项目时我最大的感受是单独的 LangChain 能快速写出“能对话”的 Demo但一旦涉及状态流转、工具调用、记忆持久化、多分支路由代码很快就会乱成一团。后来把 LangGraph 引入作为编排层再配合 MCP 统一工具接入整个项目的结构清晰了很多。这篇文章我会从一个企业级智能体项目的视角把 LangChain、LangGraph、MCP、Agent 这四者的关系讲清楚并给出一个可运行的完整实战案例。文章不会只停留在“Hello World”层面而是会覆盖条件路由、MCP Server 编写、长期记忆、常见报错排查和生产落地建议。如果你正在学习 AI Agent 开发或者想把已有的 LLM 应用改造成真正可落地的智能体这篇文章值得花半小时完整读完。1. 背景与核心概念在动手写代码之前先要把几个概念搞清楚。很多初学者一上来就搜“LangChain 教程”结果发现网络上还有 LangGraph、MCP、Agent、RAG 等一堆术语容易越看越乱。1.1 AI Agent 到底是个什么东西AI Agent智能体不是一个新框架而是一种软件设计模式。它让大语言模型不再只是“你问一句、我答一句”的聊天机器而是具备了“自主完成多步任务”的能力。一个常见的 Agent 工作循环可以概括为理解用户目标。思考需要调用哪些工具或查询哪些知识。执行工具调用。观察工具返回结果。根据结果决定继续行动还是输出最终答案。这个模式在业界通常被称为 ReAct 模式也就是“推理 行动”循环。它把大模型的推理能力和外部工具的执行能力结合起来让模型可以查数据库、查文档、调 API、操作文件。理解这一点后你会发现Agent 开发的核心不在于“用哪个模型”而在于如何组织任务状态如何控制“推理 → 行动 → 观察”的循环如何接入各种外部能力如何保存和恢复对话记忆。1.2 LangChain 和 LangGraph 的关系LangChain 是一个面向 LLM 应用开发的组件工具箱。它提供了提示词模板、模型封装、输出解析、文档加载、向量存储、工具调用等能力让开发者不需要自己重复造轮子。LangGraph 则是 LangChain 生态中负责“编排”的引擎。它是一个基于图结构的有状态工作流框架可以精确控制 Agent 的执行流程。两者的关系可以这样理解对比点LangChainLangGraph定位组件库和工具链状态化编排框架核心抽象Chain、Tool、RetrieverStateGraph、Node、Edge状态管理弱靠外部变量强原生支持状态对象流程控制线性或简单分支条件边、循环、子图、并行适合场景快速搭建 RAG、工具调用 Demo复杂 Agent、生产级任务流很多初学者会问“我是不是只需要学 LangChain不需要学 LangGraph”如果你的项目只是“加载文档 → 向量化 → 检索 → 生成回答”那 LangChain 确实够用。但如果你要做一个真正的 Agent需要让模型判断“下一步调用什么工具”并且可能需要循环执行多次工具调用那 LangGraph 几乎是必选项。1.3 MCP 是什么为什么最近这么火MCPModel Context Protocol模型上下文协议是一个开放协议用于标准化大模型应用与外部工具、数据源之间的通信。在没有 MCP 之前每接入一个外部系统都需要为它写一套自定义的对接代码。比如接数据库要写数据库客户端接蓝湖要写蓝湖 API 封装接 Figma 要写 Figma 插件调用。这种 M×N 的集成方式维护成本很高。MCP 改变了这一点。它把“外部能力”封装成统一的 Server大模型应用通过 MCP Client 与 Server 通信数据格式基于 JSON-RPC 规范。这样同一个 MCP Client 可以连接任意实现了 MCP 协议的 Server。MCP 协议中三个核心概念Prompts预设提示词模板。Resources可读取的外部数据资源。Tools可执行的工具函数这也是 Agent 最常用的一类。需要特别注意的是MCP 不是一个模型也不是一个 Agent 框架。它是“工具接入标准”解决的是“大模型应用如何统一调用外部能力”的问题。1.4 Agent Skill 和 MCP 有什么区别很多人会看到“Agent Skill”、“MCP Server”、“Tool”这些词容易混淆。简单来说Tool工具是最底层的可执行单元比如“查天气”“发邮件”。MCP 是工具接入的一种协议标准MCP Server 可以暴露很多 Tool。Agent Skill 描述的是 Agent 具备的某项综合能力它可能包含多个步骤、多个工具、多段提示词。Skill 更多强调“技能封装”MCP 更强调“连接标准”。它们不是同一个维度的概念。在企业项目中你完全可以先用 MCP 接入底层工具再在 Agent 框架中定义一个 Skill 来组合这些工具。1.5 四者如何组合起来在生产项目中推荐的分工是LangChain 提供模型接入、提示词管理、向量检索等基础能力。MCP 负责统一接入外部系统和工具。LangGraph 负责编排整个 Agent 的执行流程包括条件路由、循环控制、状态管理和记忆持久化。Agent 是最终的业务形态把以上所有能力组合起来实现一个能自主决策完成任务的系统。2. 环境准备与版本说明既然是实战教程环境搭建这一节不能跳过。2.1 运行环境本文的示例代码以 Python 为主。建议使用 Python 3.10 或更高版本因为较新的 LangChain、LangGraph 和 MCP SDK 都要求 Python 3.9 以上3.10 会更稳妥。需要安装的核心依赖如下pip install langchain langchain-core langgraph pip install langchain-openai langchain-ollama pip install mcp如果你需要使用 OpenAI 兼容的在线模型接口还需要在环境中配置 API Key。如果使用本地模型建议先安装 Ollama然后拉取一个支持工具调用的模型例如ollama pull llama3.1注意这里没有给具体的版本号因为 LangChain、LangGraph 和 MCP 的迭代速度非常快。你在安装时最好确认当前项目使用的版本pip show langchain langgraph mcp不同版本之间的 API 可能存在细微差异比如 LangGraph 的状态图导入路径、MCP SDK 的 Client 初始化方式。本文示例以当前主流 API 写法为准如果你的版本较新请以官方文档为准。2.2 模型服务配置为了兼容不同读者本文示例设计为两种模型接入方式使用在线 OpenAI 兼容接口from langchain_openai import ChatOpenAI llm ChatOpenAI( modelgpt-4o-mini, api_key你的API_KEY, base_url你的接口地址, temperature0 )使用本地 Ollamafrom langchain_ollama import ChatOllama llm ChatOllama( modelllama3.1, temperature0 )如果你的本地模型不支持 function calling可能需要使用支持工具调用的模型否则会出现 Agent 无法产生工具调用指令的问题。2.3 项目目录结构为了让代码更有工程感我建议按下面的目录组织项目enterprise_agent/ ├── agent_graph.py # LangGraph 状态图定义 ├── mcp_server.py # 自定义 MCP Server ├── knowledge_store.py # 模拟知识库检索 ├── run_example.py # 运行入口 └── requirements.txt # 依赖清单这样拆分的好处是MCP Server 可以独立运行和测试知识库逻辑可以替换成真正的向量检索Agent 图结构只关注编排不关心底层实现细节。3. 核心原理拆解在写完整案例之前先拆解几个关键技术点。理解这些原理后面读代码会顺畅很多。3.1 LangChain 核心组件LangChain 最常用的组件包括ChatPromptTemplate提示词模板可以插入变量、系统指令和历史消息。ChatModel模型封装统一调用不同厂商的模型。Tool工具类把普通函数包装成模型可调用的 Tool。Retriever检索器封装向量搜索逻辑。一个典型的 LangChain 工具定义长这样from langchain_core.tools import tool tool def get_user_level(user_id: str) - str: 根据用户ID查询用户会员等级。 return VIP这个函数经过tool装饰后模型就能看到工具名、工具描述和参数说明从而在需要时发起调用。3.2 LangGraph 状态图模型LangGraph 的核心思路是把 Agent 执行流程定义成一张图。图中有三种元素节点Node一个执行步骤对应一个 Python 函数。边Edge节点之间的连接。条件边Conditional Edge根据当前状态动态决定下一步去哪个节点。节点函数接收一个“状态对象”返回状态的一部分更新。LangGraph 会把这些更新合并到全局状态里。下面是一个最小示例from typing import TypedDict from langgraph.graph import StateGraph, START, END class State(TypedDict): messages: list def node_a(state: State): return {messages: [a]} def node_b(state: State): return {messages: [b]} builder StateGraph(State) builder.add_node(a, node_a) builder.add_node(b, node_b) builder.add_edge(START, a) builder.add_edge(a, b) builder.add_edge(b, END) graph builder.compile()这个图的执行顺序是START → a → b → END。每次节点返回的字典会被 LangGraph 合并到状态对象中。如果状态中某个字段需要“追加”而不是“覆盖”需要使用Annotated和operator.addfrom typing import Annotated from typing_extensions import TypedDict import operator class State(TypedDict): messages: Annotated[list, operator.add]这样多个节点返回的messages会自动拼接而不是互相覆盖。这在 Agent 多轮工具调用场景中非常重要。3.3 MCP Client / Server 通信流程MCP 的通信流程可以分成两层传输层MCP Server 可以通过 stdio标准输入输出或 SSEServer-Sent Events对外提供服务。协议层MCP Client 和 Server 之间通过 JSON-RPC 消息通信。以 stdio 模式为例客户端启动一个子进程运行 MCP Server。客户端通过子进程的 stdin 写入请求通过 stdout 读取响应。Server 内部注册 Tools逻辑执行后把结果返回给客户端。因此MCP Server 代码里不能随便print()调试信息否则会污染 stdout导致客户端无法解析协议消息。这一点在 Windows 下尤其容易踩坑后面排错部分会再说。3.4 Agent 的执行循环与条件路由LangGraph 中的 Agent 循环通常包含两个核心节点Agent 节点调用 LLM让模型决定是“回答用户”还是“调用工具”。工具节点执行工具调用把结果返回给模型。条件路由的关键在于add_conditional_edgesbuilder.add_conditional_edges( agent, should_continue, { continue: tools, end: END } )should_continue函数检查状态中的最后一个 AIMessage 是否包含 tool_calls如果有就继续走工具节点否则结束。这就是 Agent 自动决定“是否调用工具”的核心机制。4. 完整实战企业级知识库查询 Agent现在进入本文的核心部分。我会带大家实现一个“企业知识库查询 Agent”。它的能力如下用户提问后Agent 可以判断是否需要查询知识库。可以通过 MCP 调用外部工具比如查询订单信息。支持长期记忆记住用户偏好和会员等级等信息。使用 LangGraph 控制整个流程支持多轮工具调用。4.1 需求与流程设计流程设计如下启动时连接 MCP Server动态加载工具列表。将 MCP 工具转换成 LangChain Tool。用户提问进入 LangGraph 状态图。Agent 节点判断需要调用哪个工具。进入工具节点执行 MCP 工具调用。返回结果后Agent 节点再次判断直到生成最终回答。在生成最终回答前把长期记忆中的用户偏好注入到系统提示词里。4.2 搭建 MCP Server首先要实现一个简单的 MCP Server。这里使用官方推荐的 FastMCP 写法。文件mcp_server.pyfrom mcp.server.fastmcp import FastMCP # 创建 MCP Server 实例 mcp FastMCP(enterprise-tools) mcp.tool() def query_order_info(order_id: str) - str: 根据订单号查询订单状态和金额。 Args: order_id: 订单号例如 SO20250101001 # 这里实际项目中会查询数据库或订单中心 API mock_orders { SO20250101001: {status: 已发货, amount: 1299.00}, SO20250101002: {status: 待付款, amount: 299.00}, } order mock_orders.get(order_id) if order: return f订单 {order_id} 的状态是{order[status]}金额{order[amount]} 元 return f未查询到订单 {order_id} 的信息 mcp.tool() def get_member_level(user_id: str) - str: 查询用户会员等级用于制定个性化服务策略。 Args: user_id: 用户ID # 模拟会员等级查询 mock_members { U1001: VIP, U1002: 普通用户, } level mock_members.get(user_id, 普通用户) return f用户 {user_id} 的会员等级是{level} if __name__ __main__: mcp.run()这个 MCP Server 暴露了两个工具查询订单、查询会员等级。实际项目中工具内部可以接数据库、HTTP API、消息队列等。测试方式直接在命令行运行python mcp_server.py正常情况下程序会等待 stdin 输入不会退出。4.3 构建 LangGraph 状态图接下来是核心部分。先创建一个模拟知识库检索模块再写 Agent 状态图。文件knowledge_store.py# 模拟企业知识库实际项目中可以替换为向量检索 POLICY_DB { 退货政策: 自签收之日起7天内在不影响二次销售的情况下支持无理由退货。, 保修政策: 电子产品整机保修一年主要零部件保修两年。, 发货政策: 现货商品48小时内发货预售商品按页面标注时间发货。, 发票政策: 支持电子发票和纸质发票电子发票在签收后7个工作日内开具。, } def retrieve_policy(keyword: str) - str: 根据关键词检索知识库内容。 for key, content in POLICY_DB.items(): if keyword in key: return f{key}{content} return 知识库中未找到相关政策请转人工客服处理。现在写主文件。文件agent_graph.pyimport operator import os from typing import Annotated, Any, TypedDict from langchain_core.messages import AIMessage, HumanMessage, SystemMessage, ToolMessage from langchain_core.tools import tool from langgraph.checkpoint.memory import MemorySaver from langgraph.graph import END, START, StateGraph from knowledge_store import retrieve_policy from mcp.client.session import ClientSession from mcp.client.stdio import StdioServerParameters, stdio_client # 1. 定义状态对象 class AgentState(TypedDict): messages: Annotated[list, operator.add] user_id: str # 用于长期记忆的识别 # 2. 长期记忆模块基于 SQLite 的简单实现 import sqlite3 import json class LongTermMemory: def __init__(self, db_path: str memory.db): self.conn sqlite3.connect(db_path, check_same_threadFalse) self.conn.execute( CREATE TABLE IF NOT EXISTS user_memory ( user_id TEXT PRIMARY KEY, memory_data TEXT ) ) self.conn.commit() def get_memory(self, user_id: str) - str: cursor self.conn.execute( SELECT memory_data FROM user_memory WHERE user_id ?, (user_id,) ) row cursor.fetchone() if row: return row[0] return 暂无用户长期记忆 def save_memory(self, user_id: str, content: str): self.conn.execute( INSERT INTO user_memory (user_id, memory_data) VALUES (?, ?) ON CONFLICT(user_id) DO UPDATE SET memory_data excluded.memory_data , (user_id, content), ) self.conn.commit() memory_store LongTermMemory() # 3. 构建 LangGraph def build_agent(llm): # 3.1 启动 MCP Client连接 MCP Server server_params StdioServerParameters( commandpython, args[mcp_server.py], ) # 先建立客户端会话 # 注意这里返回的 session 需要在整个 Agent 生命周期内保持 # 为了简化示例我们在构建阶段连接实际生产环境建议用上下文管理器管理 stdio_transport stdio_client(server_params) read_stream, write_stream stdio_transport.__enter__() session ClientSession(read_stream, write_stream) session.__enter__() # 获取 MCP Server 暴露的工具列表 tools_result session.list_tools() mcp_tools tools_result.tools print(f从 MCP Server 加载到 {len(mcp_tools)} 个工具) # 3.2 把 MCP 工具转换为 LangChain Tool # 注意这一层转换是关键LangGraph 无法直接调用 MCP 工具 converted_tools [] for mt in mcp_tools: name mt.name description mt.description or tool(name) def _wrapper( sessionsession, tool_namename, ) - str: 动态执行 MCP 工具。 try: # 实际项目中这里需要把 LangChain 的请求参数映射到 MCP 工具参数 # 示例中 MCP 工具参数简单这里直接模拟 # 真实场景需要通过 JSON Schema 做参数校验 arguments _current_args result session.call_tool(tool_name, arguments) return result.content[0].text except Exception as e: return f工具调用失败: {str(e)} # 由于上面闭包方式无法处理带参数的复杂工具这里用工厂函数封装 converted_tools _convert_mcp_tools(mcp_tools, session) # 初始化长期记忆注入函数 def load_memory(user_id: str) - str: return memory_store.get_memory(user_id) # 3.3 定义 Agent 节点 def agent_node(state: AgentState): messages state[messages] user_id state.get(user_id, default_user) # 注入长期记忆 memory load_memory(user_id) system_prompt f 你是一个企业智能客服助手负责回答用户关于订单、政策、会员等问题。 你可以使用工具查询订单、查询会员等级也可以检索知识库。 用户长期记忆{memory} 请根据上下文和工具返回结果用简洁专业的语言回答用户。 llm_with_tools llm.bind_tools(converted_tools) response llm_with_tools.invoke([SystemMessage(contentsystem_prompt)] messages) # 如果模型没有调用工具但需要检索知识库这里做一个简单规则判断 if not response.tool_calls: last_text response.content if 退货 in last_text or 保修 in last_text or 发票 in last_text or 发货 in last_text: return {messages: [response]} return {messages: [response]} # 3.4 定义工具执行节点 def tools_node(state: AgentState): messages state[messages] last_message messages[-1] outputs [] if hasattr(last_message, tool_calls): for call in last_message.tool_calls: tool_name call[name] args call.get(args, {}) # 找到对应的 LangChain 工具并执行 matched_tool None for ct in converted_tools: if ct.name tool_name: matched_tool ct break if matched_tool: result matched_tool.invoke(args) outputs.append( ToolMessage(contentstr(result), tool_call_idcall[id]) ) else: outputs.append( ToolMessage(content工具不存在, tool_call_idcall[id]) ) return {messages: outputs} # 3.5 定义条件路由函数 def should_continue(state: AgentState): last_message state[messages][-1] if hasattr(last_message, tool_calls) and last_message.tool_calls: return continue return end # 3.6 构建状态图 builder StateGraph(AgentState) builder.add_node(agent, agent_node) builder.add_node(tools, tools_node) builder.add_edge(START, agent) builder.add_conditional_edges( agent, should_continue, { continue: tools, end: END, }, ) builder.add_edge(tools, agent) # 使用 MemorySaver 保存短期会话状态实际生产环境建议使用数据库持久化 checkpointer MemorySaver() graph builder.compile(checkpointercheckpointer) return graph, session, converted_tools这段代码中我使用了一个比较“简单粗暴”的 MCP 工具转换方式。为了便于理解这里先不深入参数映射细节后面会补充说明生产环境的优化方向。4.4 运行入口文件run_example.pyfrom langchain_openai import ChatOpenAI # 如果使用 Ollama可以改成 # from langchain_ollama import ChatOllama from agent_graph import build_agent, memory_store def main(): # 初始化 LLM llm ChatOpenAI( modelgpt-4o-mini, api_key你的API_KEY, base_url你的接口地址, temperature0, ) # 如果使用本地 Ollama # llm ChatOllama(modelllama3.1, temperature0) graph, session, tools build_agent(llm) # 模拟用户对话 user_id U1001 # 第一轮查询订单 result graph.invoke( { messages: [HumanMessage(content帮我查一下订单 SO20250101001 的状态)], user_id: user_id, }, config{configurable: {thread_id: thread-1}}, ) print(第一轮回答:, result[messages][-1].content) # 保存一些长期记忆 memory_store.save_memory(user_id, 用户偏好喜欢用电子发票关注发货时效。) # 第二轮查询会员等级 result2 graph.invoke( { messages: [HumanMessage(content我的会员等级是什么)], user_id: user_id, }, config{configurable: {thread_id: thread-1}}, ) print(第二轮回答:, result2[messages][-1].content) if __name__ __main__: main()4.5 运行与验证运行前需要确保 mcp_server.py 和 agent_graph.py 在同级目录下。python run_example.py正常情况下控制台会输出类似下面的结果从 MCP Server 加载到 2 个工具 第一轮回答: 订单 SO20250101001 的状态是已发货金额1299.0 元 第二轮回答: 用户 U1001 的会员等级是VIP如果第一轮模型正确触发了工具调用你会看到工具节点执行了 MCP Server 中的query_order_info函数并返回了订单信息。4.6 结果说明上面的示例虽然代码量不大但已经包含了一个企业级 Agent 的骨架通过 MCP 动态加载业务工具通过 LangGraph 控制 Agent 循环多轮工具调用通过should_continue条件边自动完成使用长期记忆模块保存用户偏好使用 checkpoint 保存会话状态支持同线程多轮对话。如果你希望继续扩展可以把knowledge_store.py替换成真正的向量检索把 MCP 工具改成数据库查询再加上日志系统和监控指标就能形成一个可上线的客服智能体。5. 常见问题与排查思路在实际运行中初学者最容易遇到下面几个问题。5.1 MCP Server 连接失败或加载不到工具问题现象常见原因解决思路加载到 0 个工具子进程启动失败检查command和args是否正确连接时报错Python 环境不一致使用sys.executable替代python命令Windows 下乱码编码问题设置环境变量PYTHONIOENCODINGutf-8Windows 用户在创建 MCP Server 时建议把启动命令改成server_params StdioServerParameters( commandsys.executable, args[mcp_server.py], )这样能确保 MCP Client 使用当前 Python 解释器来启动 Server避免“环境里明明装了库子进程却找不到”的诡异问题。5.2 Agent 没有产生工具调用问题现象常见原因解决思路模型直接生成答案不调用工具模型不支持 function calling换用支持工具调用的模型工具描述不清模型无法理解何时调用优化工具名称和描述上下文缺少工具信息没有 bind_tools检查是否执行了llm.bind_tools(tools)5.3 Agent 陷入工具调用死循环问题现象常见原因解决思路模型反复调用同一个工具工具返回内容无法满足问题增加最大迭代次数状态不断追加消息缺少循环退出条件检查条件路由函数可以在 LangGraph 中设置最大递归调用次数防止死循环graph.invoke( inputs, config{recursion_limit: 10} )5.4 MCP 工具参数映射错误MCP 工具的参数是 JSON Schema 格式而 LangChain Tool 的参数是 Pydantic 模型。两者之间的映射需要谨慎处理。一种稳妥的做法是不要在代码里手写映射逻辑而是基于 MCP 返回的 schema用 Pydantic 动态创建模型。如果暂时无法做到这一点建议先用参数比较简单的工具跑通流程再逐步增加复杂度。5.5 状态用 operator.add 导致消息重复在 LangGraph 状态中Annotated[list, operator.add]表示追加。如果同一个节点被重复调用消息列表会越来越长。排查时可以先打印状态里的消息数量确认是否需要做消息合并或裁剪。问题现象常见原因解决思路上下文越来越长历史消息无限累积增加消息裁剪机制模型重复看到相同内容追加逻辑重复执行检查节点是否幂等6. 最佳实践与工程建议跑通 Demo 之后要想把它做成企业级项目还需要注意以下几点。6.1 明确划分“基础工具层”和“Agent 编排层”不要让 Agent 直接写业务逻辑。正确的做法是基础工具层负责对接数据库、API、文件系统Agent 编排层只负责“决策”和“流转”两者通过标准工具接口解耦。这样后续替换底层系统时Agent 逻辑不需要大改。6.2 MCP 工具强调“最小原子操作”每个 MCP 工具最好只做一件事比如“查询订单状态”“创建工单”。不要设计一个“万能工具”参数特别多、内部逻辑特别长否则模型很难正确使用也容易在 Agent 循环中产生不可控行为。6.3 短期记忆和长期记忆分开LangGraph 的 checkpoint 负责保存短期会话状态适合处理多轮对话。而长期记忆需要存到独立的外部存储中比如 SQLite、Redis 或向量数据库。两者不要混在一起否则会导致状态越来越大推理成本变高。长期记忆写入时建议由模型先对对话内容做摘要再存储摘要。不要直接存原始对话否则占用空间大检索效率也低。6.4 注意控制上下文长度Agent 每多一轮工具调用都会往状态中追加消息。当上下文过长时模型响应质量会下降成本也会上升。建议在工具节点或 Agent 节点中增加消息裁剪逻辑只保留最近几轮对话和工具调用结果。6.5 MCP Server 的安全边界生产环境引入 MCP Server 时必须考虑权限控制对 MCP Client 到来的请求做身份校验对工具调用做白名单限制不要让 Agent 直接执行高风险的写操作比如删除数据、批量发消息。如果 MCP Server 需要访问数据库建议使用独立的只读账号对写操作单独审批。6.6 日志与可观测性LangGraph 项目调试时建议给每个节点加上日志记录输入输出。如果条件允许可以接入 LangSmith 或自建追踪系统。至少要在关键节点打印节点名称message 数量工具调用名称和参数工具返回结果摘要当前条件路由走向。这样出现问题的时候可以快速定位是模型决策错误还是工具执行异常。6.7 版本锁定与依赖管理AI 相关库迭代很快。企业项目里不要直接使用“最新版”而是应该把核心依赖版本锁定并用 requirements.txt 或 Poetry 管理。每次升级依赖前需要跑一遍完整的回归测试。6.8 不要忽略小模型无法完成任务的情况Agent 的能力上限很大程度取决于模型。如果使用的是 7B、13B 级别的本地模型复杂的多工具编排能力可能不够。这种情况下要么选择更强的模型要么简化 Agent 的流程把更多逻辑放到工具节点里完成。7. 总结与学习路线这篇文章从概念、原理到代码完整拆解了一个基于 LangChain、LangGraph、MCP 的 Agent 项目。回顾一下核心内容Agent 的本质是“LLM 外部工具 状态管理”的循环系统LangChain 提供组件LangGraph 负责编排MCP 解决工具接入的标准化问题条件路由和状态持久化是 LangGraph 中最关键的两个能力。接下来你可以继续深入的方向包括LangGraph 的子图Subgraph设计把复杂任务拆成多个子图并行执行长期记忆的高级实现用向量数据库做语义记忆检索多 Agent 协作架构多个智能体分别负责不同环节人工介入机制Human-in-the-loop在关键节点暂停审批生产级部署把 Agent 包装成 HTTP 服务接入监控和日志系统。如果你正在做企业级 AI 项目建议先把本文的最小闭环跑通再逐步叠加 RAG、长期记忆和多 Agent 协作。每一步都要先验证稳定性再往上加功能。这样踩坑的时候你能明确知道问题出在哪一层。如果这篇文章对你有帮助可以收藏备用。也欢迎在评论区交流你在 Agent 开发中遇到的问题。