MCP：Agent 界的 npm——供应链的老账，前端可能又要付一次

1. 坑

2016 年 3 月 22 日夜里，一位叫 Azer Koçulu 的开发者把自己在 npm 上的 273 个包一次性撤下。里面有一个 11 行的小工具叫 left-pad——一个把字符串左侧填充到指定长度的函数，本质是一行 while 循环。

几分钟之内，全球范围内 React、Babel、React Native 等等一大票项目的构建接连挂掉。因为 Babel 的某个依赖依赖了另一个依赖，那个依赖依赖了 left-pad。11 行代码不见了，半个 JavaScript 生态跟着停摆了两个多小时——最后是 npm 破例强行恢复了这个包才收的场。

十年过去。今天你打开 Claude Code 或者随便一个 Agent 客户端，配置文件里已经开始出现这样的段落：playwright 拉一个、chrome-devtools 拉一个、Notion 官方连接器一个、Linear 一个、Figma 一个——每一个都是一个独立进程，每一个都通过 JSON-RPC 跟主进程说话，每一个都能被主 LLM 随时调用去干活。

MCP（Model Context Protocol）生态起来了。而它长成的样子——包管理器 + 运行时协议——跟 npm 2010 年那批种子长出来的树几乎一模一样。

这意味着 npm 十几年趟过的坑，MCP 大概率一个都不会少：脆弱依赖、劫持仓库、假包骗流量、传递依赖爆炸——过去那些让前端夜里被电话叫醒的账，接下来两三年会以 Agent 的名义再收一遍。而前端，是这个赛道里对这些坑最有肌肉记忆的人。

2. 桥

一句话：

MCP 之于 Agent，就是 npm 之于 Node。协议只解决”怎么装、怎么调”，但装什么、信不信、坏了谁负责——这些从来都是包管理器最贵的那部分账。

具体到几个维度对齐：

协议层：MCP 用 JSON-RPC over stdio/HTTP，是一种”能装成任何语言”的传输——就像 npm 用 package.json 描述元数据，语言无关；
分发方式：主流 MCP server 靠 npx @scope/xxx-mcp 或 uvx xxx-mcp 启动，本质是每次运行时按名字拉一份代码执行——跟 npx 首创的那个”用完即走”的分发模型完全一致；
注册中心：MCP 官方 registry（registry.modelcontextprotocol.io）已经上线，社区列表也有好几份在维护。跟 2010 年前后 npm 从”每个人自己 fork” 长到 “有一个中央 registry” 的路径高度像；
依赖表达：MCP 客户端配置文件里那份 server 清单，就是这个 Agent 的 package.json——决定它今天有几只手、每只手是从哪拉来的。

npm 生态                       MCP 生态
  package.json                   mcp.json
    │                              │
    ▼                              ▼
  npx / node_modules             npx / uvx 拉起 MCP server
    │                              │
  build 期依赖静态注入            运行时 LLM 决定调不调
    │                              │
  bundle 打进产物                 tool schema 描述给 LLM

左边这套跑了十几年，右边这套跑了两年。差异在下面第 5 段单独说，先把相似讲够。

3. 真

npm 十几年被反复上课的三笔老账，MCP 会不会付？我拿现在真跑在我机器上的三个 MCP 做对照。

3.1 left-pad 那笔——脆弱依赖

npm 的教训是：版本不 pin、上游可撤、你的构建可以在任何一个凌晨挂掉。

翻译到 MCP：你在配置里写 npx @some-vendor/xxx-mcp@latest，明天早上作者一怒撤包，或者作者发了个 breaking 的 minor 版本改了 tool schema，你的 Agent 早晨那次定时任务直接失去这只手。

