前阵子我做了一个挺“反人性”的测试让一个AI Agent替我在一个软件订阅后台把月付改成年付。它自己读了账单、算了一笔账然后在授权范围内调用支付接口完成了这次变更。整个过程我只点了一次确认。体验很顺滑但事后我翻调用链的时候被震了一下——这中间其实是好几层“老协议”托着“新协议”在跑从TCP到TLS从OAuth到微信支付API再到最上层的MCP和A2A粗粗一数正好七套。搜“AI Agent 支付”相关话题时你会发现很多词混在一起can协议、modbus、锁控板协议、7层协议、基于rust语言ai agent……其实这些“协议”根本不是同一个世界的东西。can、modbus那种是硬件总线和设备控制用的大家挂在嘴边的“7层协议”通常指OSI参考模型。而Agent支付这一条链路用的是另一套层层叠加的协议栈。这篇文章我想用“七套协议”这个框架把我这些年接触到的支付体系、以及2024年到2025年AI Agent支付出现后的新格局完整拆一遍。1. 七套协议是怎么“堆”出来的1.1 我拆出来的这七套分别是哪些所谓“七套”不是OSI那个七层模型而是我从业务视角拆出来的、一条真实支付链路里会依次经过的协议栈。它们不是替代关系而是叠加关系。我列一张表你一眼就能看清。序号协议/协议族在支付链路里的角色跟Agent支付的关系1TCP/IP HTTPS传输层数据怎么从A到BAgent调用支付接口也跑在这上面2TLS加密层保证链路上没人偷看篡改所有交易数据的安全底线3HTTP API 设计规范REST/JSON/回调接口怎么定义、怎么通知结果Agent要“读懂”支付接口全靠这层的约定4OAuth 2.0 OIDC身份授权层确认“谁允许谁花钱”这是Agent能不能替用户付钱的法律边界5卡组织报文体系ISO 8583 / ISO 20022 / 3DS传统收单清算网络Agent发起的线上交易最终也要走这套老系统6支付网关API微信支付API v3、支付宝、Stripe等开发者直接面对的支付接口Agent真正调用的就是这层7MCP A2A APPC 等Agent时代新协议工具调用、Agent互操作、Agent支付规范让Agent把支付“当成工具”用起来的关键把这七套串起来看就是一条完整历史线从人看网页付钱到人调接口付钱再到机器调接口付钱。1.2 为什么是“堆”而不是“换”这里我要先说一个非常重要的认知协议栈是不会被推翻重来的新协议永远叠在旧协议之上。你可以把支付体系想象成一座老城区。TCP/IP是马路TLS是邮局的密封袋HTTP API是信封上的地址写法OAuth是门卫的出入证制度卡组织报文是城际之间的货运单据支付网关API是街边的收银台而MCP这种新协议只是在收银台上加了一个会说话的机器人。机器人再聪明也还是得用马路、用密封袋、用地址写法、用出入证。这个“堆叠”的特性决定了研究AI Agent支付不能只盯新技术。你如果不懂底层那几套老协议遇到问题会完全无从下手。比如一个最典型的故障Agent下单成功但支付回调丢失这问题往往不在MCP层而在于HTTP API的回调设计甚至可能是TLS证书校验失败。七套协议每一套解决的都是“上一个时代没解决的问题”然后被下一个时代当成地基。顺着这个思路我们一层一层往上聊。2. 前四套地基从“人看的网页”到“机器调用的接口”2.1 第一套TCP/IP HTTPS支付数据的“路面”TCP/IP是互联网的地基这个不用我多讲。但在Agent支付场景里它有一个细节值得重点说连接建立的成本。一个Agent在处理任务时可能在几秒钟内连续发起几十次支付相关的API调用。每次调用如果都重新走一遍TCP三次握手加TLS一次握手那延迟和资源开销都很吓人。我实测过一套完整握手在跨地域链路下可能吃掉200到400毫秒而Agent的一次“思考-工具调用-再思考”循环里如果工具层慢半拍整个任务的体验会变得非常迟钝。所以现在做Agent支付基础设施普遍的做法是支持HTTP/2多路复用一个连接上并发跑多个请求启用TLS会话复用减少重复握手如果是自己搭MCP server尽量用长连接而不是每来一次请求就起一个新进程。这也是为什么社区里开始有人用Rust写Agent运行时和MCP server——Tokio加rustls这套组合在高并发短连接场景下确实比Python进程省太多开销冷启动也快。我自己压过一轮Rust写的MCP server在每秒几百个并发工具调用时内存占用非常平稳而Python版本已经需要横向扩容了。这不是说Python不行而是说“Agent怎么扛并发”这个问题答案往往要先从协议栈底层找起。2.2 第二套TLS所有“钱”都跑在加密隧道里TLS解决的核心问题是“这条马路上有没有人偷看、有没有人掉包”。任何涉及支付的数据从卡号、余额、到订单金额、回调通知都必须跑在TLS隧道里这是合规底线也是技术底线。Agent支付场景里TLS有两个容易踩的坑第一个坑是证书链验证。很多Agent的服务是动态部署的容器重启、域名变更、证书过期如果证书校验逻辑写得不严谨支付回调就可能静默失败。我遇到过一个真实案例服务器时间漂移了五分钟导致TLS证书的“不在有效期之前”校验失败所有支付回调全部被拒。排查了半天最后用NTP同步时间解决。这种事真的很搞心态但谁都会遇到。第二个坑是mTLS双向认证。在服务到服务的Agent支付场景里光验证服务器的证书还不够客户端也要出示证书这样能确认“调用方确实是合法的商户系统”。微信支付API v3是使用商户API证书做客户端身份认证的这在TLS层就建立了信任基础。很多刚开始做Agent集成的同学会忽略Agent服务端和网关服务端之间除了业务签名传输层也应该有双向认证。2.3 第三套HTTP API 设计规范从网页跳转到JSON交易早期做网站支付流程是用户填完订单、跳到银行网关、输入卡号密码、再跳回来。这套流程是给“人”设计的每一步都需要人肉操作。后来支付宝、微信支付开放平台做了一套纯API的接口机器可以直接下单、查询、退款。这是Agent支付出现的前提条件——如果支付接口不能无人值守调用Agent就永远只能是个“帮你打开页面的人肉外挂”。到了微信支付API v3、支付宝开放平台、Stripe这一代接口设计已经非常标准化RESTful资源定义、JSON请求响应、签名头、幂等键、异步回调。Agent能不能顺利接进去取决于两件事一是接口语义够不够直白。比如“创建订单”“查询订单”“申请退款”这些操作都对应明确的HTTP方法和资源路径LLM理解起来几乎没有障碍。二是出错信息够不够结构化。好的支付API会返回明确的错误码和错误描述Agent可以根据错误码自行修正参数重试而不是对着一个HTML错误页发呆。实操中还有个细节要提醒给Agent用的“工具描述”里不要只写“创建支付订单”要把参数含义、限制、返回字段都写清楚。因为LLM是通过工具描述来理解API的描述越像一份精简的API文档Agent调用就越少犯低级错误。2.4 第四套OAuth 2.0 OIDC给Agent发一张“授权卡”这是七套协议里最接近“法律边界”的一层。以前是我们自己登录、自己下单系统默认操作者就是账号主人。但现在让Agent代替我们操作系统必须回答一个问题这个Agent有没有权限替这个用户花这笔钱OAuth 2.0给出的答案是用户把“权限”颁发给一个客户端可以是Agent客户端拿到的access token就是一张授权卡卡上写着“你可以创建订单”但不写“你可以提现”“你可以改手机号”。OIDC则在这之上加了一层“你是谁”的身份认证确保颁发授权卡的确实是账号主人本人。这里我强烈建议采用授权码模式配PKCE。很多Agent是运行在用户本地设备上的没有客户端密钥PKCE能把“客户端密钥”替换成“动态生成的临时密文”防拦截、防注入这个设计非常适合Agent这种不适合保存固定密钥的场景。另外一个非常关键的实操要点是scope最小化。给Agent的tokenscope只开“支付订单创建、查询”这一档千万别顺手把“商户余额查询、退款操作、提现”都开了。我见过有团队为了让Agent“更自主”给了非常宽的权限结果Agent在上下文污染下申请了一笔莫名其妙的退款。虽然最后追回来了但这个过程极其让人后怕。权限这种事宁紧勿松。3. 支付通道那两层卡组织和网关API3.1 第五套卡组织报文体系Agent看不到但绕不开很多人觉得卡组织报文体系跟Agent离得很远其实不然。任何一笔线上支付最终都要落到银联、Visa、万事达这样的清算网络里。这些网络里跑的还是另一套历史更悠久的协议。ISO 8583是最典型的银行卡交易报文格式POS机刷卡时代就存在了。它的特点是字段极其紧凑、按位编号每一笔交易、每一段金额、每一类终端信息都编码进一个个数字域里。你去看一个报文示例满眼都是“DE02卡号”“DE03处理码”“DE04交易金额”这种编号非常难读但非常高效。Agent开发者不会直接写ISO 8583报文——那是收单机构干的事——但你必须知道你通过支付网关创建的每一笔订单最终都会被打包成这样的报文送上清算网络。ISO 20022则是新一代的金融报文标准基于XML字段语义比8583丰富得多正在逐步替换SWIFT体系里的MT报文。这个迁移对Agent支付也有间接影响报文更标准化了意味着支付链路两端的数据语义更容易对齐跨国、跨机构的自动对账、自动清算会有更大的想象空间。还有EMV 3-D Secure3DS 2.0这是银行卡线上交易的身份验证协议。当Agent发起一笔线上银行卡交易时如果发卡行风控觉得可疑就可能触发3DS验证——由用户输个验证码或者指纹确认。这一步就是“人机确认”在协议层面的体现也是Agent支付和纯机器支付的分界点。3.2 第六套支付网关API开发者最常打交道的一层这一层对做应用的人来说最熟悉。国内是微信支付API v3、支付宝开放平台海外是Stripe、Adyen。它们本质上是把底层卡组织的复杂报文打包成一组简洁的HTTP接口让开发者几行代码就能创建订单。这里我以微信支付API v3为例讲三个核心机制第一个是签名机制。微信支付API v3要求商户用自己的API私钥RSA对请求签名微信服务器用商户公钥验签反过来微信回调通知则用微信平台证书签名商户用平台证书验签。双向签名确保请求和回调都不可抵赖。第二个是回调通知的加密。微信支付回调里的关键数据比如商户订单号、金额不是明文给的而是用AES-256-GCM用商户API密钥加密过一遍。商户收到回调后要先验签再解密才能拿到真正的支付结果。很多人第一次接的时候会在这里卡住以为回调内容可以直接读。第三个是幂等设计。支付接口最怕重复扣款。微信的做法是同一个商户订单号只能被支付一次你拿同一个订单号反复创建支付单它只会返回同一笔单。Stripe更直接支持Idempotency-Key请求头你可以为一次请求生成一个唯一键重试时传同一个键服务端就只执行一次。Agent场景下这三个机制等于给机器发钱上了一道道锁签名保证调用身份可信加密保证回调内容不外泄幂等保证网络重试不会造成资金重复扣。我在实操中强烈建议在Agent的MCP工具层把这三个能力做进“创建支付单”工具里而不是让Agent自己思考“要不要带幂等键”。4. 顶层新协议MCP、A2A、APPC4.1 MCP把支付工具“递”给AgentMCP的全称是Model Context Protocol2024年11月由Anthropic开源现在已经捐给Linux基金会下面的联合开发基金会托管。它解决的痛点是以前每个Agent接入一个外部工具都要写一套私有集成代码MCP把它标准化成“一个JSON-RPC服务器暴露几个工具Agent通过协议调用”。对支付来说MCP的意义很直接——**支付变成了Agent工具箱里的一个标准件。**以前你教Agent怎么支付要写一堆提示工程现在你只要写一个MCP server里面暴露create_payment_order、query_payment_status、apply_refund这几个工具Agent就能像用计算器一样调用支付能力。一些关键设计建议工具名称用动词名词语义明确比如create_payment_link就比do_pay清晰太多工具描述里写清楚“用途、参数含义、错误处理建议”LLM才能正确填参重要的非可逆操作比如“确认支付”“发起退款”建议工具描述里加上“必须先获得用户明确批准”作为约束条件。4.2 A2AAgent之间互相付钱MCP解决的是Agent和工具之间的通信而Agent和Agent之间如果也要协作支付就需要另一个协议。2025年4月Google开源了Agent2Agent协议行业内通常简称A2A核心功能是让异构的Agent能够互相发现、发送消息、下发任务。想象一个场景你的日程管理Agent发现你下周要去外地出差它需要预订酒店于是通过A2A协议联系到酒店方的预订Agent两家Agent通过Payment Agent完成一笔交易。这时候A2A就承担了“Agent之间的对话语言”而支付子能力还是通过MCP暴露。所以它俩不是竞争关系是互补关系。需要注意的是A2A这门协议还很新各家Agent框架的兼容层还在快速演进生产环境里Agent之间直接自动付钱的案例还不多。目前更多是“Agent下单人确认Agent完成支付流程”的半自动模式。4.3 APPCVisa对Agent支付的“边界约束”2024年Visa推出了一套面向Agent支付的协议能力规范业内常简称为APPCAgent Payment Protocol and Capabilities。这套规范不是教你怎么扫码付款而是给“Agent替人花钱”这件事划边界。核心概念包括Agent注册与身份绑定每个支付Agent要有可识别的身份并能关联到实际控制人交易限额控制可以对单个Agent设置单笔限额、日累计限额、月累计限额付款人确认PCA重要交易必须回到“人”那边做一次确认不能全程无人值守交易状态报告Agent和付款人要能查询每一笔Agent支付的状态。这套规范非常有现实意义。它本质上是在回应一个灵魂拷问如果Agent可以在没有用户逐笔授权的情况下自动花钱那出事了算谁的APPC的答案是可以自动但要设限要害节点要让人说话。我在实操中很认同一句话“AI Agent支付的第一版产品不应该是无人值守的全自动支付而是有护栏的半自动支付。”5. 实操把一套普通支付接口改造成Agent可用5.1 前置条件与整体流程如果你想在项目里让Agent具备支付能力不需要等什么特别复杂的基础设施。我的建议是先把手头最常用的支付通道接成MCP工具然后让Agent在一个受限场景里跑起来。前置条件很简单一个支付网关账号微信支付、支付宝、Stripe都可以必须有API接口权限一个能跑MCP server的环境Python或Node都行更推荐Rust写生产级版本一个支持工具调用的LLM客户端现在主流框架都原生支持MCP。整体业务流程分成四步用户授权、工具调用、支付下单、回调确认。下面分别说每一环的代码和细节。5.2 MCP支付工具的实现示例我平时用Python验证想法FastMCP写起来很快。下面是个简化版用来创建一笔支付订单from fastmcp import FastMCP mcp FastMCP(payment-tools) mcp.tool() def create_payment_order( order_no: str, amount_cents: int, subject: str, user_id: str ) - dict: 创建一笔新的支付订单。 参数说明 - order_no: 商户订单号必须唯一建议包含时间戳和随机数 - amount_cents: 订单金额单位是分 - subject: 商品描述会展示在用户支付页面上 - user_id: 发起付款的用户标识 返回支付链接和订单号。 特别注意调用本工具前必须先获得用户的明确授权。 # 这里调用微信API v3或Stripe的创建订单接口 # 关键点把order_no作为幂等键透传 result payment_gateway.create_order( order_noorder_no, amountamount_cents, subjectsubject ) return { order_no: order_no, pay_url: result[pay_url], expires_at: result[expires_at] } if __name__ __main__: mcp.run()这段代码里有三个细节值得展开第一工具描述里我特意写了“调用前必须先获得用户的明确授权”。LLM在执行工具调用时读到这句约束会在对话里先问用户确认。这就把“人机确认”直接写进了工具语义里。第二amount_cents用“分”而不是“元”。这个细节看着小实际能避免Agent在金额单位上犯糊涂。你在描述里写清楚“单位是分”它就不会理解成元。第三order_no必须透传给网关。这个order_no天然就是幂等键Agent重试的时候只要不换号网关就会返回同一个订单不会重复扣款。5.3 用户确认与OAuth授权环节现在很多Agent产品在“创建订单”之前都会先弹一个确认卡片给用户上面写着“本次AI将为你支付XX元用于XX服务”。这个确认动作在技术层面怎么落地我的方案是在头部Agent框架层加一道“确认闸门”。确认闸门的实现思路是在Agent的工具调用链条里插入一个特殊节点当识别到需要调用支付工具时先暂停执行向用户推送授权确认请求等用户确认后再放行。这比让LLM自己决定“要不要确认”可靠得多因为LLM在长上下文里可能忘了问。OAuth的授权环节我用授权码模式配PKCE流程是Agent运行时先生成一个code_verifier算出code_challenge引导用户打开授权页登录并同意“允许此应用创建支付订单”授权服务器通过回调带回codeAgent运行时用code和code_verifier换取access_token和refresh_token之后的支付工具调用在请求头带上access_token。需要注意refresh_token的安全。Agent的会话可能持续很久刷新令牌过期了需要重新授权。但刷新令牌本身是高度敏感的一旦泄露等于把“长期继续替用户花钱”的权限送给了攻击者。所以生产实现里刷新令牌一定要做轮换每次刷新都签发新令牌、作废旧令牌而且要绑定设备指纹之类的会话信息。5.4 并发与防重Agent场景下的三个大坑“AI Agent怎么扛并发”这个话题这两年特别火但很多讨论都跑偏了。Agent端到端调用支付真正会对并发产生压力的是两个环节一个是MCP server作为工具网关的并发承载另一个是支付回调处理端的并发一致性。坑一回调重复通知。支付网关为了保证送达会按一定策略重复发送回调通知。如果你不加去重同一笔订单可能被处理两次轻则重复发券重则资金错乱。去重方案很简单用Redis或数据库唯一键判断def handle_payment_callback(event_id: str, order_no: str): # event_id是回调事件的唯一ID网关每次回调会带上 if not redis.set(fcallback:{event_id}, 1, nxTrue, ex3600): # 这个事件已经处理过直接返回成功 return {code: SUCCESS} process_order_paid(order_no) return {code: SUCCESS}坑二订单号冲突。多Agent实例并发时如果两个请求生成了相同order_no网关会返回“订单已存在”。避免办法是order_no里加足够的随机性比如“业务前缀时间戳随机串”。服务端在收到网关错误时也要能识别“已存在”不等于失败而是应该去查询原订单再返回给Agent。坑三用户级串号。同一个用户账号下多个Agent会话同时向支付系统发起请求可能会互相覆盖上下文。解决方法是给每个用户会话加分布式锁涉及同一用户支付状态的操作串行处理。这个用Redis的setnx就能简单实现粒度是用户维度。这三个坑我在刚把支付接进Agent的时候都踩过。尤其是回调重复通知一开始没做去重测试环境里同一笔单把积分发了两次。当时就在想如果这是真金白银领导怕是要把我挂在监控大屏上。6. 现状与个人踩坑记录6.1 七套协议的现状对照走到2025年这套协议栈到了什么状态我们把它拉平做一张表协议层级演进状态在Agent支付中的角色TCP/IP HTTPS成熟一切的基础Agent并发瓶颈常出现在这层TLS成熟但证书管理仍是故障高发区保障传输安全和双向身份认证HTTP API 规范成熟业界标准化程度极高支付接口能被机器调用的前提OAuth 2.0 / OIDC成熟但Agent权限授权需要更细粒度定义“Agent能替用户做什么”ISO 8583 / ISO 20022 / 3DS老系统稳定运行新标准迁移中清算网络的底层语言Agent不可见但绕不开支付网关API成熟各家在往“开发者友好”加码Agent直接调用的“钱袋子”入口MCP / A2A / APPC快速迭代处于“标准确立初期”让支付成为Agent的“标准工具”2025年上半年MCP已经事实上成为Agent接入外部工具的主流协议主流云厂商都上线了自家的MCP市场。很多开放平台甚至直接提供“支付MCP插件”开发者把一个MCP地址粘贴进Agent配置里Agent就能具备查询商户订单、创建支付链接的能力。这与一年前完全不可比——那时候要自己写工具定义、自己处理签名、自己调Agent框架的私有接口。6.2 我在实际集成时踩过的坑有几个坑普通文档里不会写但我希望你能少走弯路。第一个是时间同步问题。支付API的所有签名都包含时间戳服务器时间如果偏差超过几分钟签名必定验不过。Agent服务经常部署在轻量容器里容器如果没有启用chrony或ntpd时间漂移很常见。我见过有人排查了两天签名错误最后发现是宿主机的UTC时间差了三分钟。第二个是回调地址的稳定性。微信支付API v3要求回调地址必须是公网可达的HTTPS地址。Agent服务如果是临时端口或者内网地址回调发不进来你就永远收不到支付结果。稳妥的做法是回调走消息队列中心化配置别让Agent的运行实例直接暴露公网。第三个是沙箱环境和生产环境不一致。不同支付通道的沙箱行为差异很大有的一直返回成功、有的完全模拟真实流程。我把在沙箱里验证过的逻辑直接搬到生产结果发现网关的错误码风格都不一样Agent的异常处理脚本完全失效。建议在沙箱阶段就按生产环境的错误码规范来写Agent的重试逻辑。第四个是权限边界比想象中更容易破。我们给Agent的OAuth scope做了最小化但Agent可以靠“诱导用户提供一次性验证码”来绕过某些验证环节比如让用户在对话框里输入短信验证码。这实际上等于把“人机确认”变成了“人给机器递刀”。所以我会在输出层做脱敏Agent看到的信息里绝不包含能单独完成支付的敏感凭据比如短信验证码、支付密码。第五个专门提醒那些想自己做“个人代理支付”的朋友支付通道的进件、结算、合规都是绕不过去的功课。正规经营一定要有完整商户资质走官方签约流程不要碰任何来路不明的聚合通道或“代进件”服务。协议层你可以玩得很花但合规底线上没有捷径。6.3 我的实操体会如果非要总结一句话我会说AI Agent支付最大的风险不在技术而在“授权边界”的把握。七套协议里底层四套解决的是“能不能安全地付款”卡组织那套解决的是“这笔账怎么清算”网关API解决的是“开发者怎么方便地接入”而顶上那三套新协议真正在解决的是“机器在什么条件下可以替人花钱”。以我个人经验在做Agent支付产品时永远要保留三条底线一是大额交易必须人工确认二是所有Agent支付操作都有可查询、可撤回的审计记录三是Agent获得的权限永远是“最小够用”而不是“最大方便”。还有一个脚手架层面的心得尽量把支付能力沉淀成一套可复用的MCP工具包而不是在每个Agent项目里重复接一遍微信支付、Stripe、支付宝。我在多个项目里复用过同一套支付MCP server只是用不同配置区分商户、通道和环境。这样新项目接入时只要把MCP地址一填Agent立刻拥有支付能力整个接入时间从几天压缩到了几十分钟。最后再分享一个实用小技巧给Agent的支付工具描述里把“最小金额限制”也写上。比如在description里注明“低于100分1元的订单不允许创建”。这样能有效防止Agent在理解偏差时产生低额骚扰交易。这种小细节都是靠一遍遍踩坑换来的。我大致估算过七套协议每一套里都藏着至少一个“先坑后懂”的教训写出来也就这么长一篇。能让你少踩一个这文章就没白写。