AI Agent支付七套协议详解：从网络传输到审计追溯的完整指南

1. 从七套协议看AI Agent支付的底层逻辑

1.1 为什么AI Agent支付不是“接个接口”那么简单

很多人第一次接触AI Agent支付，脑子里想的都是“调个API不就完了”。我一开始也这么觉得，直到真正动手把一个Agent从“能聊天”推到“能付钱”，才发现事情远没有想象中简单。AI Agent支付和传统互联网支付最大的区别在于：传统支付是人点按钮触发，Agent支付是程序自主决策触发。这个差异直接导致协议栈的设计逻辑完全不同。

传统支付场景里，用户打开App、选商品、点支付、跳转收银台、输入密码、完成扣款，整条链路有大量人工确认节点。而AI Agent支付的核心诉求是“自主完成”，Agent需要自己判断该不该付、付多少、付给谁、用什么通道付、付完怎么确认。这就意味着，支付能力必须被拆解成一套Agent可理解、可调用、可验证的协议层。

我梳理下来，一套完整的AI Agent支付体系至少涉及七套协议协同工作。这七套协议不是随便凑数，而是每一套都解决一个特定层面的问题。缺了任何一套，要么Agent付不了钱，要么付了钱但无法确认，要么确认了但存在安全漏洞。

1.2 七套协议的分层模型与各自职责

先给一个整体视图。这七套协议从下到上分别是：

这七层不是理论模型，而是我在实际搭建Agent支付系统时踩坑踩出来的。最开始我只用了HTTP+支付API两套，结果Agent付完钱不知道成功没有，只能傻等；后来加了Webhook做状态同步，又发现Agent可能被伪造的回调欺骗；再后来加了签名验证和预算控制，才勉强能用。

1.3 从热搜词看行业关注点的迁移

看热搜词列表很有意思。“ai agent怎么扛并发”说明大家已经开始关心生产环境的问题了，不再是demo级别。“做网站如何支付”和“易支付进件插件”反映的是中小开发者想快速接入支付能力的需求。“微信支付接口”和“支付宝沙箱支付”是传统支付通道的关键词，说明Agent支付最终还是要落到这些成熟通道上。

另一个值得注意的信号是“Coinbase”出现在热搜词里。Coinbase作为加密支付通道的代表，和AI Agent结合的逻辑很自然：Agent之间需要机器原生支付，而传统银行通道对机器不友好，加密通道天然适合程序调用。这也是为什么链上结算协议在七套协议里占了一席之地。

“mcp是软件协议还是硬件协议”这个搜索词也很有意思。MCP（Model Context Protocol）在AI Agent领域指的是模型上下文协议，是软件层面的。但很多人会把它和硬件领域的协议搞混，说明协议这个词在不同语境下含义差异很大。在AI Agent支付语境下，我们说的协议基本都是软件协议。

2. 七套协议逐层拆解与实操要点

2.1 第一层：网络传输协议——HTTP/HTTPS是基石但不够用

HTTP协议是AI Agent支付的基础。Agent调用支付接口、查询余额、接收回调，底层都是HTTP。但HTTP有几个问题在Agent场景下会被放大。

第一个问题是连接复用。传统Web应用里，用户操作是低频的，一个请求一个连接问题不大。但Agent可能在一秒内发起几十个支付相关请求，如果每个请求都新建TCP连接，握手开销会拖垮性能。我实测下来，开启HTTP Keep-Alive后，同样数量的支付请求，平均延迟从230ms降到了45ms左右。配置方式很简单，在HTTP客户端里设置连接池：

import httpx client = httpx.Client( limits=httpx.Limits(max_keepalive_connections=20, max_connections=100), timeout=httpx.Timeout(10.0, connect=5.0) )

第二个问题是错误处理。热搜词里有个“condahttperror: http 000 connection failed”和“error response from daemon: get https://registry-1.docker.io/v2/: net/http”，这些都是典型的HTTP连接失败。在Agent支付场景下，连接失败意味着支付指令可能没发出去，也可能发出去了但响应没收到。这两种情况的处理逻辑完全不同。我的做法是：对于幂等性支付接口，连接失败直接重试；对于非幂等接口，先查询状态再决定是否重试。

第三个问题是HTTPS证书验证。Agent运行环境如果证书链不完整，会直接报SSL错误。我建议在Agent部署时就把根证书更新到最新，并且不要图省事关闭证书验证。关闭验证等于把支付指令暴露在中间人攻击下，风险极大。

