LangChain Agent集成MCP全流程：从工具调用到记忆持久化

最近 LangChain、Agent、MCP 这几个关键词在开发圈讨论度很高。这次我们直接拆一套完整的 LangChain Agent 集成 MCP 全流程，重点解决当下 Agent 应用里最容易被忽略的问题：Agent 怎么接外部工具，以及记忆系统在企业级场景里怎么做才不是玩具。内容会覆盖核心概念、环境准备、服务启动、工具注册、记忆持久化、接口 API、批量任务、性能观察和常见坑位排查，偏实战导向。

如果你正在做 AI Agent 开发，或者准备把 LangChain Agent 接入企业内部的 MCP Server，这篇建议直接收藏，按章节跟着做。

1. 核心能力速览

在动手之前，先把这套 LangChain Agent 集成 MCP 方案的规格列出来，方便判断是不是你需要的技术栈。

需要注意，MCP 只是工具接入标准，LangChain 本身负责 Agent 的推理循环和工具调度，记忆则决定 Agent 能不能在多轮对话中保持上下文一致性。三者组合起来才是一套完整的企业级 Agent 架构。

2. 适用场景与使用边界

这套方案适合的团队和场景比较明确。首先是已经使用 LangChain 做 Agent 开发的团队，想在不重写代码的前提下接入 MCP Server 工具；其次是企业内部需要把数据库、文件系统、第三方业务系统暴露给 Agent 的工程团队；第三种是想快速验证 Agent 工程化能力，但又不想从零实现工具注册和记忆组件的开发者。

MCP 的实用价值在于工具接入标准化。以前 LangChain 要接一个内部工具，得单独写 tool 函数、做鉴权、做参数解析；现在通过 MCP Server，LangChain Agent 可以用统一方式发现和调用工具，工具数量多了之后维护成本明显降低。LangGraph 则补足了 LangChain 在复杂任务编排上的短板，适合需要条件分支、循环、人工审批节点的场景。

使用边界也要说清楚。不要把 MCP 接入当成万能方案，更不要在没有鉴权、没有审计、没有权限隔离的环境里直接让 Agent 访问核心业务数据。企业内部落地时，工具读写的接口必须遵守现有的权限边界，Agent 调用工具产生的操作应有日志可供追溯。涉及用户隐私、敏感材料、人脸声音素材等内容时，必须先确认授权链路完整，不能因为技术上能接入就直接放行。

从开发阶段就定下合规边界，比上线后再补要省事得多。

3. LangChain Agent 与 MCP 基础概念

3.1 LangChain Agent 是什么

LangChain Agent 本质上是一个让大模型可以调用外部工具的执行循环。模型根据用户输入和工具描述，决定使用哪个工具、传什么参数，然后等待工具返回结果，继续下一步推理，直到任务完成。

常见组件包括：

• Agent 模型：负责规划步骤的 LLM，通常用 OpenAI 兼容接口或本地推理服务。
• 工具集：包括内置工具和第三方工具，MCP 服务是工具来源之一。
• 推理器：根据工具描述决定调用顺序。
• 执行器：运行工具并收集结果。
• 记忆组件：保存历史消息、状态、长期事实和知识片段。

3.2 MCP 协议在 Agent 中的位置

MCP 可以理解为一套让 Agent 与大模型应用发现并调用外部工具的标准协议。MCP Server 可以是一个独立的 Python 进程，也可以是一个远程服务，内部封装文件系统操作、数据库查询、HTTP 请求、代码执行等能力。

Agent 与 MCP Server 的典型关系是：Agent 从 MCP Client 获取可用工具列表，再把用户意图转换成参数调用，拿到结果后交给大模型继续决策。

3.3 LangGraph 和 LangChain 的关系

LangChain 和 LangGraph 不是二选一的关系。LangGraph 更像是 LangChain 的编排扩展，适合把 Agent 流程表达成图结构，一边跑一边保存状态。对复杂 Agent 系统，LangGraph 的价值很大；对简单顺序调用，直接用 LangChain 的链式写法就够。

3.4 Agent 记忆系统要解决什么问题

企业级 Agent 记忆和玩具 Demo 的差别在于：Demo 只要把聊天记录暂存在内存里；企业级需要把短期对话、长期偏好、业务事实分开存，并且支持检索和过期淘汰。

