MCP 协议是什么：让 Agent 稳定连接工具和上下文

MCP，全称 Model Context Protocol。

它的定位很清楚：为 AI 应用连接外部系统提供一套开放协议。外部系统可以是本地文件、数据库、搜索引擎、业务 API、设计工具、知识库，也可以是一组预先定义好的 prompts 和 workflows。

如果只看模型本身，LLM 只能基于输入文本生成输出。真正进入 Agent 阶段后，模型需要读数据、调用工具、执行动作、拿到反馈，再继续下一步。MCP 解决的就是这层连接问题。

官方文档把 MCP 类比为 AI 应用的 USB-C 接口。这个类比有一定准确性：它不是某一个具体工具，而是让工具和 AI 应用之间有统一接法。

核心判断

MCP 的价值不在于让模型“更聪明”，而在于让 Agent 的工具层更标准、更可复用、更容易治理。

没有 MCP 之前，每个 AI 应用接每个系统都要写一套自定义集成：

Claude 接数据库：写一套
Claude 接 GitHub：写一套
IDE 接数据库：再写一套
内部 Agent 接 GitHub：再写一套

这种模式会产生典型的 N × M 集成问题。

MCP 的思路是把外部能力封装成 MCP Server，再由 MCP Client 接入。这样同一个工具能力可以被不同 AI 应用复用，不需要每换一个模型或应用就重新设计工具接口。

MCP 解决什么问题

1. 统一工具接入方式

Agent 要调用工具，最麻烦的不是写一个函数，而是让不同工具按照一致方式暴露能力、描述参数、返回结果、处理错误。

MCP 把这些能力标准化。

常见 MCP Server 可以暴露：

• 文件系统读写。
• 数据库查询。
• GitHub / GitLab 操作。
• 浏览器自动化。
• 搜索服务。
• 企业内部 API。
• 设计稿、文档、知识库。

对上层 AI 应用来说，这些工具不再是零散脚本，而是协议化能力。

2. 提供上下文，而不只是函数调用

MCP 名字里有 Context，这一点很关键。

很多人把 MCP 简化理解成“工具调用协议”，这不够准确。它不仅能暴露 tools，也能暴露 resources 和 prompts。

也就是说，MCP 可以提供：

• 当前项目文件。
• 数据库 schema。
• 文档内容。
• API 描述。
• 业务规则。
• 标准提示模板。
• 可执行工具。

这让 Agent 不只是“会调用函数”，而是能拿到完成任务所需的上下文。

3. 降低 Agent 应用开发成本

官方文档提到，MCP 能减少开发者构建或集成 AI 应用时的时间和复杂度。

原因很直接：一旦团队内部已有 MCP Server，新的 Agent 应用可以复用这些 Server。

例如：

内部知识库 MCP Server
数据库 MCP Server
GitLab MCP Server
工单系统 MCP Server
监控系统 MCP Server

后续不管接 Claude、ChatGPT、IDE Agent、内部助手，工具层都可以复用。

基本架构

MCP 规范中有三个核心角色：

可以简化理解为：

AI 应用 / Agent Host
  ↓
MCP Client
  ↓
MCP Server
  ↓
外部系统：数据库、文件、API、业务服务

MCP 规范基于 JSON-RPC 2.0 消息通信。这个选择让它更像一个清晰的协议，而不是某个厂商 SDK。

MCP 和函数调用有什么区别

函数调用通常是模型 API 级别的能力。开发者把工具 schema 传给模型，模型决定要不要调用。

MCP 更偏系统集成层。

函数调用解决“模型如何选择工具”。

MCP 解决“工具和上下文如何被标准化接入 Agent 应用”。

两者不是替代关系，更多是层次不同。

工程落地场景

1. 代码助手

IDE Agent 可以通过 MCP 访问：

• 项目文件。
• Git 状态。
• 测试命令。
• Issue。
• CI 结果。
• 代码搜索。

这类场景已经是 MCP 最自然的落地方式之一。

2. 企业知识助手

企业内部助手可以通过 MCP 访问：

• Confluence / Notion。
• 飞书文档。
• 数据库。
• CRM。
• 工单系统。
• 内部 API。

这样用户不用手动复制上下文，Agent 可以按权限读取需要的信息。

