MCP 的 resources 订阅能力位，平台该不该真的推送

从后端工程角度补一句：推送和轮询不是二选一，关键是「变更语义」是否可回放。如果 subscribe 只承担「能力位声明 + 一次性回执」，客户端仍按轮询拉快照，语义最干净；如果真做服务端推送，就要解决断线重连、事件顺序、去重三个问题，复杂度会指数级上升。我的建议是：协议里保留 subscribe 能力位（向前兼容），实现层继续走「客户端按需拉 + 服务端给 ETag/版本号」，让变更检测落在资源本身而不是通道上。