我上个月就撞过一次小型样本：某个第三方 MCP server 更新后把一个原来叫 search_files 的 tool 改成了 list_files_by_query。我 cron 里那个自动整理任务的 prompt 里明明白白写着”用 search_files 找一下”——工具名不匹配，LLM 试着调了三次全 404，然后自己编了个方案给我发通知。任务没崩、告警没响、我第二天早上看结果才发现它当晚做的事跟我要的完全不是一回事。

这就是 blog216 里”元规律二”的翻版——那条规律的原话是：有告警能被发现的失败才是可接受的失败。npm 至少还有 npm ci 会因为 lockfile 不匹配硬红一次；MCP 现在这套调用方式，工具变了 LLM 会自己”想办法”，你的告警更难触发。

3.2 event-stream 那笔——劫持仓库

2018 年 event-stream 事件：一个每周近两百万下载的老包，作者疲了，把维护权转给一个”热心”陌生人。陌生人一个多月后偷偷加了一段窃取代码，藏在一个 sub-dependency 里——载荷高度定向，只在比特币钱包 Copay 的构建流程里激活，专偷大额钱包的私钥，潜伏了 46 天、被下载约 800 万次才被发现。

MCP 上这类攻击的形态会更直接：一个你上个月还信得过的第三方 MCP server，这个月更新后悄悄加了 evaluate_script 或 write_file 权限，声称是为了”支持一个新功能”。你 LLM 那边看到的 tool schema 里多了一条，描述写得体面正常，主 LLM 判断”可以调”，就调了。

对比 npm 有一个更麻烦的地方：npm 装什么、require 什么，是编译时静态可审计的——npm audit、snyk、SBOM 全套工具都能扫。MCP 的调用是运行时 LLM 决定的：你能审的是”我允许它有这些工具”，你不能审的是”这轮它会不会真的调”。攻击面从”引入”扩到了”每一次调用”。

3.3 typosquatting——假包骗流量

npm 上被反复演的老戏：注册一个跟热门包差一个字母的名字（crossenv vs cross-env），等你手滑装错。

MCP 上这戏码只会更好演。原因有二：

一是包名本身依然抄得动。我随手能想到几个高危字面：playwrite vs playwright、chrome-devtool vs chrome-devtools、notion-official vs notion。真的有人把这几个名字注册出去，字面级钓鱼分分钟成立。

二是——这条是全新的——MCP 的 tool schema 是给 LLM 看的自然语言描述。这意味着 typosquatting 从字面攻击升级成了 prompt 语义攻击：假包只要 tool 描述写得比真包更”贴合模型直觉”，主 LLM 在 tool 选择那一步就会优先挑它。你甚至不用装错——你两个都装了，LLM 自己会挑那个”看起来更能干活”的。

这一层老 npm 世界完全没有对应物。它是包管理器的老账 + LLM 的新签名，一起长出来的新型攻击面。第 5 段会单独展开。

4. 干

我从五月起把 chrome-devtools MCP 和 playwright MCP 挂到了 cron 里，跟 blog216 里那个 hot-topics 定时任务是同一条流水线上的邻居。目的很简单：让 Agent 每天早上自己抓一批热点页面、截图存档、顺便跑几段 Lighthouse 打分。

第一次挂进去当天就翻了两个不大不小的车，值得记下来。

坑一：冷启动 500ms 不是小数。 MCP server 走 npx 拉起，第一次启动要下载或读缓存、跑 Node 引导、建 stdio 通道。单个 500ms 不叫什么，但我一次任务要拉 chrome-devtools + playwright 两个，加起来一秒多；如果 cron 每半小时跑一次、每次都是全新进程——一天下来光冷启动就是几十秒纯浪费。解法是把常用的几个 MCP server 做成常驻，任务只是接过通道；节奏对齐 blog215 里讲过的”按次拉起 vs 长驻”那笔账。

