如何选择 Agent Wallet？先问这八个问题

你想让 Agent 用 1 美元购买一份数据。搜索“Agent Wallet”会看到现成钱包、钱包 API、签名服务、银行卡凭证和支付协议。它们都可能参与这笔交易，却解决不同问题。

选型不妨先写下你的任务：谁的钱、买什么、允许花多少、谁可以撤销，以及服务失败后怎么处理。 有了这五个答案，再看产品宣传页面。

本文范围：这是选型框架，例子均为假设；未对任何产品进行支付或安全实测。官方资料查阅日期为 2026 年 10 月 28 日。费用、网络和可用性应在采购时再次确认。

从任务出发

flowchart TD A[Agent 要购买什么？] --> B{商家接受什么？} B -->|卡支付| C[检查卡凭证与商家结账] B -->|稳定币或链上支付| D[检查资产网络与钱包] C --> E[设计限额审批和撤销] D --> E E --> F[验证支付结果与交付] F --> G[记录费用对账和异常处理]

图中两条路径可以在同一产品中共存。先选商家接受的支付路径，再判断钱包是否匹配；钱包支持某种资产，不意味着商家会收。

1. 谁的钱，谁能动？

确认资金属于最终用户、企业还是服务商；再确认谁能发起交易、谁能批准、谁可以恢复或更换密钥。“非托管”是值得核实的描述，但不能单独回答全部控制问题。

要问的问题	实际意义
私钥或签名能力由谁控制？	Agent 或服务受损时，攻击者能做什么
谁能修改策略、添加签名者或恢复账户？	管理权限可能比普通付款权限更大
厂商停止服务时如何迁移？	影响能否继续控制和使用资产
是否存在其他可绕过策略的签名路径？	决定额度是否覆盖实际风险

可信执行环境（TEE）是一种隔离执行环境；多方计算（MPC）让多个参与方通过密码学协作完成操作。这些术语说明实现思路，并不能直接告诉你谁拥有控制权。

2. Agent 被允许做什么？

可检查单笔限额、累计限额、有效期、收款方、允许调用的合约，以及超过条件时的审批流程。尤其要问限制是在 Agent 提示词、应用服务器、签名服务，还是智能合约执行。不同位置的威胁模型不同。

假设每天额度为 10 美元、每笔不超过 3 美元：如果只限制转账而未限制相关合约调用，是否仍可能通过其他授权移动资金？答案必须由具体规则和实测给出。

3. 支持哪条支付路径？

路径	适合先问	常见遗漏
卡或虚拟卡	商家、发卡行和卡网络是否支持？	用户授权不等于发卡方批准
稳定币	资产与网络是否和商家一致？	同名资产跨网络不一定可直接使用
x402 等付费请求	客户端和服务方是否支持相同版本与方式？	协议本身不会代替预算管理或钱包

钱包厂商所列的网络清单还要细分到具体操作：创建地址、转账、代币、交易模拟和测试网支持可能不同。

4. 一次购买总共多少钱？

购买价之外，可能还有钱包服务费、网络费（Gas）、入金和出金费、兑换价差、跨链费用以及服务端收费。谁承担这些费用、何时扣除，要逐项问清。

例如数据标价 1 美元，只是商品价格。如果用户另外支付 0.02 美元的网络费，总支出就是 1.02 美元；这只是算术示例，并非任何产品的报价。频繁小额支付尤其需要比较总成本。

5. 如何接入，谁负责维护？

使用方式	可能更适合	仍要确认
现成 Agent 钱包或客户端	想快速完成有限任务	权限是否符合使用需求
SDK / 钱包 API	为自己的产品构建体验	身份、密钥、重试与用户支持
签名与策略基础设施	需要深度定制控制流程	自己还需组合钱包、协议及业务系统

先跑通一个测试网络或不涉及资金的示例，再测试相同工作流在生产环境里的差异。需要企业验证、地区准入或商业协议时，将其计入上线时间。

6. 服务失败时如何处理？

付款状态和交付状态应分别记录。遇到超时，先查询原交易和订单状态，再依据商家支持的幂等机制决定是否重试；不要简单地重新付款。还需确认退款由谁发起、资产能退到哪里、失败如何通知用户。

7. 撤销和恢复能否真正执行？

验证会话过期、额度变更、签名者移除、账户恢复和服务中断场景。撤销通常约束未来行为，不能假设它会逆转已经确认的交易。已签署或等待处理的请求如何处理，要查具体实现。

例如，Turnkey 策略文档明确列出了根用户法定人数可绕过策略的情况；Privy 策略文档目前说明策略默认由安全环境执行；另一些合规筛查或交易模拟可能在安全环境外进行，且不属于策略执行。具体限额涉及哪些检查，仍需向供应商核实。它们说明了为什么应核对具体控制点，而不是仅比较宣传标签。

8. 用同一个实验比较候选方案

在条件允许时，对每个候选方案运行同一套任务并保留证据：

场景	检查什么	记录结果
允许的 1 美元购买	能否付款并交付	网络、费用、时间、交易与交付状态
超过单次额度	是拒绝、等待审批还是继续	提示、执行点及状态
预算不足	是否在付款前阻止	错误信息与是否产生费用
服务超时	是否能查到付款与交付状态	重试方式、重复付款风险
撤销后再购买	新请求能否继续	生效时间、旧会话和待处理请求

表中是测试计划，不是测试结果。测试前应核对测试环境、权限、费用与资金风险。对不能测试的项目直接标记“未验证”，比补一个看似完整的结论更有用。

最终选型依据应是：你的任务能否完成、风险边界能否解释、费用是否可承受、团队能否维护，以及发生问题后能否恢复。没有一种钱包适合所有场景。