MCP 已死？Quandri 工程师的深度实测与反思

背景

Model Context Protocol (MCP) 自 2024 年底推出以来，被业界誉为“AI 生态系统的 USB-C”，旨在通过标准化协议将大语言模型（LLM）连接到 GitHub、Linear、Notion、Slack 等外部工具。然而，随着实际开发工作的深入，开发者们开始对 MCP 的实用性产生质疑。

Quandri 后端工程师 Chloe Kim 在 Hacker News 上发布了一篇引发广泛讨论的文章《MCP Is Dead》（MCP 已死），并随后在内部进行了基于实际技术栈的实验。文章指出，MCP 存在上下文窗口消耗过大、运行可靠性低以及与现有 CLI/API 功能重叠三大问题。

值得注意的是，在本文发布后，Claude Code 推出了“延迟加载工具搜索”（Tool Search with Deferred Loading）功能，使得 MCP 工具模式按需加载，上下文使用量减少了 85% 以上，从而在很大程度上缓解了上下文膨胀问题。但本文所阐述的性能、调试及架构层面的核心论点依然具有参考价值。

核心内容

1. 上下文窗口的“吞噬者”

上下文窗口是 LLM 处理信息的“桌面”。当连接 MCP 服务器时，仅工具定义（Tool Definitions）就会占据大量空间。

• 餐厅类比：想象你坐在餐桌前，桌上铺开了 10 份菜单（MCP 工具定义），导致没有空间摆放真正的食物（你的工作内容）。而且每次点餐时，这些菜单都需要重新展开。
• 实测数据：Quandri 团队提取并测量了其环境中连接的 4 个 MCP 服务器的工具定义。结果显示，仅工具定义就消耗了 10.5% 的上下文窗口。
• 具体案例：仅 Linear 一个服务就占用了超过 12,800 个 token。这意味着即使开发者只使用 get_issue 或 save_issue 中的一个功能，其余 42 个工具定义也必须始终加载在上下文中。

2. 低下的运行可靠性

性能问题是 MCP 的固有架构缺陷，而非特定服务商的问题。

• 速度对比：原始文章作者对比了 Jira MCP 与直接调用 REST API 的性能，发现 MCP 每次调用慢 3 倍，首次调用（含初始化）慢 9.4 倍。
• 架构原因：每个 MCP 服务器都在 LLM 和底层 API 之间增加了一个进程层。这种开销同样适用于 Linear、Notion 和 Slack 等服务器。

3. 与现有 CLI/API 的功能重叠

在查询相同信息时，MCP 的 Token 消耗远高于直接使用 CLI。

• Linear 问题查询对比：
  • CLI 方法：约 200 个 Token。
    • Prompt (curl 命令): ~50 tokens
    • Response: ~150 tokens
  • MCP 方法：约 12,957 个 Token。
    • 工具定义（始终加载）: ~12,807 tokens (42 个工具)
    • 工具调用 + 响应: ~150 tokens
  • 结论：MCP 消耗的 Token 是 CLI 方法的 65 倍。

4. 替代方案：Skills + CLI

文章提出了一种更高效的替代路径：提供 CLI -> API -> 文档，并强调 LLM 已经通过 man pages 和 StackOverflow 学会了如何使用这些工具。

• 直接利用现有 CLI：
  • 不浪费上下文在工具定义上。
  • 人类和 AI 使用相同的接口，便于调试。
  • 可自由组合到管道中。
• Skills 的作用：如果 MCP 是“一次性把所有菜单铺在桌上”，那么 Skills 就是“只向图书管理员借阅你需要的那本书”。
• 实施策略：将 CLI 使用说明嵌入到 Skills 中。例如，定义一个 "Linear Issue Lookup Skill"，仅在调用时加载具体的 curl 命令和认证信息，而非加载所有 42 个工具定义。

5. MCP 是否真的“死”了？

MCP 并未完全失效，它在以下场景仍具价值：

• 无 CLI 的服务：纯 Web SaaS 服务，MCP 可能是唯一的连接方式。
• 非开发者用户：对于不使用终端的用户，MCP 更易于上手。
• 实时双向通信：超出简单请求-响应模式的复杂场景。

6. 数据库场景的特殊性

• 一般情况：LLM 擅长 SQL 和 MongoDB 查询。将数据库信息和 CLI 使用说明放入 Skills 即可，无需 MCP。
• MCP 的优势：
  • 查询安全：MCP 服务器可在服务端强制执行只读模式，阻止 DROP TABLE 等危险操作，而 Skills + CLI 难以防止 LLM 执行此类命令。
  • 凭证保护：CLI 方法可能在 Prompt 中暴露连接字符串，而 MCP 服务器可内部管理凭证。
• 结论：对于大多数开发者工作流，MCP 属于过度设计。

7. 营销泡沫与现实

当前许多 SaaS 产品将“支持 MCP”作为营销卖点，类似于多年前的“AI 驱动”或“基于区块链”。然而，当用户实际连接时，往往面临数十个工具定义加载、初始化失败和会话中途崩溃等问题。

8. Quandri 的实际应用策略

Quandri 采用混合策略，根据服务特性选择最佳方案：

• Bash + CLI：用于日常工具（如 gh, psql, aws）。零上下文成本，灵活性高，可直接在终端调试。
• Skills：用于可重复的多步工作流（如提交草稿、PR 审查）。仅在调用时加载。
• MCP：用于缺乏强大 CLI 的服务（如 Slack, Notion），或需要团队级统一认证/权限范围（如生产数据库访问）的场景。

关键要点

• 上下文效率低下：MCP 强制加载所有工具定义，导致上下文窗口被大量占用（实测中 Linear 单独占用 12,800+ tokens），严重挤压实际工作内容的空间。
• 性能瓶颈：由于增加了进程层，MCP 调用速度显著慢于直接 API 调用，首次调用延迟尤为明显。
• Token 成本高昂：在相同任务下，MCP 的 Token 消耗可达 CLI 方法的 65 倍，造成不必要的计算资源浪费。
• Skills + CLI 是更优解：通过 Skills 动态加载 CLI 指令，仅在需要时引入上下文，既保持了人类与 AI 接口的一致性，又实现了高效的调试和组合。
• MCP 仍有特定适用场景：在无 CLI 的 Web 服务、面向非开发者用户以及需要服务端安全管控（如数据库只读保护）的场景中，MCP 依然具有不可替代的价值。
• 警惕营销炒作：“支持 MCP”已成为一种营销标签，开发者应关注实际连接时的稳定性、上下文消耗和初始化成功率，而非盲目追随。
• 混合架构是趋势：Quandri 的实践表明，结合 CLI（零成本）、Skills（按需加载）和 MCP（特定场景）的混合架构，能在灵活性、效率和安全性之间取得最佳平衡。

意义与影响

这篇文章揭示了当前 AI 工具集成领域的一个核心矛盾：标准化协议的便利性 vs. 实际运行效率的损耗。

1. 对开发者的启示：在构建 AI 代理或集成工具时，不应盲目追求“全连接”。开发者应优先考虑利用现有的 CLI 和 API，通过 Skills 等机制实现按需加载，以最大化上下文窗口的利用率并降低延迟。
2. 对 MCP 协议的挑战：虽然 MCP 旨在成为通用标准，但其架构设计在上下文敏感型应用中存在固有缺陷。随着 Claude Code 等工具推出延迟加载功能，MCP 协议本身也在进化，但“按需加载”和