本文深入分析 MCP 能力漂移及其对用户持久管理意图的影响，提出分层模型与 follow/review 策略以保留逻辑关系而非盲目继承旧设置。
📝 详细摘要
文章围绕 Model Context Protocol（MCP）中的能力漂移（Capability Drift）展开，首先定义了六种漂移类型：发现漂移、命名漂移、契约漂移、暴露漂移、投影漂移和行为漂移，并说明这些变化如何导致用户之前保存的 Profile、Direct Exposure 等设置失效或产生歧义。接着通过对 exa-labs/exa-mcp-server 一年内的代码变更进行案例研究，展示了默认能力面收缩、改名伴随契约变化、Prompt 删除、多个 Tool 合并等具体表现。文章进一步探讨了仅依赖名称、固定 ID、哈希或 Server 版本无法同时解决逻辑身份与定义版本的问题，提出了一种分层模型：CapabilityRef（持久逻辑关系）、CapabilityId（不可变内容身份）、SurfaceManifest（面向使用方的能力面清单）和 Publication（原子绑定），并配套 follow、review、manual_rebind 等更新策略，以在保留用户管理意图的同时安全处理能力变化。最后考察了生态中已有的应对方案（如 GitHub MCP Server 的别名机制、Context7 的空列表处理），指出 MCP 官方规范仍未提供跨版本稳定能力 ID 和使用方级发布生命周期，因而问题仍需由宿主应用或网关自行解决。全文结构清晰、引用丰富、理论与实践结合，为构建能够长期保存用户意图的 MCP 网关或宿主应用提供了系统性思路。
💡 主要观点
- 能力漂移包括六种类型，直接影响用户持久设置的有效性。 文章系统归纳了发现、命名、契约、暴露、投影、行为六种漂移，说明每种都可能导致之前保存的能力选择失效或产生歧义。
💬 文章金句
- 保留用户意图，不等于保留一个已经不可执行的旧版本。
- 名称格式、前缀和命名空间主要处理语法、路由与冲突；语义版本表达维护者预期的兼容性；摘要和 schemaHash 固定或比较某一份能力定义。控制系统仍需要决定：旧管理意图是否关联到新的逻辑对象、新定义是否需要审查，以及哪个精确定义版本进入哪个使用方当前生效的能力面。
- 对任何需要长期保存用户管理意图的宿主应用或网关来说，能力名称不足以同时承担逻辑身份和定义版本两种职责。Server 提供的别名、版本与摘要都很重要，但它们不能替控制系统决定：旧关系是否延续、新定义是否需要审查，以及哪个精确版本可以进入某个使用方当前生效的能力面。
- 只使用名称可以完成当前路由和调用，但改名会断开关系，名称不变的契约变化又可能静默继承旧决定；只使用固定 ID 可以表达逻辑连续性，但内容改变而 ID 不变时，新定义可能无提示继承旧设置；只使用哈希可以精确检测定义变化，但每次变化都会成为全新对象，长期关系随之丢失；只使用 Server 版本可以给整个 Server 一个发布边界，却难以表达能力级、使用方级和随授权变化的能力面。
- 能力漂移不仅限于 Tool ，如果宿主应用或网关保存的是 Prompt 选择，同样会遇到关系是否保留、缺失如何表达的问题。
📊 文章信息
AI 初评：88
来源：V2EX
作者：Loocor
分类：人工智能
语言：中文
阅读时间：29 分钟
字数：7042
标签： MCP 协议, API 设计, 系统设计, 开源项目, 云原生 / DevOps