什么是 MCP 采样（MCP Sampling）？

工作原理

MCP Sampling 曾标准化 Server 请求 Client 侧模型生成的方式。Client 选择可用模型与 Credential，可以修改或拒绝请求，执行模型调用，并把批准后的结果返回给 Server。它不同于普通 Tool Call：Tool 要求 Server 执行操作，Sampling 则要求由 Client 控制的模型 Runtime 为 Server 操作中的子任务生成 Text、Image、Audio 或 Tool-use Content。

Sampling 自 MCP 2026-07-28 起根据 SEP-2577 进入 Deprecated。Deprecated 不等于 Removed：它会在至少十二个月的兼容窗口内继续保留，最早只能在 2027-07-28 当日或之后发布的首个 Current Revision 中移除，实际移除时间可能更晚。已有兼容实现仍可继续运行，但新实现不应再采用；规范给出的迁移路径是直接接入 LLM Provider API。

现代兼容流程使用 Multi Round-Trip Requests（MRTR），不再发送未经请求的 Server-to-Client JSON-RPC Request。Server 在处理 prompts/get、resources/read 或 tools/call 时，可以返回 resultType: "input_required"，并在 inputRequests 中放入具名 sampling/createMessage。初始 Request 在 Transport 层已经结束；Client 完成策略检查与必要的用户审查后，使用新的 JSON-RPC ID、对应的 inputResponses，以及 Server 提供时完全原样的 requestState 重试原 Method。

Sampling 是可选且受 Capability 约束的能力。支持它的 Client 必须在每个 Request 的 _meta.io.modelcontextprotocol/clientCapabilities 中声明 sampling；允许 Sampling 使用 Tool 还必须声明 sampling.tools，Server 不得请求 Client 未声明的输入。旧 includeContext 值 thisServer 与 allServers 也已 Deprecated，默认上下文包含策略应是 none。Client 策略可以修改或忽略请求中的 Context、systemPrompt、Model Hint 或生成参数。

CreateMessage Request 可以携带 user 与 assistant Message、Model Preference、System Prompt、Token 与 Sampling 参数，以及 Request-scoped Tool Definition。Model Hint 和 Cost、Speed、Intelligence Priority 只是偏好，不保证选中某个 Provider 或具体 Model。Tool-use Output 必须在下一轮模型消息前获得匹配的 Tool Result；Tool Result Message 不能混入其他 Content Type。协议结构也不能证明模型结果正确、确定、安全，或已被批准用于副作用。

Legacy 路径中，Host 与 Client 仍是策略边界。它们应展示已配置的 Server Identity、用途、Prompt、Context Destination、请求的模型类别、Token 与成本预算、Tool 和数据敏感度；允许拒绝或编辑；并在结果回传 Server 前再次审查。Human-in-the-loop 是规范中的 SHOULD，而不是每个 Client 都强制提供的保证。可信 Connection、Client Capability 或一次历史批准，都不能静默批准已经变化的 Prompt、Context、Tool、Destination 或 Budget。

Sampling 会扩大语义攻击面。恶意或被入侵的 Server 可以把 Prompt Injection 写入 user Message，请求敏感上下文，消耗模型预算，操纵模型选择，制造无界 Tool Loop，或通过生成的 Tool Call 跨越另一条信任边界。默认不提供跨 Server Ambient Context；只允许经过审核的 Server Identity 与模型目的地；提交模型前移除 Secret；限制 Byte、Token、Cost、Latency、Retry 与 Loop Iteration；校验每个 Content Block；并独立授权每次 Tool 执行。即使经过用户审阅，模型输出仍是不可信数据。

MRTR State 不授予权限。Client 必须原样回传 requestState，不得解析、修改或用于其他 Request。Server 必须将返回 State 视为攻击者可控输入；若它影响访问或业务行为，应保护完整性，并绑定 Principal、原始 Method、关键参数摘要、Policy Revision 与短 Expiry。若 Replay 可能重复副作用，还需要服务端单次消费或后端幂等保证。

迁移应先盘点每一处 sampling/createMessage 依赖及其真实用途。每条路径都要明确 Provider Credential、Billing 与 Quota、Model 与 Region Policy、Prompt 与 Retention Policy、Tool Execution、Retry 和 Incident Response 的责任人。用经过批准的 Provider Adapter 或 Model Service 替代 Client Callback；风险需要时保留用户可见同意；并在版本化测试集上比较输出质量、隐私、延迟、成本、拒绝行为与 Fallback 语义。不能推断 Server Operator、Host Vendor 或最终用户必然承担费用，MCP 不定义这种商业关系。

生产证据应记录不可变的 Server 与 Host Build、Protocol Revision、原始 Method 与 Request ID、MRTR Step、Sampling Descriptor Hash、Principal 与 Tenant、Model Provider 与精确 Model Revision、Prompt 与 Context Digest、Tool Definition、Approval 与 Policy Revision、Token Usage、Latency、Stop Reason、Cancellation、Rejection、Retry 和下游 Effect Status。日志不应保存 Provider Credential、原始 Secret、无限制 Prompt、完整私有 Context 或敏感生成内容。迁移期间要测试 Client 拒绝、Capability 缺失、畸形 Content、Model 不可用、预算耗尽、Tool Loop 终止、Request State 篡改、Replay 与重复副作用。

主要特点

• 弃用生命周期：兼容窗口内仍可运行，但新的 MCP 实现不应再采用
• MRTR 传递：`sampling/createMessage` 位于 `InputRequiredResult.inputRequests`，Client 通过独立重试提交结果
• 逐请求 Capability：基础 Sampling 需要 `sampling`，允许 Tool Use 还需要 `sampling.tools`
• Client 控制：Model Hint、System Prompt、Context、预算、请求与结果均受 Client 和用户策略约束
• 语义风险边界：Server 编写的 Message 与模型输出可能携带 Prompt Injection、数据泄漏、成本滥用或危险 Tool Proposal
• 显式迁移：直接 Provider 集成必须明确 Credential、Billing、Model Policy、Privacy、Evaluation 与运维责任

常见用途

1. 在弃用窗口内维护已有 MCP Sampling 集成，同时验证直接 Provider 路径
2. 审计哪些 Server Workflow 依赖 Client 持有的模型 Credential、Model Choice 或人工审查
3. 测试 `prompts/get`、`resources/read` 或 `tools/call` 中 Sampling 的 MRTR 兼容性
4. 用明确的 Context、Tool、Token、Cost 与 Iteration Budget 约束 Legacy 模型辅助流程
5. 迁移前对比直接 LLM Provider 集成与旧 Sampling 路径

常见问题

相关术语

相关文章