微信号：13696566200
看到A16Z的文章在讨论agent pay，忽然就想写一篇关于agent支付的文章，对于协议层的关注，在前文
当人们讨论 AI Agent 时，焦点往往落在它能做什么——订机票、写代码、管理日程。但有一个问题被严重低估：它能花谁的钱、怎么花、花完之后谁负责？
支付，是人类经济活动中信任的最终表达。一笔交易的完成，意味着双方在法律、技术、金融三个层面同时达成了共识。而当人从这个过程中退出，换成一个自主运行的 AI Agent 时，原有的信任体系就出现了根本性的裂缝。
现有支付协议是为人点按钮设计的。用户看到商品、确认价格、输入密码——每一步都是人类意志的显式表达。但 Agent 支付要求的是：用户在某个时刻表达了一次意图，然后机器在未来的某个时间点、某个场景下，代替人类完成交易。
本文的核心论点是：Agent 支付协议的本质，是把人的意图转化为可验证的机器承诺。协议设计的好坏，是整个 Agent 经济能否建立信任基础的前提。
第一，人类是决策者。每一笔交易背后，都有一个真实的人在做判断。银行卡、密码、指纹，都是验证这个人是否在场、是否同意的机制。
第二，交易是离散的。每笔交易相对独立，用户逐笔确认。即使是订阅扣费，也是用户在某个时刻明确同意了每月扣 X 元这个约定。
第三，责任链是清晰的。出了问题，责任归属有明确路径：持卡人、发卡行、收单行、商户，各方权利义务由卡组织规则和法律框架界定。
Agent 是决策执行者，不是人类。它在用户不在场的情况下做出购买决策。它的交易是连续的、高频的、跨系统的。当它下错单、买错东西、被恶意网站劫持时，责任链立刻变得模糊：是用户的错（因为用户授权了 Agent）？是 Agent 开发者的错（因为模型产生了幻觉）？是平台的错（因为没有做好风控）？
更深层的问题是：传统支付协议没有意图这个概念。它只知道谁付了多少钱给谁，不知道为什么付、在什么条件下付、付的是否符合用户的真实意愿。在人类点按钮的时代，这不是问题，因为点击本身就是意图的表达。但在 Agent 自主执行的时代，这个缺失就变成了致命漏洞。
协议的核心任务，不是怎么扣钱，而是怎么把用户授权、Agent 行为和支付网络，用可验证的证据链严格绑在一起。
围绕这三个问题，当前主流的协议设计形成了三种范式，各有侧重，但技术思想高度趋同。
每一层都是经过加密签名的可验证凭证（Verifiable Credential）。这个设计的精妙之处在于，它把自然语言指令 → Agent 选品 → 支付扣款这个过程，变成了一条可审计、不可抵赖的证据链。
人在场模式：用户提出买鞋的请求，被记录为 Intent Mandate。Agent 帮你选好后生成 Cart Mandate。你在可信界面上确认并签名，生成 Payment Mandate 发给支付网络。这个流程和传统支付类似，只是中间多了 Agent 的选品环节。
自治模式：用户事先签署一个约束更强的 Intent Mandate，包含价格上限、时间窗口、商品类别等约束条件。Agent 在条件满足时自动生成 Cart + Payment Mandate 完成交易，全程无需用户再次确认。
这个设计有一个关键哲学：把支付从命令式 API 调用抽象成可协商的合约对话。协议消息更像一系列合同步骤，而不是create_order()这样的单次调用。这使得多方交互、条件执行、事后审计都有了语义基础。
AP2 还刻意保持支付无关（payment-agnostic）：它在协议层统一授权与责任，不规定用哪条支付轨道扣钱，理论上能兼容卡组织、银行转账、电子钱包等各种清算方式。
AP2 的价值：它提供了一套完整的语义框架，让意图成为协议的一等公民。它的局限是：作为一个开放协议，能否被支付网络、商户、Agent 平台广泛采纳，取决于生态博弈，而不仅仅是技术优劣。
在国内，支付宝和微信支付都已经推出了基于 MCP 的 Agent 支付接入方案。支付宝的支付 MCP Server让 AI 智能体通过自然语言就能实现支付、查单、退款等操作；微信支付的 MCP 协议让开发者几句话接入下单、支付、赞赏等能力。
AP2 解决的是授权语义问题——Intent 是什么、Cart 是什么、Payment 是什么，各方的权利义务如何用可验证的方式表达。
MCP 解决的是工具接入问题——如何用统一格式把支付 API 暴露给各种 Agent，不需要为每个模型、每个工具写一套集成代码。
MCP 本身不定义授权语义，真正的授权模型需要在 MCP 之上构建策略层。企业级部署中，通常会在 MCP 网关层定义规则：哪些 Agent 可以做哪些操作、额度是多少，同时输出细粒度审计日志满足监管要求。
MCP 的价值：极低的接入门槛，标准化的工具调用，快速打通 Agent 与支付能力的连接。它的局限是：MCP 是管道，不是合约。它让 Agent 能调用支付，但不能从协议层保证调用的合法性和可追溯性。
国内的 MCP 路线，本质上是在现有持牌支付机构体系上增加 Agent 接入层。资金仍由持牌机构按现行规则托管和清算，备付金制度没有被绕开，智能体只是改变了前端形态。这是一条合规优先、快速落地的路径，但也意味着它的协议创新空间受到现有监管框架的约束。
Mastercard 的 Agent Pay 方案代表了第三种范式：不重新设计支付协议，而是把 Agent 纳入现有支付网络的身份与风控模型。
核心创新是引入Agent Token：为每个注册的 AI Agent 分配独立、可撤销的 token，替代直接暴露用户的 PAN（主账号），把 Agent 身份纳入风控和交易路由逻辑。每笔交易都记录 Agentic Token，便于溯源。
L1：用户 → 设备/钱包（用户授权设备代表自己）L2：设备 → Agent（约束性委托，含可支出上限、可交互商户类别等）L3：Agent → 单笔交易（短期凭证，针对具体交易生成）
这个设计的安全逻辑是：即使 L3 凭证泄露，攻击者能做的事情也被 L2 的约束严格限制。
卡组织范式的价值：它不需要重建支付基础设施，而是在现有网络上做扩展，落地阻力最小。它的局限是：如果各家卡组织、支付网络各玩一套 Agent Token 标准，会带来严重的碎片化，商户和开发者的集成成本将急剧上升。
三种范式各有侧重，但在协议设计的核心维度上，业界已经形成了相当程度的共识。
授权不能是一次性的、模糊的我同意 Agent 帮我购物。它必须是分层的、可验证的：
三层之间的映射关系，必须是可验证的、不可篡改的。任何一层出现偏差，都应该能被检测到并阻断。
这个分层结构解决了一个根本问题：它把用户意图和机器执行之间的鸿沟，用可审计的证据链填补起来。
KYA（Know Your Agent）被明确类比为 KYC，是在给 Agent 金融权限之前，验证其身份、运营方和权限范围的一整套流程。典型的 KYA 要素包括：
KYA 目前多是最佳实践而非强制法规，但普遍被认为会像 KYC 一样逐步制度化。
这意味着协议必须支持对 Agent 的消费行为进行精细约束：金额上限、时间窗口、商户类别、商品类型。这些约束不能只是建议，而必须是在协议层可验证、在执行层可强制的硬约束。
业界正在探索的方向是Policy as Code：把合规要求、风控规则、业务约束转化为可执行的策略，在运行期实时监控并阻断越权行为，而不是只在授权时做一次性检查。
Guardrails 不是可选附加项，而是安全部署 Agent 的核心组成部分。它需要贯穿策略定义、配置、运行监测和审计的全链路。
一个重要的设计原则是：人类监管仍然需要在关键节点介入。高额支付、异常模式、超出预设范围的行为，应该触发人工审核而不是自动放行。Guardrails 的设计目标是人机协同，而不是完全自动化。
这个问题在当前的法律和监管框架下几乎没有明确答案。现有的 chargeback 体系是按人做决策设计的，Agent 打破了这个前提。
如果卡组织把 Agent 看作用户的延伸，那么代理搞错但形式合规的场景很难被按传统欺诈处理，用户投诉无门。
如果 PSP 被推定负责，那么 Agent 支付的风险溢价会极高，商业模式难以成立。
AI 模型提供方在短期内多为第五方概念，未真正纳入赔付链条。
这意味着协议必须记录：Agent 的输入/输出、关键中间决策、生成的支付指令、时间戳和调用链。能回溯是哪一个 Agent、在怎样的上下文下作出的这个支付决策，是未来监管的前提条件，也是争议解决的基础。
监管机构将会把审计可用性和可解释的决策路径视为开启 Agent 支付业务的前提条件之一。强审计不是附加项，而是监管红线。
这个原则听起来简单，但在实践中往往被忽视。很多 Agent 支付方案把授权流程设计得很流畅，却没有认真设计撤销流程。
易授权、难撤销的设计，会在未来的诉讼和监管中成为重点批评对象。这不仅是用户体验问题，更是法律风险问题。
TCP/IP 定义了数据如何在网络上传输，HTTP 定义了文档如何在 Web 上交换，SMTP 定义了邮件如何在服务器间流转。每一个基础协议的确立，都伴随着激烈的竞争，最终胜出的往往不是技术最优的方案，而是生态最广泛的方案。
支付领域同样如此。Visa/Mastercard 的卡组织网络、SWIFT 的跨行清算、微信/支付宝的移动支付，都是协议 + 网络效应的产物。一旦某种协议形成足够大的生态，后进入者几乎无法撼动。
Agent 支付协议的竞争，本质上是在争夺下一代支付基础设施的轨道控制权。
AP2/A2A代表语义层开放协议路线，试图在协议层定义意图、授权和责任的标准语言。如果成功，它将成为 Agent 支付的HTTP——所有支付网络都在其上运行，但没有哪家能独占。
MCP代表工具接入标准化路线，通过极低的接入门槛快速扩大生态。国内支付宝、微信支付的 MCP 接入，本质上是在用谁先占领开发者生态来建立壁垒。
卡组织的 Agent Token代表现有网络扩展路线，通过把 Agent 纳入现有风控和身份体系，用既有的网络效应来锁定 Agent 支付流量。
三条路线并不互斥，但它们对谁控制协议关键节点的答案截然不同。
一个值得警惕的风险是：如果 Agent 生态一开始就深度绑定某种支付轨道，未来的路径依赖会非常强。商户、开发者、用户一旦习惯了某种接入方式，迁移成本极高。这意味着早期的协议选择，可能在未来十年内都难以改变。
约束条件：国内不会走稳定币路线。人民银行的监管框架对支付牌照、备付金、反洗钱有明确要求，Agent 支付必须在持牌机构体系内运行。这意味着国内的协议创新空间，主要在九游体育接入层和授权语义层，而不是清算层。
竞争逻辑：微信支付和支付宝的 MCP 接入，本质上是两家在争夺AI 时代的支付入口。微信偏社交流量入口，支付宝偏商业闭环和商户生态，但两家的共同目标是：让 Agent 默认走自己的支付通道。
当前阶段的特点：国内落地更多是人始终在关键支付动作中在场——Ag九游体育ent 辅助生成收款二维码或支付请求，用户仍需扫码或指纹确认。这是一种过渡形态，在保留用户控制权的同时，逐步建立 Agent 支付的用户习惯。
待解决的问题：国内对Agent 乱扣钱算谁的这类责任划分问题，目前还处在讨论期，没有形成公开统一方案。随着 Agent 支付规模扩大，这个问题将不可回避。预计监管层会在支付机构风险管理指引或专项文件中，对 AI 助手/Agent 发起支付指令的场景提出额外要求：更强的用户确认、限额、日志留存和可追溯性。
国内从业者需要关注的核心问题：在现有监管框架下，如何在 MCP 接入层之上构建真正的授权语义层？当前人在场确认的过渡模式，何时会演进为事前授权、Agent 自主执行的完整 Agent 支付模式？这个演进的触发条件是什么——是技术成熟度、是用户信任度、还是监管框架的明确化？
不同层的竞争逻辑完全不同。语义层是标准之争，身份层是生态之争，接入层是开发者之争，清算层是网络效应之争，治理层是合规能力之争。搞清楚自己在哪一层，才能判断真正的竞争对手是谁。
如果你的方案对这三个问题的回答是靠信任或靠约定，而不是靠可验证的技术机制，那么它在规模化之后必然会遇到严重问题。
这是一个简单但有效的测试。如果你的产品让用户授权 Agent 支付只需要三步，但撤销需要找客服或者根本找不到入口，那么你正在埋下一颗定时炸弹。
不要等监管要求来了再补审计。现在就应该设计完整的审计轨迹：Agent 的每一个决策、每一笔交易的上下文、每一次授权的范围和时间戳。这不仅是合规要求，也是你在争议中自证清白的唯一手段。
如果你的产品深度依赖某一种协议（MCP、AP2、或某家卡组织的 Agent Token），你需要认真评估：如果这条轨道没有成为主流，你的迁移成本是多少？是否有办法在协议层保持一定的中立性，避免过早被锁定？
在人类点按钮的时代，信任来自于人的在场——你亲眼看到了商品，你主动输入了密码，你承担了这个决定的后果。
在 Agent 自主执行的时代，人的在场被替代了，但信任不能消失。它必须被转化为另一种形式：可验证的协议承诺。
协议是信任的代码。它把我信任这个 Agent这句话，翻译成机器可以执行、法律可以认定、监管可以审查的技术语言。
这是一场关于谁来定义机器时代规则的竞争。它的结果，将在未来十年内深刻影响 AI 经济的格局。
对于今天的从业者来说，在网络效应主导的世界里，早期的生态选择往往比技术优劣更重要。但有一点是确定的：无论哪条轨道胜出，能够真正解决 Authorization、Authenticity、Accountability 三个问题的协议，才有资格成为 Agent 经济的基础设施。
