企业官网建设流程全解析

最近圈子里关于 MCP 的讨论有点两极分化，一边是“万物可 MCP”的造势，一边是“MCP 已死”的唱衰。我自己的态度比较直接：它没死，但确实被用坏了。过去大半年我带着团队在三个真实项目里接 MCP，从最初的“真香”到后来被配置、调试、上下文损耗、依赖升级来回摩擦，最后把其中两个方案彻底拆掉换成了更朴素的实现。这篇不是要劝退谁，而是把这段踩坑经历和选型思考完整摊开，给正在纠结“要不要上 MCP”“怎么上 MCP”的人一个参考。

先说结论：MCP 的核心价值在于“标准化接入”，但它不是 AI 技术的银弹，更不是用来替代日常函数调用的。选型之前，先搞清楚你的项目是“需要连接很多异构系统”，还是“只需要自己内部几个工具”。前者适合 MCP，后者贸然上 MCP 大概率是给自己找麻烦。

1. MCP 到底解决了什么问题

1.1 先把它拆开看：MCP 不是一项“技术”，而是一层协议

很多人在看 MCP（Model Context Protocol）的时候，容易把它当成一个 AI 工具库，或者一个函数调用框架。但它的真实身份是一层通信协议，类比一下，它更像你家里的 USB 接口，而不是某一台具体的打印机。MCP 定义了“AI 模型 / Agent”和“外部工具 / 数据源”之间以标准方式对话的规则：客户端（Host）负责发起请求，服务器（Server）负责暴露工具、资源和提示词，两边通过 JSON-RPC 2.0 进行消息交互。

为什么要搞这么一层？因为在实际开发里，AI 应用要接入的外部系统太多了：本地文件、数据库、浏览器、设计稿、代码仓库、内部 API，甚至另一个 AI Agent。如果每个系统都自定义一套接入方式，那每换一个模型、每换一个前端入口，就要重新写一遍集成代码。MCP 想做的事情，是把“工具怎么暴露”和“模型怎么调用”统一成同一个标准，让一个 MCP Server 可以同时服务 Cursor、Claude Desktop、自研 Agent，不需要重复开发。

这个出发点我是认可的，也是为什么我至今仍然认为 MCP 有存在价值。但问题出现在它被当成了“默认选项”，甚至“唯一选项”，仿佛不接 MCP 就不够 AI 原生，这种风气把技术选型带偏了。

1.2 当初为什么这么多人踩进来

2024 年底到 2025 年初那阵子，MCP 的声量突然就起来了。一方面是因为 Anthropic 推得猛，另一方面是 Cursor、Zed 这些主流编辑器和工具快速跟进，只要是个支持 Agent 的客户端，几乎都在宣传自己支持 MCP。很多团队 demo 完“AI 读取本地文件”“AI 操作浏览器”之后，觉得效果惊艳，马上就把 MCP 列进了自己的架构。

从众心理只是一部分原因。更现实的驱动力是：MCP 确实省掉了“每个模型都要单独适配”的麻烦。我们团队当时第一个项目是做一个内部数据分析助手，需要联动本地文档、数据库、图表生成三套工具。在没有 MCP 之前，我们得针对具体模型写 function calling 的工具描述，换模型就重写一遍。MCP 看起来刚好解决了这个痛点——按协议实现一次，模型随便换。

当时我甚至觉得“这就是未来”。真正跑了一段时间后才发现，标准化省掉的是一部分重复劳动，但它引入的新问题，恰恰是选型时没人提的：协议带来的抽象损耗、工具发现的不可控、上下文消耗的成倍增长，还有调试链路长到你怀疑人生。这些坑，下面一个一个说。

2. 我踩过的坑：MCP 在实际项目里的真实状态

2.1 配置地狱：从“装完就好”到“处处报错”

MCP 的官方定位是“标准化的、一键接入的协议”，但实际使用中，最耗时的恰恰是配置环节。