常见的记忆层次：

• 短期记忆：当前会话的对话上下文，常放入 prompt。
• 长期记忆：跨会话的用户意图、偏好、结论，存入数据库。
• 知识记忆：从文档、知识库检索出的片段，可向量化后按需注入。

4. 环境准备与前置条件

4.1 基础环境

建议在 Linux 或 macOS 环境开发，Windows 也能跑，但部分进程管理和依赖编译会多一些波折。

需要准备的核心依赖：

如果使用 OpenAI 兼容接口，需要保证本机或内网能访问模型服务。如果是本地模型推理，还需要准备 GPU 环境，显存取决于模型参数量。

4.2 Python 环境创建

建议创建独立虚拟环境，避免依赖互相污染。

python -m venv .venv source .venv/bin/activate pip install --upgrade pip pip install langchain langgraph langchain-openai langchain-mcp-adapters fastmcp mcp chromadb redis

安装完成后，验证关键包能否正常导入：

import langchain import langgraph import mcp from langchain_mcp_adapters.tools import load_mcp_tools print("langchain:", langchain.__version__) print("langgraph:", langgraph.__version__) print("deps ok")

这段代码只验证包导入，真正的能力验证要看后续 Agent 能否通过 MCP Server 调用工具。

5. 安装部署与启动方式

5.1 搭建一个最小的 MCP Server

先写一个简单的 MCP Server，提供一个计算工具和一个时间工具，作为 Agent 的测试目标。

# mcp_demo_server.py from mcp.server.fastmcp import FastMCP mcp = FastMCP("demo-mcp-server") @mcp.tool() def add(a: int, b: int) -> int: """计算两个整数之和""" return a + b @mcp.tool() def get_current_time() -> str: """返回当前时间字符串""" from datetime import datetime return datetime.now().isoformat() if __name__ == "__main__": mcp.run(transport="stdio")

这个 Server 直接通过标准输入输出与 Agent 进程通信，是本地开发最稳定的方式。

启动方式：

python mcp_demo_server.py

正常情况进程会进入等待状态，不要关闭这个终端，后续 Agent 启动时会连接它。

5.2 通过配置文件管理 MCP Server

考虑到后续要挂多个 MCP Server，可以把配置放到文件里统一管理。

# mcp_config.yaml mcp_servers: demo_server: command: python args: ["mcp_demo_server.py"] file_server: command: python args: ["mcp_file_server.py"]

这样清晰可维护，用脚本读取配置再初始化连接即可。

5.3 创建 LangChain Agent

下面写一个 Agent 脚本，通过 FastMCP 标准连接加载 MCP 工具，再挂载记忆组件。

# agent_with_mcp.py import asyncio from langchain_openai import ChatOpenAI from langchain_mcp_adapters.tools import load_mcp_tools from mcp import ClientSession, StdioServerParameters from mcp.client.stdio import stdio_client async def main(): server_params = StdioServerParameters( command="python", args=["mcp_demo_server.py"], ) async with stdio_client(server_params) as (read, write): async with ClientSession(read, write) as session: tools = await load_mcp_tools(session) llm = ChatOpenAI( model="gpt-4o-mini", temperature=0, ) from langgraph.prebuilt import create_react_agent agent = create_react_agent(llm, tools) result = await agent.ainvoke({"messages": [("user", "帮我计算 128 + 256 的结果")]}) print(result["messages"][-1].content) asyncio.run(main())

执行前需要确认大模型接口地址和 Key 能通。用 OpenAI 兼容服务时，可临时在启动脚本里设置环境变量：

export OPENAI_API_KEY="your-key" export OPENAI_BASE_URL="http://your-endpoint/v1" python agent_with_mcp.py

如果一切正常，Agent 会调用 add 工具并返回 384。

5.4 启动 Agent API 服务

实际项目里，Agent 通常不是一次性脚本，而是常驻 API 服务。可以基于 FastAPI 包装：

# agent_api.py from fastapi import FastAPI from pydantic import BaseModel from agent_runtime import run_agent app = FastAPI() class ChatRequest(BaseModel): session_id: str message: str class ChatResponse(BaseModel): session_id: str reply: str @app.post("/chat", response_model=ChatResponse) async def chat(req: ChatRequest): reply = await run_agent(req.session_id, req.message) return ChatResponse(session_id=req.session_id, reply=reply)

