LLM 系列 (十九)：MCP，大模型如何连接外部工具生态

大模型擅长理解语言、生成内容和进行推理，但它并不天然连接外部世界。它不知道你电脑里的文件、数据库里的最新记录、浏览器当前页面状态，也不能直接访问企业内部系统。要让模型从“回答问题”走向“完成任务”，就必须让它能够安全、标准化地读取资料、调用 API、查询数据库、访问代码仓库、操作浏览器，并触发业务工作流。

在 MCP 出现之前，每个 AI 应用往往都要自己适配外部工具：代码助手要接文件系统、Git、数据库、终端和浏览器；企业助手要接飞书、Slack、Notion、工单、CRM 和数据平台；不同 Agent 框架又会重复实现类似能力。这会带来典型的 N × M 集成问题：N 个 AI 应用分别适配 M 个外部系统，连接方式、权限模型、工具描述和返回格式都不统一。

MCP，全称 Model Context Protocol，可以理解为大模型应用连接外部工具和数据源的一套开放协议。它要解决的核心问题是：让 AI 应用用统一方式发现工具、读取资源、调用能力，并把外部系统返回的结果作为上下文交给模型继续推理。简单说，MCP 不是让模型“多一个工具”，而是为大模型应用提供一套标准化、可组合、可治理的外部能力连接层。

为什么需要 MCP

LLM 从聊天问答走向 Agent 之后，核心变化是：模型不再只是生成一段回答，而是要围绕目标持续执行任务。

比如代码 Agent 要读项目文件、查 Git diff、运行测试、分析日志并修改代码；企业助手要查询知识库、读取权限内文档、访问数据库、调用工单系统，并输出带引用的答案。

这些任务背后都有一个共同点：模型必须连接外部系统。问题在于，如果每个 AI 应用都自己适配这些系统，工程复杂度会很快失控。

没有统一协议时，不同 AI 应用需要重复适配外部系统

这就是典型的 N × M 集成问题：N 个 AI 应用分别对接 M 个外部系统。每个应用都要处理工具描述、认证授权、参数校验、返回格式、错误处理和安全边界，最后很容易变成一堆彼此不兼容的私有集成。

MCP 的价值，是把外部系统封装成标准 Server，让 AI 应用通过统一协议访问。

MCP 把外部系统封装成标准 Server，让 AI 应用通过统一协议访问

可以把 MCP 放在整个 LLM 应用架构中的位置理解成：

层次	解决的问题	典型技术
模型层	理解、生成、推理	LLM / Reasoning Model
上下文层	给模型提供资料	Prompt、RAG、长上下文
工具层	让模型调用外部能力	Function Calling、Tool Use
协议层	标准化工具和数据接入	MCP
应用层	完成业务任务	Agent、Copilot、企业助手

MCP 不是替代模型，也不是替代 Prompt。它更像是大模型应用和外部世界之间的连接协议。

一句话概括：Function Calling 让模型知道可以调用什么函数，MCP 则进一步标准化这些函数、资源和提示模板从哪里来、如何被发现、如何被调用。

MCP 核心架构：Host、Client、Server

MCP 采用的是 Host / Client / Server 架构。理解这三个角色，是理解 MCP 的关键。很多人第一次看 MCP 时，容易把 Client 和 Server 的关系理解反：在 MCP 里，AI 应用一侧是 Host 和 Client，外部工具一侧才是 Server。

MCP 核心架构

一个 Host 可以创建多个 MCP Client，每个 Client 通常连接一个 MCP Server。三个角色的关系可以这样理解：

Host：AI 应用本身，位于 AI 应用内部，比如 Claude Desktop、代码编辑器、Agent 平台、企业 AI 助手。它负责用户交互、模型调用、上下文组织，以及决定哪些工具结果进入模型。
Client：Host 内部的连接器，Client 由 Host 创建，用来和某个 MCP Server 建立连接、发送请求、接收结果。一个 Host 可以同时维护多个 Client，从而连接多个外部系统。
Server：外部能力提供方，Server 位于工具或数据源一侧，可以运行在本地，也可以运行在远程。它负责暴露文件、数据库、API、浏览器操作、企业系统等能力。