注意：HTTP连接复用虽然能提升性能，但要注意连接池大小和超时时间的平衡。连接池太小会导致请求排队，太大则浪费资源。我的经验值是：Agent并发支付请求数的1.5倍作为最大连接数比较合适。

2.2 第二层：身份认证协议——Agent怎么证明“我是我”

Agent支付的身份认证比人类用户复杂。人类用户可以用密码、短信验证码、生物识别，但Agent没有手指也没有手机。Agent的身份认证通常走OAuth 2.0的客户端凭证模式，或者用JWT做无状态认证。

OAuth 2.0客户端凭证模式的流程是：Agent用client_id和client_secret换取access_token，然后每次支付请求带上这个token。这里有个坑：token是有有效期的，通常2小时。如果Agent在token过期后发起支付，会收到401错误。我的处理方式是提前5分钟刷新token，并且用双token机制——旧token还没过期时就获取新token，避免刷新过程中的空窗期。

JWT认证则更适合Agent之间的支付。Agent A给Agent B付款，A用自己的私钥签一个JWT，B用A的公钥验证签名。这种方式不需要中心化认证服务器，适合去中心化Agent网络。但密钥管理是个大问题，私钥泄露等于钱包被盗。我建议用硬件安全模块或者至少用操作系统级的密钥存储来保管私钥。

热搜词里“密钥透”这个词虽然不完整，但大概率是指密钥泄露。在Agent支付场景下，密钥泄露的后果比传统应用更严重，因为Agent可以自主发起支付，不需要人工确认。我的做法是给每个Agent设置独立的密钥对，并且限制单密钥的支付额度上限。即使某个密钥泄露，损失也可控。

2.3 第三层：支付指令协议——语义清晰才能避免误付

支付指令协议的核心是定义一套Agent能理解的支付语义。这套协议要回答几个问题：付给谁（收款方标识）、付多少（金额和币种）、什么时候付（立即还是条件触发）、付了之后怎么确认（订单号）。

传统支付API通常用JSON格式传递这些信息。比如微信支付接口的统一下单请求大概长这样：

{ "appid": "wx1234567890", "mch_id": "1900000109", "nonce_str": "5K8264ILTKCH16CQ2502SI8ZNMTM67VS", "body": "AI Agent服务费", "out_trade_no": "AGENT202601150001", "total_fee": 100, "spbill_create_ip": "192.168.1.100", "notify_url": "https://agent.example.com/pay/callback", "trade_type": "NATIVE" }

这里每个字段都有讲究。out_trade_no是商户订单号，必须全局唯一。我见过有Agent因为订单号重复导致支付失败，排查了半天才发现是订单号生成逻辑用了时间戳但没加随机数，高并发下撞了。total_fee单位是分，不是元，这个坑新手必踩。notify_url是回调地址，必须公网可达，否则收不到支付结果。

支付宝沙箱支付的接口结构类似，但字段命名不同。支付宝用out_trade_no、total_amount（单位是元）、subject等。如果Agent同时接入多个支付通道，需要做一层协议适配，把统一的支付指令翻译成各通道的格式。这层适配器我建议用策略模式实现，每个通道一个策略类，新增通道时只加类不改核心逻辑。

提示：支付指令里的金额字段一定要做类型校验。我遇到过Agent因为浮点数精度问题，把0.1元算成了0.09999999元，结果支付接口报金额格式错误。建议所有金额都用整数分表示，避免浮点运算。

2.4 第四层：链上结算协议——机器原生支付的终极方案

Coinbase出现在热搜词里不是偶然。AI Agent支付的一个核心矛盾是：传统银行通道是为人类设计的，有营业时间、有额度限制、有繁琐的KYC流程。而Agent是7x24小时运行的，需要即时结算。加密支付通道天然解决这个问题。

链上结算协议的核心是交易构造和签名。Agent需要构造一笔交易，指定收款地址、金额、gas费，然后用私钥签名，最后广播到网络。以以太坊为例，一笔最简单的ETH转账交易包含nonce、gasPrice、gasLimit、to、value、data等字段。Agent需要自己计算这些值。

from web3 import Web3 w3 = Web3(Web3.HTTPProvider('https://mainnet.example.com')) transaction = { 'nonce': w3.eth.get_transaction_count(agent_address), 'gasPrice': w3.eth.gas_price, 'gas': 21000, 'to': recipient_address, 'value': w3.to_wei(0.01, 'ether'), 'chainId': 1 } signed = w3.eth.account.sign_transaction(transaction, private_key) tx_hash = w3.eth.send_raw_transaction(signed.rawTransaction)

