MCP Server 发生能力漂移后，用户原有设置还能否继续匹配目标能力？

作者：袖梨 2026-09-16

MCP Server 发生能力漂移后，用户原有设置不应简单按工具名称继续匹配，也不应被直接删除。系统需要分别保存“用户想管理的逻辑能力”和“当前观察到的具体定义版本”。名称或来源不变但 Schema、描述、annotations 改变时，保留用户意图，暂时从有效能力面移除该版本，审查通过后再原子发布。

长期设置与调用时确认是不同问题

如果客户端每次只使用当下发现的目录，不保存工具级选择，并在调用前重新确认，那么能力改变可以按普通重新发现处理。复杂问题出现在 Profile、allow/ask/deny、直接暴露清单等设置要跨会话长期保留时。

这类设置表达的是：“将来这个能力再次出现时，怎样处理它？” Server 升级后工具可能改名、删除、合并、重新出现，甚至同名但 Schema 与风险属性已变。系统必须判断旧设置指向的逻辑对象是否还存在，以及旧决定能否覆盖新定义。

单独使用名称会产生两类错误

严格按名称匹配时，工具重命名会让设置立即失效，用户必须手工重建。反过来，同名工具可以改变 description、inputSchema 或副作用，却静默继承旧 allow 规则。

名称适合当前路由，不适合同时承担长期身份和定义版本。资源 URI、Prompt 名称也有相同问题：它们可以定位当前对象，却不能证明内容与旧设置审查时完全一致。

别把“逻辑连续”误认为“定义相同”

Server 提供旧名到新名的 alias，是维护者认为两个能力有延续关系的证据，但不代表契约相同。重命名同时可能删除参数、改变输出或扩大副作用。系统可用 alias 建议迁移，却仍要比较定义并决定是否重新审查。

多对一合并更危险。四个旧工具合并为一个通用工具时，允许其中一个旧工具不应自动等于允许新工具的全部能力。拆分同样不能把旧批准无条件复制给所有新工具。

把逻辑引用与内容身份分开

可以为每项长期设置保存 CapabilityRef，表示稳定 Server 身份、能力类型和原始定位键形成的逻辑关系。另用 CapabilityId 表示规范化后的有效定义内容，包括来源、路由、名称、描述、Schema 和安全 annotations 的不可变摘要。

CapabilityRef:
  serverIdentity + kind + originKey

CapabilityId:
  hash(canonicalEffectiveDefinition)

ProfileSelection:
  capabilityRef + policy

ObservedVersion:
  capabilityRef -> capabilityId

定义变化时 Ref 可以保持，表示用户仍然关心同一逻辑能力；Id 必须变化，表示不能把旧审查结果当作新内容已获批准。

Server 身份不能只用 serverInfo.name

`serverInfo` 由 Server 自报，主要适合显示、日志和调试，不能独立作为安全信任根。不同 Server 可能使用同名，远程 endpoint 也可能迁移。

稳定身份应组合受信发布者或 Registry namespace、固定 endpoint 或制品来源、组织配置 ID、认证受众和其他可验证信息。身份证据不足时，跨 Server 自动迁移设置应默认禁止。

用 Manifest 描述某个消费者看到的完整能力面

单个能力版本确定后，还需要回答某个 Agent、Profile 或 host 此刻究竟能看到哪些能力。SurfaceManifest 可以保存一组精确 CapabilityId，Publication 则把消费者原子绑定到一个 Manifest。

更新时构造完整新 Manifest，校验通过后一次替换旧版本。不能先加入新工具、稍后删除旧工具，让消费者在中间状态同时看到两个世代。原子发布只保证单次切换完整，不保证 Server 已删除的旧实现还能继续调用。

安全收缩：保留意图，暂时撤下能力

当同一逻辑能力出现新定义且需要审查时，系统不能继续假装旧定义仍可执行，也不能把新定义直接放进 Agent。更安全的动作是发布 Safe Contraction：从受影响消费者的能力面暂时移除该能力，同时保留 Profile 中的逻辑关系与历史决定。

用户批准后，新 CapabilityId 进入下一版 Manifest；拒绝后关系仍保留，但新定义不发布。这样既不丢失用户原意，也不让未经审查的新能力继承权限。

何时可以自动 follow

若重复观察到的有效定义摘要完全相同，仅时间戳等非模型可见元数据变化，可直接保持当前发布。组织还可以定义低风险 follow 策略，例如经过受信发布渠道、只读 annotations 未改变且 Schema 兼容的小版本。

自动 follow 必须是明确策略，不是“名称相同就跟随”。策略要绑定消费者与风险级别；一个只读分析 Agent 可接受的自动更新，不一定适用于拥有生产写权限的 Agent。

哪些变化默认进入 review

description、title 或模型可见 icon 变化会影响选择与理解，应创建新 Id 并审查。inputSchema、outputSchema、Prompt 参数或资源元数据变化会改变调用或消费契约，也应审查。

read-only、destructive、安全和执行语义 annotations 变化直接影响风险评估，必须审查。系统展示字段级 diff、受影响消费者和变化来源，而不是只给出一个摘要不一致提示。

Origin Key 变化应采用手动重绑定

名称、URI 或 URI template 改变时，原定位键已经失效。除非有可信 alias 或迁移声明，内容相似不足以证明是同一逻辑能力。系统可提出候选，但只允许用户手动 rebind。

重绑定后建立新的 Ref 与定义版本，并保留旧关系的审计历史。不能用文本相似度自动把已允许的删除工具迁移到一个更强的新工具。

完整盘点才能证明能力消失

只有成功完成对应能力类型全部分页的完整 inventory，才有权判断旧 Ref 已消失。连接失败、鉴权异常、单页超时或 incomplete list 只能说明本次证据不足，不能把旧设置标为删除。

失败观察记录为 operational failure，当前 Publication 保持，必要时标记 stale。完整观察确认消失后，发布安全收缩并把 Ref 标为 unresolved。

能力重新出现时不要无条件恢复

旧 Ref 之后重新出现，可能是暂时权限恢复，也可能是同名新实现。系统复用逻辑关系以保留历史，但默认重新审查新 Id。只有显式策略允许，且定义和身份满足条件时才自动 follow。

这避免攻击者通过“删除、等待、同名重建”借回旧权限，也避免一次临时故障后丢失用户设置。

新增能力是否自动加入取决于设置语义

用户选择具体工具时，新出现的 Ref 默认不加入，因为“允许这三个工具”不包含未来新增工具。若用户明确选择“暴露整个 Server”，其意图更宽，可以把新能力作为候选，并由 Server 级 policy 决定自动加入或审查。

产品必须让这两种意图在 UI 和数据模型中可区分。用同一个 checkbox 同时表达精确选择和动态全量暴露，会造成无法解释的权限继承。

TTL 与 listChanged 只解决新鲜度

缓存 TTL、版本标识和列表变化通知帮助客户端知道何时重新获取目录。它们不决定旧 allow 规则应该迁移到哪个新工具，也不解决合并、拆分与跨 Server 移动。

同样，Registry 的发布者 namespace 与 Server 版本能改善制品来源和升级边界，但不自动提供能力级稳定身份和演化关系。发现机制与管理意图迁移是两个层次。

一个推荐的变更处理流水线

observe complete capability inventory
  -> record before and after definitions
  -> resolve logical Ref evidence
  -> compute immutable CapabilityId
  -> classify change
  -> follow | review | manual_rebind
  -> build complete SurfaceManifest
  -> atomically publish per consumer

所有 catalog 变化先记录再决策。重复观察且定义未变不制造噪声；风险只影响实际使用该能力的消费者，不必阻塞所有 Profile。