MCP

MCP（Model Context Protocol）是一种让 AI 客户端接入外部工具和数据源的协议。它关注的不是“模型如何生成回答”，而是“模型所在的客户端怎样以统一方式发现工具、读取资源、调用能力”。

可以把 MCP 理解为 AI 工具生态里的统一插座：客户端不需要为每个数据库、文件系统、业务 API 都写一套私有接法，而是通过 MCP Server 暴露标准能力。

与其他模块的关系

• 大语言模型负责理解和生成，见 大语言模型。
• 智能体负责组织多步任务，见 智能体。
• Skill 负责告诉 Agent 什么时候、怎样使用工具，见 Agent Skill。

MCP 只解决连接层问题。它不会自动保证任务目标正确，也不会替代权限设计、审计和人工确认。

基本架构

角色	作用	例子
AI 客户端	承载模型和交互界面	IDE、桌面助手、命令行代理
MCP Client	客户端里的协议连接层	发现 Server、列出工具、发起调用
MCP Server	封装外部能力	文件读取、数据库查询、业务 API
外部资源	真正的数据或系统	仓库、数据库、工单、搜索、云服务

MCP Server 像一个受控服务台。它不应该把整个系统无差别暴露给模型，而应该把能力拆成明确、可审计、权限受限的工具。

MCP 能暴露什么

常见能力包括：

• 工具：执行一个动作，例如查询订单、搜索文档、创建工单。
• 资源：读取一类内容，例如文件、数据库表、知识库页面。
• 提示模板：提供固定任务入口，例如代码审查模板、摘要模板。

工具更像按钮，资源更像资料柜，提示模板更像标准表单。三者可以组合，但职责不同。

什么时候需要 MCP

适合使用 MCP：

• 多个 AI 客户端都要访问同一类内部工具。
• 工具需要统一权限、审计和参数校验。
• 希望把数据库、文件、业务系统以标准方式暴露给 Agent。
• 不希望每个客户端都维护一套私有插件。

不一定需要 MCP：

• 只是一次性脚本或本地临时命令。
• 工具只服务一个固定应用，且已有稳定私有集成。
• 数据不能被模型侧读取，必须通过后端固定流程处理。

一个具体场景

假设要做“订单客服助手”：

1. 用户问：“这笔订单为什么还没发货？”
2. 模型需要订单状态，但不能直接访问数据库。
3. MCP Server 暴露一个 query_order_status 工具，只允许按订单号查询必要字段。
4. 客户端把工具结果放回上下文。
5. 模型基于订单状态和发货规则生成答复。

这里的关键不是“模型更聪明”，而是外部数据以安全、可控、可追踪的方式进入上下文。

设计 MCP Server 的原则

工具要小而明确

不要暴露“执行任意 SQL”这类过宽工具。更稳妥的是暴露受控动作：

• 查询订单状态。
• 查询用户最近工单。
• 搜索知识库文章。
• 创建一条草稿回复。

工具越接近业务动作，越容易限制参数、审计结果和做权限控制。

权限要最小化

只读能完成任务，就不要给写权限。只需要订单状态，就不要返回完整用户信息。只需要某个目录，就不要开放整个文件系统。

结果要适合模型使用

工具返回不要过长。应包含完成任务需要的字段、必要状态和错误信息。长日志、长表格、长文档应支持分页、过滤或摘要。

错误要可判断

工具失败时应区分：

• 参数错误。
• 无权限。
• 资源不存在。
• 外部系统超时。
• 内部异常。

模型或 Agent 才能决定是重试、换参数、请求人工，还是停止。

安全边界

MCP 带来的风险主要来自“模型能触达外部系统”。需要重点处理：

• 凭证不进入对话和日志。
• 工具参数做白名单和类型校验。
• 写操作需要幂等设计和人工确认。
• 访问结果脱敏。
• 调用日志可审计。
• 不同环境使用不同权限。

MCP Server 不应把模型当成可信调用方。模型产生的是意图，Server 负责验证这个意图能不能执行。

排查路径

现象	优先检查
客户端看不到工具	Server 是否启动、配置路径是否正确、协议连接是否成功
工具调用失败	参数 schema、权限、环境变量、外部系统连通性
返回太长污染上下文	是否需要分页、过滤、摘要或字段裁剪
模型误用工具	工具命名是否清楚、描述是否准确、Skill 是否补充流程
权限过大	是否拆分只读/写入工具，是否按环境隔离凭证

总结

MCP 的价值是标准化连接外部世界。它把工具和资源包装成 AI 客户端可发现、可调用、可审计的能力。设计 MCP 时重点不是接得越多越好，而是工具边界清楚、权限最小、返回可用、失败可判断。