3. 数据分析 Agent

数据分析场景可以把数据库、指标平台、报表系统做成 MCP Server。

Agent 可以先读取 schema，再生成查询，再执行分析，再返回解释。

真正的价值不是“让模型写 SQL”，而是让数据访问、权限、查询执行和结果返回有标准链路。

4. 运维与平台工程

运维 Agent 可以通过 MCP 连接：

• 日志系统。
• 监控系统。
• Kubernetes。
• 云资源。
• CI/CD。
• 告警平台。

这类场景必须非常重视权限和审计，因为工具调用可能直接影响生产环境。

MCP 的边界

MCP 不是完整 Agent 框架。

它不负责：

• 替模型做规划。
• 替 Agent 做长期记忆。
• 决定业务流程。
• 自动保证工具安全。
• 解决所有权限问题。
• 替代应用层的审计和风控。

MCP 只是把外部能力以标准方式暴露出来。至于 Agent 应该如何使用这些能力，仍然需要上层系统设计。

这也是工程落地时最容易误解的地方：接了 MCP，不代表 Agent 就变可靠了。

可靠性仍然来自：

• 权限隔离。
• 工具白名单。
• 参数校验。
• 操作审计。
• 人工确认。
• 失败回滚。
• prompt injection 防护。

安全风险

MCP 的风险来自它的能力本身。

一旦 Agent 可以访问真实文件、数据库、代码仓库和生产工具，风险就不再只是“回答错了”，而是可能产生真实副作用。

需要重点关注：

• 工具权限过大。
• MCP Server 来源不可信。
• Prompt injection 诱导 Agent 调用危险工具。
• 本地文件或密钥被不当暴露。
• 工具返回内容污染模型上下文。
• 缺少审计日志。
• 缺少高风险操作确认。

MCP Server 应该按最小权限原则设计。生产环境工具尤其不应该直接暴露给通用 Agent。

更稳妥的做法是：

只读工具先行
低风险动作可自动执行
中风险动作需要确认
高风险动作只给建议，不自动执行

MCP 与 A2A 的关系

MCP 和 A2A 经常被放在一起讨论，但两者解决的问题不同。

一句话区分：

MCP：Agent 如何连接工具和上下文
A2A：Agent 如何发现、通信和协作

MCP 面向工具层。

A2A 面向 Agent 之间的互操作。

在一个企业级 Agent 系统里，两者可以同时存在：

销售 Agent 通过 A2A 调用 财务 Agent
财务 Agent 通过 MCP 访问 ERP 和发票系统
销售 Agent 通过 MCP 访问 CRM

这时，A2A 管 Agent 和 Agent 的协作，MCP 管 Agent 和工具系统的连接。

适合什么时候引入 MCP

适合引入 MCP 的情况：

• 同一批工具要服务多个 Agent。
• 工具数量开始增多。
• 内部系统接入重复开发严重。
• 希望把工具能力沉淀为平台能力。
• 需要对工具访问做统一治理。
• 想让 IDE、聊天助手、内部 Agent 共用能力。

暂时不需要 MCP 的情况：

• 只有一个简单工具。
• 只是一次性脚本。
• 没有复用需求。
• 还没有权限和审计设计。
• 团队只是做概念验证。

不要为了“用了 MCP”而引入 MCP。

MCP 的价值在复用和治理。当工具层还很小，直接函数调用可能更简单。

结论

MCP 是 Agent 工程化里的关键协议之一。

它把“模型调用工具”这件事，从零散函数和临时代码，推进到可复用、可组合、可治理的协议层。

它最适合解决：

• 工具接入标准化。
• 上下文供给标准化。
• 多 AI 应用复用同一批工具。
• 企业内部 Agent 平台的工具层治理。

但 MCP 不是万能答案。它提供连接能力，也放大了权限和安全问题。

真正落地时，MCP 应该和权限、审计、工具分级、人工确认、日志追踪一起设计。

更准确地说：

MCP 不是 Agent 的大脑，而是 Agent 接入外部世界的一套工程接口。

参考：

• What is the Model Context Protocol?
• MCP Specification 2025-06-18
• Introducing the Model Context Protocol
• Code execution with MCP