从 LLM 到 Agent Skill，龙虾的技术基础 · ⑥ MCP

本系列共 8 篇。总览：从 LLM 到 Agent Skill：我理解的 AI 应用进化路线

---

这篇写给谁

如果你已经把 Tool 跑起来了，但开始遇到这些问题：

• 不同客户端接同一工具要写多套适配；
• 工具清单管理混乱，元数据不统一；
• 权限、审计、鉴权每家都不一样；
• 换模型或换宿主后，改造成本巨大；

那么你需要考虑的就不再是“再加一个工具”，而是标准化连接层。

这就是 MCP（Model Context Protocol）要解决的核心。

---

1）MCP 到底是什么（先讲人话）

一句话：

MCP 是 AI 应用连接外部能力的统一协议层。

它不是某个模型，也不是某家 SDK 独占特性，而是一个“怎么连工具、怎么传上下文、怎么描述能力”的标准。

你可以把它理解为 AI 时代的“USB-C”：

• 设备可以不同（Claude、Cursor、自研 Agent）；
• 外设可以不同（数据库、搜索、文件系统、SaaS API）；
• 只要接口标准一致，连接方式就统一。

---

2）MCP 在工程上解决的不是“能不能调”，而是“能不能规模化调”

当工具只有 1~2 个，直接写函数封装就够了。
当工具达到几十个，问题会暴露：

1. 发现困难：模型不知道可用能力全貌；
2. 调用不一致：每个工具参数风格不同；
3. 治理困难：权限、日志、版本无法统一；
4. 迁移昂贵：换宿主/换客户端需要重写一堆胶水代码。

MCP 的价值在于把这些“重复工程”协议化。

---

3）MCP 架构：Host / Client / Server

官方架构可以概括为三层：

• Host：承载 LLM 的应用（例如 IDE、桌面助手、自研 Agent 平台）；
• Client：Host 内的 MCP 连接器，负责与某个 Server 通信；
• Server：暴露能力的一侧（本地或远端），提供工具、资源、提示模板。

这套分层的好处是：

• Host 专注“对话与编排”；
• Server 专注“能力与数据”；
• 中间用协议连接，降低耦合。

---

4）MCP 三大能力原语：Tools / Resources / Prompts

MCP 常见的三类能力：

Tools（可执行动作）

模型可主动调用的函数能力。
例如：查订单、建工单、发消息、执行 SQL。

Resources（只读上下文）

给模型读的结构化信息源。
例如：文件内容、数据库 schema、系统配置、API 文档。

Prompts（模板化指令）

可复用的提示模板，用来规范任务起手式，减少每次手写 Prompt 的波动。

你可以这样记：
Tool 负责“做事”，Resource 负责“供料”，Prompt 负责“方法”。

---

5）协议层细节：为什么它比“普通 HTTP 调 API”更适合 Agent

MCP 通常基于 JSON-RPC 风格消息（请求/响应/通知）组织交互。
和你手写 REST 的区别不在“能不能调用”，而在：

• 能力发现（如工具列表）是协议内一等公民；
• 变更通知（能力变化）有统一机制；
• 生命周期、能力协商、错误语义更一致；
• 更适配“模型驱动调用”这种动态场景。

换句话说，MCP 更像“面向 Agent 的控制平面”。

---

6）传输模式怎么选：stdio vs Streamable HTTP

官方常见两类传输：

A. stdio（本地子进程）

• 典型场景：本地开发、IDE 插件、单机工具链；
• 优点：部署简单、低延迟、无网络暴露；
• 风险：权限继承当前用户环境，命令执行必须谨慎审计。

B. Streamable HTTP（远程服务）

• 典型场景：生产环境、多租户、跨机器调用；
• 优点：集中治理、统一认证、易于扩展；
• 风险：需要完整网络安全体系（TLS、鉴权、限流、Origin 校验等）。

选择建议：

• 本地个人工具优先 stdio；
• 生产团队协作优先 HTTP 服务化。

---

7）MCP 安全：上线前必须补齐的 7 件事

1. 认证（Authentication）：谁在连；
2. 授权（Authorization）：能调用哪些能力；
3. 输入校验：参数合法性与注入防护；
4. 沙箱隔离：高风险工具最小权限运行；
5. 限流与超时：防止雪崩与滥用；
6. 审计日志：工具调用可追溯；
7. 漏洞管理：依赖更新、密钥轮换、应急预案。

如果是 HTTP 暴露，还要注意：

• 强制 HTTPS；
• Origin 白名单；
• 本地部署避免默认绑定 0.0.0.0。

---

8）MCP 与 Tool 的关系：不是替代，而是升级

在上一章我们讲了 Tool 的契约设计。
MCP 并不替代 Tool，而是让 Tool 进入“标准化管理”阶段：

• Tool 本体：定义业务动作；
• MCP 层：统一描述、发现、调用、治理这些动作。

所以你可以把演进理解为：

单工具封装 -> 多工具编排 -> 协议化治理（MCP）

---

9）什么时候该引入 MCP，什么时候先别上

适合尽快引入 MCP

• 多团队共用能力平台；
• 需要跨客户端复用工具；
• 对权限、审计、合规有明确要求；
• 计划构建 Agent 平台而非单点脚本。

可以暂缓

• 只有 1~2 个工具；
• 单人项目、短期实验；
• 需求变化极快，协议层尚不稳定。

实战建议：先把 3~5 个高价值工具做成 MCP Server 试点，再逐步扩展。

---

10）一个可落地的 MCP 落地路线图

阶段 1：能力梳理

• 盘点现有 Tool；
• 按读写风险分级；
• 统一命名和参数风格。

阶段 2：协议化接入

• 抽出 MCP Server；
• 先暴露核心 Tools + Resources；
• 加最小鉴权和审计。

阶段 3：平台化治理

• 接入统一网关（认证、限流、日志）；
• 建立版本策略（向后兼容优先）；
• 做回归评测（成功率、延迟、成本、错误恢复）。

阶段 4：生态化复用

• 跨团队复用同一能力目录；
• 沉淀标准 Prompt 模板；
• 让 Agent 可以稳定组合多能力工作流。

---

11）常见误区（避坑）

1. 把 MCP 当“万能性能优化”：它解决的是标准化与治理，不直接提高模型智商。
2. 只做协议，不做治理：没有权限和审计，风险反而放大。
3. 一次性全量迁移：建议从高价值工具小步推进。
4. 忽略版本兼容：接口频繁破坏会让上层 Agent 非常脆弱。

---

小结

• MCP 的核心价值是：让模型连接外部能力从“临时集成”走向“标准工程”。
• 当工具规模化后，真正难的是治理与复用，而不是“再写一个 API 适配器”。
• 可持续的路线是：先工具契约化，再 MCP 协议化，再平台治理化。

下一篇：《⑦ Agent》——从“会调用工具”到“会规划执行”的系统闭环。

---

延伸阅读

• 视频（Prompt/Agent/MCP 关系梳理）：10分钟讲清楚 Prompt, Agent, MCP 是什么
• MCP 官方架构文档：Architecture Overview
• MCP 官方 Tools 概念：Tools
• MCP 官方传输说明：Transports
• MCP 规范（最新）：Specification
• Anthropic MCP 说明页：What is MCP?
• OpenAI Agents SDK 对 MCP 的接入说明：MCP Guide

---

系列：龙虾的技术基础 ⑥/8