先看一个最常见的场景：你写了一个 MCP Server，需要注册到 Cursor 或 Claude Desktop 里。你得配置什么？服务器地址也好、本地命令也好，还牵扯到环境变量、协议版本、传输方式（stdio / HTTP）。这还没完，不同的客户端对 MCP 的支持程度还不一样，A 客户端支持的工具发现方式，在 B 客户端里可能完全无效。

我当时负责的一个内部工具，MCP Server 跑在本地 Node 环境，Cursor 连接时总是报“Failed to fetch tools”。排查了一天，最后发现是 Node 版本和 Server 端依赖不兼容，Cursor 自带的环境变量没有传给子进程，导致服务器启动时崩了。这个问题的修复并不难，但排查成本极高，因为 MCP 的报错信息通常只有一行，根本不告诉你到底是配置格式问题、网络连不上，还是服务器内部抛了异常。

更让人头疼的是权限和认证。MCP 标准里对认证这块的规范一直都在演进，很多 Server 的实现还在早期阶段。你要连一个需要 token 的远程服务，token 放哪儿？放环境变量里？放在 Server 配置里？还是直接在代码里写死？每个 Server 的做法不一样，完全没有统一的体验。安全问题也随之而来，团队成员把 token 写进配置文件并提交到仓库的情况，我们碰到过不止一次。

提醒一句：如果你们的项目不是一次性 demo，而是一个要长期维护的生产系统，一定要在设计阶段就把 MCP Server 的部署方式、认证机制、配置注入路径规划好。这个环节偷懒，后面操作时处处是坑。

2.2 上下文失控：协议是通了，模型却废了

配置问题至少是透明的，调试一下总能解决。真正让我下定决心放弃 MCP 的，是它在上下文管理和 token 消耗上的失控。

MCP 的工作方式决定了，模型要调用工具，先要通过工具发现机制拿到“工具列表”，然后根据任务的语义选择调用某一个或某几个工具。听起来很合理，但问题出在“工具列表”的体量上。你的 MCP Server 只要暴露超过十个工具，每次发起任务时，这些工具的 JSON Schema 都会被打包进上下文。一个复杂点的工具 schema 几百行很常见，十个工具就是几千行，意味着每一次普通对话都要背上几万 token 的隐性消耗。

我们当时那个数据分析助手，MCP Server 暴露了十三个工具，包括查表、统计、画图、导出等。实测下来，每个会话光工具描述就吃掉大约 8000 到 12000 个 token。用户只是问一句“上个月销售额是多少”，模型在理解问题之前，先要把一堆工具说明“读”一遍。费用是小事，更要命的是模型的注意力被分散了，复杂一点的指令需要多轮推理时，模型经常会选错工具，或者把无关工具的输入输出混在一起，生成的中间结果乱七八糟。

这不是 MCP 本身的 bug，而是“把所有工具一次性暴露给模型”这种设计天然带来的问题。缓解的办法也有，比如做工具分组，或者用更严格的工具描述精简 schema，但这样就得绕过 MCP 的标准流程，自己写一层工具筛选逻辑。绕来绕去，你回归到了自定义函数调用的老路，那 MCP 的标准化优势就名存实亡了。

2.3 调试困难：工具调用链路像黑盒

传统开发里你要排查一个问题，直接看日志、打断点、看调用栈，清清楚楚。换成 MCP 之后，整个链路变成了：用户输入 → Agent 理解 → 模型决定调用工具 → 客户端通过 MCP 协议发请求 → Server 执行 → 结果返回 → 模型生成回答。中间任何一环出问题，你都得一层一层拆开查。

最常用到的排查手段是看 MCP Server 的日志。问题是协议本身没有统一日志规范，每个 Server 打日志的格式、位置都不一样。有的输出到 stdout，有的写文件，有的压根不日志。而 MCP 客户端往往又把这些日志吞掉了，你根本不知道模型是否真的调用了工具，调用时传了什么参数，返回了什么结果。

我印象特别深的一次：一个文本分析工具在生产环境偶发返回空结果。从用户侧看就是“AI 没有给出任何内容”，不报错、不超时，很像模型自己答不上来。查了两天才定位到问题出在 MCP Server 上——它在一个边界 case 里抛了异常，但异常信息被协议层捕获后，封装成了一个“空结果”返回给模型，模型以为工具执行成功但无输出，于是直接回答“没有数据”。这个锅不能说完全甩给 MCP，但协议层对错误处理的模糊包装，确实大幅增加了排查难度。

