AI Agent支付背后的七层协议栈：从UART到MCP的完整链路解析

去年我给一家做自动售货机的公司搭AI Agent支付方案。立项时大家普遍觉得难点全在大模型这边商品识别准不准、售后话术像不像人、推荐策略能不能多卖两瓶汽水。结果我把架构图画完才发现真正决定这套系统能不能“收到钱”的是一条由七套协议接起来的长链路LLM输出的JSON意图要先变成HTTP签名请求穿过支付网关再顺着MQTT回到售货机主控板最后通过CAN总线驱动电机完成出货动作。这不是个例。所有想让AI Agent替用户、替企业完成真实支付动作的团队最后都会撞上同一个现实Agent只是最上面那层“聪明意愿”它脚下踩着的还是那些老协议——UART、CAN、MQTT、HTTP、支付API签名以及2024年之后火起来的MCP。想讲清楚AI Agent支付的历史和现状就得先把这七套协议一层层剥开。1. 一笔Agent支付背后到底藏了几套协议很多读者以为“AI Agent支付”是一个功能模块接入一个SDK就能跑通。实际上支付是分布式事务里最复杂的场景之一把它和LLM叠加之后复杂度的增加是指数级的。1.1 我口中的“AI Agent支付”指什么我给一个严格但不教条的定义只要Agent在“商品识别、下单、支付、退款、对账”这五个环节里自主完成了至少一个环节就算Agent支付。注意是“自主”不是用户手动点完链接之后让Agent帮忙填单。用户对着客服Agent说“把我购物车里的东西按最便宜的物流下单”Agent自己去查商品库、算运费、发起支付、等回调、更新ERP订单状态这算Agent支付的完整闭环。中途哪怕差一环钱就收不到或账就对不上。目前常见的形态有三种C端代付消费者授权Agent代下单代付款典型的像语音助手购物、直播间的智能客服代付。B端自动付款企业给Agent一个预算池让它按规则自动结算广告费、采购费、云资源费。M2M机器对机器结算售货机、充电桩、AGV小车之间自动结算Agent负责裁决“谁该付多少钱”。第三种最容易被忽略但它恰恰是最需要那套硬件协议栈的场景。1.2 支付协议为什么是一摞而不是一条我常用寄快递来类比。一笔支付从用户大脑里冒出来到钱真的进了商家账户相当于一个包裹从寄件人手上跑到收件人手上。包裹本体对应支付报文快递面单对应支付业务协议外面的纸箱对应应用层协议HTTP货运卡车对应传输层TCP高速公路和城市道路对应网络层驿站里那个扫码枪对应硬件链路层。每一层都在干自己那摊事而且每一层都可能成为断点。箱子上贴着易碎品但卡车急刹车碎的是里面的碗支付链路里任何一层协议解析失败订单就挂在那里。所以我跟团队说做Agent支付不要只盯着大模型推理那几百毫秒要把整条物理链路画出来。只要链路断一处你的Agent再聪明也是“一个特别聪明的哑巴”。1.3 “七套”是怎么数出来的这里得解释一下因为不同人可能数出五套也可能数出十二套。我不按OSI七层模型数那个太碎搞协议开发的人看着都头疼。我按“实际部署中谁会变成断点”来数数来数去正好七层层级典型协议在Agent支付里负责什么典型设备/系统第1套 硬件链路协议UART、SPI、IIC、RS-485、蓝牙Core 5.3支付终端、传感器与主控MCU之间的最后握手扫码枪、钱箱、显示屏、称重模块第2套 现场总线与设备协议CAN、DroneCAN、Modbus、PLC、SECS/GEM把支付结果变成机械动作或设备指令售货机、AGV、封测设备、充电桩第3套 网络与传输协议TCP/IP、蓝牙Mesh、Wi-Fi跨设备、跨地域的透明搬运网关、路由器、Mesh网络节点第4套 应用与消息协议HTTP/HTTPS、WebSocket、MQTT、RTMP订单、回调、消息通知的实时流转API服务、消息队列、终端App第5套 Agent智能交互协议MCP、Function Calling让大模型理解并调用支付工具Agent运行时、MCP Server第6套 支付业务协议微信支付V3、支付宝开放平台API签名、下单、退款、异步回调验签支付服务、商户系统第7套 网关与对账协议支付网关PRD报文、对账文件幂等控制、资金清分、差错处理支付网关、财务系统这套划分法不是学术标准但实战里特别适用。因为每一套协议都对应着一种常见的故障类型硬件层的波特率不匹配、总线层的ID过滤错误、消息层的QoS丢消息、业务层的签名错误。2. 从人工点按钮到Agent自主付款一段协议驱动的演进史AI Agent支付不是凭空冒出来的它是在过去二十年支付接口协议不断沉淀的基础上长出来的。看历史不能用“谁发明了什么”的视角要看“每一代人在协议栈上加了什么”。2.1 API支付时代2005-2015程序代替人调用接口这个时代没有Agent但所有基础设施都是这个时代打下的。网银直连、支付宝担保交易API、微信支付2014年面向商户开放先后出现。开发者的工作是写一个后台服务用HTTP去调用支付接口然后把回调地址指到自己的订单系统。这个时代的协议栈很短大致只有三样HTTP、支付网关的签名规则、商户自己的订单表。签名规则尤其重要它确定了“用私钥签名、用公钥验签、回调里带notice”这套玩法。后来Agent能接支付本质上是把这套签名玩法原封不动地封装成了工具并没有发明新支付协议。2.2 RPA与IoT支付时代2016-2020机器人先学会“跑腿”共享单车、无人货柜、自动售货机在这几年爆发支付不再只发生在“网页后台”而是发生在物理设备上。开发者发现HTTP回调不一定能到达无人值守的设备于是MQTT这类消息协议大规模进场支付网关把回调发布到Topic设备端Agent订阅Topic收到消息再驱动电机。同时RPA机器人开始在财务系统里模拟人工操作自动登录、自动批量付款、自动下载对账单。RPA严格说不算AI Agent但它证明了“机器可以自己完成一笔支付”的可行性也把“边界校验”和“审批流”这两个概念带进了自动化支付场景。协议栈在这一阶段已经叠到五层左右硬件链路、现场总线、传输、消息、支付业务。2.3 LLM Agent时代2021-2024大模型第一次摸到支付工具GPT-4带火Function Calling之后支付接口终于被封装成了“工具函数”。LangChain、Spring AI这些框架让开发者能在一个普通Java方法上挂一句“这是支付工具传入金额和订单号”大模型就能在对话里决定调用它。但这个阶段非常危险也非常早期。大模型会伪造参数、会幻觉出订单号、会被prompt注入诱导付款。所以当时绝大多数团队只能做沙箱演示不敢让Agent碰真钱。协议栈里真正新增的其实是“意图层”——也就是Function Calling规范和Tool Schema它让LLM和应用之间的交互从“聊天协议”变成了“命令协议”。2.4 MCP协议进场2024-2026支付网关变成Agent的标准化工具Anthropic开源MCPModel Context Protocol之后工具供给方式发生了一次大变化。以前每个Agent框架要自己定义Tool的格式LangChain一套、Spring AI一套、自己写的一套互相不通。MCP把工具暴露变成了统一协议支付网关只要实现一个MCP Server给出一份JSON Schema任何支持MCP的Agent都能直接调用。我见过不少团队把微信支付、支付宝当面付、对账查询都封装成MCP工具然后用Spring AI或者自己写的Agent运行时去编排调用。这个阶段才真正配得上“AI Agent支付”这个说法支付能力和Agent智能解耦了。同时工业场景开始把CAN、Modbus、SECS/GEM这些老设备协议也封装成MCP服务让Agent能直接对PLC下达生产指令并触发结算。到了2026年国内主流智能体产品已经普遍把支付能力做成内置工具中台化、插件化越来越明显协议栈也稳定在这七套左右。3. 逐一拆解这七套协议角色、代表与实战负载讲完历史我把七套协议逐一拆开说不只是报名字要讲清楚它们在一条真实支付链路里到底干了什么活。3.1 第1套硬件链路协议——Agent与收银终端的最后一步握手这套协议藏在最底层但坑最多。Agent要驱动一台收银机灵魂是MCU主控身边跟着扫码枪、钱箱、显示屏、称重模块。它们之间通常走UART、SPI、IIC或者RS-485简单、便宜、稳定。最常见的问题是UART波特率不匹配。扫码枪默认9600主控板配置成115200结果扫码数据全是乱码订单金额解析不出来Agent再聪明也没用。还有RS-485总线屏蔽层没接好半双工通信撞包传感器采集的计费数据就跳数字。蓝牙设备也要注意Core 5.3里GATT连接参数如果配得太激进握手总是超时支付凭证传不过去。我的建议是做硬件型Agent支付先把串口助手调通再谈大模型。协议栈最底层跑不通上层全是空中楼阁。3.2 第2套现场总线与设备协议——工业Agent支付的另一半如果Agent要指挥的不只是收银台而是一台售货机、一台AGV或者一台半导体封测设备就得面对现场总线协议。售货机行业最典型的是CAN总线。一个CAN报文ID标识消息类型Data段通常只有8字节你需要自己定义前4字节放订单金额单位分后4字节放货道号再加一字节校验。波特率默认500k帧过滤配错订单就发到了隔壁货道。DroneCAN则是无人机圈子里把CAN应用层协议化的方案做无人机配送代收款的团队会碰到。工业场景还有Modbus和PLC。Modbus读电表、读计量耗材生成计费单后再触发支付PLC里跑梯形图逻辑Agent通过OPC UA或Modbus TCP改变寄存器值驱动机械臂完成出货出货完成后才允许扣款。半导体封测领域则是SECS/GEM协议SECS-I和SECS-II里动辄几百个SML报文。EAP系统上线时要兼容不同设备商的GEM实现Agent想在产线上做“耗材用完自动结算”就得学会这套正经的工业报文格式。3.3 第3套网络与传输协议——信息流动的高速公路没有这一层前面那些现场总线根本跨不过几十米。TCP/IP是整个链路的地基Agent服务调用支付网关是HTTPS底层是TCP终端设备回传状态是长连接底层还是TCP。线下设备组网还经常用到蓝牙Mesh或Wi-Fi Mesh。一家商场里几十台售货机没必要每台拉网线用蓝牙Mesh组网一台作为主节点跟网关通信其余节点逐跳转发。这里要特别关注Mesh的消息时间戳支付指令兜兜转转绕了七八跳如果不做时序校验退款单和支付单的先后顺序容易错乱。3.4 第4套应用与消息协议——订单在系统间跑起来要靠它HTTP/HTTPS是最常见的应用层协议微信支付、支付宝开放平台都要求HTTPS调用。WebSocket在需要双向实时通信的场景很有用比如Agent在前端展示“正在创建支付订单…”后端通过WebSocket把订单状态推给用户。MQTT是IoT支付的主心骨。我记得有位做共享洗衣机的朋友把支付回调直接发布到MQTT Topic洗衣机端订阅“order/payed”后立刻启动程序。这里关键要把握QoS级别QoS0可能丢消息QoS1保证至少一次但不排重所以设备端必须有消息ID去重表否则一次支付触发两次洗衣启动商家得哭。如果你做直播打赏Agent还可能遇到RTMP流里夹带礼物事件Agent解析事件后触发代付这算应用层协议的一个小众变体。3.5 第5套Agent智能交互协议——大模型开始理解“支付”这个概念第五套是2024年以后新增的。MCP本质上解决的是“Agent怎么发现工具、怎么调用工具、工具结果怎么回到对话”的问题。支付MCP Server的典型形态是把自己包装成一组Tool每个Tool有名字、描述、输入输出JSON Schema。Agent看到“createPayment”这个Tool再读到注释里写着“金额单位分、收款方白名单”就知道该传什么参数。Function Calling更轻量适合单机Agent。Spring AI的Tool注解本质就是在做这件事把Java方法变成大模型可调用的结构化函数。这一层不是替代支付协议而是给支付协议套了一层“给AI看的说明书”。这里要提醒一句经常有人问MCP是软件协议还是硬件协议。答案是它是一层纯软件的契约协议不关心底下走CAN还是走MQTT它是用来给Agent“指路”的不是给设备“通电”的。3.6 第6套支付业务协议——签名、回调、退款那点事微信支付接口V3、支付宝开放平台API是离钱最近的协议。支付业务协议的核心是三件事下单、回调、退款。下单时你要按商户密钥或证书对参数排序签名把签名串放进Header回调时支付平台用它的私钥签名通知你你要验签后再更新订单退款接口同样要签名而且退款金额不能超过原订单金额。这里没有太多神奇之处但坑极其密集。很多人第一次接微信支付晚上十一点发来“用户态签名signature错误”其实就是参与签名的字段顺序错了或者对空值也做了URL编码。微信支付V3和支付宝的签名机制不一样千万别套用。这部分我在第4章会详细展开。3.7 第7套网关与对账协议——钱和账不能有半毛钱偏差第七套往往是中小团队最不重视、但出事后最难受的一套。它不是一个公开的ISO协议而是支付网关PRD里定义的内部报文规范、对账文件格式、差错处理流程。我见过一份合格的对账PRD至少要定义成交订单表、撤回订单表、交易退款表、汇总对账单。每天凌晨拉取支付平台的账单和本地订单库做轧差差一分钱也要查清楚。对账文件通常是CSV或特定分隔符格式字段顺序、日期时区、金额精度都写死在规范里Agent就算把支付流程跑通了对不上账财务还是会半夜给你打电话。4. 从0到1搭一个能付钱的AI Agent最小闭环实战讲了这么多原理落不了地等于零。我以Java技术栈举例把从0到1搭一个最小闭环的路线跑一遍这套方法已经是多个项目验证过的。4.1 先冻结业务边界再写代码启动Agent支付项目第一周不要碰代码先把业务边界冻结。需要确认的问题至少有Agent能发起的单笔支付上限是多少比如默认500元。收款方白名单有没有能不能动态加。哪些用户有权让Agent付款是仅限本人还是多人共享额度。Agent能不能发起退款退款要不要人工复审。线上支付还是测试沙箱生产前有没有灰度切换机制。回调是走HTTP还是走MQTT断电断网怎么补偿。这些问题不冻结Agent就会以一种“看起来智能但完全不可控”的方式替公司花钱。我自己吃过亏上线当天没冻结退款权限Agent收到一条恶意退款指令被prompt注入放大了直接发起退款财务系统里多出一堆退款单。4.2 用Spring AI把支付工具暴露给LLMSpring AI对Java开发者最友好的点是它能用最简单的注解把方法暴露成大模型工具不重新学一套编程模型。核心代码长这样Tool(description 创建支付订单金额单位是分收款方必须是白名单商户号) public String createPayment(String orderId, Long amount, String payee) { if (!whiteList.contains(payee)) { return 收款方不在白名单内; } if (amount 50000L) { return 金额超出单笔限额; } // 调用微信支付V3统一下单 / 支付宝当面付 return paymentService.create(orderId, amount, payee); }然后通过AgentClient或ChatModel把该Tool注册进去同时在系统提示词里强调用户请求付款时必须先确认金额、收款方、订单号三项信息金额超过限额必须请求人工审批你无权修改已创建的订单。这里的关键不只是代码而是工具描述的措辞。大模型是靠描述来理解工具边界的描述写得模糊它就可能把“分”当成“元”传进去。我建议每条Tool的描述都带上单位、限额、白名单要求三件套。4.3 微信支付与支付宝沙箱调试阶段的保命配置真实资金不能拿来联调所以两大支付平台都有沙箱。支付宝开放平台有专门的沙箱应用提供测试商家账号和买家账号应用私钥用沙箱密钥环境下单时把请求地址指向支付宝沙箱网关付款时用沙箱买家账号扫码即可。微信支付的测试环境没有支付宝那么“开箱即用”V3接口通常建议先用商户平台里的“模拟数据”或自己mock回调来测。我的经验是维护三套配置正式环境、测试环境、本地Mock环境由Spring Profile切换。代码里绝不能出现“测试key被发布到生产”这种事别问我为什么强调这一句问就是有人干过。4.4 排查signature错误的完整链路微信支付的“用户态签名signature错误”是热搜词的高频问题。第一次遇到时别慌按这条链路排查打开请求日志确认你是微信支付V2还是V3。V2用的MD5或HMAC-SHA256V3用的是证书序列号加密和请求头里的Authorization。两套完全不是一个玩法。检查参与签名的参数列表。最常见的错误是把“空值参数”也算进签名串。正确做法是值为空的字段不参与签名。检查参数排序和编码。所有字段名按ASCII码升序排列中文必须UTF-8编码RSA签名时还要注意RSA/ECB/OAEPWITHSHA-256这种填充方式。检查商户key或私钥是否和接口版本匹配。V2用APIv2密钥V3用商户API证书证书过期或者私钥密码错了都会报签名错。最后看时间戳和随机串。微信要求时间戳在5分钟内有效随机串不能重复使用。支付宝的签名机制是RSA2报“验签失败”时优先查公钥和私钥是否成对、平台公钥是否换过、参数格式是不是表单序列化。4.5 给Agent装上“人工闸门”审批与幂等Agent可以自主发起支付但不代表必须完全无人值守。我的设计是“人工审批还是自动放行”由规则引擎决定单笔小于等于200元且收款方在白名单内自动放行其余全部推送到审批流要求人在企业微信里点确认。幂等设计也不能少。支付回调可能因为网络超时被平台重试多次退款回调也一样。我习惯在数据库里加唯一约束以paymentId作为唯一键重复回调直接走“无操作返回成功”。同时用Redis做分布式锁防止多个Agent实例并发处理同一个订单。5. 2026年的现状与还没解决的坑说到现状2026年国内智能体产品的格局基本稳定主流Agent产品都把支付能力做成了内置工具支付插件市场、Agent支付中台纷纷出现做技术选型时不再需要自己从零实现那些回调逻辑。但框架成熟了不代表坑变少了。5.1 国内智能体产品支付现状扫描现在打开各大Agent平台的工具列表支付类工具已经是最常见的基础工具之一。很多中台产品把支付宝、微信支付封装成统一支付MCP ServerAgent开发者只需要申请好商户号配好密钥把Server地址填进去就能调用。这个趋势对中小团队是友好的因为省去了维护签名库、回调服务、对账任务的成本。但也要清醒这些工具大多数是把支付能力“安全地暴露”出来而不是替你的业务做决策。订单金额怎么算、退款条件怎么判、风控规则怎么配仍然要业务系统自己负责。5.2 三个最容易被忽视的坑第一个是金额精度。支付平台金额通常用“分”做单位但订单系统可能用“元”用float一乘一除就有0.1分的误差。我的习惯是订单系统里所有金额字段都用Long存分不使用浮点数计算。第二个是回调幂等。微信和支付宝都声明回调可能重复而且顺序不一定必须先查后改不能收到一次回调就无条件更新订单状态。第三个是日志泄露。支付开发里最怕把私钥、证书、签名串打到日志里我都会在日志框架里加过滤规则对出现“private_key”“certificate”“signature”关键字的日志做了脱敏替换。5.3 我踩过的一次重复退款事故复盘有一年上线Agent自动退款功能上线第三天凌晨财务被警报吵醒一笔退款重复了三遍多退了六百多块。排查发现原因很简单退款回调走MQTTQoS1的语义是“至少一次”消息重投时带着同一个messageId但我的退款处理接口没有做幂等判断。第一遍处理成功第二遍查不到单据状态变化又处理了一次第三遍同理。修法也很简单在退款表加refundId唯一约束重复消息统一返回“已处理”。但那次教训让我以后再也不会忽略“消息至少一次”这个坑凡是涉及钱的动作必须先幂等再执行。5.4 给从业者的几条建议基于这几年的实操我给同行三条建议。第一先画协议链路图再画系统架构图把每一层协议的负责节点、数据格式、故障模式都标出来这张图比任何技术文档都有价值。第二工具描述写清楚别指望大模型猜支付工具的描述里必须写单位、限额、白名单。第三MCP是工具不是银弹它能解决工具互操作问题但解决不了业务规则缺失的问题。说句实在话做了这么多年支付相关系统我越来越觉得AI Agent不是来取代协议的它是来“命令”协议的。那些老协议——UART、CAN、MQTT、HTTP、支付签名——一个都没退休反而因为Agent的到来重新变成了系统中的主角。谁能把这七层协议高效地串起来谁就能在Agent支付的下一波浪潮里站住脚。最后分享一个小技巧给Agent下单前先在沙箱里用极端值测一遍金额0、负金额、巨额金额、重复订单号把这些边界打满再放线上不迟。