面试题库

7 天 MCP：把工具接进任何 Agent

D3 resources 与 prompts：URI 模板、变更通知、进度与日志、分页，以及客户端能力

• 订阅流和请求内的进度通知在 HTTP 上都走 SSE，为什么 2026-07-28 规范要把它们分成两个通道？On HTTP both subscription streams and in-request progress notifications ride SSE, so why does the 2026-07-28 spec split them into two channels?

  国内高频海外高频深入#subscriptions#notifications

  分析过程 · 先想清楚再作答

  1. 这题的区分度在版本认知。还在讲 resources/subscribe 和一条独立 GET 长连接的人会当场暴露——这两样在这一版被合并替换成了 subscriptions/listen。
  2. 先把事实摆清：subscriptions/listen 本身是一条普通请求，只是它的响应是一条一直开着的通知流；客户端在 notifications 过滤器里显式勾选 toolsListChanged、promptsListChanged、resourcesListChanged、resourceSubscriptions，服务端不得推送没勾选的类型；第一条消息必须是 acknowledged，之后每条通知在 _meta 里带 subscriptionId。
  3. 拆法：问两类通知的生命周期一样吗。进度和日志属于某一次具体请求，请求结束它们就该停；列表变更、资源更新属于整个连接期，跟任何单次请求都无关。生命周期不同的东西混在一条流里，取消语义就说不清——HTTP 上关闭响应流就是取消该请求，你不会希望取消一次工具调用顺带把订阅也掐了。
  4. 第二个理由是无状态与可路由。请求内通知天然跟着那条请求的响应流走，任意副本都能处理；订阅是唯一一条长活连接，把它单独隔出来，剩下的请求才能真正做到无粘性路由。
  5. 结论：订阅流回答「世界变了吗」，跨请求、长期存在；响应流回答「我这一单做到哪了」，随请求生随请求死。规范明确写了进度与日志通知不在订阅流上出现。
  6. 可预期的追问：日志通知现在怎么开？logging/setLevel 已删除，改为每请求在 _meta 的 logLevel 里指定，且服务端不得对没带这个字段的请求发日志通知；而且 Logging 连同 Roots、Sampling 一起已被标记弃用，建议迁到 stderr 或 OpenTelemetry。

  How to reason about it · think before answering

  1. The discriminator is version awareness. Anyone still describing resources/subscribe and a standalone GET stream exposes themselves — both were replaced by subscriptions/listen in this revision.
  2. Get the facts straight first: subscriptions/listen is an ordinary request whose response is a stream that stays open. The client explicitly opts into toolsListChanged, promptsListChanged, resourcesListChanged, and resourceSubscriptions; the server must not push unselected types; the first message must be the acknowledgment, and every later notification carries subscriptionId in _meta.
  3. Then compare lifetimes. Progress and log notifications belong to one specific request and should stop when it ends. List changes and resource updates span the whole connection and relate to no single request. Mixing different lifetimes into one stream wrecks cancellation semantics, because closing a response stream on HTTP is the cancel signal — you do not want cancelling a tool call to kill your subscriptions.
  4. The second reason is statelessness and routability. In-request notifications naturally ride their own response stream so any replica can serve them; isolating the one genuinely long-lived connection is what lets every other request avoid sticky routing.
  5. Conclusion: the subscription stream answers has the world changed, spanning requests; the response stream answers how far along is my request, living and dying with it. The spec states outright that progress and message notifications never appear on the listen stream.
  6. Likely follow-up: how do you enable log notifications now? logging/setLevel was removed in favour of a per-request logLevel in _meta, and servers must not emit message notifications for requests that omit it. Logging is also deprecated alongside Roots and Sampling, with stderr or OpenTelemetry as the suggested migration.

  答题要点

  • 这一版用 subscriptions/listen 取代了 resources/subscribe 与独立的 GET 长连接，客户端显式勾选通知类型
  • 两类通知生命周期不同：进度日志随请求生灭，列表与资源变更跨请求长期存在
  • 混在一条流里会让取消语义失效，HTTP 上关闭响应流即取消该请求，不该顺带掐掉订阅
  • 隔离出唯一的长活连接，其余请求才能无粘性路由，这是无状态设计能横向扩容的前提

  Key points

  • This revision replaced resources/subscribe and the standalone GET stream with subscriptions/listen, where clients explicitly opt into notification types
  • The two kinds have different lifetimes: progress and logs live and die with a request, list and resource changes span the connection
  • Merging them breaks cancellation, since closing a response stream on HTTP cancels that request and must not kill subscriptions
  • Isolating the single long-lived stream is what lets every other request route without stickiness, enabling horizontal scaling