这段代码看起来简单，但实际部署时有几个关键点。nonce管理是第一个坑，如果Agent并发发起多笔交易，nonce必须严格递增且不能有间隙，否则交易会卡住。我的做法是用一个中心化的nonce管理器，每次发交易前先锁定nonce，发完再释放。gasPrice是第二个坑，设低了交易迟迟不确认，设高了成本飙升。我通常参考最近几个区块的中等gasPrice，再上浮10%。

链上结算的确认时间也是问题。以太坊主网一笔交易可能要几十秒到几分钟才能确认。Agent如果同步等待确认，会阻塞后续操作。我的方案是异步确认：交易广播后立即返回tx_hash，Agent继续做其他事，后台起一个监听任务轮询交易回执。

2.5 第五层：状态同步协议——让Agent知道钱付没付

状态同步是Agent支付里最容易被忽视但最致命的一环。Agent发起支付后，必须可靠地知道支付结果。如果不知道结果，Agent可能重复支付，也可能该付的没付。

主流的状态同步方式有三种：Webhook回调、主动轮询、WebSocket推送。Webhook是支付通道主动通知Agent，实时性最好，但要求Agent有一个公网可达的回调地址。轮询是Agent定时查询支付状态，实现简单但实时性差。WebSocket介于两者之间，但需要维持长连接。

我实际用的是Webhook+轮询兜底。Webhook收到后立即处理，同时启动一个定时任务，如果5分钟内没收到Webhook，就主动轮询查询。这样既保证了实时性，又避免了Webhook丢失导致的状态不同步。

Webhook处理有个安全要点：必须验证签名。支付通道发来的回调请求里通常带一个签名字段，Agent需要用约定密钥验证签名，防止伪造回调。我见过有开发者图省事不验签，结果被恶意回调骗了，Agent以为支付成功实际没付。

import hmac import hashlib def verify_webhook_signature(payload, signature, secret): expected = hmac.new( secret.encode(), payload.encode(), hashlib.sha256 ).hexdigest() return hmac.compare_digest(expected, signature)

注意：Webhook回调可能重复发送。支付通道为了保证可靠性，通常会在没收到ACK时重试。Agent的回调处理逻辑必须幂等，同一笔订单多次回调只能处理一次。我通常用订单号做去重键，处理前先查一下这笔订单是否已经处理过。

2.6 第六层：风控与限额协议——防止Agent“手滑”

Agent自主支付最大的风险是“手滑”——程序bug导致重复支付、金额算错、付给错误地址。风控与限额协议就是给Agent套上缰绳。

我设计的风控层包含几个核心规则。第一是单笔限额，比如单笔不超过100元。第二是日累计限额，比如每天不超过1000元。第三是收款方白名单，只允许付给预先配置的地址。第四是速率限制，比如每分钟最多发起5笔支付。第五是异常检测，比如同一收款方短时间内收到多笔相同金额的支付，自动拦截。

这些规则用简单的规则引擎就能实现。我用的是一棵决策树：先检查白名单，不在白名单直接拒绝；再检查单笔限额，超了拒绝；再检查日累计，超了拒绝；再检查速率，超了拒绝；最后检查异常模式。每层检查都有日志记录，方便事后审计。

热搜词里“ai agent怎么扛并发”其实和风控也有关。高并发场景下，多个支付请求同时到达，风控层如果处理不当会成为瓶颈。我的做法是把风控检查做成无状态的，用Redis做计数器，每个Agent一个key，原子操作增减。这样即使并发很高，风控层也不会成为单点。

2.7 第七层：审计与追溯协议——事后能查才是真可靠

审计与追溯是Agent支付的最后一道防线。不管前面六层做得多好，总有可能出问题。出问题之后能不能查清楚，决定了系统能不能持续运行。

审计的核心是日志。每笔支付从发起到完成，全链路都要有日志。日志里要包含：时间戳、Agent标识、支付指令、支付通道、交易号、状态变化、错误信息。这些日志要集中存储，最好用结构化格式比如JSON，方便查询和分析。

链上支付还要利用区块链浏览器做追溯。每笔链上交易都有tx_hash，通过tx_hash可以在区块链浏览器上查到交易的完整信息：从哪个地址到哪个地址、金额多少、gas费多少、确认数多少。Agent的审计日志里记录tx_hash，事后对账时直接查链上数据，比信任自己的数据库更可靠。