如果你们团队还没习惯“模型调用工具”这种新调试方式，建议在上 MCP 之前就先想好可观测性方案。重点关注工具调用参数记录、各环节耗时、错误码透传、上下文 token 统计。这些在函数调用时代可以靠加日志解决，但在 MCP 体系里，得提前设计一套围绕“协议链路”的监控方案，不能等出了事故再补。

2.4 生态依赖：今天的英雄，明天的弃子

技术选型里一个很容易被忽略的变量，是“生态期限”。MCP 的问题在于：它本身是个开放的协议，但具体到 SDK、客户端支持度、Server 实现质量，都还在非常早期的阶段。协议虽然好，但上下游生态不成熟，你这个“船”就不好开。

举几个我们实际遇到的例子：某些客户端只支持旧版协议，新版 Server 无法接入；某个常用的官方 SDK 在处理大体积响应时会内存溢出，但一直没修复；还有一些社区 Server，维护不积极，上游依赖一升级就挂，根本没有商业主体兜底。你花力气接入一个 MCP Server，等它的维护者不干了，就得自己 fork 一份维护，这笔隐形成本在选型时几乎没人算进去。

再说版本兼容。MCP 协议更新频率并不算慢，但每次更新都意味着客户端、SDK、Server 要跟着调。单机本地用还好，一旦涉及多端、多环境、多人协作，升级就是一次小型项目。我们在第二个项目里吃过一次大亏：为了一个安全补丁升级了 MCP SDK 版本，结果四个依赖这个协议的服务里有三个跑不起来，回滚又牵扯到客户端缓存，整个过程非常狼狈。

3. 技术选型反思：MCP 不是万能钥匙

3.1 什么时候我仍然推荐 MCP

说了这么多坑，如果让我直接下结论“彻底别用 MCP”，那是另一种不负责任。它是工具，有它最合适的边界。

我推荐你在三种场景里认真考虑 MCP。

第一种，是需要跟大量异构系统或第三方服务对接的场景。比如你的 Agent 要同时访问 GitHub、Notion、Slack、本地文件、数据库、浏览器等，MCP 的标准化价值就像 USB 接口一样体现出来了。你不需要为每个数据源单独写一套接入逻辑，只要对方提供 MCP Server，接入就是配置层面的事。

第二种，是“一次开发、多端复用”的场景。团队里同时有多个 AI 客户端（Cursor、Claude Desktop、自研 Web 端等），希望同一个工具复用。MCP 把工具封装成标准服务，一次部署就能被多种 Host 使用，比针对每个 Host 写适配层划算得多。

第三种，是数据敏感但又要灵活性有限的内部工具场景。比如企业内部有一些隔离的内部知识库或权限系统，MCP Server 可以做成一个受控的“数据阀门”，统一管控 AI Agent 能触达的数据范围和操作边界，审计也集中。这种模式的本质是“标准化封装 + 集中管控”，MCP 的协议优势能充分发挥出来。

3.2 什么时候坚决不碰 MCP

反过来，我在这些场景里会明确拒绝 MCP：只有一两个内部工具，模型需要频繁调用且对延迟敏感；或者当前模型已经自带了很强的 function calling 能力，而你的工具数量不多、schema 固定。这时候上 MCP 等于给一辆自行车装上飞机机翼，纯属增加复杂度。

以我们那个数据分析助手为例，最终拆掉 MCP 方案后，我回到传统函数调用，用模型的 function calling 接口直接暴露六个核心工具。工具数量少了，schema 精简单了，上下文消耗直接降了 70%，调用成功率也上去了。而且调试链路短了，出了问题看一次日志就能定位，运维成本大幅下降。

还有一种情况也不要碰：团队里没有熟悉协议层开发的人。MCP 虽然概念不复杂，但它牵扯到进程管理、传输协议、安全边界、兼容性测试等，没有一两个能看懂协议栈的人，出问题的时候你连“该怪谁”都说不清楚。不如老老实实写函数调用，至少电光火石之间都知道去哪修。

