新的 MCP 规范是否悄悄改变了谁为你的 AI 调用买单?
摘要
文章讨论了 2026-07-28 更新日志中 MCP 规范对 Sampling 的弃用,将模型调用成本从客户端转移到服务器,并建议如何通过代码或日志检查服务器是否依赖 Sampling。
大家都在发帖说 MCP 变成无状态了,但我一直想的其实是 Sampling 被弃用这件事。我翻看 2026-07-28 的更新日志时,这一点确实很显眼。为什么它对成本很重要:使用 Sampling 时,服务器可以请求你的客户端去执行它的模型调用,所以费用由你这一方承担。现在它被弃用了,需要调用模型的服务器只能自己去对接提供商,所以成本就落在运行服务器的人身上。Sampling 从来都不是用得最广泛的功能,所以对很多配置来说这可能不是问题。但如果你运行或依赖某个曾经依赖它的服务器,谁为这些调用买单就在悄悄改变。有用的地方在于,你实际上可以检查而不是猜测:如果你能看到服务器的代码,就用 grep 搜一下 sampling/createMessage,还有它的 SDK 里的 sampling 调用(大多数服务器用的是包装器,而不是原始方法)。如果出现任何一个,就说明它用了 Sampling。如果是你读不到的第三方服务器,就在你使用它的时候观察你的 MCP 客户端日志里有没有传入的 sampling/createMessage 请求。服务器只有在你的客户端声明了 sampling 能力的情况下才能发送这种请求,所以如果在正常使用中看不到,它大概率不依赖这个功能。被弃用的东西大约还会继续工作 12 个月,所以还有时间。有人真的去检查过自己的服务器了吗?
相似文章
付费智能体 MCP 服务器
一位开发者正在为 AI 智能体构建 402 个 MCP 服务器,并寻求社区反馈,了解哪些付费微服务能让智能体更加实用。
你愿意付费让别人来运行你的智能体的MCP服务器吗?
本文探讨了一种付费服务选项,供希望将AI智能体的MCP服务器管理外包出去的用户使用。
MCP 服务器是否正在成为架构依赖?
引发了关于 MCP 服务器可能引入新的架构依赖的担忧,质疑绑定到特定服务器认证和实现的智能体是否真正可移植。
到2026年,哪些MCP服务器能让AI代理具备真正的业务能力?
一位实践者分享了他们在业务工作中使用MCP(模型上下文协议)服务器的经验,详细介绍了哪些服务器提供真正的读写能力(例如Postgres MCP、HubSpot MCP、PostFast)以及哪些令人失望(例如Slack MCP、Google Ads MCP),同时强调了主要的安全问题,如OAuth采用率低和漏洞率高。
MCP-Billing
MCP-Billing 是一款将 OAuth 2.1 与基于用量的 Stripe 计费整合到 MCP 服务器中的工具,简化 AI 模型端点的变现。