对账是审计的延伸。每天定时跑一次对账任务，把Agent的支付记录和支付通道的账单做比对。不一致的记录要人工介入排查。我见过因为网络超时导致Agent以为支付失败但实际成功的案例，如果不做对账，这笔钱就悄悄丢了。

3. 从0到1搭建AI Agent支付系统的完整实操

3.1 环境准备与依赖安装

动手之前先把环境搭好。我用的技术栈是Python 3.11 + FastAPI + httpx + web3.py + Redis。FastAPI做Agent的Web服务框架，httpx做HTTP客户端，web3.py做链上交互，Redis做风控计数和幂等去重。

pip install fastapi uvicorn httpx web3 redis python-dotenv

环境变量用.env文件管理，不要把密钥硬编码在代码里。需要配置的环境变量包括：支付通道的API密钥、链上钱包私钥、Redis连接信息、Webhook签名密钥。

PAYMENT_API_KEY=your_api_key_here WALLET_PRIVATE_KEY=your_private_key_here REDIS_URL=redis://localhost:6379/0 WEBHOOK_SECRET=your_webhook_secret_here

提示：私钥千万不要提交到代码仓库。我建议用.gitignore把.env排除掉，生产环境用密钥管理服务注入环境变量。

3.2 支付指令的构造与签名

Agent发起支付的第一步是构造支付指令。以传统支付通道为例，需要把Agent的支付意图翻译成通道要求的格式。我封装了一个PaymentInstruction类，统一管理支付参数。

from dataclasses import dataclass from decimal import Decimal @dataclass class PaymentInstruction: order_id: str amount: Decimal currency: str recipient: str description: str callback_url: str def to_wechat_payload(self): return { "out_trade_no": self.order_id, "total_fee": int(self.amount * 100), "body": self.description, "notify_url": self.callback_url, "trade_type": "NATIVE" }

金额用Decimal而不是float，避免精度问题。转成微信支付要求的“分”时，用int(self.amount * 100)而不是round，因为round在边界情况下可能出问题。

签名环节，微信支付用MD5或HMAC-SHA256，支付宝用RSA2。签名前要先把参数按字典序排序，然后拼接成字符串，再加上密钥做哈希。这个顺序不能错，错了签名就验不过。

3.3 支付请求的发送与重试策略

发送支付请求时，超时设置很关键。我设的是连接超时5秒，读取超时10秒。支付接口通常响应很快，如果10秒还没返回，大概率是网络问题。

重试策略要区分幂等和非幂等。微信支付的统一下单接口是幂等的，同一个out_trade_no重复请求会返回相同结果，可以安全重试。但有些通道的支付接口不是幂等的，重复请求会创建多笔交易。对于非幂等接口，重试前必须先查询状态。

async def send_payment_with_retry(client, payload, max_retries=3): for attempt in range(max_retries): try: response = await client.post(PAYMENT_URL, json=payload) if response.status_code == 200: return response.json() except httpx.TimeoutException: if attempt == max_retries - 1: raise await asyncio.sleep(2 ** attempt) raise PaymentError("Max retries exceeded")

退避策略用指数退避，第一次等1秒，第二次等2秒，第三次等4秒。这样给网络恢复留出时间，也避免密集重试打垮支付通道。

3.4 Webhook回调的接收与处理

Webhook回调是Agent支付状态同步的主通道。FastAPI接收回调的代码大概这样：

from fastapi import FastAPI, Request, HTTPException app = FastAPI() @app.post("/pay/callback") async def payment_callback(request: Request): body = await request.body() signature = request.headers.get("X-Pay-Signature") if not verify_webhook_signature(body.decode(), signature, WEBHOOK_SECRET): raise HTTPException(status_code=403, detail="Invalid signature") data = await request.json() order_id = data["out_trade_no"] if await is_order_processed(order_id): return {"code": "SUCCESS", "message": "OK"} await process_payment_result(order_id, data) await mark_order_processed(order_id) return {"code": "SUCCESS", "message": "OK"}

处理逻辑里，先验签，再查重，再处理，最后标记已处理。这四步顺序不能乱。验签保证请求来自合法通道，查重保证幂等，处理是实际业务逻辑，标记是防止重复处理。

注意：Webhook处理要快。支付通道通常要求回调接口在5秒内返回，超时会重试。如果业务逻辑复杂，建议先返回成功，把实际处理放到后台任务队列里异步执行。