3.3 “MCP 已死”的另一种解读

说“MCP 已死”的人，一部分是标题党，一部分是经历过和我类似的踩坑。但我更愿意把这件事理解成：MCP 的“热炒期”已经结束了，接下来进入的是“冷静期”。

在热炒期里，所有人都在担心错过机会，所有的架构设计都优先考虑“够不够 AI 原生”，而不是“够不够简单、够不够稳”。等热度退下来，大家才会认真审视它到底适合什么、不适合什么。MCP 会活下来，但它的定位会更朴素——不是所有 AI 工程的必需品，而是一个“遇到对应问题时才拿出来用的标准方案”。

所以在我看来，“MCP 已死”这句话真正想表达的是：那个“万物皆可 MCP、不上 MCP 就不是好工程”的幻觉已经死了。留下的，是一个真实、有用、边界清晰的协议工具。

4. 从 MCP 的教训中提炼出的 AI 工程选型框架

4.1 用协议，还是用接口？

AI 工程里最核心的选型维度之一，就是“用协议还是用接口”。你可以把这两个选项理解成：协议解决的是“怎么统一地描述和发现能力”，接口解决的是“怎么简单地调用一个能力”。

如果你的目标是一个稳定的工具集、调用链路由你自己完全控制，那接口就是最优解。自己定义函数、定义输入输出、用模型能力直接调用，链路短、可控性高、调试直观。而如果你的目标是要接入一个不可控的庞大生态，而且这个生态的参与者各自独立、不想为你的接口定制，那协议就是最优解。

不要因为“协议听起来更先进”就选协议，也不要因为“接口更简单”就无脑选接口。结合自己的系统边界来选，选错了就会把“接入能力”变成“接入复杂性”。

4.2 稳定性的优先级

技术选型的第二维度是稳定性。这个“稳定”，包含两层意思：一层是运行时稳定，请求不挂、不出错；另一层是迭代稳定，版本升级、依赖更新不会动不动破坏性变更。

在运行时稳定上，MCP 的表现取决于 Server 的实现质量，而 Server 生态良莠不齐，需要你自己在选型前做大量兼容性验证。在迭代稳定上，MCP 目前的版本演进还存在不少 breaking change，你得预留维护成本。所以，如果你们的系统对稳定性有非常高的要求，比如面向金融、医疗、生产环境，那么引入 MCP 之前一定要做充分的试点验证，而不是看别人 demo 完就跟着抄。

4.3 可观测性和可调试性

我前面花了这么长篇幅讲调试难，潜台词是：在 AI 应用里，可观测性不是附加项，而是选型的关键约束。选 MCP，就得配套解决“链路级日志”“工具调用记录”“错误码透传”这些问题。选函数调用，这些天然更简单。

选型时不妨先问自己一个问题：线上出了问题，你有多大概率能在 10 分钟内定位到根因？如果答案是“不确定”，那就别选那种让链路更黑盒的方案。AI 本身就够难调试了，不要再叠加一层不可控的复杂度。

4.4 团队能力的匹配度

最后一个维度，却往往是最关键的现实因素：团队里有没有人真正搞明白协议层、有没有人能把 Server 从头到尾修好、有没有人能理解“模型 + 工具 + 上下文”这条链路的整体开销。如果答案是否，再好的技术方案也很难落地。

MCP 的部署、Server 开发、协议调试，都需要一定门槛。团队里如果没有处理过进程管理、网络通信、JSON-RPC 的人，强烈建议先从函数调用开始，等技术债积累到确实需要一个统一协议来治理时，再引入 MCP。到那时，你们的抽象能力、问题理解、坑的认知都上来了，MCP 才能真正变成工具而不是负担。

5. 实操建议：如果你现在要做一个接入外部工具的 AI 功能

5.1 五步走：从需求到技术落地的简化流程

如果你听了我上面这些反思，对 MCP 的边界有了大概认知，但还是不确定怎么落地，可以按下面这套简化的流程来走。

