多数人以为 MCP 只是”客户端调用服务端工具”的单向通道，协议里其实设计了一组反向能力：服务端在处理请求的过程中，可以向客户端申请一次模型推理（Sampling），也可以向用户追问缺失信息（Elicitation）。这两个能力用好了，工具就从”函数调用”变成了”协作流程”。
为什么需要反向请求
典型场景：一个代码审查工具读完了差异，需要对危害做语义判断。若没有反向能力，服务端只能自己持有模型凭证并调用 LLM——凭证管理、费用归属、模型选择全压在服务端。
有了反向能力，服务端只需发一个请求，由客户端决定用哪个模型、是否在跑之前给用户看一眼。凭证始终留在用户的应用里，这是这套设计最核心的好处。
Sampling：向客户端的模型要一次生成
服务端在工具执行过程中发送生成请求，客户端审核后调用自己的模型，再把结果回填给服务端，整个过程嵌套在一次工具调用里。
- 请求内容：消息列表、最大 token 数，可选的提示词、温度、停止词，以及模型偏好。
- 模型偏好只是建议：服务端可以给成本、速度、智力三个优先级（0 到 1）和若干模型名提示，但客户端完全可以不采纳，最终用哪个模型由客户端决定。
- 必须有人工闸门：规范要求应该让人能 review 请求、能修改提示词、能在结果送达前审阅——这条不能省，它是抵御恶意服务端的主要防线。
留意规范迭代：按官方当前文档，Sampling 在较新的协议版本中已被标记为弃用，新实现建议直接对接模型厂商接口，不要在新建的重磅服务上依赖它。
Elicitation：向用户要一句关键的话
它的作用是”工具执行到一半发现少了必要信息”。与 Sampling 的区别一目了然：一个要模型的判断，一个要人的判断。
| 维度 | Sampling | Elicitation |
|---|---|---|
| 请求对象 | 客户端的模型 | 真实用户 |
| 典型用途 | 语义判断、摘要、分类 | 补一个必填字段、确认一个选择 |
| 规范建议的形态 | 需要人工确认闸门 | 表单模式与 URL 模式两种 |
| 成本 | 一次推理往返，延迟明显 | 没有推理成本，但会打断用户 |
Elicitation 有两种形态：表单模式适合非敏感的少量字段，用一份扁平的结构描述期望的返回；URL 模式用于凭证、支付、 OAuth 这类敏感交互，让用户在外部页面中完成，信息不经过智能体。
能力协商：先看对方会不会，再开口
- 初始化时声明：客户端在初始化阶段明确自己支持哪些能力，服务端不要假定任何未声明的能力。
- 调用前检查：服务端在发起 Sampling 或 Elicitation 前，必须确认对方已声明该能力，否则请求会被拒绝。
- 把拒绝当正常分支：用户可以拒答、客户端可以拒绝、请求可以超时，这些都要写成正常的业务分支，而不是报错重试死循环。
- 保留部分进展：被拒绝或取消时，返回清晰的状态和已完成的进度，方便用户决定下一步。
隐私边界怎么守
四条底线
- 最小信息：只申请完成当前工作必需的信息与能力，不要顺手多要。
- 敏感走外部：任何凭证、支付类输入用 URL 模式，不要经过客户端。
- 说明来源：请求里要讲清是哪个服务端在问、为什么需要，用户才有判断依据。
- 限制频率：对重复的追问做限流，避免把用户当成免费的自动机。
和其他 MCP 概念怎么接上
Resources 与 Prompts 是从服务端流向客户端的上下文与模板，Sampling 和 Elicitation 是反方向的能力，两者合起来才构成真正的双向协议，前两者的用法见MCP Resources 与 Prompts。
是否让用户介入、介入点在哪个位置，和人机协作的审批点设计是同一套逻辑：放在不可逆、高风险、低置信度的地方。实现上遇到请求报错或能力不生效，可以按MCP 调试常见问题里的路径排查。
延伸阅读：Resources 与 Prompts 用法服务端能不能指定必须用某个模型？
不能。模型偏好只是提示，最终选择权在客户端。这也是为了避免服务端把费用与能力绑定在自己偏好的厂商上。
用户一直不响应追问怎么办？
要设置超时上限，把超时当作正常失败分支处理：返回当前进度与缺失项，让用户决定是补齐还是取消。
恶意服务端会利用 Sampling 做什么？
可能通过诱人的提示词诱导模型输出敏感上下文，形成数据外泄。所以规范要求 Sampling 必须有人可以审核与否决的环节，且不要运行来源不明的服务端。
什么时候不该用反向能力？
能用普通工具返回值解决的就不要用。只有当确实需要宿主侧的判断（人或宿主模型）时才引入，因为这些能力会显著增加状态数量和失败路径。
评论 (0)