AI 时代的 USB-C 接口：解析 Model Context Protocol (MCP) 原理

What（本文讲什么）

MCP（Model Context Protocol）解决的不是“让模型变聪明”，而是“让外部能力的接入方式变得可复用、可治理、可审计”。它提供一套协议，把外部能力标准化为三类对象：

1. resources：只读、文件式的数据入口。
2. tools：可执行能力（可能有副作用）。
3. prompts：可版本化的提示模板（减少把 prompt 写死在 host 的倾向）。

这篇文章会把 MCP 拆成工程可落地的三件事：

1. 角色边界：host / client / server / model 各自负责什么。
2. 协议语义：发现（discover）与调用（invoke）怎么发生。
3. 治理落点：超时、重试、幂等、权限、隔离、审计、观测要落在哪里。

Problem（要解决的工程问题）

在 MCP 之前，你的外部接入通常会出现这些问题：

1. N×M 适配：每个模型/框架各一套工具封装，迁移成本极高。
2. 契约漂移：外部平台升级，工具 schema 变化，agent 直接崩。
3. 权限失控：工具越接越多，副作用通道越来越多，没有统一的 PEP（权限执行点）。
4. 可观测缺失：工具调用失败、超时、重试、幂等冲突无法聚合统计（观测）。

MCP 让“工具接入”从工程碎片化走向标准化，但它不自动解决安全与稳定性。它只是把边界变清晰，使治理成为可能。

Principle（角色边界：client 是看门人，model 不直连 server）

MCP 的关键边界是：

1. MCP Server：提供能力（tools/resources/prompts），可以是本地进程或远端服务。
2. MCP Client：协议中介，维护连接，负责发现/调用，并对外提供统一接口。
3. MCP Host：承载应用逻辑（UI、任务状态机、上下文装配、治理管线）。
4. Model：只产生意图与调用请求，不直接接触 server。

这条边界的价值是：host/client 可以成为权限与审计的强制点（权限、隔离、审计）。如果你让模型直连工具服务，你就把不可信输入直连副作用通道。

官方文档与规范入口：

1. Anthropic MCP docs: https://docs.anthropic.com/en/docs/mcp
2. MCP Base Protocol: https://modelcontextprotocol.io/specification/2025-11-25/basic

协议对象：resources/tools/prompts 为什么要分开

你必须理解三者的治理差异：

1. resources：只读，适合被 host 主动拉取并注入上下文。风险主要是“数据泄露与过量注入”（权限、降级）。
2. tools：可能有副作用，需要超时、重试上限、幂等 key 与审计（超时、重试、幂等、审计）。
3. prompts：是“服务端管理的可版本化提示”，适合把领域最佳实践与约束集中管理，但也需要审计与变更控制（审计）。

把它们混成一种“tool”，你会把读与写混在一条链上，治理会变得更难。

Usage（怎么用：把 MCP 接到你的 agent runtime）

1) 发现（discovery）：列出能力并建立本地契约

实践上，host 会做这些事：

1. 连接 server（本地 stdio 或远端传输）。
2. 拉取 tools/resources/prompts 列表。
3. 将 tool schema 注入模型上下文（但只注入接口，不注入实现）。
4. 将 resources 当成“可拉取的数据源”，按需装配到上下文里。

2) 调用（invoke）：把 tool call 放进治理管线

对 tools，你必须把调用做成一条治理管线：

1. parse：严格解析参数（schema）。
2. validate：参数白名单/路径约束/大小上限。
3. authorize：ABAC/任务绑定权限（权限）。
4. execute：设置超时（超时）。
5. retry：有限次重试 + backoff（重试、降级）。
6. idempotency：副作用必须有幂等 key + WAL（幂等、审计）。
7. observe：trace/span + 结构化字段（观测）。

如果没有这条管线，MCP 只是在“更方便地接入更多副作用”。

3) 最小生命周期图（协议层 vs 执行层）

下面的序列图强调“client 是中介”，而 host 才是治理与装配的执行者：

