乐于分享
好东西不私藏

MCP 又死了?3亿月下载量打脸唱衰者!前端工程师何去何从?

MCP 又死了?3亿月下载量打脸唱衰者!前端工程师何去何从?

智能体有多好用,完全取决于它能连上多少东西。就像一个再聪明的助理,她要是进不了公司系统、打不开邮箱、看不到日历——那它也干不了什么活儿。

01 前端工程师真的”死”了吗?

最近技术圈有个”月经话题”:MCP 到底死了多少回了?

不少人吐槽:模型能力每提升一次,前端工程师就要”死”一次。一次又一次,前端岗位确实在减少,或者被”合并”到了全栈工程师当中。

但就在唱衰声最大的时候,一组数据砸了过来——

MCP SDK 的月下载量,从今年年初的 1 亿次,飙到了最近的 3 亿次。

数据来自 Claude 官方博客,不是野榜。

先说结论:前端岗位在锐减,但凶手不是 MCP。

来看几组硬数据:

2025 年,84% 的开发者已在或计划使用 AI 工具,初级程序员岗位需求同比下降约 30%

智联招聘 2026 年 Q1 报告:普通前端开发岗位需求同比暴跌 52%

美国劳工统计局数据:过去两年,编程类初级岗位减少了 27%

到 2025 年底,部分公司的专职前端岗位已经消失——要么转全栈,要么走人

📌关键判断

这不是 MCP 的锅,这是 AI 对整个软件开发行业的结构性冲击

“死”了的只是那种”只会写页面、调接口、切图”的纯执行型前端。活下来的,正在变成三种人:

1

全栈工程师:一个人用 AI 助手搞定前后端,独立交付整个功能

2

架构师 / 协调者:不再一行行码代码,而是设计系统架构、写提示词、指挥多个 AI 智能体协同工作

3

AI 原生开发者:熟练使用各种 AI 工具,具备”把需求拆解成 AI 可执行任务”的能力

不是”前端死了”,而是”只懂前端”死了。

02 让智能体连上外部系统,三条路怎么选?

目前主流有三种方法,咱们一个一个讲清楚。

方法一:直接调 API

起步最简单。一个 API 对应一个场景,Agent 直接调就完事了。

但规模一上来,问题就炸了:每新增一个”Agent × API 服务”的组合,都得从头写一套认证和工具描述。这就是经典的 M×N 集成难题:M 个 Agent × N 个 API 服务 = M×N 套代码。小打小闹可以,上生产就疼。

方法二:命令行工具(CLI)

更快、更轻。直接复用现成工具链,本地环境里非常好使。Agent 天生就会用命令行语言。

但天花板也很明显:移动端、网页端、云端没有 shell,就玩不转了。CLI 的认证通常靠磁盘上的凭证文件,最适合本地开发环境,正经生产场景会受限。

方法三:模型上下文协议(MCP)

把”统一中间层”做成了协议。认证、工具发现、语义表达全部标准化。

建好一台 MCP 服务器,Claude、ChatGPT、Cursor、VS Code 等所有兼容客户端都能直接用,部署在哪儿都行。

💡结论

三条路不是非此即彼。成熟的集成,往往三者都用

03 MCP 被骂得最狠的问题:Token 死贵

MCP 虽好,但被骂得最多的就是:太费 token 了,贵得离谱。

ScaleKit 做了一组严格的 benchmark,拿 GitHub 官方 MCP 服务器和 gh CLI 对照跑实验。

问题出在 schema 膨胀上。

GitHub 的 MCP 服务器带了 43 个工具定义,每次对话都得把这些工具的描述塞进上下文。你只是想查个仓库语言,但模型得先读完所有工具的说明书——

方案
Token 消耗
GitHub MCP 服务器(43个工具)
44,026 tokens
gh CLI 完成同样任务
1,365 tokens
差 32 倍,我都想天天骂。

04 Token 问题的两个解法,已经落地了

好消息是,这些问题正在被解决。

解法一:按需加载工具定义(Tool Search)

以前是一上来就把所有工具定义塞进去——43 个工具、55,000 tokens,活还没干,工作台就被说明书堆满了。

工具搜索把这步推迟了:智能体先描述它想做什么,系统在运行时搜索相关工具,只把匹配的几个拉进来。

ℹ️实测数据

工具定义的 token 消耗减少 85% 以上,准确率没有下降。差距从 32 倍缩到约 7 倍——还是比 CLI 贵,但不再是数量级的差距了。