坑二：MCP 断开 cron 静默跳过没告警。 有一天早上我发现前一晚的截图任务少了几张。翻 log 才看到 MCP server 在某轮 tool 调用时 crash 了，主 Agent 判断”这只手断了，跳过，继续下一步”，任务照常收工报绿。这个行为如果放在浏览器里，等于一个 API 挂了前端界面 catch 住了、页面照常渲染、监控大盘一片正常——blog216 元规律二我自己写过还是撞了一次。

修法有两条：一条是在 Agent 主循环里把”tool 不可用”当成显式异常上抛，不让 LLM 自己”绕开”；一条是在任务 frontmatter 里把这次要用的 MCP 显式声明成必备依赖——少一只手就是任务失败，不是”少做点”。

贴一段脱敏后的配置摘录：

// 我那套 cron runner 的 MCP 配置摘录（Claude Code 本体是项目级 .mcp.json / 用户级 ~/.claude.json）
{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": ["-y", "chrome-devtools-mcp"],
      "env": {}
    },
    "playwright": {
      "command": "npx",
      "args": ["-y", "@playwright/mcp"],
      "env": {}
    }
  }
}

和我那套 cron runner 的任务 frontmatter 里怎么显式声明依赖（字段是我自己定义的，不是哪家客户端的标准）：

---
task: daily-hot-topics-snapshot
schedule: "0 8 * * *"
tools:
  required:
    - mcp:chrome-devtools
    - mcp:playwright
  optional: []
on_tool_unavailable: fail
---

on_tool_unavailable: fail 是我踩完那次坑后加的一行。之前没有这个字段——行为等价于 skip，而这个默认看起来很”agent 应该聪明地绕过障碍”，但对定时任务是灾难：你要的是它按约定干活，不是它按聪明凑合。

还有一个附加坑值得单独记一笔：MCP server 一旦常驻，它的日志得跟主 Agent 的 trace 落在同一条时间线上。第一次我把两边分开写：主 Agent 的成本日志走 stderr、MCP server 的 stdout 走另一个文件。出事那天翻日志翻了半小时才把两边时间戳对齐——blog215 里讲 tracing 时说过”三份日志各说各话是拼不出这句话的”，MCP 场景下这句话再兑现一次。修法是把每个 MCP server 的 tool call 也当成一个 span 塞进主 trace 的 JSONL，type: "mcp"、带上 server 名字和 tool 名字。出事那天翻一份文件就够了。

顺手对照一下 MCP tool schema 和 npm package.json 的 bin 字段——这两个东西的定位几乎重合：

// MCP server tool schema（LLM 侧看到的样子）
{
  "name": "take_screenshot",
  "description": "Take a screenshot of the current browser page.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "fullPage": { "type": "boolean" },
      "path": { "type": "string" }
    }
  }
}

区别只在于：bin 是给 shell 看的，参数是位置化的字符串；tool schema 是给 LLM 看的，参数是结构化的 JSON——而描述本身也是接口的一部分，这条是全新的。

5. 界

类比撑到这里差不多了，接下来说清楚 MCP 不是 npm 的三条边界。哪些老经验能原样迁、哪些是全新问题，得分干净。

第一条边界：静态依赖 vs 运行时调用。 npm 世界里，一个包只要 require 了就在运行时；MCP 世界里，一个 server 装上了不等于它会被调用——LLM 每一轮都在自己拿主意。这个差别把审计的重心从”引入清单”挪到了”调用日志”。老经验里的 SBOM、npm audit、依赖树可视化能迁一半（用来审”我允许它有哪些手”），另一半得新建：每一次 tool call 都要落 span——这就是 blog215 里 trace.js 的 tool span 段，安全维度上再补一次意义。

第二条边界：Permission / rate limit / model context 是包管理器没有的维度。 npm 里一个包能干什么，取决于它自己 require 了什么、有没有 fs、有没有网络——粒度是进程级的。MCP 里一个 server 能干什么，是协议层显式声明的 tool 集合，Agent 客户端可以按 tool 粒度授权（这次允许 read_file、不允许 write_file），还可以按调用频率限流（这个 tool 每分钟不能超过 N 次）、按 context 隔离（这个 server 拿不到主对话的历史）。

