MCP

什么是 Model Context Protocol (MCP)？和 Function Calling、Agent 什么关系？

MCP 是为 Agent 提供工具的，只不过它的工具是运行在云端或本地其他服务上的，Agent 需要经过一层 MCP客户端 -> JSON RPC协议 -> MCP服务器（其他服务） 才能注册和使用 MCP 提供的工具，省了我们手动定义工具，也防止 Agent 和 Tool 的高度耦合。

前 MCP 时代

在前 MCP 时代，工具是与 Agent 高度耦合的，不管是 Agent 内部的函数工具，抑或是对象工具都是如此。

在 Agent 启动时，会将自己所有的工具的 name 和 description 以列表的形式加载到内存内，并最终拼接到上下文的系统提示词内，到运行时 LLM 判断需要使用工具时就查看 system prompt 中有哪个工具直接告诉 Agent 调用就行了。

这样一来缺点很明显，不能复用、依赖手动编写、Tool 间容易重复定义。

MCP 三要素与 MCP 工作流程

MCP 问世之后，MCP 将 Agent 与 Tool 解耦了，原本的 Agent + Tool 被拆分为 Host(Agent 进程)、MCP Client 和 MCP Server 三层。

Agent 启动时，同样需要加载工具列表，但除了加载自身已有的工具，还要唤醒 MCP Client，与 MCP Server 通信获取 MCP 工具列表，将其也加入到工具列表。而需要调用 MCP Tool 时，通用通过 Client 与 Server 通信，调用工具并获得响应。

工作流程如下：

1
2
3

Host -> MCP Client -> (JSON RPC 2.0) -> MCP Server -> 工具注册/访问资源/执行工具操作 -----
  ^                                                                           | 结果回传
  |----- MCP Client <--- (JSON RPC 2.0) <--------------------------------------

为什么将 MCP Client 耦合到 Host？这是将其与 Memory、LLM、Agent Loop 看作同一层级的组件。

另外，一个 Host 也可能有多个 MCP Client，分别与多个 MCP Server 一一对应。

Server 向 Client 暴露：Resources、Tools、Prompts

三个部分：Resources、Tools 和 Prompts。

Resources 用于提供只读上下文，例如本地文件、日志片段、数据库 Schema 或配置记录。前面的工具注册严格来说就是这一能力。

Tools 用于执行动作，例如查询数据库、发送消息、创建工单或调用业务接口。会主动执行逻辑、可能改变外部状态的能力，应当放在 Tools 中。

Prompts 是可复用的提示词模板，是 Server 为自己拥有的 Tool 专门配套优化的，可以用自身工具解决更复杂的问题。比如 Server 中的 Tool 都是职责十分单一的 Tool，那么要如何用这些工具完成一项复杂的任务？也许可以交给 LLM 自行判断，但这个时候如果有 Server 提供的 Prompts 就好多了，因为我们假设 MCP Server 完全了解它的 Tool，那么如何调用这些 Tool 自然也是 MCP Server 更有经验，所以它是这个作用。

Prompts 和 Skill 有什么区别？其实在作用、形态上没什么本质区别！都是指导 Agent 完成某件事。其最大的区别只是在谁拥有：Skill 是 Agent 自己拥有的，Prompts 则是 MCP Server 借给 Agent 用的。

另外，Prompts 也需要注册，MCP Client 从 MCP Server 获取 name description metadata 以列表形式注册给 Agent，和 Tool 、Skill 一样都只引用式存储，真正需要时才渐进式披露加载整体。

Client 为 Server 赋予能力：Roots、Sampling、Elicitation……

Roots：

Sampling：允许 Server 通过 Client、Host 调用一次 LLM。

然而，2026 年 7 月 28 日，官方已经将 Roots 和 Sampling 标记为 deprecated，Elicitation 仍是当前机制。

Elicitation：Server 反问用户的能力，比如一个工具调用缺失必要字段，Server 就能通过 Client、Host 直接提问以获取缺失字段。

为什么用 JSON RPC 2.0

因为相比起 REST 更倾向于访问资源（例如直接访问目标服务器的文件系统），JSON-RPC 更倾向于访问动作，即远程调用。

MCP 的通信方式：stdio、Streamable HTTP

stdio：一般用在本地 Agent 系统里，比如 MCP Server 就在本地作为子进程，进程之间使用 stdin 和 stdout 就能很方便互相通信。适用于本地服务，且要求极低的时延.

SEE + HTTP：在远程服务器之间，通常就要采用 HTTP 进行远程通信了，比如部署在远程云端的 MCP Server。SEE 常被用于实时通信，比如新闻、股市推送等。

