B3 · MCP 通解——把后端工具/数据用统一协议喂给大模型

系列第 7 篇 · B 线（AI 工程化）第 3 篇
定位：架构师选型视角 · 深度长文
承接：B1《架构优先于模型》（架构优先）、B2《RAG 实战》（检索即能力）
衔接：B4《Agentic 与多智能体 Control Plane》（MCP 服务 = 新型微服务）

0. 一句话立论

MCP（Model Context Protocol）不是又一个 AI 框架，它是一套"后端能力 ↔ 大模型"之间的 USB-C 接口标准。它的价值不在于让模型更聪明，而在于让你已经写好的业务服务，能被任意遵循该协议的 Agent/Client 零改造成本地复用——N 个后端能力 × M 个 AI 应用，从 N×M 的胶水地狱，收敛为 N+M 的协议对接。

对架构师而言，MCP 真正要回答的不是"怎么接一个工具"，而是：你的后端能力，要不要、何时、以什么形态，暴露成可被智能体调用的标准服务。

1. 为什么架构师必须懂 MCP：那个被忽略的集成爆炸

回到 B1 的八层架构，其中有一层叫Tool + MCP（工具与上下文接入）。这一层是 AI 应用"能动手做事"的唯一出口——查库、调 API、改订单、跑脚本，全靠它。

在没有统一协议的时代，接一个工具长这样：

你的后端有一个「查订单」API ├─ 给 Claude 用 → 写一套 Anthropic function schema + 执行适配 ├─ 给 Cursor 用 → 写一套 VS Code 插件 + 协议适配 ├─ 给内部 Agent 用 → 写一套 LangChain tool + 重试/鉴权 └─ 给 Java 智能体用 → 写一套 Spring AI @Tool + 传输

N 个能力 × M 个客户端 =N×M 套重复胶水代码。每换一个模型供应商、每加一个工具，集成成本线性叠加。这正是 2023–2024 年 AI 应用落地最痛的"集成税"。

MCP 的解法很朴素：在"模型宿主"和"能力提供方"之间插一层标准协议。能力方把工具注册成 MCP Server（一次），任意 MCP Client（Claude/Cursor/VS Code/你的 Java 智能体）通过标准握手自动发现、调用它（一次）。重复劳动从 N×M 坍缩为 N+M。

一句话给老板讲清楚：MCP 让你花钱写一次的业务能力，能被公司里所有 AI 应用免适配地调用。

2. MCP vs Function Calling：不是替代，是分层

这是 2026 年被问得最多、也最容易讲错的一个问题。结论先给：

Function Calling 是"模型如何调用一个函数"的应用层能力；MCP 是"模型如何发现并标准化连接外部能力"的协议层标准。两者互补，不互斥。

最常见的误读：“MCP 要取代 Function Calling。”
正解：MCP 底层仍然依赖模型的功能调用能力。它解决的是"工具怎么被发现、怎么被标准化交付、怎么跨客户端复用"——即 Function Calling 之上的传输与发现层。典型协作链路是：

MCP Host（Claude/你的智能体） └─ 通过 MCP 协议发现 Server 暴露的 tools └─ 把 tool schema 翻译成模型 API 期望的 function schema └─ 模型产出 function call └─ Host 调对应的 MCP tool，拿回结果，继续生成

所以：MCP 是服务端集成边界，Function Calling 是模型交互边界。一个适配器负责翻译两边的 schema、错误、调用身份——这正是 B1 强调的"模型无关抽象层"的落地形态之一。

选型口诀：

• 单应用、三五个内部函数、最简实现 → 直接用 Function Calling。
• 能力要跨客户端/跨厂商复用、要动态发现、要资源与提示模板一起暴露 → 上 MCP。

3. 协议三原语：Tools / Resources / Prompts

MCP 之所以比"只暴露函数"厚一层，是因为它定义了三类原语，正好对应 AI 与外界交互的三种需求。记住一句口诀：Tools 让 AI 动手做，Resources 给 AI 看数据，Prompts 给 AI 定调子。

