LangChain、LangGraph、MCP、Agent企业级AI应用实战：从入门到部署

这次我们直接聊一个和“能不能落地”强相关的话题：LangChain、LangGraph、MCP、Agent 这一整套 AI 应用开发技术栈，到底该怎么学、怎么用、怎么在自己项目里跑通。

现在网上讲大模型应用开发的资料很多，但大多数要么只讲 LangChain 基础，要么只放一个 Agent Demo，真正把 LangChain、LangGraph、MCP、Agent 串起来做企业级实战的内容并不多。而这两年 AI 应用开发的变化又非常快，LangChain 已经把很多能力下沉到了 LangGraph，MCP 协议又被各大模型厂商和开发工具广泛接入，Agent 也从“聊天机器人”走向了“能调用工具、能编排流程、能批处理任务”的工程化形态。如果你还在照着 2024 年的旧教程学，很容易学完就发现 API 已经变了。

这篇文章会围绕 2026 新版的企业级实战路线，把 LangChain、LangGraph、MCP、Agent 这四块内容拆开讲清楚，并给出一套可以直接照着做的本地部署、接口调用、批量任务和排查方法。前半部分先解决“这套技术栈能干什么、门槛在哪里”，后半部分重点演示“从环境准备到 Agent 服务启动，再到接口 API 调用和批量任务验证”的完整流程。无论你是刚入门 AI 大模型应用开发，还是已经在做 RAG、Agent 项目，这篇文章都建议先收藏。

1. 核心能力速览

在开始部署和写代码之前，先把这套技术栈的规格梳理清楚。下面的表格不需要你完全背下来，但建议先看一遍，方便后面对照。

这里有一点需要先说清楚：LangChain、LangGraph、MCP、Agent 不是一个“开箱即用”的软件，而是一套开发框架和协议。这意味着你需要写代码、调 API、处理依赖，而不是下载一个一键包就能双击启动。不过这也是它值钱的地方：掌握这套技术栈之后，你可以把不同的模型、工具、数据源组合成自己的 AI 应用。

从材料给出的 2026 新版教程标题来看，这一套课程的核心思路是“企业级实战 + 从入门到实战”，而不是单独讲某一个框架的 API。所以下面的内容也会按照“先理解概念，再准备环境，再写代码，再测试接口，再跑批量任务”的顺序展开。

2. 适用场景与使用边界

2.1 适合谁

先判断一下你需不需要学这套技术栈：

• AI 应用开发者：你已经在用大模型 API，但每次都要自己封装 Prompt、处理上下文、管理多轮对话，希望有一套更工程化的方案。
• RAG 项目开发者：你需要把公司内部文档、PDF、网页内容接入大模型，做知识库问答，LangChain 是目前最成熟的 RAG 框架之一。
• Agent 开发工程师：你要做的不只是“聊天”，而是让模型自动调用搜索、数据库、API、代码执行等工具，LangGraph 比裸写 while 循环更可控。
• MCP 服务使用者：你想了解 MCP 协议是什么，为什么蓝湖、Figma、IDE 等工具都在接入 MCP，以及如何把 MCP Server 接到自己的 Agent 里。
• 课程学员或自学者：你在纠结先学 LangChain 还是 LangGraph，担心学了老版本 API 后用不上，需要一条 2026 年的学习路线。

2.2 能解决什么问题

这套技术栈解决的核心问题有三个：

第一，把大模型从“聊天接口”变成“应用组件”。你可以用 LangChain 的 ChatModel 封装统一调用 OpenAI、国产大模型、本地模型，不需要每次写一堆 HTTP 请求模板。

第二，让 Agent 从“实验 Demo”变成“可编排流程”。LangGraph 引入了图结构，你可以定义节点、条件边、循环、并行分支，让 Agent 的行为变得可预测、可调试。

第三，让外部工具接入标准化。MCP 协议解决了“每个 Agent 都要自己写一套工具接入方式”的问题。只要工具方提供 MCP Server，你的 Agent 就能按统一方式发现和调用工具。

2.3 不适合什么场景

• 如果你只需要 ChatGPT 网页版或者开箱即用的应用，不需要学这套技术栈。
• 如果你只想跑通一个几行代码的 Prompt Demo，直接用大模型官方 SDK 更快，不建议一上来就引入 LangChain。
• 如果你的项目只有固定流程、完全不需要模型自主决策，传统代码更好维护。
• 如果本地部署大模型 + 大批量任务需要极高并发，需要做架构设计，不能简单套用教程里的单机脚本。

