MCP Sampling 模型路由：偏好映射、工具循环与双重同意收据

Server 在 modelPreferences.hints 写了一个模型家族，Client 却只接入另一家供应商，于是路由器静默映射到更昂贵的模型。用户批准了最初 prompt，却没看到 Client 自动补入的上下文和模型发起的工具调用；最终结果一返回就被 Server 当作已同意事实。协议允许抽象选择，但生产系统仍要说明究竟发送了什么、选了谁、花了多少以及谁批准交付。

LLM Gateway 路由策略处理供应商选择，Agent 人工审批合同处理一般工具授权。本篇把二者收束到 MCP sampling/createMessage：Client 保有模型访问、选择和许可控制权，Server 只能表达偏好，不能把 hint 当硬编码模型 ID。

把路由解释变成可复现合同

只有 Client 在初始化声明 sampling 后，Server 才能请求 Sampling；带工具请求还要求 sampling.tools 子能力。includeContext 的 thisServer 与 allServers 已软弃用，未协商 sampling.context 时不应使用。Client 首先规范化 messages、systemPrompt、maxTokens、tools、toolChoice 和 modelPreferences，生成 samplingRequest.v1 摘要，再由 samplingRoutePolicy.v1 将 hints 与 costPriority、speedPriority、intelligencePriority 映射到当时可用模型集合。

路由收据保存请求摘要、Server 与用户主体、session capability receipt、候选集快照、策略版本、实际 provider/model、价格表 generation、数据区域、预算上限、上下文来源和降级理由。hint 只参与排序；即使名称完全匹配，也要通过租户授权、模态支持、工具支持和成本门。多 Agent 能力过载路由中的容量思想可复用，但 Sampling 还必须把实际 model 返回给 Server。

RECEIVED -> VALIDATED -> REQUEST_REVIEW
REQUEST_REVIEW -> REQUEST_APPROVAL_UNKNOWN | DECLINED | ROUTED -> MODEL_RUNNING
MODEL_RUNNING -> TOOL_USE_REVIEW -> RESPONSE_APPROVAL_UNKNOWN | TOOL_USE_DELIVERED
MODEL_RUNNING -> FINAL_REVIEW -> RESPONSE_APPROVAL_UNKNOWN | FINAL_DELIVERED | REJECTED
TOOL_USE_DELIVERED -> ROUND_CLOSED -> NEXT_REQUEST_RECEIVED

两阶段审批都使用稳定 approvalId = (sessionGeneration, samplingRequestId, phase, revision)。账本把用户看到的完整 prompt、工具 schema、拟选模型级别或响应摘要、成本上限和过期时间绑定到 PENDING -> APPROVED | DECLINED receipt。持久化决定后 UI ACK 丢失则标本地 UNKNOWN，并按同一 approval ID 查询；不得生成新 ID 重复提示，也不得把“用户可能点过”当批准。请求摘要被用户修改必须提升 revision，只有 request-approval receipt 存在才允许路由和调用模型。

模型返回 stopReason: toolUse 时，Client 审核每个唯一 tool use ID，并在 response-approval receipt 后把 CreateMessageResult 交付 Server；这一轮至此终结，Client 不替 Server 执行工具。Server 执行后发起新的 sampling/createMessage，把历史和 tool results 带入下一轮。新请求有独立 JSON-RPC ID、摘要与审批，只通过 conversation root 和前一 delivery receipt 关联。

Client 对新请求的历史校验：每个先前 assistant tool use 都必须由紧随其后的纯 tool-result user message 按 ID 一一匹配，工具结果不能与文本或其他内容混装；当前正要交付的 toolUse response 尚无结果，不能因“不平衡”被拒。每轮调用受最大迭代、总 token、总成本和墙钟预算约束，工具执行还需 Server 侧独立审批，不能继承“允许采样”的决定。审批重放绑定阻止旧同意用于新 prompt。

每次请求的唯一交付点是 deliverApprovedSamplingResult。事务匹配 request digest、路由收据、实际模型、内容验证和本轮 APPROVED response receipt，再写 delivery receipt 与唯一 response outbox；approval UNKNOWN 时一律不交付。toolUse 分支验证当前 IDs 与工具集合后交付，不虚构尚未发生的 results；final 分支以及后续请求的传入历史才执行完整配对检查。用户拒绝结果时返回明确错误，不把模型原文泄给 Server。Agent 工具输出 Schema 防线继续检查内容。

故障注入覆盖 hint 无匹配、请求审批决定或 UI ACK 丢失、批准后 prompt 被改、response 审批 ACK 丢失、tool use ID 重复、toolUse delivery ACK 丢失、Server 重放下一轮、历史缺 tool result、并行结果乱序、session 撤销和模型名称伪造。断言同 approval ID 最多一个决定且不重复提示，UNKNOWN 未查明时模型调用/交付均为 0，当前合法 toolUse 不因未有 result 被阻塞，新请求的不平衡历史必拒绝，循环越界必停且费用不越上限。

门禁要求一万次路由重放选择一致率 100%；未协商工具请求拒绝率、审批 UNKNOWN 推进、tool-use/result 漏检和成本超限均为 0；所有模型调用关联 request approval，所有交付关联 response approval，重复用户提示率为 0；人工队列 p95 等待低于业务 SLO。上线先 shadow 路由和审批 ledger，再对内部 Server 开 1%。回滚冻结新策略，继续验证已签收轮次；审批不能迁移到不同模型、prompt 或工具集合。