MCP 协议层基于 JSON-RPC 2.0 消息通信，并包含生命周期管理、能力协商、工具发现、资源读取、Prompt 获取和通知等机制。一个典型流程可以简化为四步：

连接初始化：Client 和 Server 建立连接，并进行能力协商；
能力发现：Client 获取 Server 暴露的 Tools、Resources、Prompts；
模型决策：Host 将可用能力组织进上下文，模型决定是否调用；
结果回传：Server 执行调用并返回结果，Host 再交给模型继续推理。

MCP 的核心流程是连接初始化、能力发现、工具调用和结果回传

MCP 的通信方式主要有两类：

通信方式	适合场景	特点
stdio	本地 Server	适合桌面应用、代码助手、本地文件系统
Streamable HTTP	远程 Server	适合企业服务、云端工具、多人共享能力

所以，MCP 既可以用于本地桌面 Agent，也可以用于企业内部工具平台。前者更适合连接本机文件、终端、浏览器；后者更适合连接企业知识库、数据库、工单系统和内部 API。

MCP Server 的核心能力：Tools、Resources、Prompts

MCP Server 的核心价值，不是简单把一个 API 暴露出去，而是把外部系统的能力标准化描述出来，让 Host 可以通过 Client 统一发现、读取和调用。

这一节重点讨论 MCP Server 暴露给 Client 的三类核心 primitives：Tools、Resources、Prompts。需要注意的是，MCP 协议并不只有这三类能力，它还包括 Sampling、Elicitation、Logging 等 Client 侧 primitives，主要用于模型采样、用户信息补充和日志通知等场景。本文先聚焦 Server 如何向大模型应用提供外部能力，这些 Client 侧能力暂不展开。

简单理解，这三类对象分别对应三件事：

Tools：模型可以触发什么动作；
Resources：模型可以读取什么上下文；
Prompts：某类任务应该如何组织提示词和工作流。

MCP Server 的核心能力：Tools、Resources、Prompts

需要注意的是：MCP Server 是把能力暴露给 MCP Client，真正决定是否交给模型使用的是 Host。模型通过 Host/Client 来访问 Server。

Tools

Tools 是 MCP Server 暴露的可执行能力，适合表达“做一件事”。比如查询订单、执行 SQL、搜索代码、打开网页、创建工单、发送消息等。一个 Tool 通常需要描述清楚几件事：

字段	作用
name	工具唯一名称，供调用时定位工具
description	告诉模型这个工具什么时候该用
inputSchema	用 JSON Schema 描述输入参数
output / response	工具执行后的返回内容，通常体现在 `tools/call` 的响应里

例如，一个订单查询工具可以这样描述：

{
  "name": "query_order",
  "description": "根据订单 ID 查询订单状态",
  "inputSchema": {
    "type": "object",
    "properties": {
      "order_id": {
        "type": "string",
        "description": "订单 ID"
      }
    },
    "required": ["order_id"]
  }
}

当模型判断需要查询订单时，Host 会把工具调用转发给对应的 MCP Server：

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "query_order",
    "arguments": {
      "order_id": "ORD-20260707-001"
    }
  }
}

Tools 的关键价值是：让模型从“只生成文本”变成“可以触发外部动作”。但 Tool 也是风险最高的一类能力，因为它可能改变外部系统状态。所以生产系统里，Tool 一定要配合权限控制、参数校验、调用审计和高风险确认。

Resources

Resources 是 MCP Server 暴露的数据资源，适合表达“读一份信息”。比如文件内容、数据库 Schema、API 文档、项目 README、网页内容、企业文档、应用运行状态等。Resource 通常通过 URI 标识：

{
  "uri": "file:///project/README.md",
  "name": "README.md",
  "description": "项目说明文档",
  "mimeType": "text/markdown"
}

读取资源时，Client 可以发送：

{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "resources/read",
  "params": {
    "uri": "file:///project/README.md"
  }
}

Resources 的关键价值是：让模型获得外部上下文，但不一定执行动作。这类能力更适合给模型补充事实依据，例如“当前项目结构是什么”“数据库有哪些表”“这份文档里写了什么”。

Resources 和 RAG 有点像，但它们不是同一层东西：

