北京
一个智能体需要补全一条客户记录。干这件事的工具要花钱。x402 v2没有规定谁有权批准这笔支出，MCP 2026-07-28也没有。两份规范都把价格和路由元数据搬进了HTTP头部，网关因此能看见一次工具调用值多少钱。但看得见价格，和有权批准价格，是两回事。
这套判断来自与Agentic AI Foundation合作的一篇文章，标题是《402 Payment Required：企业MCP服务器欠付费智能体什么》。随后作者把它带到了东京的AGNTCon + MCPCon Japan，让一个智能体在测试网络上真跑了一遍。
先补两段背景
HTTP里有个402 Payment Required状态码，从1997年起就闲置着，被保留但从未被定义。x402给了它含义：服务器用402回应，附上自己想要的条款；客户端带着签名的支付授权重试；服务器返回结果，外加结算凭证。v2版本在2025年12月把这一切搬进了头部——PAYMENT-REQUIRED、PAYMENT-SIGNATURE和PAYMENT-RESPONSE，不再埋在请求体里。
MCP则是智能体发现和调用工具的方式。2026-07-28修订版移除了会话和Mcp-Session-Id头部，新增Mcp-Method和Mcp-Name头部，并按RFC 9207强化了签发方校验。
两份规范放在一起看，意义在于：有趣的元数据都从请求体挪到了头部。网关、限流器和WAF现在不用解析一行JSON-RPC正文，就能看清谁在调用、调用哪个工具、花多少钱。付费智能体流量的计量和路由成本大幅下降。
问题恰恰从这里开始。头部可见不等于授权。基础设施一旦能看见价格，就必须对价格做出某种决定，而两份规范都没说这个决定该由谁来做。文章的观点是：支出决策应归属于智能体够不着的预算权威，把它放在哪里，才是协议细节过时之后仍然重要的部分。
东京现场跑了什么
在东京，作者停止了争论，直接跑起来：一个真实智能体在测试网络上为MCP工具调用付费，其中包含它试图为未经批准的事项花钱的那条路径。
威胁模型需要说清楚：智能体进程及其所有输入都被视为敌对的；网关、服务及其策略是诚实的但会犯错；被篡改的二进制、恶意操作者、从硬件中提取密钥以及链级攻击不在讨论范围内。
智能体的任务用业务语言表述：补全42号记录。它不知道这要花多少钱，也不知道哪个提供方会做这件事。第一个问题立刻出现：怎么让一个敌对的东西去比价，又不先递给它一个钱包？
它发出请求，然后被故意拒绝。返回的PAYMENT-REQUIRED头部是base64编码的JSON，解码后是一份报价，包含方案、网络、资产、收款地址、最高应付金额、资源地址、最长超时秒数和服务器选定的随机数。
这是HTTP绑定下的情形。在MCP下，同样的协商会发生，但位置不同。这一点在边缘做计量之前值得知道：MCP绑定会给网关返回一个200，而这次调用还没人付过钱。如果计量逻辑以状态码为键，就会直接放行。
这里有个比表面更重要的设计决定：询价是免费的。如果弄清价格本身就要花钱，那么每个智能体在规划之前就需要支出权限，这会把授权决策推到整个流程中信息最不充分的时刻。免费发现让第一轮请求完全不携带消耗价值的能力。边界之所以能放行，正是因为放行不使组织承诺任何东西。
因为这一轮放行成本很低，边界在转发时还能做一件安静但重要的事：校验断言、施加更轻的策略、做受众转换——铸造一个只针对单一资源和单一动作的下游凭证，然后只带着这个凭证转发。返回时，网关自己看到了报价。记住这一点，到了边界处它就是全部的关键。
跨过边界的不是企业凭证，而是新铸造的、限定于一个资源和一个动作的凭证，用于其他任何事都不行。这就是受众转换，也是避免把下游服务能反过来复用的东西交出去的办法。
四个决定，四个归属
现在智能体想真正执行了。这是钱变得真实的时刻，也是智能体之外的某个人必须说“可以”的时刻。这里有四个决定纠缠在一起，有用的做法是把它们拆开，各给一个归属。
文章在这一点上收束：最后一个决定，正是预算检查该放的位置。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