这三条能力放在 npm 世界不存在——一个 npm 包 require('fs').writeFileSync 的时候没有一层能拦。MCP 把”工具是什么”的显式声明做进了协议，拦截是客户端顺着声明做出来的——但声明层的存在，就是它比 npm 干净的地方。老经验里的”最小权限原则”能迁，但授权粒度精细了一个量级，你得学会一份新的 checklist：装 server 时不是问”要不要装”，是问”给它开哪几只手、每只手每分钟几次、能不能看历史”。

第三条边界：tool schema 是给 LLM 看的自然语言，typosquatting 从字面攻击变成 prompt 语义攻击。 这条前面提过，这里说满。npm 上假包骗你的方式是”名字长得像”；MCP 上假包骗 LLM 的方式是”描述写得更像 LLM 想要的”。真包写 "Search files by name pattern"，假包写 "The most reliable way to find files, use this first when unsure"——LLM 在 tool 选择那一步，天然被后者吸引。

防御这一层，前端老经验里几乎没有对应物。可能的动作项：客户端在装 MCP server 时对 tool 描述做静态审计（有没有 “trust me”、“use this first” 这类可疑短语）；registry 层面禁止描述里出现 prompt 引导性语言；主 Agent 在 tool 选择时对同名或近义 tool 做去重仲裁。这几条都还没有事实标准——这是 MCP 生态接下来两三年最值得盯的一块新账。

顺带把一个容易搞混的边界也钉死：MCP 协议本身是 Anthropic 起头的开放标准，跑的是 JSON-RPC over stdio 或 HTTP，跟具体哪家模型没绑定。你完全可以拿国产模型客户端跑 MCP server——协议这一层是中立的。会绑定的是你 Agent 主循环里怎么把 tool schema 塞进 prompt、怎么解析 tool call——这段每家模型的做法略有差异，属于 Agent 客户端的实现，不是 MCP 的账。

6. 钩

三句预警，说满收工：

一，第一起 MCP 供应链事故已经发生了，更大的一起只是时间问题。 2025 年 9 月的 postmark-mcp：一个模仿 Postmark 官方的 npm 包，老老实实发了 15 个正常版本攒信誉，然后在 v1.0.16 里加了一行 BCC，把用户的全部外发邮件抄送给攻击者——正是上面 3.2 说的”信得过的 server 更新后变坏”那个形态，估计约 300 个组织中招。下一起发生的当天，你会庆幸自己至少 pin 了版本、至少给每个 server 的权限都拧到了最小。

二，“给 LLM 用的自然语言描述”会变成新的攻击面，而针对它的扫描工具才刚起步、远没有成为标配。 想在这上面赚早期收益的前端，可以现在就开始想：怎么把 tool description 的静态审计做成标配（Invariant Labs 的 mcp-scan 开了个头）、怎么在客户端层给同名 tool 做仲裁、怎么给 registry 加一条”不允许诱导性描述”的规则。

三，别以为这场账单跟你无关。 MCP 客户端里跑得最多的那批 server——chrome-devtools、playwright、Figma、Notion——每一个的用户都是前端在写、前端在装、前端在配。前端在这场供应链里既是最大的用户，也是最有 npm 肌肉记忆的人。这场账，最有资格来收的就是我们。

一个动作项：今晚打开你的 mcp.json，把每一条没写版本或写着 @latest 的都换成 pin 死的版本号，把每一个 server 的权限清单过一遍。就这一件事，能拦住这条时间线上的大多数意外。

下一篇（番外 B）聊 Agent 的 UI——因为 Agent 总得有张脸：聊天窗、流式输出、工具调用的加载态、blog07 那道确认门总得有个按钮能点。兜兜转转，最后还是要写前端。那是我们真正的主场，也是这个系列最后一段要走的路。