MCP已死？

# MCP 已死 | Quandri Engineering 来源: https://www.quandri.io/engineering-blog/mcp-is-dead 💡 参考: MCP 已死，CLI 万岁 (https://ejholmes.github.io/2026/02/28/mcp-is-dead-long-live-the-cli.html) 阅读上述文章后，我们在实际技术栈上进行了实验。本文档涵盖原论点、额外研究以及我们的测量结果。 📌 **更新：** 自这些测量完成以来，Claude Code 已推出支持延迟加载的工具搜索 (https://code.claude.com/docs/en/mcp)，可按需加载 MCP 工具模式，并将上下文使用量减少 85% 以上。问题 1 中描述的上下文膨胀问题对于使用当前 Claude Code 版本的用户已基本解决。以下关于性能、调试和架构的论点仍然适用。 ## MCP 的问题 MCP（模型上下文协议）将 LLM 与外部工具（GitHub、Linear、Notion、Slack 等）连接起来。 自 2024 年底推出以来，它被称为“AI 生态系统的 USB-C”。但实际每天使用它的开发者开始有不同的看法。 **TL;DR**：MCP 消耗上下文、可靠性低，且与现有的 CLI/API 功能重叠。 ### 问题 1：吞噬上下文窗口 上下文窗口是 LLM 的工作台。当你连接 MCP 服务器时，**仅工具定义**就会占据工作台的一大块。 餐厅类比： - 你坐下，10 份菜单（MCP 工具定义）摊在桌上 - 没有空间放实际食物（你的工作） - 每次点餐时，菜单都得重新拿出来 我们提取并测量了环境中实际连接的各 MCP 服务器的工具定义。**连接全部 4 个服务器后，仅工具定义就消耗了上下文窗口的 10.5%。** #### 测量：工具定义大小（Quandri 技术栈） | MCP 服务器 | 工具数 | 估算字符数 | 估算 Token 数 | |------------|--------|------------|---------------| | Linear | 42 | ~51,229 | ~12,807 | | Notion | 14 | ~16,156 | ~4,039 | | Slack | 12 | ~15,168 | ~3,792 | | Postgres | 9 | ~1,755 | ~438 | | **总计** | **77** | **~84,308** | **~21,077** | #### 上下文窗口使用量（全部服务器合并）**** | 模型 | 上下文窗口 | 工具定义使用占比 | |-----------------|---------------|------------------| | Claude (200K) | 200,000 token | 10.5% | | GPT-4o (128K) | 128,000 token | 16.5% | 仅 Linear 就占用超过 12,800 个 token。即 42 个工具定义始终加载，即使你只使用 `get_issue` 和 `save_issue`。 #### 按大小排序的最大工具 （此处应为实际图表或列表，但原文仅有一行标题，可能缺失内容。我们将按原文保留标题。） ### 问题 2：运行可靠性低 | 问题 | 详情 | |--------------------|--------------------------------------| | 初始化失败、重复重新认证 | 需要启动并维护一个独立进程 | | AI 响应变慢 | 每次工具调用都需外部服务器往返 | | 会话中工具崩溃 | MCP 服务器进程崩溃 | | 权限不透明 | 不清楚每个工具实际拥有哪些权限 | 性能是已知问题。原始文章作者对 Jira MCP 及其 REST API 进行了基准测试，发现 **MCP 每次调用慢 3 倍，首次调用（含初始化）慢 9.4 倍**。这不是 Jira 特有的问题，而是架构性的：每个 MCP 服务器都会在 LLM 与底层 API 之间增加一层进程。同样的开销也适用于我们技术栈中的 Linear、Notion 和 Slack 服务器。 ### 问题 3：与现有 CLI/API 功能重叠 | 方面 | CLI / API | MCP | |-----------------|-----------------------------------------|--------------------------------------| | 人机一致性 | 人类和 LLM 使用相同的命令 | 仅在 LLM 对话中存在 | | 可组合性 | 管道、jq、grep 可自由组合 | 锁定在服务器返回格式中 | | 调试 | 可立即在终端中复现 | 仅在对话上下文中可复现 | | 训练数据 | 已从 man 手册、StackOverflow 学习过 | 需要单独的工具定义 | | 安装成本 | 大多已安装 | 需要服务器搭建、认证、进程管理 | ### Token 对比：用 MCP 与 CLI 查找同一个 Linear Issue **查找同一个 Linear Issue 需要多少 token？** MCP 消耗的 token 大约是 CLI 方法的 65 倍。 ``` [ CLI 方法：~200 个 token ] curl -s -H "Authorization: Bearer $LINEAR_TOKEN" \ -H "Content-Type: application/json" \ -d '{"query":"{ issue(id: \"ISSUE-ID\") { title state { name } assignee { name } } }"}' \ https://api.linear.app/graphql -> 提示（curl 命令）：~50 个 token -> 响应：~150 个 token [ MCP 方法：~12,957 个 token ] -> 工具定义（始终加载）：~12,807 个 token（42 个工具） -> 工具调用 + 响应：~150 个 token ``` ``` ## 有哪些替代方案？ #### 替代方案 1：CLI 优先策略 按 CLI → API → 文档的顺序提供。LLM 已经从 man 手册和 StackOverflow 学习过。 直接使用现有 CLI： - 不浪费上下文在工具定义上 - 人类和 AI 使用相同接口，易于调试 - 可自由与管道组合 #### 替代方案 2：技能模式 如果说 MCP 是“事先把所有菜单摊在桌上”，那么技能模式则是“**只向图书管理员借你需要的书**”。 | 方面 | MCP | 技能模式 | |---------------|-----------------------------------|----------------------------------| | 加载时机 | 连接时加载所有工具定义 | 仅在需要时加载 | | 上下文消耗 | 一直占用 | 仅在使用时占用 | | 可扩展性 | 上下文压力随服务器数量增加而增大 | 与技能数量不成比例 | 关键在于将 CLI 使用说明嵌入技能中。结合替代方案 1 的 CLI 优先策略，这是最高效的方式。例如，一个 Linear 技能： ``` # Linear Issue 查找技能 - Linear API: https://api.linear.app/graphql - 认证：Bearer Token（$LINEAR_TOKEN 环境变量） - 获取 Issue：curl -s -H "Authorization: Bearer $LINEAR_TOKEN" -H "Content-Type: application/json" -d '{"query":"{ issue(id: \"ISSUE-ID\") { title state { name } assignee { name } } }"}' https://api.linear.app/graphql - 搜索 Issue（GraphQL）：调整查询字段以实现类似 JQL 的过滤 - 结果为 JSON，使用 jq 解析 ``` ``` 这样，只有当技能被调用时，LLM 才会将上述内容加载到上下文中。无需始终携带 42 个工具定义。只需它需要的 CLI 命令。 ## 那么 MCP 真的死了吗？ 并非完全如此。MCP 在以下场景中仍然有效： - **服务没有 CLI**：仅 Web 的 SaaS，MCP 可能是唯一的连接方式 - **非开发者用户**：MCP 对不使用终端的人更易上手 - **实时双向通信**：超出简单请求-响应的场景 ### 数据库呢？ 简短回答：视情况而定。 数据库归根结底只是执行查询。LLM 已经非常了解 SQL 和 MongoDB 查询。将数据库信息和 CLI 用法放入一个技能中，无需 MCP 也能正常工作。只需提供模式，它就能编写查询。 ``` # Postgres 技能 - 主机：postgres://localhost:5432/myapp - 表：users (id, name, email), orders (id, user_id, status) - CLI: psql -h localhost -d myapp -c "SELECT * FROM users WHERE ..." ``` ``` 然而，MCP 对数据库有优势： - **查询安全**：MCP 服务器可以在服务器级别强制只读模式并阻止危险查询。技能 + CLI 无法阻止 LLM 运行 `DROP TABLE`。 - **凭据保护**：CLI 方法可能会在提示中暴露连接字符串。MCP 服务器在内部管理凭据。 | 场景 | 推荐方案 | 原因 | |--------------------|--------------|--------------------------------------------------------| | 本地开发/个人数据库 | 技能 + CLI | 轻量快速，错误容易恢复 | | 生产数据库/团队共享 | MCP | 安全护栏至关重要，查询验证和访问控制在服务器级别实现 | 但对于大多数开发者工作流而言，MCP 是过度工程。 如今，每个 SaaS 着陆页的功能列表中都写着“支持 MCP”。MCP 服务器是否稳定或消耗多少上下文并不重要——目标只是勾选“我们也有 MCP”这个框。这与过去几年“AI 驱动”和“基于区块链”的营销模式如出一辙。当用户实际连接时，他们得到的是几十个加载的工具定义、初始化失败以及会话中途的崩溃。 ## Quandri 如何使用技能模式 在 Quandri，我们同时使用三种方法，为每个服务选择最合适的方案： - **Bash + CLI**：用于我们日常使用的工具（`gh`、`psql`、`aws`）。零上下文成本，完全灵活，直接在终端中调试。 - **技能模式**：用于可重复的多步骤工作流，如提交草稿和 PR 审查。仅在调用时加载。 - **MCP**：用于没有强大 CLI 的服务（Slack、Linear、Notion），以及需要团队级认证或权限范围控制的场景（如生产数据库访问）。 我们不强行采用某一种方式。如果 CLI 已经存在且能在本地进行认证，那通常是最轻量的选择。如果某个服务没有 CLI，或者我们需要团队范围内的统一认证，MCP 就有其价值。 ## 结论 **教导得当比连接一切更重要。** 对我们来说，用包装现有 CLI 的技能模式替代 MCP 服务器，释放了约 21K 的上下文 token，消除了日常工作中的初始化失败，并将调试保持在终端中——它本应属于那里。 只加载你需要的工具，只在需要时加载，并内嵌 CLI 指令。MCP 可能会不断演进来解决这些问题，但就目前而言，技能模式更胜一筹。 **** **** **测量方法**：工具定义大小通过从我们 Claude Code 环境中实际加载的 MCP 服务器中提取每个工具（名称 + 描述 + 参数）的 JSON 模式进行测量。Token 估算使用约 4 字符/token 的经验法则。完整服务器估算是从采样工具平均值外推得出的。