对比项	RAG	MCP Resources
核心目标	检索相关知识	标准化暴露外部资源
典型对象	文档 chunk、向量索引	文件、Schema、API 响应、应用状态
触发方式	根据问题召回	按资源列表或 URI 读取
关注重点	检索质量、排序、引用	协议、权限、资源描述、上下文接入
关系	可以封装成 MCP Server	可以承载 RAG、文件、数据库等资源入口

简单说：RAG 更像知识检索方案，MCP Resources 更像外部上下文接入协议。

Prompts

Prompts 是 MCP Server 提供的提示词模板或工作流模板。它适合把某类任务的经验沉淀下来，比如代码审查、SQL 分析、故障排查、文档总结、安全审计等。例如，一个代码审查 Prompt 可以这样描述：

{
  "name": "code_review",
  "description": "对代码进行质量审查并给出修改建议",
  "arguments": [
    {
      "name": "code",
      "description": "需要审查的代码",
      "required": true
    }
  ]
}

获取 Prompt 时：

{
  "jsonrpc": "2.0",
  "id": 4,
  "method": "prompts/get",
  "params": {
    "name": "code_review",
    "arguments": {
      "code": "def hello(): print('world')"
    }
  }
}

Prompts 的关键价值是：把领域任务经验沉淀成可复用模板，而不是让每个用户从零写提示词。

这对企业系统尤其重要。因为企业内部往往有固定的代码审查规范、事故复盘格式、数据分析模板、客服回复风格。如果这些经验只写在文档里，模型未必能稳定遵循；如果沉淀成 MCP Prompt，Host 就可以按标准方式获取并复用。

三者如何配合

Tools、Resources、Prompts 不是彼此孤立的。真正的 Agent 任务里，它们通常会组合使用：Prompt 负责给出任务模板，Resources 负责提供上下文，Tools 负责执行动作。如下图所示：

Prompts 组织任务，Resources 提供上下文，Tools 执行动作

例如，一个“分析线上故障”的 Agent 可以先通过 Prompts 获取故障排查模板，再通过 Resources 读取服务拓扑、监控指标和错误日志，必要时通过 Tools 查询工单、执行只读诊断命令、拉取最近发布记录。工具结果会继续回到上下文中，模型再基于这些信息分析故障原因、影响范围和修复建议。

所以 MCP 的硬核点不只是“能调用工具”，而是把外部能力拆成了三类标准接口：Prompts 组织任务，Resources 提供上下文，Tools 执行动作。这套抽象让不同 AI 应用不必重复发明工具协议，也让外部系统可以用统一方式进入 Agent 生态。

MCP 如何连接外部工具生态

MCP 真正有价值的地方，不是让模型多调用一个工具，而是把外部系统封装成一组标准化、可组合、可治理的 Server。这样不同 AI 应用就不需要重复适配文件系统、数据库、浏览器、企业系统和开发工具，而是通过统一协议发现和调用这些能力。

MCP Server 可以把不同外部系统标准化接入同一个 Agent

常见的 MCP Server 大致可以分成几类：

Server 类型	暴露的能力	典型场景
文件系统 / 代码仓库	读写文件、搜索目录、查看 Git diff	代码理解、代码修改、项目分析
数据库 / 数据平台	Schema、只读 SQL、样例数据、报表摘要	数据分析、指标解释、业务问答
浏览器 / UI 环境	打开页面、读取 DOM、截图、点击、填表	UI Agent、网页操作、自动化测试
企业系统	文档、工单、CRM、审批、IM、监控告警	企业助手、运维助手、工作流自动化
开发工具	CI、日志、Tracing、部署记录、监控	故障排查、发布分析、代码 Agent

这里最关键的不是“能不能接上”，而是 接入后能不能被 Agent 稳定使用。

例如数据库 Server 不应该默认给模型任意 SQL 权限，更合理的方式是只读访问、限制库表、限制返回行数、执行前校验 SQL，并把所有查询写入审计日志。浏览器 Server 也类似，模型可以读取页面和截图，但点击、提交、购买、删除等动作应该有明确权限边界。

对 Agent 来说，MCP 的意义更大。因为 Agent 不是一次性调用工具，而是会在任务执行过程中不断规划、调用、观察和修正。

MCP 可以成为 Agent 工具发现和调用的标准协议层

这也是 MCP 和普通 API 调用最大的区别之一：

