MCP协议60秒实战：逐条消息拆解一次真实会话

一段来自 YouTube 的短视频演示，用一个真实会话把 MCP（Model Context Protocol）讲清楚了。作者把上一期硬编码在 Agent 代码里的工具，搬到了一个用官方 MCP SDK 编写的服务器上。工具位置变了，Agent 的逻辑一行没改，最终答案还是同一个端口 8080。这篇文章把这 9 条 JSON 消息背后的协作机制拆开来聊。

工具搬家：从硬编码到独立服务器

上一期的 Agent 把工具直接写死在代码里，改了工具就得改 Agent。这一次，作者用官方 MCP SDK 单独搭了一个服务器，所有文件系统能力都挂在这个服务器上。

这个变化看起来只是工程上的整理，但含义不小：工具定义和 Agent 实现彻底解耦了。Agent 不需要知道工具怎么实现、跑在哪里、用什么语言写的，只要对方会说 MCP 就行。工具从"Agent 的一部分"变成了"任何人都可以接上的外部能力"。

MCP（Model Context Protocol，模型上下文协议）最初由 Anthropic 于 2024 年底开源提出，目标是给大模型与外部工具、数据源之间定义一套统一的通信标准。它采用 JSON-RPC 2.0 作为消息格式，并支持两种常见传输方式：基于标准输入输出的 stdio 传输（进程间通信，适合本地工具）和基于 HTTP 的 Streamable HTTP（适合远程服务）。协议在架构上把参与者分成三类角色——Host（宿主应用，如编辑器或 Agent 运行环境）、Client（宿主内部负责与单个服务器建立连接的客户端）和 Server（对外暴露工具、资源或提示模板的服务端）。这种分层让同一个服务器可以被不同 Host 复用，这也是文章里"工具搬家"能成立的前提。

握手：Agent 先问，服务器再答

会话一开始，Agent 并不知道对面有什么能力。它的第一个动作是提问：你有哪些工具？

服务器随后返回一份清单，把每个工具的名称、描述和输入参数逐项列出来。Agent 拿到这份清单，才知道自己现在手上多了哪些牌。

这一步是整个 MCP 协作的关键。不是 Agent 预先知道工具、去查文档、写适配代码，而是运行时动态发现。工具是新的、Agent 没见过，也不影响它接着往下干活。

MCP 的能力发现并不是一步完成的。连接建立后，Client 与 Server 首先要进行一次初始化握手（initialize / initialized），双方交换协议版本号、各自的 capabilities（比如服务器是否支持 resources、prompts、tools，客户端是否支持采样等）。只有握手完成后，Client 才能调用 tools/list 拉取工具清单，服务器也可以在这之后主动发送 notifications/tools/list_changed 通知工具列表发生了变化。此外，工具清单里每个工具都带有一个 JSON Schema 描述其输入参数，模型正是依据这份 schema 生成调用参数的。理解这一点，就能明白为什么 Agent 不需要预先知道工具长什么样——元数据在运行时由服务器提供。

执行：Agent 转发，服务器干活

真正的执行环节更有意思。当模型提出"列出文件"时，Agent 自己什么都没跑。

它只是把调用请求转发给服务器，由服务器去读目录、执行逻辑，再把结果送回来。Agent 在这里像一个中间人：接收模型的意图，把它翻译成 MCP 调用，然后把回包还给模型。真正的 I/O 和副作用都发生在服务器那一侧。

这样切分的好处很直接——权限、审计、沙箱都可以收在服务器一端统一处理，Agent 不必也不该拥有这些能力。

循环没变：同一个模型，同一个任务，同一个答案

容易被忽略的一点是：这次改动完全没有动到 Agent 的推理循环。

同一个模型、同一个任务、同一个输出——端口 8080。工具的来源换了，接入方式换了，但从模型的角度看，世界没有变化。它依然是在"提需求—等结果"的循环里工作，中间是谁在跑这段代码，它并不关心。

这也解释了 MCP 为什么容易被集成：它不是要改变模型或 Agent 的架构，而是给工具这一层定了一个统一的插槽。

幕后：9 条 JSON 消息就够了

整套会话并没有想象中复杂。作者提到，底层不过是管道上往返的 9 条 JSON 消息——工具列表的请求与响应、调用请求与响应，再加上一些流程控制。

一旦把服务器搭好，任何会说 MCP 的 Agent 都能直接接上来用。这意味着工具的复用成本从"为每个 Agent 重写一遍"变成了"搭一次，人人可用"。

从协议设计的角度看，MCP 做的事情和当年 LSP 统一编辑器与语言服务的关系很像：把 N×M 的适配矩阵压缩成 N+M。工具生态越繁荣，这个收益就越明显。

LSP（Language Server Protocol，语言服务器协议）是微软在 2015 年前后为 VS Code 提出的编辑器与语言智能服务之间的通信标准。它把过去每个编辑器都要为每种语言单独写插件的 N×M 适配问题，简化为编辑器实现一次 LSP 客户端、语言实现一次 LSP 服务端即可对接的 N+M 模式，极大降低了生态扩展成本。MCP 的设计哲学与此高度一致：把大模型应用与工具之间的适配矩阵同样压缩为 N+M。区别在于 LSP 面向的是代码编辑场景，而 MCP 面向的是模型的工具调用与上下文注入场景。

小结

这次演示的意义不在于协议本身有多复杂，而是它证明了一件事：给 Agent 换一套工具来源，不需要改模型、不需要改循环，只需要换一个会说 MCP 的服务器。60 秒的会话里，真正做决策的还是模型，真正干活的是服务器，而连接两者的，不过是 9 条 JSON 消息。