Agentic AI 架构入门（十）：MCP 深潜——4 层拓扑、生命周期与设计模式

课程：《Agentic AI Architectures with Patterns, Frameworks and MCP》笔记整理（第 464–512 页）

---

1. 为什么深潜 MCP？（「90% 问题」）

• 回顾：A2A 解决 Agent 协作、MCP 解决 Agent 工具集成、ACP 两者都管——企业最紧迫的问题是集成
• MCP 是"你正在面对的问题"的标准——防止供应商锁定、构建面向未来的 Agentic 架构
• MCP = “Agent 的 OpenAPI/Swagger”，是实现架构师首要目标——解耦（Decoupling）——的关键

---

2. MCP 架构：4 层拓扑（架构师最核心的概念）

从 1 万英尺看，MCP 系统不是复杂网络，而是干净、线性的 4 层管道：

层	组件	角色	说明
1	MCP Client（Host）	发起连接的 AI 应用	Claude Desktop（消费端）、Cursor IDE（开发者端）、你的自定义 Agent（企业端）。职责：维持连接（1:1 或 1:N）、提供 LLM（大脑）、决定何时调工具
2	The Protocol（Bridge 桥）	通信标准规则	基于 JSON-RPC 2.0；传输通道（Transport）：Stdio（进程管道，本地应用）/ SSE（HTTP 流，远程服务器）；定义如何发送 Prompts、Resources、Tools
3	MCP Server（Adapter 适配器）	你构建的轻量翻译层	「万能适配器」：包装特定数据源，把"混乱的现实"翻译成"标准 MCP"。关键：不含 LLM，是确定性的（代码/SQL）。例：Google Drive MCP Server 知道怎么用 Drive API
4	Data Source（Reality 现实）	真实数据系统	PostgreSQL、Slack API、本地文件系统。Server 持有数据源的 API Key，对 Client 保密

数据流：Client（问）→ Protocol（说标准语）→ Server（翻译）→ Data Source（取数）

小结：Client 提供大脑并发起请求；Protocol 提供标准语言；Server 提供"手"并翻译请求；Data Source 提供"现实"。架构上是 1 Host → 多 Client → 多 Server → 多数据源 的扇出结构。

---

3. MCP 规范四大核心概念

3.1 两大支柱

• Pillar 1：DISCOVERY（发现）——“这个工具能做什么？” → 机制：manifest.json，位置：标准「知名路径」
• Pillar 2：EXECUTION（执行）——“怎么运行这个工具？” → 机制：标准 call 端点

3.2 概念 1：/.mcp/ 知名路径

GET https://api.my-eshop.com/.mcp/manifest.json

• 单一、标准、可预测的位置——Agent 找工具清单的「前门」，消除所有猜测
• Agent 不需要被告知 manifest 在哪，它知道去哪找
• 类比：Agent 界的 robots.txt / ads.txt——已知的标准程序化发现入口

3.3 概念 2：manifest.json（「给 LLM 的用户手册」）

顶层字段示例：

{
  "name": "EshopProductAPI",
  "description": "API for searching E-shop product details, stock, and pricing.",
  "documentation_url": "https://docs.my-eshop.com/api",
  "authentication": {"type": "bearer", "instructions": "Get your API key from your E-shop user profile..."},
  "functions": [...]
}

functions 数组（单个工具定义）示例：

{
  "name": "get_product_details",
  "description": "Gets all details for a single product (price, stock, specs) given its unique product ID.",
  "parameters": {"type": "object", "properties": {"product_id": {"type": "string", "description": "The unique ID (e.g., 'abc-123') of the product."}}, "required": ["product_id"]},
  "endpoint": "/mcp/call/get_product_details"
}

3.4 概念 3：call 端点格式

• manifest 定义了"怎么做"，call 端点是"做"
• 核心原则：JSON 进，JSON 出——简单、标准、无状态

3.5 概念 4：安全与认证

• 问题：manifest 和 call 端点是公开的，怎么保护？
• MCP 之道：复用成熟 web 标准——标准 Authorization 请求头（Bearer token / OAuth）
• 验证流程：Agent 发 API 请求（带 Authorization: Bearer API_KEY_OR_OAUTH_TOKEN 头）→ MCP Server 验证令牌 → 有效则处理返回结果 / 无效则拒绝

3.6 小结：规范四件套

1. /.mcp/ 路径：可发现的前门
2. manifest.json：LLM 的用户手册（定义做什么和怎么做）
3. call 端点：执行机制（JSON in, JSON out）
4. 安全：复用标准 Authorization 头

---

4. MCP 生命周期：4 步握手

