企业官网建设流程全解析

技术圈每隔几个月就会上演一轮“XX已死”的戏码，这次的主角轮到了MCP（Model Context Protocol，模型上下文协议）。起因并不陌生：越来越多的Agent开发者开始抱怨，MCP server的调试链路太长——工具逻辑就几步，非要包一层JSON-RPC，与其维护这些“薄封装”，不如直接在代码里调原生函数。再加上有人在社交平台上略带情绪地喊出“删掉薄封装”，一股“Agent连接架构要推倒重来”的讨论迅速蔓延，连带着A2A、原生函数调用、纯HTTP API这些方案都被重新摆上台面。

作为一个从function calling时代一路做到现在的开发者，我理解这种情绪，但并不认同“MCP是薄封装”这个判断。这一轮争议里，真正的关键词不是“薄”，而是Agent连接架构到底该怎么选。这篇文章我会拆一下MCP被集火的真实原因、它真正的价值所在，以及在做架构重选时，哪些因素才真正影响你的技术决策。

1. “删掉薄封装”的呼声，到底是从哪里冒出来的

1.1 开发者口中“薄封装”的三宗罪

为什么这么多人觉得MCP是“薄封装”？我总结下来，大家真正不满的点集中在三个地方。

第一是协议层“看起来没干活”。MCP本身基于JSON-RPC 2.0，定义了一组方法：initialize做握手，tools/list列工具，tools/call调用工具。对一个内部工具来说，这确实只是把原本的一次HTTP调用或本地函数调用，改成了另一套消息格式。如果工具本身就3个函数、2个参数，MCP这层封装的边际价值确实小得可怜。很多人的第一反应是：这不就是我给HTTP接口加了一个壳吗？是的，单看一次调用，它确实就是这个壳。

第二是调试链路变长。以前直接在Agent代码里调函数，报错就是Python/TypeScript的堆栈，IDE里单步就能跟进去。换成MCP之后，一条调用要穿过Agent框架、MCP client SDK、传输层（stdio或HTTP）、MCP server进程，最后才到你的工具逻辑。任何一个环节出问题，日志相互不统一，排查起来非常痛苦。我在自己的项目里就遇到过stdio传输模式下server进程直接退出，client端只报一句“connection closed”，没有任何上下文，查了好久发现是某个依赖在初始化时崩溃了。

第三是生态质量参差。MCP火起来之后，大量“hello world”级别的server涌现：工具列表倒是写得很全，但错误处理、超时重试、流式输出、鉴权基本没有。接入这样的server，Agent在一个场景下跑得通，换一个场景就莫名其妙失效。这种体验积累下来，很容易让人得出“还是别用MCP了”的结论。

1.2 一个经常被混淆的点：MCP是软件协议，重点在互操作

讨论过程中我发现很多人其实混淆了一个基础问题——MCP是软件协议还是硬件协议？还有人问“MCP 是软件协议、硬件协议那个概念叫什么来着”。这个问题的答案很简单：MCP是应用层软件协议，和硬件总线协议是两个完全不同的概念。MCP做的不是“传输”，它定义的是两个软件组件之间如何进行发现、协商与调用，类似于LSP（语言服务器协议）在编辑器与语言工具之间做的事情。类比一下，硬件协议好比USB接口，规定了针脚和电平；软件协议更像两个系统之间约定的报文格式和交互流程，USB接口解决的是“物理上怎么插得上”，MCP解决的是“逻辑上怎么对得上话”。

这个区别特别重要。它意味着MCP追求的目标是互操作性：同一个工具描述一次，所有支持MCP的Client都能用，而不是某个单一传输通道。如果你只看单次调用的链路，MCP确实是“薄”的；但如果你看的是跨系统、跨框架的连接，它提供的是一个共同语言。协议的价值从来不在单次调用的复杂度，而在覆盖面的广度。

1.3 为什么现在才吵起来：从“拥塞”到“疲劳”

还有一个时间线上的背景。MCP最早在2024年11月由Anthropic开源，2024年12月发布1.0版本，随后迅速成为Agent工具接入的事实标准。短短一年之内，各个框架、IDE、Agent平台都在拥抱它。事情一旦成为热门，就会进入反噬期：期待过高的用户开始回来找毛病，质疑的声音自然集中爆发。加上OpenAI系的Codex等产品对MCP支持并不算积极，有些用户甚至遇到“codex无法找到mcp”“无法发送消息，显示更新agent沙盒”这类问题，进一步放大了负面体验。简单说，现在的争议不完全来自“协议不好用”，还来自“协议在快速普及过程中，暴露了大量工程质量问题”。这两件事不能划等号。