2.4 合规与安全边界

使用这套技术栈开发跟 AI 大模型相关的项目时，有几个边界必须提前确认：

• 调用第三方大模型 API 时，注意数据隐私和合规要求，尤其是涉及公司内部数据或用户个人信息时，需要确认是否允许发送到云端模型。
• 本地部署大模型时，需要确保模型权重来源合规，使用开源模型也要遵守对应许可证。
• 如果你做 Agent 去自动操作外部系统，比如发送邮件、修改数据库、调用第三方服务，必须做权限控制、审批机制和操作日志。
• 涉及人脸、声音、文档版权的内容，必须确认授权后再处理。
• MCP Server 接入的第三方工具，要确认它是否安全，避免把 API Key 泄露给不可信的工具服务。

3. 环境准备与前置条件

3.1 操作系统与 Python 环境

LangChain、LangGraph、MCP Agent 开发以 Python 为主，推荐使用 Python 3.10 或更高版本。Windows、macOS、Linux 都可以，但如果你要本地跑 LangGraph 服务或者部署到服务器，Linux 更省事。

建议先创建虚拟环境，避免不同项目之间的依赖冲突。

python -m venv .venv source .venv/bin/activate # Windows 使用 .venv\Scripts\activate

然后升级 pip：

python -m pip install --upgrade pip

3.2 核心依赖安装

根据项目需要安装 LangChain、LangGraph、LangChain Community、LangGraph CLI 和 MCP 相关库。2026 年版本中，LangGraph 已经逐步成为工作流编排的核心，所以安装时建议把 LangGraph 相关包一起装上。

pip install langchain pip install langchain-core pip install langchain-community pip install langgraph pip install langgraph-cli pip install langchain-openai pip install mcp

说明：LangChain 的生态包更新比较频繁，如果你在安装过程中遇到版本冲突，可以先不锁定版本，安装最新稳定版；如果后续代码报 API 变更错误，再按错误信息调整。

3.3 大模型 API 配置

LangChain 和 LangGraph 本身不包含大模型，你需要准备一个可用的模型接入方式。常见的做法有两种：

第一种，使用云端大模型 API，需要配置 API Key 和基础地址。以 OpenAI 兼容接口为例：

export OPENAI_API_KEY="你的_API_Key" export OPENAI_API_BASE="https://api.openai.com/v1"

如果你使用国内大模型服务或本地部署的模型网关，通常也提供 OpenAI 兼容接口，可以按类似方式设置。

第二种，本地部署大模型。这种情况下你不需要把数据发送到外部服务，但需要一定的硬件支持。一般来说，CPU 推理也可以跑小模型，但速度会比较慢；如果想流畅运行 7B 级别的模型，建议至少准备 16G 内存，显存按模型量化版本确认。这里不做具体显存数字的保证，因为不同量化等级、上下文长度、并发数对显存的影响差异很大。

3.4 端口与目录规划

LangGraph 启动服务时默认会监听某个端口，如果端口被占用会启动失败。建议在项目目录下规划清晰的目录结构：

agent-project/ ├── .venv/ ├── src/ │ ├── agent.py │ ├── tools.py │ └── graph.py ├── config/ │ └── settings.yaml ├── data/ │ ├── input/ │ └── output/ ├── logs/ └── requirements.txt

批量任务的输入输出分目录管理，后面处理大量文件时会方便很多。

4. 安装部署与一键启动

这一节我们从零开始搭建一个可运行的 Agent 服务，并演示三种启动方式。需要提前说明：下面示例是通用模板，实际命令中的路径、模型名、端口需要按你的项目替换。

4.1 安装 LangGraph CLI 并初始化项目

LangGraph 提供了命令行工具，可以快速创建一个项目骨架。

langgraph new agent-project

执行后按提示选择模板，生成一个包含 LangGraph 服务配置的项目。如果你拉取的是现有项目，可以直接跳到下一步。

4.2 编写一个最小 Agent

下面的代码实现了最简单的 Agent：接收用户消息，调用大模型，返回回答。这里用create_react_agent创建一个带工具调用能力的 Agent，但先不绑定任何工具，先验证链路是否通。