启动方式：

uvicorn agent_api:app --host 127.0.0.1 --port 8000

接口服务启动后，后续所有客户端调用、批量任务、前端接入都可以统一走 HTTP 协议。

6. 功能测试与效果验证

6.1 基础工具调用测试

先测 Agent 是否能识别“我需要使用工具”的场景。

测试输入：

帮我计算 128 + 256 的结果

预期：

• 大模型识别到需要 add 工具。
• Agent 调用 MCP Server 中的 add。
• 返回 384。

如果 Agent 直接把原问题返回给你，说明工具没有正确加载，或者模型被配置成禁用工具。

判断标准是 Agent 在推理过程中确实调用了工具，并输出了计算结果，而不是猜了一个结果。

6.2 多工具联合调用测试

再测多步骤规划能力：

先计算 100 + 200，再计算结果的 2 倍

预期：

• 先调用 add。
• 再调用 multiply 之类的工具，或由模型直接计算。
• 最终输出正确结果。

这一步主要验证 LangChain Agent 能否连续规划多个工具调用。LangGraph 可以把这类多步调用结构清晰地展示出来。

6.3 MCP Server 连接失败测试

故意把 MCP Server 的路径改错，然后启动 Agent。

预期现象：

• 连接阶段报错，或工具列表为空。
• 服务可能启动失败，或请求超时。

排查思路：

1. 先单独启动 MCP Server，确认不报错。
2. 检查 stdio 进程路径和参数是否匹配。
3. 看 Agent 所在进程有没有 MCP 日志输出。

6.4 记忆持久化测试

记忆是重点，先测短期记忆。

步骤：

• 第一次调用，告诉 Agent“我叫张三，帮我记住”。
• 第二次调用，不提名字，直接问“我叫什么”。

如果 Agent 能回答，说明短期记忆生效了，也就是当前会话多少轮内的历史进入了 prompt。

再测长期记忆：

• 关闭服务进程。
• 重启。
• 再次问“我叫什么”。

如果重启后仍然能回答，说明 Agent 对话历史被写入了持久化存储，例如 Redis 或数据库。

企业级场景不能接受重启后记忆丢失，所以这一步必须验证。

6.5 知识库检索记忆测试

企业级 Agent 还需要能从文档库检索知识。可以先生成一个向量库：

from langchain.embeddings import OpenAIEmbeddings from langchain.vectorstores import Chroma docs = [ "公司内部报销标准：单次低于2000元由部门经理审批。", "项目上线前必须完成安全评审并留下记录。", ] vectorstore = Chroma.from_texts(docs, OpenAIEmbeddings())

Agent 在回答相关问题时，会优先从向量库检索片段注入 prompt，而不再只依赖模型内部知识。

7. 接口 API 与批量任务

7.1 API 端点设计

企业级 Agent 服务建议至少提供以下端点：

API 启动后，先用 curl 验证健康检查：

curl http://127.0.0.1:8000/health

再验证对话：

curl -X POST http://127.0.0.1:8000/chat \ -H "Content-Type: application/json" \ -d '{"session_id": "user-001", "message": "今天天气怎么样"}'

7.2 Python 调用示例

import requests BASE_URL = "http://127.0.0.1:8000" def chat_with_agent(session_id: str, message: str) -> dict: resp = requests.post( f"{BASE_URL}/chat", json={"session_id": session_id, "message": message}, timeout=60, ) resp.raise_for_status() return resp.json() if __name__ == "__main__": result = chat_with_agent("user-001", "帮我查一下项目的最新状态") print(result["reply"])

7.3 批量任务队列设计

批量任务的核心不是循环调用接口，而是将任务切成可控单元。

推荐路径：

• 输入目录读取一批问题或文档。
• 每条任务生成一个任务 ID。
• 通过队列提交给 Agent。
• 后台 Worker 消费队列，逐个处理。
• 结果写入输出文件或数据库。
• 失败任务重试并记录日志。

配置示例：

batch: input_dir: ./data/input output_dir: ./data/output concurrency: 4 max_retries: 3 timeout_seconds: 120

并发数不建议一上来就调太高，先 2 到 4 并发跑一小批，观察服务稳定性和响应时间，再逐步调高。

