MCP是如何走下神坛的？

        2024 年 11 月，Anthropic 发布"模型上下文协议（MCP）"，几乎所有 AI 开发者社区都在讨论这件事。

        MCP的设计之初就是要成为大模型和外部工具之间通信的"通用标准"，有点像当年 HTTP 对 Web 的意义。一时间，MCP server 满天飞，各种集成教程、开源实现层出不穷。

但现在为啥没有热度了？

一句话总结：MCP 的核心矛盾就是"工具发现"和"上下文预算"之间的冲突——Agent 要先知道有什么工具才能决定用什么，但光是列工具清单就占了一大块 context window。

---

        MCP 的工作方式是，把工具的名称、描述、参数结构（Schema）以及使用示例，全部注入到 Agent 的上下文窗口里。Agent 读完这些信息，再决定要调用哪个工具。

        这个设计在工具数量少时还可以接受。但你一旦接入 10 个服务，每个服务有 5 个工具，光是工具定义本身就已经烧掉了几千个 token。Agent 还没开始干活，上下文就已经塞满了一半。

        上下文窗口是 Agent 最宝贵的资源，它决定了 Agent 能看见多少对话历史，能保留多少工作记忆，能有多大的推理空间。MCP 的代价，是把这个资源拿来"列菜单"。        

---

面对这个问题，现有的出路只有三条：

• 一次性加载所有工具，接受推理性能下降
• 限制接入工具数量，接受 Agent 能力边界收窄
• 构建动态工具加载机制，接受额外的延迟和复杂度

---

        除此之外，日常使用中的痛点也不少。MCP server 启动失败是家常便饭，有时重试能解决，有时必须推倒重来。接入多个服务就要在每个服务上重新认证一遍。权限管理也只有"允许"和"不允许"两档，没有办法把某个工具限制为只读，也没有办法约束它可以传什么参数。