MCP 2.0 无状态架构：AI 工具调用从玄学回归工程
最近 AI 圈有个很值得关注的信号：Anthropic 主导的 MCP 协议正在从「有状态」切换到「无状态」架构。这个变化看起来是工程优化，但背后折射出的问题值得我们每个开发者认真思考。
从「教 AI 做事」到「给 AI 递工具」
MCP（Model Context Protocol）本质上是一套 AI 与外部工具之间的通信契约。1.0 时代，你需要维护 Session 状态，两次 HTTP 交互才能完成一次工具调用。2.0 直接砍掉服务器端 Session 维护，变成纯粹的单次请求-响应。
这意味着什么？企业级部署的复杂度骤降。以前你要操心 Session 过期、会话状态同步、分布式 Session 一致性……现在统统不需要了。
Skills 和 MCP 的博弈：上下文污染才是真正的敌人
最近开发者社区有个争论：Skills（基于提示词的技能）和 MCP 到底谁更好？
支持 Skills 的人说：轻量，用自然语言描述就能让 AI 理解新技能。
反对的人说：Skills 本质上是把业务逻辑塞进 Context Window，模型容易在模糊意图里跑偏。
我自己站后者。核心问题不是 Token 数量，而是「想法密度」——十个模糊的技能描述，可能比三万字的 API 文档更让 AI 迷失。MCP 这种硬核工具链提供的是确定性和可审计性，你调用了什么工具、返回了什么结果，全都清清楚楚。
OpenAI 和 Anthropic 已经在客户端侧实现了按需加载工具，从工程上解决了全量加载导致的上下文爆炸。这说明头部玩家已经用行动投票了。
无状态 MCP 为什么重要
无状态 MCP 的普及，标志着 AI 应用开发正在从「玄学调 Prompt」回归到「正经 RPC 工程」。这对开发者来说是好事——你可以用熟悉的工具链、熟悉的调试方法、熟悉的监控手段来构建 AI 应用，而不是在一堆模糊的自然语言描述里碰运气。
如果你在搞 AI Agent 或者想给自己的应用接入大模型能力，MCP 2.0 值得关注。官方 reference servers 已经覆盖了文件系统、GitHub、Google Drive、PostgreSQL 这些常见场景，拿来就能用。
总结
MCP 2.0 无状态架构不只是一个协议升级，它代表了一种认知转变：让 AI 获得能力，靠的是精确的 API 契约而不是模糊的提示词描述。这个方向，值得押注。
GitHub – Model Context Protocol Servers
评论区
登录后可评论。