# MCP：AI Agent 连接现实世界的“USB 接口”

> 本文整理自 Maria Mouschoutzi 发表于 Towards Data Science 的文章 [MCP Explained: How Modern AI Agents Connect to the Real World](https://towardsdatascience.com/mcp-explained-how-modern-ai-agents-connect-to-the-real-world/)，原文发表于 2026 年 7 月 28 日。本文保留原文的核心论点、架构说明与风险边界，并做适合中文读者的结构化改写。

## Agent 真正难的，不只是“会不会调用工具”

过去讨论 AI Agent 时，我们往往把注意力放在模型如何选择工具、生成参数，以及如何把执行结果送回上下文。但进入真实应用后，一个更基础的问题会迅速浮现：这些工具从哪里来，又该怎样接入不同模型？

如果每个模型和每个工具之间都要维护一套专用连接器，系统就会陷入典型的 **M×N 集成问题**。三个模型连接十个工具，理论上可能产生三十套适配关系；任一模型、接口或鉴权方式改变，都可能带来连锁维护成本。

MCP（Model Context Protocol）试图解决的正是这个问题：把模型与工具之间的点对点适配，变成遵循统一协议的连接。

## 为什么有人把 MCP 比作 AI Agent 的 USB

早期计算机外设各自使用专用接口，设备和主机必须一一匹配。USB 出现后，主机和设备只要共同支持标准接口，就能互相连接。

MCP 的思路相似：

- AI 应用不必为每个工具重新编写模型专用适配器；
- 工具通过统一协议描述和暴露能力；
- 支持 MCP 的宿主可以在运行时发现工具，并按统一结构调用；
- 工具实现和 Agent 编排因此能够分离演进。

这并不意味着 REST、GraphQL 或现有 API 会消失。MCP 更像是面向 LLM 的标准接入层：底层工具仍可调用原有 API，只是对 Agent 暴露出统一、可发现的接口。

## MCP 的三层架构

原文将 MCP 架构分成三个角色。

### Host：承载用户与模型交互

Host 是用户直接操作的 AI 应用，例如桌面助手或编辑器扩展。它管理模型上下文、决定何时发起工具调用，并把工具结果送回对话。

### Client：管理协议连接

Client 位于 Host 内部，负责与一个或多个 MCP Server 建立连接、发现能力并交换协议消息。它是 Host 与 Server 之间的通信层。

### Server：提供工具和数据

Server 承载真正的能力和数据。它不会直接与 LLM 通信，而是通过 Client 向 Host 暴露标准化接口。

这种分层的重要意义，是把“模型怎样思考”和“工具怎样实现”分开。模型可以更换，工具也可以独立升级，只要双方继续遵循协议边界。

## Server 暴露的不只是工具

MCP Server 可以提供三类能力：

1. **Tools**：可执行操作，例如查询服务、发送邮件或修改数据。能力最强，风险也最高。
2. **Resources**：只读数据，例如文件内容、数据库记录或 API 响应。
3. **Prompts**：可复用的结构化提示模板，例如代码审查流程。

原文用 Python SDK 演示了一个天气服务：开发者通过 `@mcp.tool()` 注册普通函数，SDK 根据类型标注生成 JSON Schema；Client 初始化会话后，可以先调用 `list_tools()` 发现工具，再通过 `call_tool()` 执行。

关键变化不是少写了几行代码，而是工具从“写死在 Agent 脚本里”变成了“运行时可发现的标准能力”。

## 标准化连接之后，治理成为主问题

当“Agent 能否接入工具”逐渐从定制开发变成配置问题，团队需要回答的新问题是：

- 哪些 Agent 可以看到哪些工具？
- 哪些能力必须保持只读？
- 写入、删除、通知和部署是否需要人工确认？
- 工具描述是否足够准确，能否避免模型选错工具？
- 工具返回内容会不会携带提示词注入？
- 如何识别同名假工具或被篡改的 Server？

原文特别强调三类风险：工具输出中的提示词注入、恶意 Server 的工具投毒，以及违反最小权限原则的过度授权。MCP 统一了接入方式，但不会自动让不可靠的工具变可靠，也不会替团队完成权限设计。

原文还强调，MCP 规范要求 Host 在真正执行工具前获得用户明确授权。实际系统仍需把这一要求落实为工具调用审批、最小权限和可审计的授权记录，而不能只依赖协议兼容性。

## 快速增长的生态，不等于零成本落地

原文梳理了一条快速发展的时间线：MCP 于 2024 年 11 月由 Anthropic 开源；2025 年 3 月 OpenAI 宣布支持，2025 年 4 月 Google 确认支持；2025 年 12 月，Anthropic 将其捐赠给 Linux 基金会旗下的 Agentic AI Foundation。原文还引用数据称，到 2026 年 3 月，Python 与 TypeScript SDK 的月下载量合计达到 9700 万。

这些信号说明 MCP 正在成为重要的 Agent 工具协议，但“接入变成配置”仍是偏乐观的表述。企业环境中的身份认证、网络隔离、审计、版本兼容和故障恢复，并不会因为采用统一协议而消失。

## 对团队最有价值的落地顺序

与其一开始迁移全部工具，不如先做一次边界清晰的小规模验证：

1. 盘点多个 Agent 或模型中重复维护的工具定义；
2. 选择一个只读、低风险、结果容易验证的能力；
3. 将工具所有权与 Agent 编排分离；
4. 检查工具名称、描述、参数 Schema 和错误返回；
5. 为调用补充脱敏参数、结果状态、审批决定和关联 ID；
6. 验证收益后，再决定是否扩大迁移范围。

MCP 最值得关注的地方，不是它又增加了一个 Agent 框架，而是它把工具接入变成了一个可独立治理的协议边界。连接标准化只是起点；权限、信任与可观测性，才决定 Agent 能否真正进入生产环境。

## 来源与边界

- 原文：[MCP Explained: How Modern AI Agents Connect to the Real World](https://towardsdatascience.com/mcp-explained-how-modern-ai-agents-connect-to-the-real-world/)
- 作者：Maria Mouschoutzi
- 来源：Towards Data Science
- 日期：2026 年 7 月 28 日
- 边界：文中的架构、时间线和风险类型来自原文；中文组织、落地顺序与保守实施建议属于本文提炼。原文引用的生态下载量未在本文中另行独立核验。