3.5 链上支付的构造与广播

链上支付比传统支付多了一个步骤：交易签名。Agent需要用私钥对交易进行签名，签名后的交易才能广播到网络。

async def send_chain_payment(to_address, amount_eth): nonce = await get_next_nonce(agent_address) tx = { 'nonce': nonce, 'to': to_address, 'value': Web3.to_wei(amount_eth, 'ether'), 'gas': 21000, 'gasPrice': await get_safe_gas_price(), 'chainId': 1 } signed = w3.eth.account.sign_transaction(tx, private_key) tx_hash = w3.eth.send_raw_transaction(signed.rawTransaction) return tx_hash.hex()

nonce管理我用Redis做原子递增。每次发交易前，用INCR命令获取下一个nonce，保证并发安全。gasPrice我设了一个上限，比如50 gwei，超过就等待，避免gas费失控。

交易广播后，启动一个后台任务监听回执。监听用轮询方式，每5秒查一次，查到回执后更新支付状态。如果超过10分钟还没确认，标记为超时，人工介入。

3.6 风控层的实现与参数调优

风控层我用Redis的原子操作实现。单笔限额检查直接比较金额，日累计限额用INCRBY累加，速率限制用滑动窗口。

async def check_risk(agent_id, amount, recipient): if recipient not in ALLOWED_RECIPIENTS: return False, "Recipient not in whitelist" if amount > SINGLE_LIMIT: return False, "Single payment limit exceeded" daily_key = f"daily:{agent_id}:{today()}" daily_total = await redis.get(daily_key) or 0 if float(daily_total) + amount > DAILY_LIMIT: return False, "Daily limit exceeded" rate_key = f"rate:{agent_id}" current = await redis.incr(rate_key) if current == 1: await redis.expire(rate_key, 60) if current > RATE_LIMIT: return False, "Rate limit exceeded" return True, "OK"

参数调优是个经验活。单笔限额我设的是100元，日累计1000元，速率每分钟5笔。这些值可以根据实际业务调整。如果是企业级Agent，限额可以设高一些，但一定要有上限。

4. 常见问题与排查技巧实录

4.1 支付状态不同步的排查思路

支付状态不同步是最常见的问题。表现是Agent以为支付失败，但用户实际收到了钱，或者反过来。排查思路是：先查支付通道的订单状态，再查Agent的本地状态，对比差异。

如果通道显示成功但Agent显示失败，大概率是Webhook没收到。检查回调地址是否公网可达，检查防火墙是否放行了支付通道的IP，检查Webhook处理逻辑是否抛异常导致没返回成功。

如果通道显示失败但Agent显示成功，可能是Agent误判了响应。检查响应解析逻辑，特别是错误码的判断。有些通道用HTTP 200返回业务错误，如果只看HTTP状态码就会误判。

4.2 链上交易卡住的解决方法

链上交易卡住通常是因为gasPrice设低了。矿工优先打包gasPrice高的交易，gasPrice低的交易会一直待在内存池里。解决方法是发一笔相同nonce但gasPrice更高的交易，覆盖掉原来的交易。

def speed_up_transaction(tx_hash, new_gas_price): tx = w3.eth.get_transaction(tx_hash) new_tx = { 'nonce': tx['nonce'], 'to': tx['to'], 'value': tx['value'], 'gas': tx['gas'], 'gasPrice': new_gas_price, 'chainId': tx['chainId'] } signed = w3.eth.account.sign_transaction(new_tx, private_key) return w3.eth.send_raw_transaction(signed.rawTransaction)

nonce必须和原交易相同，这样矿工只会打包其中一笔。新交易的gasPrice要比原交易高至少10%，否则矿工没动力替换。

4.3 常见问题速查表

4.4 独家避坑经验

第一个坑：不要信任任何客户端传来的金额。Agent支付场景下，金额应该由服务端根据业务逻辑计算，而不是Agent自己填。我见过Agent因为上下文理解错误，把100元付成了10000元。服务端必须做金额校验，超过预期金额的直接拒绝。

第二个坑：Webhook回调要加时间戳校验。防止重放攻击，回调请求里带的时间戳如果和当前时间差超过5分钟，直接拒绝。这个细节很多文档不会写，但实际生产环境必须做。