8. 资源占用与性能观察

8.1 显存与 CPU 开销

需要区分两部分开销。

LangChain Agent 编排本身占用极少，主要是 Python 进程和内存，不依赖 GPU。如果挂载的是本地 Llama 或 Qwen 这类开源模型，显存需求才出现，取决于模型参数量和量化方式。

观察方式：

watch -n 1 nvidia-smi

重点看模型服务进程的显存占用，而不是整个 Agent 进程。

8.2 推理参数对性能的影响

影响 Agent 响应速度的主要因素：

• 大模型服务本身的推理延迟。
• MCP Server 工具响应速度。
• 上下文长度，历史消息越长，推理越慢。
• 批量并发数，并发太高时模型服务可能排队。

如果发现响应明显变慢，先看模型服务延迟，再看 Agent 日志里哪一步耗时最多。

8.3 降低资源占用的策略

如果本地部署，降低资源占用可以从下面几方面入手：

• 使用量化模型，例如 4bit、8bit，而不是全精度。
• 控制上下文长度，定期裁剪早期对话。
• 缓存高频检索结果。
• 并发数严格限制。
• 用向量数据库替代每次全量扫描。

9. 常见问题与排查方法

如果在接入其他 MCP Server 时遇到注册不上或工具无法识别的问题，优先检查服务端启用的 transport 方式、允许的工具白名单、以及 Agent 侧是否接收到了同一份工具协议格式。

10. 最佳实践与使用建议

10.1 先做最小验证

不要第一次就接几十个 MCP Server。先用一个最小可运行版本，验证 Agent 能发现工具、能调用工具、能返回结果，再逐步扩展工具集。

10.2 记忆组件要分表分逻辑

不要把短期聊天记录、长期用户偏好、知识库片段混在一个地方。建议至少拆成三个存储域，分别设置生命周期：

• 聊天记录：保留最近 N 轮。
• 长期记忆：按用户维度长期保留。
• 任务状态：按任务 ID 保留执行前后快照。

10.3 日志与审计优先

企业级 Agent 必须有日志。每次工具调用、每个关键决策、每次记忆写入，都应该有结构化日志，方便排查问题和审计。

10.4 注意工具授权与安全边界

MCP Server 不应该直接暴露全部资源。比如文件系统服务，只允许读写指定目录；数据库 MCP 服务，只允许执行只读查询或限定表范围；网络请求服务，最好配置域名白名单。

隐私与版权方面，涉及人脸、声音、版权素材、用户个人信息时，必须确认使用授权。Agent 处理的内容不应违反现有保密协议，不应绕过系统的权限控制。

10.5 提示词和工具描述要写成约束

给工具起名字和描述时，尽量写清楚适用条件和输入输出格式。工具描述写得模糊，模型就会误用。建议描述模板：

工具名：xxx 用途：当用户需要xxx时使用 输入：参数类型与语义 输出：返回格式 注意事项：什么情况下不能使用

10.6 推荐先梳理三个 Agent

第一个是简单 ReAct 风格 Agent，验证工具调用；第二个是带记忆的 Agent，验证多轮和持久化；第三个是结合 MCP Server 的业务 Agent，验证真实工具链路。按这个顺序推进，踩坑率会低很多。

11. 总结与下一步

把 LangChain Agent 和 MCP 集成这件事拆开看，最值得先动手验证的三件事是：MCP 工具能否被 Agent 发现并调用、多轮对话记忆能否持久化、批量任务是否稳定可重试。建议先把这三条主链路跑通，再往里加业务工具。

最容易踩的坑集中在两块：一块是 MCP Server 进程的管理，stdio 模式适配不好经常导致工具列表为空或执行超时；另一块是记忆组件只在内存里生效，一重启全丢，给人“Agent 失忆”的错觉。

代码跑通后，可以继续向这几个方向扩展：接入官方或第三方 MCP Server，丰富工具生态；将记忆迁移到 Redis 与向量库，支撑更大规模用户；使用 LangGraph 编排更复杂的多 Agent 协作流程；在 API 服务前面加统一鉴权与限流，作为企业服务对外暴露。

如果只看一篇 LangChain Agent 与 MCP 的教程，按这套路径往下走即可。建议收藏备用，后边接入自己项目的时候直接照着跑。