第9章 MCP 协议与通信算法

Tue, 09 Jun 2026 00:00:00 +0800

“任何足够先进的抽象，都不可与协议区分。”

一个智能 Agent 的能力上限，不在于它的模型有多强大，而在于它能与多少外部系统有效协作。Claude Code 通过 MCP（Model Context Protocol）协议，将数据库、API、文件系统、IDE、浏览器乃至 SaaS 服务，统一纳入 Agent 的工具可达边界。本章将深入 MCP 协议的设计思想，逐层剖析连接建立、能力发现、传输选择、认证流程、交互式授权以及资源截断等核心算法。

9.1 问题引入：Agent 通信的统一协议挑战

现代 AI Agent 面临一个根本性的通信难题：它需要与形态各异的外部服务交互——本地命令行工具通过 stdin/stdout 对话，远程 API 通过 HTTP 请求访问，IDE 通过 WebSocket 推送事件，SaaS 服务需要 OAuth 认证后才能调用。如果为每种服务编写专用的通信逻辑，系统复杂度将随服务数量呈组合爆炸式增长。

MCP 协议正是为解决此问题而设计的。它定义了一套标准化的客户端-服务端交互规范，使 Agent 能够以统一的方式发现、连接、调用任意外部服务。从 Claude Code 的源码中，我们可以提炼出 MCP 协议的七个核心算法问题：

连接建立：如何在多种传输层之上建立标准化连接？
能力协商：客户端与服务端如何互相声明和发现功能？
传输选择：如何为不同场景选择最优的传输层？
生命周期管理：如何处理连接的缓存、超时、断开与重连？
OAuth 认证：如何安全地完成浏览器重定向认证流程？
交互式授权（Elicitation）：服务端需要用户输入时如何发起交互？
资源截断：大型工具输出如何智能截断以适应上下文窗口？

9.2 传输层选择算法

9.2.1 多传输层架构

Claude Code 支持的传输类型在 types.ts 中通过 Zod Schema 严格定义：

export const TransportSchema = z.enum([
 'stdio', // 本地子进程通信
 'sse', // Server-Sent Events（旧版远程）
 'sse-ide', // IDE 专用 SSE
 'http', // Streamable HTTP（新版远程）
 'ws', // WebSocket
 'sdk', // 进程内 SDK 传输
])

每种传输类型对应不同的配置 Schema。例如 stdio 需要 command 和 args，而 http 和 sse 需要 url、可选的 headers、headersHelper 和 oauth 配置。这种设计体现了策略模式的典型应用——传输层的选择与连接的建立逻辑分离。

协议通信 on Last Stand

第9章 MCP 协议与通信算法

9.1 问题引入：Agent 通信的统一协议挑战

9.2 传输层选择算法

9.2.1 多传输层架构