你有没有遇到过这样的场景想用 AI 大模型帮你分析数据库里的数据却发现它连不上你的数据库想让它帮你操作 Figma 设计稿却发现它连不上你的设计工具。你只能手动复制粘贴数据、截图、描述效率低下不说还容易出错。这背后是一个根本性的问题大模型本身是一个“大脑”但它没有“手”和“眼睛”。它无法直接操作你电脑里的软件、读取你数据库里的数据、调用你公司内部的 API。过去我们解决这个问题的方式是写大量的胶水代码为每一个工具、每一个数据源定制开发一个“连接器”这个过程繁琐、重复且难以维护。最近一个名为MCPModel Context Protocol的协议开始引起广泛关注。当它与 LangChain 这样的 Agent 框架结合时事情开始变得不一样了。它不像是一个简单的功能更新更像是在为 AI Agent 搭建一套标准化的“神经系统”和“感觉器官”。这不仅仅是让 Agent 多会几个“技能”Skills而是从根本上改变了 Agent 获取和利用外部世界信息的方式。本文不会停留在概念介绍我们将深入探讨为什么 MCP 的出现是 Agent 能力的一次关键跃升LangChain 接入 MCP 后其 Agent 的工作流发生了哪些底层变化以及我们如何利用这套新范式将 Claude、GPT 等大模型真正变成能操作我们私有工具、处理我们私有数据的“超级员工”1. 从“胶水代码”到“标准接口”MCP 解决了什么根本问题在 MCP 出现之前让 AI Agent 使用外部工具通常是这样一幅图景定义工具函数开发者需要为每一个想被调用的能力比如查询数据库、调用天气 API、操作文件编写一个 Python 函数。描述工具用自然语言详细描述这个函数是干什么的、需要什么参数、返回什么结果。注入 Agent将这些函数和描述“喂”给 LangChain 的 Agent。Agent 调用Agent 在思考过程中如果觉得需要某个工具就会生成调用该工具的指令框架再执行对应的函数。这个过程存在几个明显的痛点开发成本高每个新工具都需要从零开始写代码、处理认证、解析输入输出。维护困难工具一旦更新如 API 变更对应的代码和描述也需要同步更新。灵活性差工具与 Agent 框架深度耦合。换一个框架比如从 LangChain 换到 LlamaIndex工具代码可能得重写。动态性弱工具列表通常在 Agent 启动时就固定了运行时难以动态发现和加载新工具。MCP 的核心思想就是将这些“胶水代码”标准化。它定义了一套简单的、与编程语言无关的协议让任何“能力提供方”Server都能以统一的方式向“能力消费方”Client如 AI Agent宣告“我这里有哪些工具Tools可以用有哪些数据Resources可以读。”你可以把 MCP Server 想象成一个标准的“插座面板”上面有各种形状的“插孔”工具和数据源。而 LangChain Agent作为 MCP Client则是一个自带“万能插头”的设备。只要插头对上就能即插即用无需为每个插座单独改造设备。1.1 MCP 协议的三块基石Tools, Resources, Prompts理解 MCP关键是理解它定义的三种核心“资产”Tools工具这是最核心的部分。一个 Tool 代表一个可执行的操作比如query_database,create_figma_frame。MCP Server 向 Client 声明这些工具的名称、描述、输入参数 schema。当 ClientAgent决定调用某个工具时它只需要按照协议发送一个标准的调用请求Server 负责执行并返回结果。Resources资源代表可读取的静态或动态数据比如一个数据库表的结构描述Schema、一个文件夹下的文件列表、一个实时更新的日志流。Client 可以“读取”Read这些资源将其内容作为上下文提供给大模型。这解决了“如何让模型知道外部系统里有什么”的问题。Prompts提示词一些预定义的、可复用的提示词模板。Client 可以获取并填充这些模板用于引导模型行为。这有助于在不同 Agent 间共享最佳实践。这种分离带来了巨大的优势工具和数据的提供者Server与使用者Client彻底解耦。开发一个 Figma 插件作为 MCP Server 后任何支持 MCP 的 AI 平台如 Claude Desktop, Cursor, LangChain都能立即获得操作 Figma 的能力无需各自为战。1.2 为什么这对 LangChain Agent 是“跃升”对于 LangChain 开发者来说MCP 带来的改变是范式级的从“建造工具”到“集成服务”你不再需要为 PostgreSQL、Slack、Jira 等每一个服务编写 LangChain Tool 类。你只需要找到一个现成的 MCP Server社区已经有很多或者自己按标准实现一个然后通过几行配置连接到 LangChain。你的开发重心从“实现功能”转向了“编排和调度”。动态能力发现Agent 在运行时可以动态查询已连接的 MCP Server 提供了哪些工具和资源。这意味着 Agent 的能力可以随时扩展而不需要重启或修改代码。上下文获取质变通过ResourcesAgent 可以主动获取外部系统的结构信息。例如在回答关于数据库的问题前它可以先读取“数据库schema”这个 Resource从而准确理解表结构和字段含义生成更精准的 SQL。这比单纯靠静态的、可能过时的工具描述要可靠得多。生态共享一个为“内部工单系统”写好的 MCP Server可以同时被 LangChain、Claude Desktop、自定义前端等多个 Client 使用极大提升了代码的复用价值。2. LangChain 如何接入 MCP技术原理与核心组件拆解LangChain 通过langchain-mcp-adapters等包提供了对 MCP 的一流支持。其接入的核心流程和技术原理可以概括为以下几步2.1 建立连接MCP Client 与 Server 的会话首先LangChain 需要化身为一个 MCP Client并与一个或多个 MCP Server 建立连接。这通常通过 STDIO标准输入输出或 SSEServer-Sent Events进行通信。# 示例性代码展示核心概念 from langchain.agents import AgentExecutor, create_openai_tools_agent from langchain_mcp_adapters import MCPClient, MCPServer # 假设我们连接一个本地的“文件系统” MCP Server import subprocess # 1. 启动 MCP Server 进程例如一个用Python写的文件操作Server server_process subprocess.Popen( [python, path/to/filesystem_mcp_server.py], stdinsubprocess.PIPE, stdoutsubprocess.PIPE, textTrue ) # 2. LangChain 创建 MCP Client并与该进程的 stdin/stdout 绑定 client MCPClient(server_process.stdin, server_process.stdout) # 3. 初始化会话Client 会向 Server 发送 initialize 请求交换能力信息 await client.initialize_session()连接建立后Client 会收到 Server 宣告的完整工具 (tools) 和资源 (resources) 列表。2.2 工具转换将 MCP Tools 适配为 LangChain Tools这是关键的一步。LangChain Agent 内部运作依赖于其自有的Tool抽象。因此需要将从 MCP Server 获取到的工具描述包装成 LangChain 能识别的Tool对象。from langchain.tools import Tool # 从 MCP Client 获取原始工具列表 mcp_tools await client.list_tools() langchain_tools [] for mcp_tool in mcp_tools: def make_tool_func(tool_meta): # 这是一个闭包用于捕获当前工具的元数据 async def tool_func(**kwargs): # 当Agent调用此工具时通过 MCP Client 发送标准的 call_tool 请求 result await client.call_tool(tool_meta.name, argumentskwargs) return result.content # 返回工具执行结果 return tool_func # 创建 LangChain Tool 对象 langchain_tool Tool( namemcp_tool.name, funcmake_tool_func(mcp_tool), descriptionmcp_tool.description, args_schema... # 可以根据 mcp_tool.inputSchema 生成 ) langchain_tools.append(langchain_tool)这个过程是自动化的。langchain-mcp-adapters提供了类似MCPToolkit或load_mcp_tools这样的高级接口让你用一两行代码就能完成所有 MCP Server 工具的加载和转换。2.3 资源集成将动态上下文注入 Agent 思维MCP Resources 的集成更为巧妙。它不像 Tools 那样被直接“调用”而是作为一种增强型上下文在 Agent 需要时被拉取并插入到给大模型的提示Prompt中。例如一个“数据库 Schema” Resource。当用户问“我们用户表里有哪些字段”时传统的 Agent 可能因为缺乏上下文而胡编乱造。而集成了 MCP 的 Agent 工作流会这样处理意图识别Agent或规划器判断这个问题需要了解数据库结构。资源读取通过 MCP Client 发送read_resource请求获取名为database://myapp/schema的 Resource 内容。上下文增强将获取到的 Schema 描述可能是 JSON 或 DDL 语句作为系统提示词System Prompt或对话历史的一部分提供给大模型。生成回答大模型基于准确的 Schema 信息生成可靠的回答“用户表有 id, name, email, created_at 四个字段。”这相当于给了 Agent 一个“随时查阅说明书”的能力从根本上减少了幻觉。2.4 构建并运行 Agent最后将这些转换好的 LangChain Tools 和集成了资源获取逻辑的 Prompt 模板交给标准的 LangChain Agent 框架去运行。from langchain_openai import ChatOpenAI from langchain.agents import AgentExecutor, create_openai_tools_agent from langchain_core.prompts import ChatPromptTemplate, MessagesPlaceholder # 加载所有 MCP 工具 mcp_toolkit MCPToolkit.from_mcp_server(server_process) tools mcp_toolkit.get_tools() # 创建 Agent llm ChatOpenAI(modelgpt-4o, temperature0) prompt ChatPromptTemplate.from_messages([ (system, 你是一个助手可以操作文件和数据库。在回答前如果需要你可以先查看可用资源和工具。), MessagesPlaceholder(variable_namechat_history), (human, {input}), MessagesPlaceholder(variable_nameagent_scratchpad), ]) agent create_openai_tools_agent(llm, tools, prompt) agent_executor AgentExecutor(agentagent, toolstools, verboseTrue) # 运行 Agent result await agent_executor.ainvoke({ input: 请先查看数据库schema然后告诉我订单表里金额大于100的订单有多少条, chat_history: [] }) print(result[output])在这个流程中当 Agent 决定要“查看数据库schema”时它实际上会调用对应的 MCP Resource 读取工具将 schema 信息拉取到上下文中然后再进行后续的分析和查询。3. 深度应用实践打造你的“超级技能”工作流理解了原理我们来看如何应用。MCP 的价值在复杂、真实的工作流中才能完全体现。我们设计一个进阶场景一个集成了内部数据库、云存储、项目管理工具和代码仓库的“数据分析与报告生成”Agent。3.1 场景搭建连接多个 MCP Server假设我们有以下几个 MCP ServerPostgreSQL Server提供查询工具和表结构资源。S3 Server提供文件列表、读取、上传工具。Jira Server提供查询任务、创建子任务工具。GitHub Server提供获取 PR 列表、仓库文件资源。在 LangChain 中我们可以同时连接所有这些 Server。# 概念性代码展示多 Server 集成思路 servers [ launch_mcp_server(postgres, connection_string...), launch_mcp_server(s3, bucketmy-bucket), launch_mcp_server(jira, url..., token...), launch_mcp_server(github, ownermyorg, repomyrepo, token...), ] all_tools [] all_resource_readers {} # 保存资源读取器 for server in servers: client MCPClient(server.stdin, server.stdout) await client.initialize_session() # 加载工具 toolkit MCPToolkit(client) all_tools.extend(toolkit.get_tools()) # 缓存资源读取器供后续使用 all_resource_readers[server.name] toolkit.get_resource_reader()3.2 设计智能工作流超越简单问答现在我们可以向 Agent 提出复杂请求“分析上周从S3的logs/目录下新上传的日志文件找出错误率最高的服务。然后去数据库里查一下这个服务对应的负责人是谁最后在Jira上给他创建一个‘日志分析跟进’的任务并把分析结果的摘要上传到S3的reports/目录。”这个工作流涉及多个系统的链式操作和决策。传统的、工具列表固定的 Agent 很难可靠地完成。但在 MCP 范式下我们可以通过以下设计来实现规划阶段让 Agent或一个上级规划器先拆解任务。它可能会先尝试读取s3://my-bucket/logs/的资源来了解文件列表。迭代执行步骤1调用 S3 的list_files工具过滤出上周的文件。步骤2调用 S3 的read_file工具获取日志内容在内存中或通过调用一个分析函数计算错误率。步骤3识别出服务名后调用 PostgreSQL 的query工具执行类似SELECT owner FROM services WHERE name ‘xxx’的查询。步骤4调用 Jira 的create_issue工具创建任务并将负责人字段填入上一步查询的结果。步骤5将分析摘要组织成文本调用 S3 的upload_file工具上传。上下文传递每一步的结果如服务名、负责人邮箱都作为下一步的输入。MCP 协议本身不管理状态这需要由 LangChain 的 Agent 执行器或 LangGraph 这样的工作流引擎来维护。3.3 关键实现细节与避坑指南在实践中有几个细节决定了成败工具描述的清晰度MCP Server 提供的工具描述 (description) 至关重要。它必须足够清晰、无歧义让大模型能准确理解何时调用、如何传参。避免使用过于技术化的内部术语。错误处理与重试网络调用、权限问题、数据异常都可能发生。必须在 LangChain Agent 的调用层或自定义的 Tool 函数里加入健壮的错误处理和重试逻辑并将友好的错误信息返回给模型让它能调整策略。资源更新的实时性对于Resources要明确它是静态快照还是动态实时。如果数据库 Schema 经常变那么read_resource的结果可能很快过时。需要考虑缓存策略或让 Server 提供“强制刷新”的机制。权限与安全这是重中之重。MCP Server 是直接操作敏感系统和数据的网关。必须实施严格的权限控制如基于角色的访问控制 RBAC确保 Agent 只能访问被授权的工具和资源。不要在 Server 端实现过于宽泛的权限。性能与成本频繁读取大型 Resource如整个数据库表或调用慢速工具会导致 Agent 响应变慢和大模型 Token 消耗激增。设计时要考虑“按需获取”和“摘要提取”。例如提供一个get_table_summary工具而不是每次都拉取全部数据。4. 面向生产从原型到可靠系统的工程化思考将基于 MCP 的 LangChain Agent 用于个人自动化很有趣但要用于生产环境必须跨越“玩具”与“系统”之间的鸿沟。4.1 架构模式选择根据复杂度可以选择不同的架构单一智能体模式一个 LangChain Agent 集成所有 MCP Tools。适合逻辑相对线性、工具数量不多15个的场景。管理简单但任务复杂时 Agent 容易“迷失”。分工协作模式创建多个 specialized Agent。例如一个“数据查询 Agent”专管数据库和 S3一个“任务管理 Agent”专管 Jira 和邮件。通过一个“主控 Agent”或 LangGraph 进行任务规划和分发。这更符合复杂业务逻辑但编排复杂度高。MCP Server 即微服务将每个 MCP Server 视为一个独立的微服务拥有自己的认证、限流、监控。LangChain 作为统一的智能编排层。这种架构最 scalable也最复杂。4.2 可观测性与调试Agent 的“黑盒”特性是生产调试的噩梦。必须建立强大的可观测性全链路日志记录每一次工具调用输入、输出、耗时、每一次资源读取、每一次模型请求与响应。追踪Tracing使用 OpenTelemetry 等标准为每个用户会话生成一个追踪链可视化整个工作流的执行路径和耗时瓶颈。评估与测试建立自动化测试套件针对关键工作流进行回归测试。使用 LLM 本身或规则来判断 Agent 输出的正确性。4.3 稳定性保障限流与降级对 MCP Server 的调用进行限流防止意外流量打垮后端系统。当某个工具持续失败时要有降级策略如返回缓存数据或友好错误。上下文管理长时间运行的 Agent 会话其上下文对话历史、工具调用结果会不断膨胀。需要设计策略来修剪或总结历史防止超出模型上下文长度并减少 Token 消耗。人的介入Human-in-the-loop对于关键操作如创建 Jira 任务、发送邮件可以设计审批环节。让 Agent 生成待执行的操作描述经人工确认后再实际调用工具。4.4 技能Skills的沉淀与复用“Skills”在这里可以理解为预配置、可复用的 Agent 行为模块。一个 Skill 可能包含一组相关的 MCP Tools 配置。一段针对特定任务的优化 Prompt例如专门用于 SQL 生成的 Prompt。一套错误处理规则。甚至是一个小型的 LangGraph 工作流。你可以将“生成周报”、“故障排查”、“用户反馈分类”等常见任务封装成 Skills。这样构建新应用时就不再是从零开始连接工具和写 Prompt而是像搭积木一样组合这些 Skills。5. 总结MCP 不是又一个工具而是 Agent 的“能力总线”回顾整个过程MCP 与 LangChain 的结合其深远意义在于它标准化了 AI Agent 与外部世界交互的接口。过去每个 AI 应用都在重复造轮子编写与特定系统对话的代码。现在只要一个系统暴露了 MCP Server 接口它就自动接入了整个支持 MCP 的 AI 生态。对于开发者和企业而言最直接的行动建议是盘点内部能力列出你最希望 AI 能自动操作的系统数据库、CRM、Git、监控平台等。优先实现或采用 MCP Server为这些核心系统寻找或开发 MCP Server。从简单的、只读的资源开始如数据字典再到复杂的、可写的工具。用 LangChain 进行高阶编排利用 LangChain 强大的 Agent 和 Workflow 能力将一个个独立的 MCP 能力串联成能解决实际业务问题的智能工作流。重视工程化从第一天就考虑权限、监控、日志和测试避免后期重构。这项技术正在快速发展Claude Code、Cursor 等工具已内置 MCP Client 支持意味着你为 LangChain 开发的 MCP 技能可能也能直接被这些日常工具调用。未来我们或许不再需要为每一个新 AI 应用重新连接数据源而是拥有一个由标准化“能力插座”构成的智能环境。而 LangChain 接入 MCP正是迈向这个未来关键而坚实的一步。
![[光学原理与应用-521]：对光的错误理解与纠偏](http://pic.xiahunao.cn/yaotu/[光学原理与应用-521]：对光的错误理解与纠偏)