3.1 Tools（工具）——“动手做”

有副作用的动作。tools/list返回工具清单（每个带 JSON Schema 入参），tools/call按名调用。对应 Function Calling 的能力。

• 例：query_order、create_ticket、run_migration
• 关键：每个 tool 的description不是给人看的，是给模型读、用来决策是否调用的——这既是宝也是雷（见 §6 工具投毒）。

3.2 Resources（资源）——“看数据”

只读数据源，按 URI 读取（文件、数据库快照、API 响应、文档）。resources/list+resources/read。

• 例：file:///demo.txt、db://orders/schema、config://feature-flags
• 价值：把"上下文"标准化注入，而不必每家公司自己发明一套 RAG/注入机制。

3.3 Prompts（提示模板）——“定调子”

参数化、可复用的提示词模板。prompts/list+prompts/get。

• 例：代码审查模板、需求拆解模板、客服话术模板
• 价值：把"领域最佳实践"沉淀成 Server 提供的标准工作流起点。

架构师视角：把 Tools/Resources/Prompts 拆开，等于把"动作、数据、方法论"三种资产分别产品化。一个 Server 就能覆盖一个业务域的大部分 AI 增强需求。

4. 协议机制：JSON-RPC 2.0 + 小方法集

MCP 的底座是JSON-RPC 2.0 over transport，上面叠了一组刻意做小的方法，只管"线缆格式"，不管模型怎么选工具、Agent 循环怎么跑：

设计哲学：协议刻意瘦。它不规定工具该做什么、模型该怎么选、Agent 循环怎么写，只把"工具运行时 ↔ Agent 宿主"的线格式标准化。这让它能被任意模型供应商和客户端复用，也是它 18 个月内从"有趣 spec"变成"运营标准"的原因。

5. 传输层选型：stdio / Streamable HTTP / SSE（已废弃）

这是 2026 年部署 MCP 最容易被过时教程坑的一步。2024 年的教程今天多半已经失效——传输层和安全模型在 2025 年的协议更新里都变了。

三个关键事实：

1. SSE 已废弃。原始HTTP+SSE传输在 2024-11-05 之后被弃用，2025 年协议更新中被Streamable HTTP取代（单端点/mcp，POST 发请求，长任务才用 SSE 流式）。如果你的 Server 配置里还写着transport: sse，你跑的是已被淘汰的协议。
2. Streamable HTTP 为什么赢：标准 HTTP POST/GET，CDN、负载均衡器、边缘运行时都能直接处理，无需长连接、无需特殊代理。社区实测：stdio 在 20 并发下 22 个请求里失败 20 个；SSE 稍好但仍受连接池约束；Streamable HTTP 在负载均衡后并发表现最好。
3. Streamable HTTP 安全要求（协议白纸黑字）：
   • 校验Origin头防 DNS rebinding，非法即返回HTTP 403；
   • 本地运行只绑127.0.0.1，绝不绑0.0.0.0；
   • 所有连接必须认证。否则攻击者可用 DNS rebinding 从远程网页调你的本地 Server。

部署建议：本地开发用 stdio，生产多 Agent 用 Streamable HTTP；若客户端类型杂（CLI + IDE + 远程），用一个网关把传输归一化。

6. 安全：三个 2026 年真实教训，每一条都值钱

这是全篇最该让架构师警醒的一节。MCP 的安全故事，是用真实事故写出来的。

教训一：公网裸奔——119/119 全部无凭证

2026 年 1 月，安全团队 Knostic 扫描公网发现1862 个 MCP Server 在运行；随机手动测了119 个，119 个全部允许无凭证访问。不是服务器坏了，而是它们"完全按旧教程写的"——那些教程写于认证还没进 MCP spec 的年代（协议 2024-11 发布时根本没有强制认证，OAuth 直到 2025-03 才加）。

红线：任何暴露在 HTTP 上的 MCP Server，认证不是可选项。OAuth 2.1 + Protected Resource Metadata + Resource Indicators（RFC 8707，token 绑定到特定资源 URI，防 token relay 跨端复用）是 2026 基线。

