AI Agent支付揭秘：从TCP/IP到MCP的协议栈与工程实践

1. 从"人点按钮"到"Agent自己下单"，支付协议栈是怎么被一层层垫高的

1.1 先讲一个翻车现场

前阵子我在调试一个AI Agent项目，功能很简单：用户用自然语言说"帮我买杯美式"，Agent自动去外卖平台下单付款。听起来很酷对吧？但真正跑起来的第一天就翻车了——Agent成功创建了订单，却在支付环节卡了整整三小时。

日志打出来，问题出在回调通知上。我用的支付网关要求配置异步回调地址，Agent把服务器IP写错了，支付成功了但回调打不进来，订单状态一直是"待支付"，Agent完全不知道钱已经扣了。最后只能靠手动同步订单，那个"自动付款"就变成了"自动下单+手动确认"，特别尴尬。

这件事让我彻底意识到：AI Agent支付，难点根本不在模型，而在协议。从Agent的HTTP请求发出，到支付网关扣款，再到异步回调通知Agent，整条链路上每一层都有一套协议在约束。你跳过任何一层，后面都会以意想不到的方式回报你。

1.2 七套协议，不是设计出来的，是堆出来的

很多人以为Agent支付是2024年才有的事，其实它的根基至少能追溯到2000年代初的在线支付。只是那时候没有Agent，协议是给网站用的；后来给了App；再后来给了机器人；现在轮到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/IP：Agent支付看不见的"快递干线"

很多做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/HTTPS：Agent的每次"下单"本质上就是一次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客户端必须支持证书校验，别图省事把verify=False写上去，那是给自己埋雷。

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 签名与OAuth2：Agent最大的拦路虎就是"签名不对"

做过支付接入的人应该都有过这种经历：所有参数都对，但接口返回"签名错误"。微信支付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年，MCP（Model Context Protocol）这个词在AI圈刷屏。很多人问，MCP和以前的API网关有什么区别？简单说，API网关是给"程序"调用的统一入口，而MCP是给"模型"调用的统一工具层。

MCP定义了一个很薄的协议层：客户端（Agent/Claude/ChatGPT这类模型应用）连接到MCP Server，Server暴露若干工具（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 worker

"AI 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的作用是帮用户找到订阅商品、触发购买意图，实际扣款还是系统支付UI，Agent拿不到密码，也碰不到银行卡号。某种意义上，这反而是最安全的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主动付款之前，先问自己一句：如果这笔钱错付了，用户会不会骂我？如果会，那就多留一个确认步骤，永远不要嫌多。