企业官网建设流程全解析

MCP：给 Agent装一个 USB-C 接口

大家好，我是搬砖工呀。

Skill是功能描述。但是Agent和各个系统交互，真干活还是需要MCP，MCP就像我们电脑的USB接口一样，可以接网线，可以接耳机，可以接摄像头，可以键盘鼠标。很符合Universal Serial Bus的定义。

从「每个工具写一遍适配」到「一套协议打通」——以及它和 Skill 到底怎么分工。

目录

1. MCP前时代：N × M难题
2. MCP 是怎么把这个乘法变成加法的
3. MCP：流淌着LSP 的血脉
4. MCP 和 Skill 怎么配合
5. 完整走一遍
6. 结语

一、MCP前时代：N × M难题

以一个故事开始。（不是股市，看清楚了亲们，股市咱就不提了好吧！）

假设你有一个 AI 编程助手。你希望它能做四件事：读你本地的代码、查公司的订单库、在 GitHub 上提 PR、往群里发条通知。

在 2024 年之前，这四件事要写四遍，而且每一遍的写法都不一样。读文件写一套路径处理和编码判断；连数据库写一套连接池、SQL 参数化、权限控制；调 GitHub 要处理 token 存在哪、分页怎么翻、被限流了怎么退避；发消息还得看是钉钉、飞书还是 Slack。

真正要命的不是「写」，而是那个被乘起来的数：

你有 3 个客户端（IDE 插件、聊天窗口、命令行工具），4 个数据源，那就是12 份适配代码。再上线一个客户端，变成 16 份。而且这 12 份代码互相不知道对方存在——你为 GitHub 写的那个适配器，只在你自己的插件里能用，换个产品就得重写一遍。

这就是软件工程里最古老的那个难题：N 个消费者 × M 个提供者。

计算机史上，这个形状被解决过很多次，用的都是同一招：在中间插一层标准。

USB 之前，鼠标走 PS/2、打印机走并口、调制解调器走串口，电脑背面一堆形状各异的洞。USB 之后，鼠标、键盘、U 盘、打印机插同一个口，电脑不需要认识设备，只要认识 USB。ODBC 之于数据库、POSIX 之于操作系统、LSP 之于编辑器，都是同一个套路。

MCP 同样是这一招，用在「AI 应用」和「外部工具与数据」之间。归纳->抽象->统一。

二、MCP 如何化繁为简

MCP 把「连接」这件事从应用里抽出来，做成独立的一层。

它定的是一套协议——不是库，不是框架，不是某家公司的 SDK。协议规定的是「怎么说话」：想提供能力的一方怎么描述自己有什么，想使用能力的一方怎么问、怎么调、怎么接结果。两边都按这个说话，就能接上，不需要事先认识。

三个角色，各管一段

MCP 里有三个词，第一次看容易混：Host、Client、Server。

Host是宿主应用——就是你正在用的那个东西：IDE 里的助手、聊天客户端、跑在服务器上的 Agent 运行时。它握着模型、握着权限、决定一次调用到底要不要真的执行。

Client是 Host 内部的一个连接器。关键点：每个 Server 配一个 Client。这意味着「一个 Host 同时连十个 Server」是协议原生支持的，而不是打补丁打出来的。

Server是真正干活的一方。它可以是本机上的一个子进程，也可以是远端的一个 HTTP 服务。

把 Host 和 Client 分开，是为了让权限有个明确的落脚点。Client 自己没有权限，它只是 Host 的一部分；一个 Server 想干什么，最终都得经过 Host 的同意。

3.1 三种角色，一定分得很清楚

Server 能对外提供三样东西。这个区分是 MCP 设计里最见功力的地方——很多早期的工具调用方案把它们混成一锅，结果就是一锅粥。

为什么要分？因为信任级别不一样。

Tool 是模型自己决定要调的，可能把数据删了、把钱转了，所以规范里明确要求：调用前应当有人能看见、能拒绝。Resource 是宿主决定挂进上下文的，只读，风险低，不需要每次都问。Prompt 是用户主动选的，等于说「我要按这个套路来」，语义上最安全。

三者混在一起的后果很具体：模型没法判断「这件事我该不该自己动手」，于是要么过于保守——查个文件也要问你三遍；要么过于激进——顺手把你生产库的 schema 改了。

3.2 一次调用完整过程

整条链路上跑的都是JSON-RPC 2.0，没有任何私有格式。这一点看着朴素，实际上是它能被各种语言、各种框架快速实现的前提——不用写解析器，现成的库一堆。

3.3 两种传输方式

stdio：Server 是本地子进程，通过标准输入输出通信。适合本地文件、本地数据库、本地命令行工具。零网络、零配置、天然隔离。

Streamable HTTP：Server 是远端服务，一个 HTTP 端点，可以用 SSE 流式返回。适合 SaaS、企业内部系统、需要统一鉴权的场景。

