1. 从人点按钮到Agent自己下单支付协议栈是怎么被一层层垫高的1.1 先讲一个翻车现场前阵子我在调试一个AI Agent项目功能很简单用户用自然语言说帮我买杯美式Agent自动去外卖平台下单付款。听起来很酷对吧但真正跑起来的第一天就翻车了——Agent成功创建了订单却在支付环节卡了整整三小时。日志打出来问题出在回调通知上。我用的支付网关要求配置异步回调地址Agent把服务器IP写错了支付成功了但回调打不进来订单状态一直是待支付Agent完全不知道钱已经扣了。最后只能靠手动同步订单那个自动付款就变成了自动下单手动确认特别尴尬。这件事让我彻底意识到AI Agent支付难点根本不在模型而在协议。从Agent的HTTP请求发出到支付网关扣款再到异步回调通知Agent整条链路上每一层都有一套协议在约束。你跳过任何一层后面都会以意想不到的方式回报你。1.2 七套协议不是设计出来的是堆出来的很多人以为Agent支付是2024年才有的事其实它的根基至少能追溯到2000年代初的在线支付。只是那时候没有Agent协议是给网站用的后来给了App再后来给了机器人现在轮到Agent自己。我把整条链路拆开数了一下真正绕不开的协议一共有七套协议/规范在支付链路里扮演的角色Agent感知度TCP/IP网络传输的底层管道所有支付报文的快递干线低但断了就全停HTTP/HTTPS支付请求的承载协议REST接口的基础高Agent每次调用都在用WebSocket服务端主动推送、长连接通知中回调/状态推送可选OpenAPI / JSON-RPC支付接口的机器可读契约与远程调用规范高Agent读API文档靠它OAuth2 / 签名规范授权、鉴权、防篡改高Agent要会签报文支付网关专有协议微信支付V3、支付宝开放平台、三方聚合各自的报文规范高不按它来就报错MCPModel Context Protocol把支付能力封装成Agent可直接调用的工具协议极高Agent支付的新范式这七套不是同一时代的东西TCP/IP是上世纪70年代的HTTP/HTTPS是90年代的WebSocket是2011年定稿的OpenAPI是2015年前后普及的OAuth2是2012年的标准支付网关专有协议是2010年后国内支付大战时各家的地盘MCP则是2024年底突然火起来的新物种。所以七套协议堆出来的AI Agent支付说的不是一套精美架构而是四十年网络基础设施和十五年移动支付经验在Agent时代撞到了一起。2. 底层三件套TCP/IP、HTTP/HTTPS、WebSocket先给Agent打好地基2.1 TCP/IPAgent支付看不见的快递干线很多做AI Agent的人不太关心TCP/IP觉得这是网络工程师的事。但你只要碰过一次连接超时或Connection reset by peer就知道TCP层不稳定Agent连支付网关的门都摸不到。TCP/IP在Agent支付里的职责很简单保证Agent所在服务器和支付网关服务器之间有一条可靠的字节流管道。下单请求是一个HTTP报文这个报文从Agent这边出发要经过TCP分段、IP路由、可能还有TLS握手最后到达支付网关的Nginx。任何一段网络抖动都会导致支付请求被重复发送或丢失。实际写Agent支付逻辑时我一般会在HTTP客户端层设置连接池和超时参数。比如用Python的httpx连接池大小给到100超时设成5秒连接、10秒读取。不要小看这两个参数Agent在并发支付场景下如果没有连接池每个请求都新建TCP连接光握手就能把延迟拉高三倍高峰时直接把支付网关的连接数打爆。2.2 HTTP/HTTPSAgent的每次下单本质上就是一次POST支付网关对外暴露的几乎都是HTTP接口。微信支付V3、支付宝开放平台、国际上的Stripe全部走REST风格。Agent要做的事很直白构造JSON报文带上商户号、订单号、金额、回调地址然后POST到指定接口。这里有个Agent项目特别容易踩的坑金额和幂等。人类写代码时知道金额要用分为单位、订单号不能重复但Agent用自然语言生成请求参数时很容易把10元直接写成10而支付网关要的是1000分。所以我在Agent的提示词里强制加了一条规则所有金额必须转换为最小货币单位并且用订单ID作为幂等键。幂等键这件事多说一句。HTTP在网络上可能会超时重试Agent拿不到响应时会自己重试。如果没有幂等键同一个订单被提交两次用户就会被扣两笔钱。支付宝和微信都把幂等键作为必填参数这就是在HTTP协议之上加了业务层语义Agent不遵守就出事。HTTPS则为这条链路加了一层防窃听的壳。支付请求里有用户openid、银行卡号、地址等敏感信息如果走明文HTTP路由器上随便抓包都能看到。现在正规支付网关强制TLS所以Agent的HTTP客户端必须支持证书校验别图省事把verifyFalse写上去那是给自己埋雷。2.3 WebSocket与Webhook支付状态从轮询变成你喊我HTTP本身是单向的客户端发请求服务端给响应。但支付是异步的——用户扫码后可能要几十秒才确认付款支付网关确认完要通知商户这时候HTTP那一套就尴尬了。最早的解决方案是轮询Agent每隔几秒去查一次订单状态。粗暴但是有效缺点是浪费资源而且查得不够快用户就以为卡死了。后来微信支付和支付宝都用Webhook回调的方式商户提供一个回调URL支付网关在支付成功后主动POST一条消息过去。再后来WebSocket也加入进来。一些聚合支付平台和自建支付网关支持WebSocket长连接支付状态实时推给客户端。Agent如果连着WebSocket用户刚扫码确认Agent这边就能收到支付成功事件直接触发后续的核销、发券流程体验比轮询好太多了。在Agent支付里我建议把回调看成是一个外部事件源Agent的请求-响应模型必须迁就它。比如用FastAPI写回调接口时要立刻返回SUCCESS给支付网关然后丢进消息队列慢慢处理不要让Agent在回调里同步调用一堆LLM推理那样很容易把回调超时拖爆。支付网关回调超时后会自动重试重试多了你的错误日志会很难看。3. 中间那层OpenAPI、签名规范和支付网关专有协议把支付能力变成Agent能读的说明书3.1 OpenAPI让Agent不用再问接口参数是什么2015年之前接入支付接口靠的是PDF文档人读都费劲更别说程序自动对接。OpenAPI规范普及之后支付平台把接口定义写成机器可读的YAML/JSON里面清楚写明了每个接口的路径、请求参数、响应结构。这件事对Agent支付的意义非常大。Agent不能像人一样翻几十页文档但它可以加载OpenAPI定义按照schema生成合法请求。我在LangChain项目里试过把微信支付的OpenAPI JSON喂给Agent当工具描述配合few-shot示例Agent能在不知道SDK源码的情况下准确构造出创建订单的JSON报文。当然OpenAPI只是说明书支付平台真正认的是签名和权限。说明书可以帮你拼报文但能不能通过验证取决于下一层的签名规范。3.2 签名与OAuth2Agent最大的拦路虎就是签名不对做过支付接入的人应该都有过这种经历所有参数都对但接口返回签名错误。微信支付V3用的是商户私钥对请求报文做SHA256-RSA2048签名支付宝用的是RSA2签名Stripe用的是API Key JWT。签名的作用是防止报文被篡改也验证调用方身份。Agent天生不擅长这个。因为签名算法要求字节级准确自然语言模型在拼接字符串时经常多一个空格、少一个换行签名就全乱了。我的处理办法是绝不让Agent自己拼签名字符串而是封装一个签名工具函数出来Agent只传业务参数签名由代码完成。OAuth2的情况类似。Agent要操作用户的钱包必须先拿到用户授权。支付平台的OAuth2流程一般是Agent引导用户到授权页用户同意后拿到授权码再换取access_token。这个流程里有个决策点什么时候该让人类介入。我的经验是支付授权必须有一步人工确认不能完全交给Agent否则用户可能根本不知道自己的钱被花出去了。这也算一种合规保险。3.3 支付网关专有协议微信、支付宝、三方聚合各有各的脾气严格说支付网关专有协议不能算一套但它确实是Agent支付里绕不开的一层。以微信支付V3为例创建订单要POST /v3/pay/transactions/native回调通知用AES-256-GCM解密退款接口要申请证书各种API版本还不同。支付宝开放平台又是另一套参数按application/x-www-form-urlencoded编码签名用RSA2异步通知要验签。对Agent来说最稳妥的方式是用官方SDK别自己裸调HTTP。SDK帮你把签名、加解密、回调验签全部封装好了Agent只要调用SDK提供的高层方法就行。我在项目里用过一个取巧的方案把SDK包装成MCP工具这样Agent不用理会底下是微信还是支付宝统一走create_payment一个入口。三方聚合支付平台比如易支付则是把微信、支付宝、云闪付全部聚合到一个接口对接门槛低很多个人站长做网站支付时喜欢用。这类平台通常需要进件也就是提交商户资料开通收款能力。Agent支付如果走聚合平台好处是接口统一坏处是平台的风控和结算政策不稳定建议只小流量测试。4. 转折点MCP协议出现之后Agent支付的玩法彻底变了4.1 MCP到底是什么别把它当成又一套API网关2024年底到2025年MCPModel Context Protocol这个词在AI圈刷屏。很多人问MCP和以前的API网关有什么区别简单说API网关是给程序调用的统一入口而MCP是给模型调用的统一工具层。MCP定义了一个很薄的协议层客户端Agent/Claude/ChatGPT这类模型应用连接到MCP ServerServer暴露若干工具tools每个工具有名字、描述、输入输出schema。模型根据用户意图自动选择合适的工具并生成调用参数。从支付的角度看MCP把创建订单查询订单退款这些动作封装成了模型可以理解并调用的原子技能。以前Agent调用支付接口要写一堆工具函数还要在提示词里费劲解释每个函数怎么用有了MCP之后Agent通过协议自动发现工具、读取schema、生成调用接入成本低了一个量级。这算是Agent支付协议栈真正的转折点。4.2 用MCP把支付变成Agent的手和钱包假设我想让Agent做一个用户说一句话就能完成商品购买的能力用MCP实现的话流程可以拆成四步第一步启动一个MCP Server注册三个工具create_order(product_id, amount, user_id)、confirm_payment(order_id)、query_refund_status(refund_id)。第二步Agent通过MCP协议拿到这三个工具的schema写进上下文中。第三步用户说我要买那本书Agent调用create_order拿到一个支付二维码链接或收银台URL。第四步用户扫码付款后支付网关回调更新订单状态Agent收到回调触发事件再调用confirm_payment完成闭环。这里最关键的点是支付动作从写死在代码里变成了模型根据语义动态决定。Agent不再是一套固定流程机器而是可以像一个真实助理那样在多个支付场景中自由切换。当然这也意味着你要做好权限控制不然Agent可能在用户说完买之后就真的把钱扣了连个确认都不问。4.3 我在实测MCP支付时踩过的坑都说MCP香但真正落地支付场景坑也不少。第一个坑是上下文爆炸。MCP工具描述如果太长Agent的prompt会变得很大响应延迟直线上升。我的优化办法是把工具描述写得精炼并把工具数量控制在8个以内。支付相关的工具其实用不了太多核心三四个就够剩下的用参数组合表达。第二个坑是工具调用结果里包含大量无关信息。比如调用查询订单返回的JSON里有时会带退款详情、营销信息、优惠活动等Agent解析时很容易被干扰。我直接在后端把返回结果裁剪成一句话摘要再返回给Agent。这样既省token又减少幻觉。第三个坑是回调鉴权。MCP Server接收支付回调时如果直接透传给Agent很容易被伪通知攻击。我现在的做法是MCP Server先做验签和解密确认消息是真的支付结果之后才把结果交给Agent处理。这一层绝不能省否则别人伪造一个支付成功回调Agent就会发货了。5. 现状扫描Agent支付在真实项目里的选型、并发和合规5.1 AI Agent怎么扛支付高并发asyncio、连接池和Rust workerAI Agent怎么扛并发是社区里问得很凶的问题。支付场景下尤其明显Agent不是单线程聊天它可能在同时处理几百个用户的购物意图每个都要创建订单、查余额、等回调。我的基本盘是Python FastAPI asyncio。同步阻塞IO比如requests在这种场景下是灾难一定要用httpx.AsyncClient。数据库连接和Redis连接也都用异步版本否则Agent一旦同时处理五十个会话事件循环会被数据库连接等待卡死。如果量再往上走比如秒级千单Python那边就算用了异步也还是有性能天花板。我的思路是拆支付请求的接收、验签、幂等判断这些轻逻辑用Python处理而报文签名计算和回调数据解密这种CPU密集操作丢给Rust写的worker去处理。我之前用Rust写过一个小型签名服务WebAssembly编译成本低、性能好Python这边只要通过IPC或者内存队列把raw报文送过去Rust worker算完签名再送回来。当然Rust不是唯一选择如果你团队不熟Rust也可以用Go或者直接上云函数。关键是设计原则Agent编排和业务逻辑是一层支付协议处理是另一层尽可能让协议层无状态水平扩展才容易。并发场景下还有一个隐藏问题支付回调重试风暴。高峰期如果Agent在处理回调时宕机支付网关会把几万个回调压过来直接把MCP Server打崩。我的办法是回调接口先落库立即返回SUCCESS真正的支付后处理发货、通知用户、触发下一个Agent动作放进任务队列慢慢消费。这样就算队列堆积也不会丢消息最多延迟。5.2 FastAPI LangChain LangGraph编排支付状态机的实战经验很多Agent项目现在用LangGraph来编排复杂的多步骤任务因为支付本质上是一个状态机创建订单 → 等待支付 → 支付成功/失败 → 退款/完成。用LangGraph的好处是能把Agent的决策循环和固定流程拆开。我搭过的一套流程大概是入口FastAPI接收用户消息转给LangGraph Agent。节点1意图识别判断用户是不是真的要买东西。节点2商品检索从商品服务和库存系统拿数据。节点3创建订单调用支付MCP工具拿到支付链接。节点4等待回调把Agent的状态挂起来等Webhook事件唤醒。节点5支付成功后再校验一次库存然后发货。这里最灵活的设计是等待回调这个节点。LangGraph可以设置一个异步事件循环当Webhook到达时往队列里塞一个事件Graph的某个节点监听队列并继续执行。不要尝试在回调线程里直接驱动Graph那样状态会乱。另一个经验是每个节点都要有重试和超时。Agent调用支付MCP工具时如果网络抖动导致超时不能直接报错退出最好重试两次。但如果重试还失败就该把控制权交还给用户让人类决定是继续等还是换支付方式。支付这事的容错设计原则就是宁可慢不能错。5.3 网站支付、Android订阅支付和三方进件的接入方式差异做网站支付最基础的方案是后台生成二维码用户扫码付款。这块用微信支付Native支付或者支付宝当面付都行Agent要做的就是把支付链接以二维码形式发给用户。技术上不复杂但要注意用户身份的传递Agent一开始不知道用户是微信里的谁所以要用一个商户订单号把用户会话和支付订单绑在一起。Android订阅支付又是另一套。Google Play和国内安卓渠道都有各自的订阅协议Agent要拉起支付时一般是通过Deep Link跳转到Play商店完成结算。这里Agent的作用是帮用户找到订阅商品、触发购买意图实际扣款还是系统支付UIAgent拿不到密码也碰不到银行卡号。某种意义上这反而是最安全的Agent支付方式——Agent只负责发指令不碰钱。三方聚合平台的进件我前面提过就是提交商户资料。现在的聚合支付平台基本都有API进件接口可以把用户提交的营业执照、结算银行卡、法人都手机号等资料打包上传。Agent如果能处理好信息采集和状态查询就能做一个入驻助手。但说实话这个场景非常敏感如果平台本身不合规Agent就是在助纣为虐。我个人的原则是只接有支付牌照的持牌机构接口别碰那种三无通道。5.4 合规红线人机验证、限额和可追溯聊到现状不提合规都是耍流氓。Agent支付最大的争议是AI到底能不能替人类做主花钱目前主流做法是Agent建议人类确认。所有大额支付在执行前都应该有一个人机验证环节。我在项目里做了三层保护第一层单笔限额超过500元必须人工扫码确认。第二层全天累计限额Agent自己每天的支付总额封顶防止用户误授权后被连续扣款。第三层完整操作日志Agent每一次支付动作都记录用户ID、订单号、金额、时间戳和调用来源方便事后审计。很多人觉得这样麻烦但Agent支付本来就不该追求完全自动化。支付是金融行为金融的第一原则是可追溯、可撤回效率排在后面。真正成熟的Agent支付应该是高度自动化地完成繁琐步骤但关键决策永远留给人。6. 七套协议还没完MCP之后的故事从TCP/IP到MCP支付协议栈从来没有停止过演进。我个人的判断是未来很长一段时间里Agent支付会分成两条路线一条路线是AI辅助人类支付Agent把下单、优惠计算、支付链接生成全部做好最后一步让用户在手机上扫码确认。这是当前最稳妥的落地方式很多电商和外卖场景已经在跑。另一条路线是Agent之间互相支付。Agent帮企业采购、帮开发者调用API、帮内容创作者做分账它不再每一次都问人类而是通过预授权、预算池、账单协议这些机制在额度范围内自主完成交易。这条路现在还非常早期但它对协议栈又提出了新要求跨机构身份、分账结算、信用额度、自动对账——每一层几乎都要长出新的协议。我最近在盯的一个方向是支付MCP Server的白名单化。随着MCP生态火爆会出现越来越多支付类MCP Server但安全问题也会随之而来。你接了一个来路不明的MCP Server它可能是恶意钩子等着窃取你的支付密钥。我的建议是自己实现支付MCP Server或者只接入知名机构官方发布的密钥永远不要离开自己的进程。回到那七套协议TCP/IP是主干道HTTP是信封WebSocket是门铃OpenAPI是说明书OAuth2和签名是钥匙支付网关协议是保险公司MCP是给Agent装上的一双新手。七套堆在一起才让AI Agent从只会聊天变成能干活、会花钱。但协议是死的判断始终要给人留一道闸门。做Agent支付这两年我最深的体会是技术难度没有想象中大真正难的是在自动化程度和风险控制之间找到平衡点。每一次让Agent主动付款之前先问自己一句如果这笔钱错付了用户会不会骂我如果会那就多留一个确认步骤永远不要嫌多。