2. MCP的价值不在“薄”，在于它把连接变成了一条标准轨道

2.1 回看function calling时代：每个Agent都在重复写“工具适配层”

在MCP出现之前，Agent接工具是怎么做的？以2023年OpenAI推出function calling之后那段时期为例。每个Agent框架，都要自己定义一套工具接入方式。开发者想让自家工具被Agent调用，得给OpenAI写一套JSON Schema塞进system prompt；想支持LangChain，又得继承它的Tool基类重写run方法；想给AutoGPT或自研Agent用，又得再写一遍工具封装。工具一旦多起来，每次请求还要把所有工具定义全量塞进上下文，token开销大，Agent也容易在选择工具时犯迷糊。

这个问题本质上是：工具方和Agent方之间缺少一个稳定的“中间协议”。大家各自在两端造适配器，适配器又只在自己的框架里成立。每次出一个新Agent框架，之前的工作就折一次。我相信不少人都经历过这种“为三个框架适配同一把螺丝刀”的无聊劳动。

2.2 MCP标准化的六个关键能力

MCP做的事情，是把这段“各自适配”变成了“统一接入”。它定位在Agent（Client）和工具（Server）之间，定义了几个关键接口：

• initialize：协商协议版本、能力声明。
• tools/list：工具发现，Client启动时获取可用工具清单和参数Schema。
• tools/call：工具调用，带参数、可流式返回。
• resources/list与resources/read：读取文件、数据库表、URL等资源。
• prompts/list：获取可复用的提示词模板。
• 认证与采样（OAuth 2.1、LLM sampling）：处理鉴权和“让工具调用另一个模型”的场景。

以tools/call为例，一次MCP调用本质上就是这样一个JSON-RPC消息：

{ "jsonrpc": "2.0", "id": 1, "method": "tools/call", "params": { "name": "query_stock", "arguments": { "symbol": "600519" } } }

这些接口单独拿出来都平平无奇，但组合在一起就形成了一套完整的最小互联模型。工具方只需要实现一次，之后无论Claude Desktop、Cursor、自研Agent还是IDE插件，只要对方支持MCP协议，就能直接接入。这一点是MCP真正的护城河，也是“生态大于单点性能”的典型案例。你可以把它想象成充电器标准：一个充电头虽然比“直接用导线接电池”多了一层，但这层让所有设备都能共用同一个头。

2.3 生态端的选择已经回答了“该不该用”

看看过去一年里围绕MCP长出来的实际应用，就能理解为什么“薄封装”批评没有动摇社区：

• Playwright MCP和Browser Use MCP这类浏览器自动化工具，虽然定位相近，但都选择保留MCP接入方式。原因很简单：浏览器操作能力要被不止一个Agent产品复用。社区里也经常有人问“browser use mcp跟playwright mcp有什么区别”，但没人质疑它们为什么都走MCP。
• 同花顺MCP、量化领域的各类数据MCP，把行情、数据查询能力标准化接入Agent，避免每个Agent单独对接一遍。
• 游戏内存分析领域有Cheat Engine桥接MCP的教程，Unity有Unity MCP，安全测试场景有Trae IDE搭载Burp Suite MCP Server这类玩法。
• 还有IDE生态，通义灵码通过MCP连接Oracle数据库，蓝湖通过MCP接入Codex，Cursor内核直接支持MCP。
• 更典型的是一些开源项目，比如ruoyi-vue-pro这种企业级后台框架，也开始把MCP功能直接合并进标准模块。这说明MCP已经不是“某个AI公司的私有协议”，而是成了通用基础设施层。

这些例子的共同特征是什么？都是“一个工具能力，被多种客户端消费”。只要这个特征存在，直接写业务函数、直接暴露REST API，都无法替代MCP提供的通用接入层。删掉薄封装容易，删完之后你得为每个客户端重新写一遍薄封装。

3. Agent连接架构重选：四个真实方向，各有各的适用位置

“重选”不是非此即彼的站队问题。我把目前讨论里真正有价值的几个方向梳理一下，每个方向都对应一类场景，选错了才是问题。