顺带一提，最早那版用的是「HTTP + SSE 双端点」，2025 年 3 月被 Streamable HTTP 取代了——因为双端点在带状态代理后面非常难部署，运维会想打人。

这里再提一嘴，我们编码可能更多的需要和本地的工具打交道。但是很多时候，想把程序写好，免不了需要借助网络的。一定要主意网络安全。

三、MCP:流淌着LSP 的血脉

MCP 不是凭空冒出来的，它有一个非常明确的源头：LSP（Language Server Protocol）。

LSP 解决的是形状完全一样的问题。M 种编辑器 × N 种编程语言，过去要给每种组合写一份语法高亮、跳转定义、查找引用。微软 2016 年提出 LSP，把「编辑器」和「语言分析」拆开，于是 VS Code、Vim、Emacs、Sublime 都能用同一批 language server。

MCP 的两位作者 David Soria Parra 和 Justin Spahr-Summers 都在这套东西边上工作过。他们做的是同一件事，只是把「编辑器 ↔ 语言」换成了「AI 应用 ↔ 工具与数据」。

图 5 从一家公司的开源项目，到多方共管的基础设施，用了不到两年。

以下节点：

2024 年 11 月 25 日——Anthropic 公开发布并开源 MCP。第一版规范，JSON-RPC 2.0，三种原语，两种传输。

2025 年 3 月 26 日——Streamable HTTP 取代双端点方案，同时引入 OAuth 2.1 授权框架。这一版是它「能上生产」的分水岭：远程 Server 终于有了像样的鉴权故事。

2025 年 11 月 25 日（一周年）——加入异步任务（Tasks）、Server 身份、以及官方扩展机制。扩展机制这一条后来变得非常重要，下一节会讲。

2025 年 12 月 9 日——Anthropic 把 MCP 捐给了Agentic AI Foundation（AAIF），一个挂在 Linux 基金会下面的定向基金。同期创始项目还有 Block 的 goose 和 OpenAI 的AGENTS.md。成立时不到 40 家成员，到 2026 年 8 月已经超过 250 家。

2026 年 7 月 28 日——一次结构性改动：把协议改成无状态。去掉了initialize握手和Mcp-Session-Id，每个请求自带版本和能力信息，Server 用server/discover自报家门。好处很实在：任何一个 Server 实例都能处理任何请求，可以直接躲在普通负载均衡后面，不用粘性会话。

2026 年 8 月——Google 把 A2A 也捐给了 AAIF。MCP 管「Agent 连工具」（纵向），A2A 管「Agent 连 Agent」（横向）。两个正交的层，从此一个屋檐下。

截至 2026 年，公开的 MCP Server 已经超过一万个，Python 和 TypeScript 两套 SDK 月下载量合计 9700 万次，ChatGPT、Cursor、Gemini、Microsoft Copilot、VS Code 都原生支持，AWS、Cloudflare、Google Cloud、Azure 都提供了托管部署。

微软真的设计了很多先进的概念呀。但是发扬光大的往往不是他，又想起当年的COM了，他现在又陷入没有自己的顶尖模型上了。

四、MCP 和 Skill 怎么配合

上文我们讲到Skill。我们现在深入学习下Skill和MCP是如何配合的。

MCP 管「能碰到什么」，Skill 管「该怎么做」。
一个是连接层，一个是知识层。它们不在一个维度上，所以不冲突。

4.1 MCP和Skill一个不能少

假设你要 Agent 帮你「把本周合并的 PR 整理成一份发布说明」。

MCP 能给你三个工具：github.list_prs拿 PR 列表、jira.get_issue查需求背景、fs.write_file把结果写下来。

但这三个工具摆在那儿，Agent 并不知道：应该按state=merged&since=本周一去查；PR 标题太随意，得按模块重新归类；团队规范里「破坏性变更」必须单独一节；文件名必须是docs/release/v1.8.md；写文件之前要先问人。

这些都不是「能力」，是「知识」。你没法用一个 API 表达「按我们的规范写」，但你可以写一份文档。Skill 就是那份文档。

一句话判据：如果这件事「想想就能说清楚」，写成 Skill；如果这件事「必须连到某个系统才做得了」，写成 MCP。

4.2 Skill 的关键设计：渐进式披露

如果每个 Skill 一上来就把全文塞进上下文，装二十个上下文就爆了。所以 Agent Skills 用三级加载：

L1常驻的只有每个 Skill 的name和description，大约 100 tokens 一个。装 50 个，一开始也就五千出头。

L2当用户的任务和某个 description 对上了，才把SKILL.md正文读进来，一般 2–5k tokens。

L3正文里提到的references/、scripts/，只有真的走到那一步才读、才执行。

这里有个容易被忽略的细节：description写得好不好，直接决定这个 Skill 会不会被触发。它同时是文档和路由条件。写「这是一个处理 Excel 的技能」基本没用，得写「当用户上传 .xlsx 并需要清洗、透视或生成图表时使用」——说清楚什么时候用，而不是这是什么。