import os from langchain_openai import ChatOpenAI from langgraph.prebuilt import create_react_agent os.environ.setdefault("OPENAI_API_KEY", "your-api-key") model = ChatOpenAI( model="gpt-4o-mini", temperature=0.3, ) agent = create_react_agent(model=model) def run(message: str): config = {"configurable": {"thread_id": "test-1"}} result = agent.invoke({"messages": [{"role": "user", "content": message}]}, config=config) return result["messages"][-1].content if __name__ == "__main__": print(run("用一句话介绍 LangGraph"))

这里有几点需要说明：

• create_react_agent是 LangGraph 预构建的 ReAct Agent，适合快速验证。
• 如果你使用的模型不支持工具调用，需要换成普通StateGraph，或使用支持 function calling 的模型。
• 如果使用本地模型，需要保证模型服务已经启动，并且 API 地址与base_url一致。

4.3 在 LangGraph 中显式编排节点

当项目变复杂，建议使用StateGraph来定义流程。下面是一个带条件路由的最小实现：先调用模型，然后根据输出是否包含“工具”字样决定走哪个分支。这个例子用于理解 LangGraph 的节点和边关系。

from typing import TypedDict, Literal from langchain_openai import ChatOpenAI from langgraph.graph import StateGraph model = ChatOpenAI(model="gpt-4o-mini") class State(TypedDict): query: str answer: str def call_model(state: State): response = model.invoke(state["query"]) return {"answer": response.content} def route(state: State) -> Literal["need_tool", "end"]: if "工具" in state["query"]: return "need_tool" return "end" def tool_node(state: State): return {"answer": state["answer"] + "（说明：这里可以替换为真实工具调用）"} graph = StateGraph(State) graph.add_node("llm", call_model) graph.add_node("tool_node", tool_node) graph.add_edge("__start__", "llm") graph.add_conditional_edges("llm", route, {"need_tool": "tool_node", "end": "__end__"}) graph.add_edge("tool_node", "__end__") app = graph.compile()

这种图结构的好处是：Agent 的每一步变得可追踪、可控制，尤其适合多步骤企业流程。LangGraph 还支持子图、并行分支和循环检测，后面做批量任务时可以配合使用。

4.4 启动 LangGraph 服务

LangGraph 可以作为一个 API 服务启动。LangGraph CLI 提供了一条命令：

langgraph dev

启动后，默认会提供一个本地接口地址，你可以用浏览器访问。

如果你不想依赖 LangGraph 自带服务，也可以直接用 FastAPI 把它包装成自己的接口。

from fastapi import FastAPI from pydantic import BaseModel from agent import run app = FastAPI() class QueryBody(BaseModel): message: str @app.post("/agent") def agent_endpoint(body: QueryBody): return {"reply": run(body.message)}

然后启动服务：

uvicorn main:app --host 127.0.0.1 --port 8600

这里需要注意，LangGraph 服务默认端口、FastAPI 自定义端口都可能冲突。如果发现端口被占用，使用--port换一个端口，或者先查看端口占用情况。

4.5 检验启动是否成功

至少完成以下三个检查：

1. 日志中没有报错。
2. 本地接口地址能打开，或者访问/docs、/health能看到接口文档或健康状态。
3. 发送一次测试请求，返回结果正常。

如果发现“服务启动成功但页面打不开”，优先检查端口是否被防火墙拦截、服务是否绑定到了127.0.0.1而不是0.0.0.0。

5. 功能测试与效果验证

不同的项目需要的 Agent 功能差别很大，下面给出一套通用测试流程。

5.1 测试基础对话能力

先不要接任何工具，只测试 Agent 是否能正常调用大模型并返回结果。

result = agent.invoke({"messages": [{"role": "user", "content": "你好，介绍一下你自己"}]}) print(result["messages"][-1].content)

判断标准：

• 返回内容是否正常，无超时、无报错。
• 是否消耗了 API 配额或本地模型资源。
• 日志中是否记录完整的请求和响应。

如果模型返回为空，可能是模型 API 地址配置错误、API Key 无效、或者请求超时。

5.2 测试工具调用（Function Call）

给 Agent 绑定一个简单的工具，例如获取当前时间或查询天气。这一步是 Agent 开发中最常见的验证点。

from langchain_core.tools import tool @tool def get_current_city() -> str: """返回当前所在城市，用于测试工具调用。""" return "北京" @tool def get_weather(city: str) -> str: """查询指定城市的天气。""" return f"{city}：晴，25℃，适合测试。" agent = create_react_agent(model=model, tools=[get_current_city, get_weather])

测试输入：

帮我查一下北京的天气