步骤	名称	动作
1	「敲门」（发现）	Agent 检查知名路径
2	「菜单」（能力协商）	Agent 读取并摄取 Manifest
3	「点单」（工具选择与执行）	Agent 选择工具并发送 JSON 负载（Agent 根据你的 schema 自动写 JSON body）
4	「上菜」（响应）	Server 执行逻辑并返回原始 JSON

要点：步骤 1&2 中，Agent 下载 manifest.json 并注入系统提示（上下文）——“LLM '知道’你的 API 存在；如果用户问产品，我可以用这个工具”；步骤 3 的关键是 Agent 根据你的 schema 自动写 JSON body。

---

5. MCP vs OpenAPI（为什么不用现成的 OpenAPI？）

5.1 两个问题

1. 噪音与 token 成本：你的 E-Shop OpenAPI 规范可能有 5,000 行——全塞进 LLM 上下文太贵
2. 「开发者语言」 vs 「LLM 语言」：OpenAPI 是写给工程师的，不是给 LLM 的；MCP 是语义规范，不只是技术规范

5.2 解决方案：MCP = 「Agent 友好适配器」

• 不是用 MCP 替代 OpenAPI——MCP 是「适配器/门面（Facade）」模式
• OpenAPI = 全面的技术蓝图（为人设计）；MCP = 精选的语义「菜单」（为 LLM 设计）
• 架构师的工作：用 MCP 在复杂内部系统前面建一个安全、高效、智能的「门面」

---

6. MCP 设计模式与案例

6.1 模式 1：Adapter（适配器）模式（遗留系统）

• 问题：你有一个**单一、有价值但不「懂 Agent」**的遗留系统（如 SOAP/REST XML）
• 任务：把调用「翻译」给这一个特定系统
• 类比：新「插头」（Agent）→ **国际电源适配器（MCP Server）**→ 旧「墙插座」（Legacy 系统）

6.2 模式 2：Gateway（网关）模式（微服务）

• 问题：不是 1 个遗留系统，而是 50 个现代微服务——不想暴露 50 个不同的 MCP server
• 收益：所有 Agentic 流量的单一、安全、可管理的入口（内含 manifest.json 聚合 + ROUTER 路由）

6.3 案例：用 MCP 架构 E-Shop

• 系统：微服务架构（Inventory 库存、Orders 订单、User 用户服务）
• 目标：把 get_product_details（来自 Inventory）和 get_order_status（来自 Orders）暴露给合作伙伴的 Support Agent
• ❌ 错误做法：给伙伴 Agent 两份 API 规范，指望它都集成
• ✅ 正确做法（网关模式）：
  1. 建一个 MCP 网关 server：https://api.my-eshop.com
  2. 它的 manifest.json 同时定义 get_product_details 和 get_order_status
  3. Agent 调 get_product_details → 网关路由到 Inventory
  4. Agent 调 get_order_status → 网关路由到 Orders Service

• 结果：伙伴 Agent 只有一个简单工具；我们保持完全内部控制和解耦——单一、安全、可管理的入口

6.4 小结：从理论到蓝图

• Adapter 模式：有一个遗留系统要暴露 → "翻译"调用给一个特定系统
• Gateway 模式：有很多微服务 → "路由"调用到许多不同系统

---

7. 小结

本段精华：

1. MCP = 解耦标准：企业最紧迫的集成问题，防止供应商锁定
2. 4 层拓扑（架构师最核心概念）：Client（大脑，发起）/ Protocol（标准语言 JSON-RPC，Stdio/SSE）/ Server（适配器，翻译，无 LLM 确定性）/ Data Source（现实，API Key 藏在 Server 侧）——线性管道
3. 规范两大支柱：发现（manifest.json + /.mcp/ 知名路径）+ 执行（call 端点 JSON in/out）
4. 四大核心概念：/.mcp/ 路径（Agent 界的 robots.txt 前门）/ manifest.json（LLM 用户手册）/ call 端点（执行）/ 安全（复用标准 Authorization 头）
5. 生命周期 4 步握手：敲门（发现）→ 菜单（读 manifest 注入上下文）→ 点单（Agent 按 schema 自动写 JSON body）→ 上菜（返回 JSON 进循环）
6. MCP vs OpenAPI：OpenAPI = 5,000 行技术蓝图（给人），MCP = 精选语义菜单（给 LLM）——不替代，是门面（Facade）
7. 两大模式：Adapter（1 个遗留系统，翻译）/ Gateway（50 个微服务，路由）
8. E-Shop 案例：一个 MCP 网关同时暴露库存+订单工具，伙伴 Agent 只需一个工具，内部完全解耦
9. 下一段预告：Context Engineering（上下文工程）——Prompt 工程 → Context 工程的范式转移、5 种上下文类型、上下文窗口管理策略