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

本文整理自 Maria Mouschoutzi 发表于 Towards Data Science 的文章 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 的思路相似：

这并不意味着 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 能否接入工具”逐渐从定制开发变成配置问题，团队需要回答的新问题是：

原文特别强调三类风险：工具输出中的提示词注入、恶意 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 能否真正进入生产环境。

来源与边界