教训二：工具投毒（Tool Poisoning）——最被忽视的攻击面

比缺认证更隐蔽：攻击者在工具的description / schema（模型读取的元数据，而非输出）里嵌入恶意指令。模型按"指令遵循"去执行，而非按工具本意。AAAI 2026 的MCPTox 基准测了 45 个在线 Server、353 个真实工具，跨现代 LLM 的攻击成功率>60%——且模型越强越易中招，因为这攻击利用的是"指令遵循能力"而非模型缺陷。

架构师动作：第三方 Server 的元数据当作不可信数据处理。接入前审查 tool description；命名空间隔离（避免两个 Server 暴露同名工具导致调错）；绝不让模型的 tool call 直接越过 Host 的权限/审批/业务规则校验。

教训三：schema 合法 ≠ 已授权

一个结构合法的参数，依然可能要求一笔不该退的款、读错租户的记录、删错路径的文件。协议层能力协商只说明"端点支持什么"，不说明"当前用户被允许做什么"。

架构师动作：身份与资源策略独立于协议单独评估。认证远程端点、按当前用户/资源授权、最小凭证、超时约束、对重大副作用要求显式审批；调用后读回真实状态确认成功，而非只看协议返回正常。

MCP 安全清单（架构师版）

• 远程 Server 强制 OAuth 2.1 + DCR + PKCE，token 用 Resource Indicators 绑定资源
• 工具数 < 50，且每个 tool 的description经过可信审查（防投毒）
• 第三方 Server：命名空间隔离 + 元数据当不可信 + 接前威胁评估
• 所有 tool 调用过 Host 的权限/审批/业务规则校验，不从 schema 直接授权
• Streamable HTTP 校验 Origin、绑 localhost（本地）、强制认证
• 重大副作用（写/删/退款）要求人工确认，禁止静默执行

7. 后端工程师落地：Spring AI MCP

作为 Java 后端，好消息是Spring AI 把 MCP 接得很彻底。以下是 2026 年可跑的生产形态。

7.1 起一个 MCP Server（暴露你的业务工具）

依赖（Web 版，Streamable HTTP 生产推荐）：

<dependency><groupId>org.springframework.ai</groupId><artifactId>spring-ai-starter-mcp-server-webmvc</artifactId></dependency>

配置：

spring:ai:mcp:server:name:order-mcpversion:1.0.0

用注解把现有 Service 方法暴露成工具（Spring AI 1.1+ 起@McpTool/@McpToolParam稳定，组件扫描自动注册，免手写 bean）：