预期结果：Agent 先调用get_weather工具，拿到结果后组织回答。

判断标准：

• 日志中出现了工具调用记录。
• 返回内容包含工具返回的天气信息。
• 如果模型一直不调用工具，可能是模型能力不支持 function calling，或工具描述不够清晰。

5.3 测试 RAG 知识库问答

RAG 是 LangChain 最常见的生产场景。你可以用本地文档构建向量索引，然后让 Agent 根据文档回答。

流程如下：

1. 将文档拆分为 chunk。
2. 调用 Embedding 模型向量化。
3. 存入向量数据库。
4. 检索相关片段并拼接 Prompt。
5. 大模型基于检索结果回答。

from langchain_community.document_loaders import TextLoader from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain_openai import OpenAIEmbeddings from langchain_community.vectorstores import FAISS loader = TextLoader("docs/company.md") documents = loader.load() splitter = RecursiveCharacterTextSplitter(chunk_size=500, chunk_overlap=50) chunks = splitter.split_documents(documents) embeddings = OpenAIEmbeddings() vectorstore = FAISS.from_documents(chunks, embeddings) retriever = vectorstore.as_retriever(search_kwargs={"k": 3})

然后定义一个检索工具，绑定给 Agent。

@tool def search_docs(query: str) -> str: """根据用户问题检索公司知识库文档。""" docs = retriever.get_relevant_documents(query) return "\n".join([d.page_content for d in docs])

测试输入：

根据知识库内容，介绍一下公司产品的售后服务政策。

判断标准：

• 回答内容是否来自知识库，而不是模型胡编。
• 检索结果是否相关。
• 如果答案是模型自己编的，说明检索没有命中，需要检查 chunk 大小、embedding 模型和检索 TopK。

5.4 测试多轮对话状态

Agent 企业级应用通常需要多轮记忆。LangGraph 中可以通过thread_id维护会话状态。

config = {"configurable": {"thread_id": "session-001"}} agent.invoke({"messages": [{"role": "user", "content": "我的名字是张三"}]}, config=config) agent.invoke({"messages": [{"role": "user", "content": "我叫什么名字？"}]}, config=config)

第二问应该能正确回答“张三”。如果不能记住，说明记忆配置没有生效，或者模型没有拿到历史消息。

5.5 测试长文本与高并发稳定性

用一段较长的文本连续请求 10 次，观察是否出现超时、内存上涨、API 限流。

import time for i in range(10): start = time.time() result = agent.invoke({"messages": [{"role": "user", "content": "请用100字解释什么是MCP协议"}]}) print(f"第{i+1}次耗时：{time.time() - start:.2f}s")

这个测试能快速暴露模型服务的并发上限和你的代码是否有简单性能问题。如果每次都接近超时，需要优化 Prompt 长度、缩短上下文、或者升级模型服务配置。

6. 接口 API 与批量任务

企业级实战中，Agent 很少只跑在 Python 脚本里，更多时候需要暴露接口给前端、后端或其他服务调用。这一节演示接口 API 调用和批量任务设计。

6.1 启动接口服务

前面已经用 FastAPI 写了一个最小服务。为了更接近企业场景，给接口增加超时控制、请求日志和简单错误处理。

import logging from fastapi import FastAPI from pydantic import BaseModel from agent import run logging.basicConfig(level=logging.INFO) logger = logging.getLogger("agent-api") app = FastAPI() class QueryBody(BaseModel): message: str thread_id: str = "default" @app.post("/agent") def agent_endpoint(body: QueryBody): logger.info("收到请求：%s", body.message) try: reply = run(body.message, body.thread_id) return {"code": 0, "reply": reply} except Exception as e: logger.exception("Agent调用失败") return {"code": 500, "message": str(e)}

启动：

uvicorn main:app --host 0.0.0.0 --port 8600

注意：如果绑定0.0.0.0，局域网内其他机器也可以访问。如果是在公网环境部署，一定要加接口鉴权或放到网关后面。

6.2 curl 测试接口

curl -X POST http://127.0.0.1:8600/agent \ -H "Content-Type: application/json" \ -d '{"message": "请用一句话介绍 LangGraph", "thread_id": "test-001"}'

预期返回 JSON：

{ "code": 0, "reply": "LangGraph是一个用于构建有状态Agent应用的工作流编排框架。" }

如果返回 500，查看服务端日志。

6.3 Python 调用接口实现批量任务