第一步，梳理你的工具清单。把所有 AI 需要调用的外部动作列出来，比如查文件、查数据库、调 API、发通知。注意，这一步不要考虑技术，只做业务梳理。

第二步，评估工具数量和异构程度。如果工具少于三个，且都是自己系统内的 API，直接走函数调用，别想 MCP。如果工具超过五个，并且涉及很多第三方系统，或者未来要支持多个 AI 客户端，才考虑 MCP。

第三步，做一个小样验证。选一个最典型的工具，分别用函数调用和 MCP 两种方式实现，对比上下文消耗、调用延迟、错误率、开发工时。别光看 demo，要放到真实数据、真实 prompt 下测。

第四步，设计可观测性方案。无论选哪种方案，都要确保你能看到每次工具调用的输入、输出、耗时、token 费用。MCP 方案尤其要重视这一层，因为链路更长，出错面更大。

第五步，构建回退机制。AI 工程非常重要的一条实践：任何依赖模型调度工具的方案，都必须有“模型不调用工具也能完成任务”的备用策略。不要让外部工具故障变成系统不可用的唯一原因。

5.2 替代方案对比：MCP 和函数调用、插件机制怎么选

为了更直观，我把三种主要方案放在一起做了个横向对比。

不是每一个场景都必须三选一。实际操作中，它们也可以组合使用，比如你有一个比较完善的函数调用基础，再通过 MCP 暴露部分第三方能力给外部客户端，这种“混搭”思路反而是比较务实的解法。

5.3 哪些坑是可以绕过的

“避坑”不是让你不去踩，而是让你在踩之前有心理准备，至少把伤害控到最低。

工具列表数量要克制。不管用不用 MCP，暴露给模型的工具都不要贪多。与其一次性给模型二十个工具，不如只给最核心的五六个，把不常用的工具放到第二层，让模型先选领域再选工具，那种“一下子就全给”的设计迟早完蛋。

要严格控制 MCP Server 的响应体大小。有些 Server 在导出数据的时候会把整个文件内容塞进响应，模型拿到一个几十万字符的响应，几乎就“失去理智”了。在 Server 层做数据截断、分批返回、索引优先，是必须的优化，不是可选项。

认证和密钥管理要专门治理。MCP Server 往往连接着真实的业务数据，token、密钥、数据库口令不能只丢在环境变量里，要有一个集中的密钥管理系统，并且定期轮换。另外，凡是涉及外部访问的 MCP Server，一定要有权限管控和审计日志，防止“AI 一高兴，把不该暴露的数据都暴露了”。

版本升级不要激进。MCP 生态还在快速迭代阶段，每次升级前都先做一轮完整的回归测试，最好挑一个非核心服务先升级试运行，稳定了再铺开。不要因为一个安全补丁或者新特性，就一把梭把所有服务全升了，我在这上面吃的亏够写一篇专门的文章了。

写在最后的一点个人体会

如果只能从我这半年经历里提炼一句话，那就是：技术选型最忌讳的是“因为大家都在用，所以我们也用”。MCP 确实是一个有潜力、有价值的协议，它让 AI 连接外部世界的路径第一次有了统一标准，这件事本身很重要。但对单个团队、单个项目来说，“标准”不代表“最优”，它只是众多选项里的一个。

我后来把两个项目里的 MCP 方案拆掉，换回函数调用时，有同事问我：是不是以后都不用了？我说不是，以后遇到 Ga 的场景，比如要接入十几个第三方服务，或者要同时支持多个 AI 客户端，我还是会考虑它。只是这一次，我会先把它放在一个“可控的、可观测的、有回退方案”的位置上，而不是让它承担所有不该它承担的神话期待。

判断力比工具本身更能决定项目质量。

这句话也是我想对所有正在做 AI 工程选型的人说的。参数、协议、框架，这些都是可以学的，但“什么时候能用它”和“什么时候不要用它”这种经验，只能靠踩坑去换。希望这篇分享能让大家少踩几个我踩过的坑，把踩坑省下来的时间，花在你真正该解决的问题上。