解法二:用代码处理工具结果(程序化工具调用)

工具返回的结果不再直接丢给模型,而是扔进代码执行沙箱里处理。智能体在沙箱里循环、过滤、聚合,只把最终结果返回到上下文——中间的原始数据不经过模型。

在复杂多步骤工作流中,token 使用量可减少约 37%

两个解法叠加,上下文更瘦、往返更少、响应更快。

05 怎么做出一个好用的 MCP 服务器?

目前目录里已有超过 200 个 MCP 服务器,每天数百万人在用。结合大量实践,总结了几个关键设计原则。

① 做成”远程服务器”,触达面才大

远程服务器是唯一能同时被网页端、移动端、云端智能体调用的形态。想让智能体无论跑在哪儿都能用上你的系统?做远程的,没别的选择。

② 按”用户意图”组织工具,别按 API 端点

很多人第一反应是把 API 一对一翻译成工具——这是个陷阱。少而精、描述清晰的工具,远比一堆细碎的工具好用。

与其给智能体四个工具(获取消息串 + 解析消息 + 创建工单 + 关联附件),不如直接给一个 “从消息串创建工单”,一步到位。

思路:围绕“用户想完成什么”,而不是”API 有哪些方法”。

③ 接口非常多时,改成”代码编排”

如果你的服务有几百个操作——比如 Cloudflare、AWS、Kubernetes——”意图分组”也包不完。这时换个思路:只暴露一两个接受代码的工具

Cloudflare 的 MCP 服务器就是典型案例:只有两个工具(search 和 execute)。整个工具定义只占大约 1K tokens,却覆盖了约 2,500 个端点

这个模式叫“代码编排”——把 CLI 的哲学搬进了 MCP 协议里。

④ 在关键时刻,给用户更丰富的交互

MCP Apps 允许工具直接返回可交互界面——图表、表单、仪表盘,直接渲染在聊天里,不用让用户跳出去。会用 MCP Apps 的服务器,采用率和留存率都明显更高。

⑤ 认证用标准方案,别自己造轮子

认证是否标准化,直接决定云端智能体能不能用起来。

最新 MCP 规范支持 CIMD 客户端注册方式,用户首次登录快,后面也不容易突然被要求重新授权。Claude Managed Agents 的 Vaults(保险库) 帮你管令牌:用户登记一次,之后每次会话平台自动注入正确凭据并帮你刷新——不用自己搭密钥存储。

06 MCP + Skills:不是替代,是组合拳

Skills 和 MCP 是互补的两件事:

能力
作用
MCP
给智能体”工具和数据的访问权”——能做什么
Skills
给智能体”怎么用这些工具完成真实工作的流程知识”——怎么做

方式一:打包成 Plugin 一起分发

Claude 的插件可以把 skills、MCP 服务器、hooks、LSP 服务器、子智能体全打进一个包里,一键安装。

方式二:从 MCP 服务器直接分发 Skills

服务提供方发布 MCP 服务器时,顺手附送一份 skill——客户端拿到的不只是原始能力,还有一本”最佳使用手册”。Canva、Notion、Sentry 今天都在这么干。

07 三条路,各回各家

场景
推荐方案
理由
本地开发环境
CLI + Skills
轻量、快速、上下文干净
云端生产环境
MCP + Skills
标准化、跨平台、认证完备
简单场景
直连 API
别瞎折腾
💡结论

MCP 并没有死。 它当然不是万能方案,但它正在成为云端智能体的标准化接入层。今天建好一台远程 MCP 服务器,就能触达所有兼容客户端、所有部署环境,认证、交互、语义全部由协议兜底。更妙的是:随着规范支持的客户端越来越多,你那台老服务器会自动变强——什么新东西都不用额外写。

写在最后

回到开头的问题:前端工程师真的”死”了吗?

没有。但”只懂前端”的工程师,确实在被淘汰。

AI 不是来抢饭碗的,是来重新定义饭碗的。MCP 也不是来杀死谁的,它是来给智能体铺路的。

如果你想在这个时代活下去、活得更好,方向很清晰:

从”写代码的人”变成“用 AI 写代码的人”

从”只懂前端”变成“懂业务、懂架构、懂 AI 工具链”

从”被 MCP 吓到”变成“会写 MCP 服务器的人”

3 亿的月下载量摆在那里,MCP 生态还在加速,你是想继续当那个”被淘汰的人”,还是成为”让 AI 替你干活的人”?

作者:Tiger / 公众号:TechLifeExplorer