@ServicepublicclassOrderService{@McpTool(description="按订单号查询订单详情与异常状态")publicStringgetOrder(@McpToolParam(description="订单号",required=true)StringorderId){// 调你的真实业务逻辑returnorderRepository.findWithExceptions(orderId).toJson();}}

老项目（Spring AI 1.0.x）用@Tool+MethodToolCallbackProvider同样可行。启动后端点就在http://localhost:8080/mcp，任意 MCP Client（含官方 Inspectornpx @modelcontextprotocol/inspector）可连上列出工具。

7.2 起一个 MCP Client（你的 Java 智能体消费工具）

依赖：

<dependency><groupId>org.springframework.ai</groupId><artifactId>spring-ai-starter-mcp-client</artifactId></dependency>

连本地 Streamable HTTP Server，并把发现的工具直接注入 ChatClient：

spring:ai:mcp:client:streamable-http:connections:order:url:http://localhost:8080

@RestControllerpublicclassChatController{privatefinalChatClientchatClient;privatefinalToolCallbackProvidermcpTools;// 自动聚合所有已连 Server 的工具publicChatController(ChatClient.Builderbuilder,ToolCallbackProvidermcpTools){this.chatClient=builder.build();this.mcpTools=mcpTools;}@GetMapping("/ask")publicStringask(@RequestParamStringquestion){returnchatClient.prompt(question).toolCallbacks(mcpTools)// 所有 MCP 工具自动可用.call().content();}}

还可同时连多个 Server（一个 Streamable HTTP + 一个 stdio），Spring AI 各自独立生命周期、自动聚合为统一工具注册表——这就是 B1 说的"工具标准化"在 Java 栈的落地。

7.3 生产形态：薄适配层 vs 独立网关

从架构视角，引入 MCP 有两种模式（codecentric 总结）：

• 薄适配层：在现有业务 Service 上包一层，额外暴露 MCP 端点（改动小、快）；
• 独立 Adapter/Gateway：在 AI 客户端与后端之间加一个专门网关，归一化传输、做鉴权/审批/限流（解耦更彻底，治理更清晰，推荐生产）。

8. 在 2026 协议栈里的位置：MCP 不孤战

别把 MCP 当孤勇者。2026 年一个生产级 Agent 系统同时用一整套协议，各占一层、互不替代：

关键判断：MCP 在"工具/上下文"层主导；它不取代 A2A/ACP（那是 Agent 互调层）。多智能体系统里，MCP 负责"Agent 调后端工具"，A2A 负责"Agent 调 Agent"——这正是 B4 要展开的 Control Plane 拼图。

9. 架构师决策框架：何时自建 / 何时用现成 / 何时只用 Function Calling

把前面所有信号压缩成一张决策表：

工具数量红线：一个 Server 暴露< 50 个描述清晰的工具。清单越长，占模型上下文越多——150 工具清单可吃掉30000+ token才开聊。用 tool annotations（readOnlyHint/destructiveHint/idempotentHint/openWorldHint）帮模型安全规划多步流程、对破坏性调用要求确认。

10. 生产踩坑清单（下发版）

1. 别信 2024 年的教程：传输用 Streamable HTTP，认证用 OAuth 2.1，SSE 已废弃。
2. 远程必认证：无凭证 MCP Server 在公网实测 119/119 裸奔，这是事故不是理论。
3. 工具数 < 50：每个工具进上下文都烧 token，清单膨胀反伤效果。
4. description 当产品文档写、当不可信数据审：模型靠它决策，攻击者也靠它投毒。
5. 权限/审批在 Host 层做：schema 合法 ≠ 业务已授权，调用后读回真实状态。
6. 传输按客户端选型：CLI→stdio，IDE→SSE/HTTP，生产→Streamable HTTP + 网关。
7. Origin/localhost/认证三件套：Streamable HTTP 防 DNS rebinding。
8. 可观测埋点：用 OTel GenAI 语义约定记录 discovery/server/tool/参数（脱敏）/策略决策/状态变更/停止原因——B6 细讲。
9. 版本与回退：协议版本协商MCP-Protocol-Version，旧 SSE 端点过渡期可双跑，客户端升级后弃用。
10. B2 回扣：你的 RAG 检索链路，本就可以包成一个 MCP tool 暴露给任意 Agent——检索即能力，能力即工具。

11. 收尾与系列衔接

MCP 把 B2 的"检索"和 B1 的"工具标准化"拧成了一个可落地的协议：你后端写好的每一个能力，都能以 USB-C 般的统一形态，被公司里任意 AI 应用免适配调用。它不让你模型更聪明，但让你的工程资产产生复利。

下一站B4《Agentic 与多智能体 Control Plane》会把这个故事推到终点：当一堆 MCP Server 被智能体动态编排、彼此委托，真正的架构问题就从"怎么接一个工具"变成"怎么治理一群会自己决策的服务"——多智能体 = 新型微服务，Control Plane 是 2026 最被低估的一层。

回扣 B1：架构优先于模型。MCP 正是"架构"这一层的具体产物——它把你围绕模型建的护城河，标准化成了可复用、可治理、可跨模型替换的协议资产。

下一篇预告：B4 · Agentic 与多智能体 Control Plane——当工具变成服务、服务开始自己协作，架构师该管的是"编排面"而非"模型面"。