为什么 MCP 从一开始就是个坏主意 最近我参加了一个为期一天的活动，主题围绕 MCP 世界的最新进展。虽然所有演讲者都很棒，且对他们的工作充满热情，但我实在对 MCP 感到厌倦。这是一个为 LLM 尚不聪明的时代设计的糟糕协议，而我们早已超越了它。

简史

MCP 于 2024 年 11 月由 Anthropic 团队发布，作为一种协议，旨在帮助智能体连接到外部服务和数据源。当时的模型与现在相比仍相对原始。我们甚至还没有 Claude Code，通用智能体工作流的可靠性也远低于现在。用户开始意识到给 AI 模型提供外部服务访问权限的用处。这实现了我们以前未曾见过的生产力水平。我们见证了 MCP 采用的爆发式增长，这与整个经济中 LLM 采用的类似甚至更剧烈的爆发式增长同时发生。随着时间的推移，MCP 在 Anthropic 的管理下持续演进，最终于 2025 年捐赠给 Linux 基金会下的 Agentic AI Foundation。

MCP 产业复合体

随着采用量的巨大增长，用户开始在其设置中添加许多 MCP 服务器，并开始遇到上下文膨胀问题。每个服务器都带有多个工具，每个工具都有自己的模式，这开始使所有这些模型的上下文过载。开发者找到了许多应对技巧，包括 Composio、Mint MCP 和 Pipedream 等平台现在提供的通用搜索/执行模式。它们都有效地解决了将各种外部服务的凭证放在一个地方，并给智能体提供一组最小工具（以减少上下文膨胀）来访问它们的问题。我想明确指出，短期内这是件好事。

随着我们围绕 MCP 构建的所有东西，我们没有考虑到，或者可能忽略了，模型正在变得更好。我们现在有专门的系统来监控 MCP 服务器，确保响应良好，确保智能体能轻松访问工具，弄清模式，并确定我们需要给智能体什么，以便它们能在正确的时间做出正确的调用。

惊喜，惊喜，大实验室是对的

模型变得更好了。它们现在能在计算机上执行代码、推理大型代码库，并总体上比以往任何时候都更自主地行动。这项工作的很大一部分是为编码目的编写/运行脚本。一个副作用（虽然算副作用吗？）是它们现在擅长直接调用 API。它们可以编写脚本、组合多个不同服务，并调用从未见过的 API，所有这些都在用户极少干预的有用工作流中完成。

LLM 在这方面变得如此之好，以至于 Cloudflare 甚至推出了 Code Mode，一种通过让 LLM 将各种调用组合成可在沙箱中执行的脚本来更好地使用 MCP 的方式。但甚至比这更好的是，LLM 已经弄清了如何使用 --help 命令来发现 CLI，因此它们不再需要 MCP 服务器来访问许多通过文档化 API 或 CLI 可用的服务。大多数远程服务 MCP 服务器最终包装的都是已存在的 API。

现在怎么办？

我们删除大多数 MCP 服务器。就是这样。拥有终端访问权限的智能体可以替代大多数 MCP 服务器，且通常更强大。

仍有一些问题，比如 CLI 返回机器可读响应（JSON/XML 等），往往非常冗长且消耗大量 token，但我们有办法解决这个问题。许多替代方案已经存在：文档化的 HTTP API、标准内容协商和成熟的认证机制。我们应该开始标准化智能体如何直接使用 HTTP API。例如，智能体客户端可以附加标头来标识自己为智能体，服务器可以自动向它们发送 Markdown 或文本格式的响应数据，而不是 HTML 或……