第三个坑：链上支付的gas费要设上限。我遇到过gasPrice突然飙升到200 gwei的情况，如果没设上限，一笔普通转账可能花掉几十美元手续费。设上限后，超过就等待，等gas费降下来再发。

第四个坑：日志要脱敏。支付日志里可能包含密钥、Token等敏感信息，记录前要脱敏。我通常只记录订单号、金额、状态，不记录完整的请求和响应体。

第五个坑：对账要自动化。人工对账迟早会出错，而且效率低。我写了一个定时任务，每天凌晨跑一次对账，把Agent的支付记录和通道账单做比对，不一致的自动发告警。

4.5 性能优化与并发处理

Agent支付系统在高并发下的瓶颈通常在三个地方：HTTP连接池、Redis操作、数据库写入。

HTTP连接池前面说过了，调大max_connections就行。Redis操作要注意避免大key和热key。风控计数器的key按Agent ID分片，避免所有Agent共用一个key。数据库写入用批量插入，不要一条一条写。

如果并发量真的很大，可以考虑把支付请求放到消息队列里异步处理。Agent发起支付后立即返回“处理中”，后台worker从队列里取任务执行。这样前端响应快，后端也能控制消费速率。

提示：异步处理虽然能提升吞吐量，但增加了系统复杂度。如果并发量不大，同步处理更简单可靠。我建议日支付量低于1万笔时用同步，超过再考虑异步。

4.6 安全加固的五个关键点

第一，所有支付接口必须走HTTPS，不允许HTTP。第二，密钥必须加密存储，不能用明文。第三，Webhook必须验签，不能信任未验证的回调。第四，风控规则必须覆盖单笔、日累计、速率、白名单四个维度。第五，审计日志必须完整且不可篡改，建议用只追加的日志存储。

这五点看起来简单，但每一点都有细节。比如密钥加密存储，用什么加密？我建议用操作系统级的密钥管理，比如Linux的keyring或者云服务商的KMS。不要自己写加密逻辑，容易出漏洞。

4.7 从单Agent到多Agent支付的扩展

单Agent支付跑通之后，下一步通常是多Agent协作支付。比如一个主Agent协调多个子Agent完成任务，每个子Agent需要支付自己的费用。这时候需要解决几个新问题：子Agent的身份认证、预算分配、支付权限隔离。

我的做法是给每个子Agent分配独立的支付凭证和预算额度。主Agent负责分配预算，子Agent在预算范围内自主支付。子Agent的支付记录汇总到主Agent，由主Agent统一对账。这样既保证了子Agent的自主性，又保证了整体可控。

多Agent支付的协议层需要增加一个协调协议，定义主Agent和子Agent之间的支付指令传递格式。这个协议可以基于现有的消息队列实现，也可以用HTTP API。关键是保证指令的可靠传递和状态同步。

5. 协议演进的观察与个人体会

七套协议不是一成不变的。随着AI Agent支付场景的丰富，协议层也在演进。我观察到几个趋势。

第一个趋势是支付指令协议的标准化。目前各支付通道的API格式各不相同，Agent接入多个通道需要写多套适配代码。未来可能会出现统一的Agent支付指令标准，类似传统支付领域的ISO 8583，但更轻量、更适配Agent场景。

第二个趋势是链上结算协议的普及。随着Layer 2解决方案成熟，链上支付的成本和确认时间都在下降。Agent之间的小额高频支付，链上结算比传统通道更有优势。Coinbase等通道已经在探索Agent原生的支付接口，这个方向值得关注。

第三个趋势是风控协议的智能化。目前的风控主要是规则引擎，未来可能会引入机器学习模型，根据Agent的历史行为动态调整限额和风控策略。比如一个一直表现正常的Agent，可以适当放宽限额；一个新接入的Agent，限额设紧一些。

我个人在实际操作中的体会是：Agent支付系统的核心不是支付本身，而是信任。Agent要信任支付通道会如实执行，支付通道要信任Agent不会乱来，用户要信任Agent不会乱花钱。七套协议本质上是在不同层面建立和维护这种信任。协议设计得好，信任成本就低；协议设计得差，信任成本就高，最终要么Agent不敢付，要么用户不敢用。

最后分享一个小技巧：在Agent支付系统上线前，一定要做压力测试和故障演练。压力测试验证高并发下的表现，故障演练验证异常情况下的恢复能力。我通常会模拟网络中断、通道故障、Webhook丢失、链上交易卡住等场景，看Agent能不能正确处理。这些演练能发现很多平时想不到的问题，比看文档管用得多。