Streamable HTTP：已全面取代 SEE + HTTP。也是基于 HTTP 的，但是其核心优势在于能够接受到数据片段的同时就开始处理，无需传输完毕后才能处理。因此非常适合大型实时文件的传输，比如视频播放。

但是为什么远程情况不用 stdio？stdio 虽然只是一种进程 io 标准而非网络通信协议，但它可以用在任意互联的进程之间使用，只要双方能够建立起管道 pipe，不也可以实现远程通信吗？原因有三：1. stdio 没用网络的概念，找不到服务器地址，也找不到进程号；2.远程进程之间的 pipe 构建很麻烦，需要为了两个进程的通信再开一个进程代理。

MCP 的意义：复用 & 解耦

MCP 的意义绝非仅仅能让 Agent 调接口。

复用：工具无需专门针对不同 Host 特调，可以统一下发给若干 Host。

解耦：Agent 不再负责工具的实现。

MCP 要如何针对生产环境优化？

方面	生产环境需要解决的问题
接口规范	明确时间、金额、分页等字段的格式、单位、默认值；Schema、说明和示例必须一致；Server 要做参数校验并返回可让模型修正的错误
可观测性	用 Trace ID、结构化日志记录参数、耗时、结果摘要、错误码，串起 Agent → 多个 Server → 工具的完整调用链
权限与安全	明确文件、数据库、生产 API、邮件等权限范围；删除、修改、发送、生产调用等高风险操作需要确认、审计和回滚机制
Prompt Injection	防护 Server 的 description、Prompt、返回结果都可能影响模型行为，因此必须审核 Server 来源、依赖、权限和更新记录，防止诱导模型越权或泄露数据
成本治理	Token、向量检索、第三方 API、云资源都有成本；调用必须能关联用户、业务线、工具，才能进行成本追踪和控制
版本与兼容性	工具字段、枚举、返回结构的变化会影响模型决策；需要工具级版本、灰度发布、旧版本保留和自动化兼容性测试

一句话：MCP 确实实现了解耦，但解耦后来源各异的 MCP 工具的安全性必须要经过审查，杜绝引入危险内容（prompt 注入等问题）；同时要经过实际测试判断成本，是否值得使用？这也是一个问题。

构建MCP Server 时应该注意什么

Tool 职责单一

不要追求大而全的万能工具。这种工具必然导致 description 杂乱无章， metadata 也会无限增大，共同作用下 LLM 会很难判断是否使用，于是造成召回率低的问题。

大文件

大文件、长文件天然不好传输，我们换个思路，难道所有业务都需要读取整个文件吗？所有内容都要加入到上下文吗？肯定不是，一般情况下都是读取其中一部分，所以我们每次只传一部分，例如 100KB 一个 chunk，按需读取。甚至有时候不需要读取原文的，传输文件名、大小、更新时间、摘要、可读取范围等就行了。

另外，文件 chunk 为什么只能用字节数计算大小而非 token 数？是因为不同模型的 tokenizer 不同，算得的 token 数也不同，这一点记住就好。

安全问题

可以分为四个大点：权限、参数校验、超时和审计。

方面	核心问题	MCP 中应该怎么做
权限	Server / Tool 能访问什么、操作什么？	最小权限；限制文件目录、数据库、API、写操作范围；高风险操作二次确认
参数校验	Agent 传进来的参数是否合法？	Server 必须依据 Schema 做类型、范围、枚举、格式、业务规则校验；不能只相信模型
超时	工具一直不返回怎么办？	Tool 调用设置超时、取消机制和资源上限；区分连接超时、执行超时、下游超时
审计	谁调用了什么，发生了什么？	记录用户、Agent、Tool、参数摘要、时间、Trace ID、耗时、结果摘要、错误码；敏感数据脱敏

接入时记录协议 revision

方面	核心要求
协议版本	固定并记录 MCP protocol revision 和 SDK 版本，避免同一个 Server 在不同 Host 上行为不一致
能力协商	Host 能否使用 Sampling、Elicitation、Tasks 等能力，取决于双方实际协商结果，不能假设“支持 MCP = 支持所有能力”
接入验证	最小 Server 先用 Inspector 验证初始化、能力协商、参数校验和错误响应是否正确
生产治理	远程服务再补 OAuth、限流、Trace、版本兼容、回滚；文件和命令工具必须在 Server 侧做目录校验与沙箱隔离

MCP 是能力协商协议，而不是连上就默认所有功能都能用，在真正使用之前要对 MCP 进行校验。