批量任务是 Agent 工程化的常见需求。你可以写一个 Python 脚本，从文件中读取多条问题，逐条调用接口，把结果写入输出目录。

import requests import json import time from pathlib import Path input_file = Path("data/input/questions.jsonl") output_dir = Path("data/output") output_dir.mkdir(parents=True, exist_ok=True) url = "http://127.0.0.1:8600/agent" headers = {"Content-Type": "application/json"} success_count = 0 fail_count = 0 with open(input_file, "r", encoding="utf-8") as f: for idx, line in enumerate(f): item = json.loads(line) try: response = requests.post(url, json={ "message": item["question"], "thread_id": f"batch-{idx}" }, timeout=120) response.raise_for_status() result = response.json() if result.get("code") == 0: with open(output_dir / f"result_{idx}.txt", "w", encoding="utf-8") as out: out.write(result["reply"]) success_count += 1 else: fail_count += 1 print(f"第{idx}条业务失败：{result}") except Exception as e: fail_count += 1 print(f"第{idx}条请求异常：{e}") time.sleep(0.5) print(f"完成，成功：{success_count}，失败：{fail_count}")

这里建议加入失败重试。一个简单的重试方案是：请求异常时最多重试 3 次，间隔指数递增。

def request_with_retry(payload, retries=3): for attempt in range(retries): try: resp = requests.post(url, json=payload, timeout=120) resp.raise_for_status() return resp.json() except Exception as e: print(f"第{attempt+1}次失败：{e}") time.sleep(2 ** attempt) return {"code": 500, "message": "重试耗尽"}

6.4 使用 LangGraph 并行节点处理批量任务

如果你的批量任务希望在一个 Agent 内部并行处理，可以使用 LangGraph 的并行分支。简单来说，可以在图中添加多个节点，让它们共享输入并分别生成结果。这种方式的优点是可以并发调用多个工具或模型，缺点是调试复杂度上升。

并行分支的详细实现涉及子图和节点设计，这里不展开，优先建议先把串行批处理流程和接口服务跑通，再考虑并发优化。

7. 资源占用与性能观察

7.1 显存占用观察

如果你使用的是云端大模型 API，模型推理发生在远端，本地资源占用主要是 Python 进程、内存和网络开销。如果使用本地部署模型，才需要重点观察显存。

观察显存可以使用nvidia-smi：

nvidia-smi

可以隔几秒执行一次，或者用watch -n 1 nvidia-smi持续观察。

需要注意，显存占用受模型量化等级、上下文长度、并发数、是否启用vLLM等影响。教程里给出的数字只能作为参考，实际占用需要按你的环境和模型版本测试。

7.2 内存占用

LangChain + LangGraph 项目如果只是简单调用 API，内存占用通常不高。但如果你加载了大型文档、向量数据库、本地模型，内存可能快速上涨。建议在批量任务时监控 Python 进程内存：

top -p $(pgrep -f "uvicorn")

如果内存持续增长，考虑：

• 减少向量库中的文档数量。
• 使用流式加载而不是一次性读入全部文档。
• 批量任务增加限速和重置机制。

7.3 分辨率、步数与批量数的影响

在图像生成类项目中，这些参数影响很大，但在 LangChain/LangGraph 项目中，影响性能的参数主要是：

• 模型上下文长度：历史消息越长，请求耗时越长。
• RAG 检索数量：TopK 越大，Prompt 越长，模型输入 token 越多。
• 工具数量：绑定工具过多，可能导致模型在工具选择阶段更慢。
• 并发请求数：过高会产生 API 限流或本地模型排队。
• 嵌入向量维度：越高，向量检索耗时越长。

如果觉得 Agent 响应慢，先做输入输出耗时打点，确认瓶颈在模型调用、检索还是工具调用。

7.4 如何降低资源占用

通用方法：

• 控制多轮对话的历史消息数量，只保留最近几轮。
• RAG 检索使用更小的 TopK。
• 本地模型优先使用量化版，例如 4bit 量化。
• 批量任务限速，避免同时发起大量模型请求。
• 接口服务增加超时和最大并发连接限制。

8. 常见问题与排查方法

这里整理了一份出现频率较高的问题清单，按现象、可能原因、排查方式和解决方案整理。

9. 最佳实践与使用建议

9.1 先从最小可运行版本开始

第一次跑通 LangGraph Agent 时，不要直接上复杂工作流。建议先用一个模型、一个工具、一个节点跑通流程，再逐步加入条件路由、多节点、RAG、MCP 服务。最小可运行版本能帮你快速定位问题是在模型调用、工具调用还是图编排阶段。