3.1 方向A：同进程函数调用，最彻底的“删薄封装”

如果你只有一个Agent代码库、工具就是项目里的几个函数、没有其他客户端会复用，那同进程函数调用确实是正确答案。新一代Agent框架基本都有工具装饰器，一个函数标注一下，agent就能自动发现、生成参数Schema、做类型校验。比如：

@tool def query_stock(symbol: str) -> dict: """查询股票行情""" ...

这个过程无需网络请求、没有进程开销、调试就是IDE里的堆栈回溯。我写日常自动化脚本时就经常这么做——几十行代码，定义两个函数，框架一注册就行。这种情况下硬上MCP，等于给自己制造维护负担：要管理server生命周期、要处理传输层、要写一套无关业务的状态管理。这是“为了标准而标准”，没必要。

3.2 方向B：HTTP API + 各框架自带Tool Use，不加中间协议

很多工具方现在的形态是：服务已经提供了REST/HTTP API，客户端则各自用OpenAI function calling或Anthropic tool use做适配。这种方案优点很明显：没有额外一层协议，API本身可复用，调试可以直接用curl看结果。缺点同样明显：工具schema、认证方式、分页结构等细节，每个客户端框架都要单独适配一次。

所以这个方向更适合“只有一两个固定客户端”的场景。比如你的Agent只跑在自研后端里，前端固定调用同一个服务，那完全不需要引入MCP。它和MCP方案的区别，我列成一个表格更直观：

这个表基本就是“选型时的天平”：左边赢在简单，右边赢在通用。没有绝对优劣，只有匹配不匹配。

3.3 方向C：A2A（Agent-to-Agent），和MCP不在同一个层次

“Agent连接架构重选”讨论里另一个常被提到的名字是A2A协议。Google在2025年主导推动。很多人把A2A和MCP对立起来，这是一个误区。

MCP解决的是“Agent到工具”：工具是被调用的资源，Agent是调用方。A2A解决的是“Agent到Agent”：两个能力对等的Agent进行任务委托、结果回传和状态协商。它们处于不同的抽象层次，可以共存。一套完整的Agent架构里，很可能是上层用A2A做多Agent编排，下层用MCP让各个Agent去碰具体工具。这和“harness和agent区别”是同一类分层问题——执行环境和决策主体要分开看，连接协议同样要分层次看。你会因为有了高速公路，就不修连接服务区的匝道吗？不会。A2A和MCP就是这样的关系。

3.4 方向D：保留MCP，但换成网关与分层模型

在实际落地中，保留MCP但改变使用方式，往往比彻底删除更有效。我现在见过几类演化模式：

• 聚合式网关：一个MCP Server同时暴露多个内部服务，通过名称空间或路由前缀区分。对外是一个server，对内聚合了十几个工具。
• 标准分层：边缘层负责认证、限流、日志，协议层继续用MCP，业务层无感。
• 混合接入：高延迟低频场景用MCP，低延迟高频场景直接用函数调用。Agent框架中通过路由规则决定走哪条链路。

这种“MCP当现成的JSON-RPC网关用”的做法，本质上是把MCP从“工具接入协议”升级成了“工具编排基础设施”。我了解的不少自研Agent平台（包括Hermes Agent这类桌面端工具）都采用了这种分层思路：接口层保持MCP兼容，底层统一走自己的服务调度。这样既照顾了生态，又不被协议绑死。

4. 实战选型：什么时候我用MCP，什么时候我劝你别用

4.1 先问三个灵魂问题

选型不要看风向，要看自己的连接图。我给团队内部做方案评审时，通常会让大家先回答三个问题：

1. 这个工具会被多少个客户端消费？只被一个Agent消费，优先函数调用或直接API；会被多个Agent、IDE、自动化脚本消费，优先MCP。
2. 工具方对协议演进敏感吗？工具经常要改参数、加功能，MCP的tools/list动态发现能力可以省去客户端代码更新。
3. 你能承受调试MCP栈的维护成本吗？没有专职工程兜底，MCP server出了故障会阻塞业务。

这三个问题的答案组合起来，基本决定你选左边还是右边。我把四个方向总结进一张选型矩阵表：

4.2 我经历的一次正向转化：函数调用改成MCP后，收益其实很大