sequenceDiagram
  participant Model as Model
  participant Host as Host (runtime)
  participant Client as MCP Client
  participant Server as MCP Server

  Host->>Client: connect(server)
  Client->>Server: initialize / capabilities
  Host->>Client: tools/list + resources/list + prompts/list
  Client->>Server: tools/list
  Server-->>Client: tool schemas
  Client-->>Host: schemas

  Host->>Model: inject(tool schemas + rules)
  Model-->>Host: request tool call (name,args)
  Host->>Host: gate(parse/validate/auth/timeout/idempotency/audit)
  Host->>Client: tools/call
  Client->>Server: tools/call
  Server-->>Client: result
  Client-->>Host: result
  Host->>Model: observation

安全与失败模式（协议不等于安全）

MCP 引入的新风险必须写清楚：

1. prompt injection：资源内容可以诱导模型调用危险工具。
2. tool poisoning：工具描述/提示模板可能被投毒。
3. 越权与横向移动：server 一旦能访问内部系统，就可能变成通道。

安全审计论文明确提醒：MCP 让接入更容易，但也带来新的攻击面，必须在 runtime 层落地权限与审计。
参考: https://arxiv.org/abs/2504.03767

Pitfall（常见坑与防错）

1. 把 resources 当“可信事实”：必须带来源与验证状态（审计）。
2. tool 输出过大：不截断会污染上下文并导致成本爆炸（降级）。
3. 无超时/重试上限：工具慢会拖死主循环（超时、重试）。
4. 无幂等：重试会制造重复副作用（幂等）。
5. 无审计：无法追溯谁触发了什么 tool（审计、观测）。

Debug（如何排查 MCP 接入问题）

排查顺序建议：

1. 协议层：server 是否响应 initialize/tools/list/tools/call？
2. 契约层：tool schema 是否与实际参数匹配？
3. 治理层：超时/重试/权限拒绝发生在哪一环？
4. 数据层：resources 注入是否过量/过期/无来源？

工程清单（把 MCP 从“接入”变成“可上线”）

MCP 接上只是开始。可上线至少要做这些事：

1. tool 元数据:
   • tool 是否只读/是否有副作用/风险等级
   • 超时与最大重试（超时、重试）
2. 输出控制:
   • tool 输出截断（防止 10MB 输出污染上下文）（降级）
   • 错误码与失败原因标签（观测）
3. 幂等与提交:
   • 有副作用的 tool 必须生成幂等 key 并写 WAL（幂等、审计）
4. 权限与隔离:
   • server 的能力边界（网络、文件、凭证）必须最小化（权限、隔离）
   • host/client 必须作为 PEP（权限执行点）
5. 观测与审计:
   • 每次 tools/call 必须记录 trace_id/tool_name/timeout/retry/idempotency_key/resource_targets（审计、观测）
6. 安全:
   • prompt injection 防护（对 resources 做去噪、来源标注）
   • tool poisoning 防护（server 版本签名/allowlist）

这份清单的价值在于：把“协议”落到“事故防线”，否则 MCP 只是把接入速度提升，同时把事故半径扩大。

失败原因标签（建议从第一天就标准化）

建议至少做这些标签，用于聚合统计与自动化降级：

1. schema_parse_failed
2. permission_denied
3. timeout
4. retry_exhausted
5. idempotency_conflict
6. output_too_large
7. server_unavailable
8. resource_stale

没有标签，你就无法做“失败原因分布”，最终只能靠读日志猜（观测）。

一条底线：MCP server 也是“供应链”

很多人把 MCP 当成“统一接口”，但在安全上它更像“供应链”：

1. server 能访问什么网络、什么文件、什么凭证？
2. server 的版本如何发布与回滚？
3. server 的 tool 描述是否可信，是否会被投毒？

因此你需要把 server 管理纳入：

1. allowlist（只允许连接可信 server）。
2. 版本固定与签名（防止悄悄换包）。
3. 能力最小化（server 只暴露必要 tool，且默认只读）。

这不是额外负担，而是你把工具接入规模化之后必须付出的治理成本（权限、审计）。

Source（资料来源）

1. Anthropic MCP docs: https://docs.anthropic.com/en/docs/mcp
2. MCP Base Protocol spec: https://modelcontextprotocol.io/specification/2025-11-25/basic
3. MCP GitHub org: https://github.com/modelcontextprotocol
4. InfoQ 报道（背景与概念分离动机）: https://www.infoq.com/news/2024/12/anthropic-model-context-protocol/
5. MCP 安全审计论文: https://arxiv.org/abs/2504.03767