9.2 把配置和代码分离

模型名、API Key、端口、TopK 这些参数应该放到配置文件或环境变量里。不要写死在代码中，因为企业项目中不同环境往往需要不同的配置。

model: provider: openai name: gpt-4o-mini temperature: 0.3 api_key_env: OPENAI_API_KEY agent: max_iterations: 10 system_prompt: "你是企业知识库助手" rag: top_k: 3 chunk_size: 500 chunk_overlap: 50

通过一个简单的 YAML 读取函数加载配置：

import yaml from pathlib import Path def load_config(path="config/settings.yaml"): with open(Path(path), "r", encoding="utf-8") as f: return yaml.safe_load(f)

9.3 工具调用要加白名单和鉴权

Agent 的工具越强大，风险越高。如果 Agent 可以调用发送邮件、修改数据库、执行命令等工具，生产环境至少要加权限验证。建议让 Agent 先生成操作意图，由人工确认后再执行关键操作，不要完全放开自动执行。

9.4 日志是排查核心

给 Agent 的每个节点、每次工具调用、每次模型请求都增加日志。特别是在 LangGraph 中，你可以打印graph.get_state()或者自定义中间回调来输出每一步状态。

from langchain_core.callbacks import BaseCallbackHandler class LogCallback(BaseCallbackHandler): def on_llm_start(self, serialized, prompts, **kwargs): print("LLM开始调用:", prompts) def on_tool_start(self, serialized, input_str, **kwargs): print("工具调用:", input_str)

把日志输出到文件，而不是只打印到控制台，后面排查线上问题会非常方便。

9.5 批量任务必须有断点续跑和失败重试

批量任务跑了几百条后卡住、重启脚本又要从头开始，这是很常见的问题。建议在脚本中记录已处理的索引或任务 ID，每次启动时跳过已完成的任务。同时给每次请求增加唯一 ID，便于日志追踪。

result_file = output_dir / "results.jsonl" done_ids = set() if result_file.exists(): for line in result_file.open("r", encoding="utf-8"): done_ids.add(json.loads(line)["id"])

9.6 模型服务要留意限流和配额

调用云端大模型 API 时，注意查看模型的 RPM 和 TPM 限制。批量任务建议加一个简单的限速器，控制每秒请求数：

import time class RateLimiter: def __init__(self, min_interval=1.0): self.min_interval = min_interval self.last_time = 0.0 def wait(self): now = time.time() wait_time = self.min_interval - (now - self.last_time) if wait_time > 0: time.sleep(wait_time) self.last_time = time.time()

这不是什么复杂方案，但在批量任务里非常实用。

10. 总结与下一步

这套 LangChain + LangGraph + MCP + Agent 技术栈，核心价值不是某一个框架的 API，而是让你有能力把大模型接入到真实业务系统中。LangChain 负责封装模型和工具，LangGraph 负责工作流编排，MCP 负责工具接入标准，Agent 则是把这一切组合起来的最终形态。

如果你现在刚入门，建议按这个顺序来：

1. 先跑通基础的 LangChain 模型调用和 Prompt 模板。
2. 再给 Agent 绑定 1 到 2 个工具，测试工具调用。
3. 然后引入 LangGraph 的 StateGraph，把流程变成可控的图。
4. 接着加入 RAG，做知识库问答。
5. 最后接入 MCP Server，把外部工具标准化接进 Agent。
6. 再封装接口 API，接批量任务。

最容易踩的坑集中在两块：一是版本变更导致的 API 不兼容，二是模型不支持工具调用但你没发现。遇到问题先看日志，再看模型能力，最后再怀疑代码逻辑。

这套技术栈的学习资料和框架版本更新很快，网上的教程需要结合官方文档一起看。你手头如果已经拿到“2026新版企业级实战全套教程”，可以按照里面的章节顺序学习，但不要只看不练，更不要跳过环境准备和接口测试。先把最小案例跑通，再逐步加复杂度，比背 API 列表高效得多。

部署好服务、验证完接口、跑完批量任务之后，可以继续扩展的方向包括：多 Agent 协作、长短期记忆、复杂的条件路由与并行子图、MCP Server 开发、以及把 Agent 服务接入到现有的业务系统里。这套技术栈的边界不在于框架本身，而在于你想让 Agent 在你的业务里承担多少工作。