4.3两者怎么串起来

Agent 的循环其实就一句话：

读指令（来自 Skill） → 选工具（来自 MCP） → 看结果 → 再决策 → 循环 ↑ 知识层 ↑ 能力层

Skill 说「第一步拿 PR 列表」，Agent 就去 MCP 那边找能拿 PR 列表的工具；Skill 说「第三步写文件前要确认」，Agent 就在调fs.write_file之前停下来问人。

分工的判据可以整理成一张表：

4.4官方方案

2026 年 4 月提出、9 月定稿的SEP-2640（Skills Extension），做了一件很聪明的事：它没有发明新原语，而是用现成的 Resources 把 Skill 装了进去。

机制很简单：Server 声明支持io.modelcontextprotocol/skills扩展；客户端用skills/list发现有哪些 Skill、每个文件的 SHA-256 指纹和大小；用resources/read读正文和附件。

这么做解决了一个很实际的痛点：Server 和「它的说明书」过去是分开版本、分开安装的。你装了一个github-server，可能还得另外找一份「怎么用这个 server」的文档，两者版本还可能对不上。现在 Server 自己带说明书发货，装上一个就全有了。

而且它复用了现有机制：能读 MCP Resource 的 Host，天然就能读 Skill，不需要额外适配一整层。

一个必须说的安全细节：skills/list返回的每个文件都带 SHA-256 摘要，Host 加载前要校验，内容被改过就拒绝。因为 Skill 本质上是「可执行的指令」，第三方 Skill 是不可信输入——一份被篡改的SKILL.md可以让 Agent 去做你完全没打算做的事，而且它长得像一份普通文档。

五、通讯完整过程

把前面所有零件拼起来，跑一次。

图 10 四步：一句话需求 → 命中技能 → 按技能调三个工具 → 产出。注意顺序和判据是技能定的，动作是工具做的。

第一步，用户说：「把本周合进 main 的 PR 整理成发布说明。」一句话，没说用哪个工具、按什么格式、去哪查。

第二步，命中技能。Agent 在 L1 索引里扫，release-notes的 description 命中了「整理发布说明」这个意图，于是把SKILL.md读进上下文。里面写着三步：取本周合并的 PR 列表 → 按模块归类并补背景 → 套模板写成文件。

第三步，按流程调工具。github.list_prs拿到 17 个 PR；jira.get_issue按 PR 里带的 key 取回 17 条需求背景；fs.write_file准备写入——因为技能里写了「写文件前必须确认」，Agent 在这里停下来问了一句。

第四步，产出docs/release/v1.8.md，按模块分好组，「破坏性变更」单独一节。

这份工的分工很清楚：

顺序、判据、格式、确认点——Skill 决定。
拉数据、写文件——MCP 决定。

换一个项目呢？同一份 Skill 照样能用，只要那边也有list_prs这个工具。因为它只描述方法，不绑定实现。这也是 Skill 比「一段写死的脚本」更耐用的原因。

六、结语：协议解决什么，不解决什么

MCP 这个东西，讲到底没有多玄。它就是把软件工程里的一个老问题——N 个消费者乘 M 个提供者——用一份协议解决掉，和 USB、LSP、ODBC 是同一类东西。

我觉得有三个原因。

第一，它把「连接」从「应用」里拆了出来。工具可以独立开发、独立部署、独立升级、独立授权，不用绑死在某个 Agent 的代码库里。这件事的价值，和当年「驱动从内核里拆出来」差不多。

第二，它被交出去了。捐给 Linux 基金会这件事，比任何技术特性都更能解释它为什么在两年内铺开。协议的生命力来自信任，信任来自中立。

第三，它守住了自己的边界。MCP 只定义「怎么说话」，不定义模型怎么想、Agent 怎么循环、权限怎么做。所以它能和 Skill、A2A、AGENTS.md 这些不同层的东西拼在一起，而不是互斥。一个想吞掉所有层的协议，最后往往一层都占不住。

但也别把它当万能药。几个现实问题：

工具描述本身就是上下文成本。接 200 个工具，光描述就能吃掉半个窗口。渐进式发现（不要一次全加载）正在成为标配，这不是 MCP 的问题，是所有工具调用方案的共同难题。

工具写得烂，模型再强也没用。名字含糊、参数设计反人类、错误信息只有error: 400——「给 Agent 写工具」本身就是一门手艺，和给人写 API 不是一回事。

安全边界没有变。协议只是让「谁能碰什么」变得可描述、可审计，实际执行还是得靠人把权限管住。所谓「工具投毒」「混淆代理」这些攻击，靠协议规范是防不住的，得靠部署时的隔离和审批。

协议解决的是「能不能连上」，解决不了「连上之后干得好不好」。
后者永远是工程问题，不是标准问题。

以上是我们AI学习的第三篇全部内容。欢迎大家关注，你在AI使用过程中，都用过哪些神奇的MCP呢？欢迎分享出来，大家一起进步。我们下期再见！