这里讲一段个人经历。之前做一个面向咨询团队的数据问答Agent，最开始所有工具都是Python函数直接注册，一切顺利。后来团队新来的分析师用起了其他Agent工具，问能不能接入同一批数据查询能力。我当时的第一个想法是“给那个工具写一个适配器就行”，结果发现它需要的适配方式和我现在的框架完全不同——数据结构要重排、schema要重写、错误信息格式也不同。工作量不大，但很烦。

后来我把这批数据查询能力整理成一个MCP server，提供统一schema和错误约定。之后再接入新框架，只需要配置URL和token，半小时内就能跑通。这个项目是我对MCP态度转变的直接原因：单次调用的成本确实多了几毫秒，但“接下一个客户端”的成本从几天变成半小时。这也解释了为什么“ai agent怎么扛并发”这类问题会在MCP场景里反复出现——server侧性能和稳定性，才是MCP好用与否的关键变量。

4.3 另一段反向教训：为标准化强行MCP，换来一地鸡毛

反过来我也踩过坑。有个内部监控脚本，只有我自己在使用，工具逻辑就三四个函数。为了“统一架构”，我硬写了一个MCP server，还在里面加入了resources、prompts这些其实用不到的能力。结果两周后脚本逻辑要求变动，我得先改server、再改client，一次简单变更变成了两处操作。最后我果断删掉MCP，恢复直接函数调用，事情一下子清爽了。

这段经历之后的结论是：MCP不是“更好”或“更差”，它只是“更通用”。通用性只有在你需要跨接的时候才有价值，否则它就是一个徒增复杂度的中间人。删掉薄封装这件事本身没有错，错的是把“删掉”当成一种政治正确，而不是一种基于场景的工程决策。

5. MCP会不会退出历史舞台？我的判断比“凉了”复杂一些

5.1 协议的历史经验：没被淘汰的，只是被放进了合适的位置

回看计算机协议史，很少有一种协议被完全淘汰。SOAP没有消亡，只是从主流Web服务场景退回到企业级集成场景；CORBA在今天仍然活跃在部分通信和国防系统中。REST很流行，但gRPC、GraphQL也在各自的生态位活得很好。协议的结局通常不是“死亡”，而是“降级”——从“被所有人谈论”变成“在合适的场景里被合适的人使用”。

MCP现在处于每轮技术浪潮都会经历的阶段：炒作峰值已过、质疑开始涌现、真实价值被工程问题掩盖。把它和“退出历史舞台”放在一起，说早了。真正值得关注的不是它会不会死，而是它会在哪一层活下来。

5.2 未来几个绕不开的演进点

• 协议版本演进：MCP 1.x时代还带着早期设计的影子，未来大概率会对resources、prompts、sampling这些低频功能做简化，让协议更专注“工具发现和调用”。
• 网关与代理成熟：一批MCP Gateway、Proxy产品正在把server质量参差的问题收敛到基础架构层。到那时候，你接入MCP的体验可能会接近“请求打到API网关”的稳定度。
• 与A2A形成分层普及：Agent-to-Tool用MCP，Agent-to-Agent用A2A，这个分层会越来越清晰。
• 大厂态度会决定速度：OpenAI、Google、Anthropic对MCP的支持程度，会影响它在不同生态里的渗透率。但协议的生命力从来不是单一大厂决定的，社区实践往往更持久。

5.3 给正在做架构选型的人几条实操建议

基于我自己的开发经验，给几个可落地的建议：

先画清楚连接图，再谈协议。你的Agent会连接到哪些工具？哪些工具会被多个Agent复用？这张图决定你是用MCP还是直接函数调用。别让“趋势”替你回答这个问题。

学协议思想比背协议接口重要。MCP的核心思想是“连接标准化、复用最大化”，这套思想在A2A和未来任何连接协议中都会复用。就算哪天MCP真的被替代，你掌握的这个思想也不会过期。

预留替换空间。MCP client端做一个薄适配层，server端保证工具逻辑不依赖MCP数据结构，这样将来无论MCP怎么演变，你都能平滑切换。

最后，别被“薄封装”这种标签带着走。标签只能定义已有事物，不能定义你面对的场景。我现在的习惯是，先把工具逻辑写清楚，再问一遍自己：谁会复用这个工具？如果答案只有自己的代码，就不碰MCP；如果答案里有多方接入的可能，就认真搭MCP server。这个判断做完，所谓的“退不退出历史舞台”，其实已经不影响你的日常开发了。