方式	特点	局限
普通 API 调用	开发者提前写死接口调用逻辑	每个应用都要重复适配
Function Calling	模型输出函数名和参数，应用执行对应函数	工具来源、发现、资源读取仍依赖应用自定义
MCP	Server 标准化暴露 Tools、Resources、Prompts，Host 统一发现和调用	仍需要权限、安全、审计等生产治理

简单说，MCP 让工具生态从“应用内硬编码”走向“协议化接入”。这会让外部能力更容易复用，也让 Agent 更容易在多个系统之间组合完成任务。

安全治理与未来演进

MCP 让模型可以连接更多外部系统，也意味着风险会同步放大。一旦模型能读文件、查数据库、操作浏览器、调用企业 API，错误输出就不只是“答错一句话”，而可能变成真实的业务影响。核心风险可以分成几类：

风险	说明	示例
数据越权	模型读取了用户无权访问的数据	查询跨部门文档、数据库越权
工具误调用	模型调用了错误工具或传错参数	修改错误工单、发错消息
高风险操作	模型触发写入、删除、支付等动作	删除文件、提交审批、下单
Prompt Injection	外部文档诱导模型忽略规则	网页里隐藏恶意指令
工具投毒	Server 或工具描述不可信	恶意 Server 伪装成可信工具
结果污染	工具返回内容未经校验就进入上下文	错误数据影响最终结论
审计缺失	无法回放模型调用链路	出问题后不知道调用了什么

MCP 系统的安全边界应该覆盖连接、权限、调用、结果和审计全链路。

MCP 的安全治理需要覆盖连接、权限、调用、结果和审计全链路

生产级 MCP 落地时，可以重点把握几条原则：

Server 必须可信：只允许连接可信 MCP Server，不要让用户随意加载未知 Server。尤其是能访问文件、浏览器、数据库和企业系统的 Server。
Tool 最小权限：每个 Tool 只暴露完成任务所需的最小能力。能只读就不要写，能查询单表就不要开放全库。
高风险动作显式确认：写文件、删除数据、发送消息、提交审批、支付、下单等动作，都应该有人类确认或审批流。
输入输出都要校验：Server 要校验工具输入，Host 也要校验工具结果。外部内容不能直接无处理地进入模型上下文。
防 Prompt Injection：外部资源中的内容必须视为不可信数据，而不是系统指令。网页、文档、邮件、工单评论尤其需要注意。
审计与回放：每次工具调用都应该记录：谁发起、调用了哪个 Server、哪个 Tool、参数是什么、返回了什么、是否经过确认。
版本与兼容：MCP 有协议版本、Server 版本、工具 Schema 版本。生产环境要避免 Server 升级后工具含义变化，导致 Agent 行为漂移。

MCP 和现有技术的关系可以这样理解：

技术	解决的问题	和 MCP 的关系
Prompt	如何表达任务	MCP Prompts 可以沉淀任务模板
RAG	如何检索外部知识	RAG 可以封装成 MCP Server
Function Calling	如何让模型调用函数	MCP 标准化工具发现和调用来源
Agent	如何规划和执行任务	MCP 提供工具生态接入层
API Gateway	如何治理服务调用	MCP 仍需要网关、权限和审计配合
Plugin	如何扩展某个应用	MCP 更偏跨应用、跨工具的协议化连接

未来 MCP 可能会成为 Agent 应用的重要基础设施。它不会替代模型，也不会替代业务系统，而是把模型、上下文、工具和工作流之间的连接标准化。

一句话概括：MCP 的核心价值，不是让模型多一个工具，而是让大模型应用拥有一套标准化、可组合、可治理的外部能力连接层。它让文件、数据库、浏览器、企业系统和 Agent 工具生态可以被统一暴露、统一发现、统一调用，也让大模型从“会回答问题”进一步走向“能连接系统、执行任务、参与工作流”。

参考

LLM 系列 (十九)：MCP，大模型如何连接外部工具生态

LLM 系列 (十九)：MCP，大模型如何连接外部工具生态

为什么需要 MCP

MCP 核心架构：Host、Client、Server

MCP Server 的核心能力：Tools、Resources、Prompts

Tools

Resources

Prompts

三者如何配合

MCP 如何连接外部工具生态

安全治理与未来演进

版权说明

公众号