MCP Sampling 为什么不该继续扩张：模型责任、上下文过滤与兼容验收

维护 MCP Server 的时候，如果日志里还出现 sampling/createMessage，先别急着删掉对应接口：MCP 2026-07-28 版本规范已经把 Sampling 标记为弃用，旧能力仍保留完整过渡期。你真正要做的，是把“服务端借客户端模型完成一次生成”的逻辑从新功能入口里移出去，同时给已经接入的存量连接安排好兼容和回归边界校验。

先看清 Sampling 以前解决了什么

旧版 MCP 允许服务端在处理单次客户端请求时，向客户端发起 sampling/createMessage，让客户端代为选择模型、发起生成请求，再把结果回传给服务端。这套逻辑的好处是服务端不需要存储模型厂商的密钥，客户端也能自主控制模型选择，以及是否让用户确认生成动作、查看生成结果。

这条链路的核心问题从来不是“能不能正常生成内容”，而是权限归属链路的强绑定：服务端提出消息内容和模型偏好，客户端决定是否放行、用哪个模型执行，以及要不要让用户查看请求和结果。只要这几个动作仍然依赖一条全程保持打开的长请求流，后续部署到网关、队列或者无状态实例的时候，麻烦会非常多。

2026-07-28 规范变了什么

2026-07-28 版本把 Roots、Sampling 和 Logging 三个能力标记为弃用。官方发布说明同时明确：这些能力在过渡期内完全可用，至少会保留十二个月，真正下线还需要后续的正式规范迭代。所以线上的旧客户端不能只看到字段里的deprecated标记，就直接切断对应链路。

对正在开发新代码的开发者来说，更重要的信号是官方给出的替代方向：Sampling 能力建议改成由服务端直接集成模型提供商 API；需要把上下文输入带入一次工具调用时，优先使用工具参数、资源 URI 或者服务端侧配置；跨无状态请求的交互需求，则转向带有 input_required 和 inputResponses 的多轮模式。

迁移时先拆掉哪一层

可以把旧的 Sampling 调用拆成三层：业务层判断要不要触发生成，协议层负责发送 Sampling 请求，模型层完全由客户端代管。迁移不是简单把 JSON-RPC 的方法名换成另一个，而是把模型层的责任重新放回一个完全可观测的服务边界里。

{
  "method": "sampling/createMessage",
  "params": {
    "messages": [{"role": "user", "content": {"type": "text", "text": "整理这次工具调用的结果"}}],
    "maxTokens": 300,
    "includeContext": "thisServer"
  }
}

这些请求要逐项盘点校验：哪些文本来自用户输入，哪些内容来自关联资源，includeContext 有没有超出预设的数据范围，生成请求被拒绝后业务是否还能返回用户可读懂的结果。迁移到直连 API 之后，这些校验逻辑不能直接删掉，只是从 MCP 客户端的确认界面，转移到服务端的授权、审计和数据过滤模块里。

直连模型 API 的最小落地边界

新的实现方案可以让 MCP 工具只返回结构化的事实数据，把摘要生成、内容分类或者任务规划这类能力，交给服务端自己维护的模型适配器处理。适配器至少要包含模型白名单、请求超时控制、最大输入长度限制、调用费用统计和失败降级逻辑；不要让工具参数直接拼接成一段完全不可追踪的系统指令。

tool result -> context filter -> model adapter -> JSON schema check -> user-visible result

这套方案的好处是调用链路更直接：服务端能明确知道是哪次工具调用触发了模型请求，也能在数据落库之前清理掉密钥、个人信息和不必要的原始资源内容。需要额外付出的成本是服务端要自己管理模型密钥、不同供应商的接口差异和限流规则，这些运维成本应当在迁移评审环节明确记录下来。

MRTR 适合解决哪类跨请求问题

如果工具处理到一半需要用户补充额外信息，旧的实现方式可能依赖服务端向客户端发起额外请求，同时全程保持长连接流。2026-07-28 规范介绍的 MRTR 能力，允许服务端直接返回 resultType: input_required，客户端补齐 inputResponses 之后直接重试最开始的原始调用即可。

这不代表所有 Sampling 场景都要机械替换成 MRTR 逻辑。模型生成环节仍然由服务端直连的 API 负责；只有“工具执行中途需要用户输入、确认或者下一步动作”这类场景，才把中断状态建模成可恢复的业务状态。两类逻辑职责完全不同，混在一起会让重试机制和审计链路变得非常模糊。

一份可执行的迁移验收清单

• 能力协商：旧连接声明 sampling 时，适配层仍能正常识别并记录对应版本信息。
• 安全边界：发起模型请求前自动过滤用户隐私、密钥和不必要的 includeContext 内容。
• 失败路径：用户主动拒绝、模型超时、供应商限流和返回 JSON 格式不合规时，都有明确的预设业务返回。
• 跨请求：需要补充用户输入时，验证 input_required、inputResponses 的幂等键和过期时间是否正常生效。
• 观测能力：能按工具调用 ID 关联对应的模型耗时、令牌用量、供应商响应内容和最终返回结果。

常见问题

MCP Sampling 是不是 2026-07-28 就不能用了？

不是。它只是被标记为弃用，旧能力仍有完整的兼容过渡期；新功能不应该继续把它当作长期依赖的基础能力。

为什么推荐直连模型 API？

服务端可以统一管理模型选择、密钥、审计、超时和费用统计，也更容易在无状态部署环境里完整追踪一次工具调用的全链路。

MRTR 能完全替代 Sampling 吗？

不能直接画等号。MRTR 主要解决跨请求的输入和交互需求，模型生成本身仍然需要按照业务实际需求接入合适的模型 API。

已经上线的 MCP Server 现在应该立刻全部重写吗？

先统计现有 Sampling 的调用量和存量客户端版本，保留原有兼容适配层，再给新接入的路径增加灰度和回归校验；没有明确的调用量统计支撑的前提下，不建议盲目一次性全量切换。

把弃用变成可控的迁移窗口

这次变更的核心不是要大家死记硬背一个废弃接口，而是重新划清模型调用、用户确认和工具交互三者之间的责任边界。旧 Sampling 链路先保持稳定兼容，新功能改走直连模型 API 的路径，需要跨请求的交互场景再用可恢复的输入状态处理，迁移就能从一次大改拆成多组可观测、可回退的小范围变更。