独立解读
Coinbase Agentic Wallets：让 AI Agent 自己为 API、数据和链上交易付款
项目资料 · Coinbase Agentic Wallets ↗结论先行：Coinbase Agentic Wallets 是给 Agent 用的链上钱包基础设施。其突出之处是把 Base、USDC、x402 与受控签名放在一起，适合需要访问付费 API 或执行链上动作的团队；它不是一个自动适配所有网页商户的通用银行卡钱包。
研究边界：基于公开官方资料，查阅于 2026-10-28；本文没有注册、接入或进行真实支付。功能、费用和地域以当前产品及合同为准。
它是谁，为什么进入这个市场？
Coinbase 从加密资产交易扩展到面向开发者的钱包、支付与交易基础设施。Agentic Wallets 属于 Coinbase Developer Platform（CDP）的 Agent 专用方案，官网将其描述为可供智能体支出、收款与交易的钱包，提供 Authenticate、Fund、Send、Trade、Earn 等技能，并强调 x402 与 Base 上的交易。产品与能力
这对 Coinbase 的意义不只是增加一个钱包界面：Agent 一旦持续消费链上服务，钱包、交易服务与支付网络都可能成为它的平台入口。这是基于产品组合的商业推断，不是该产品已披露的收入。
一笔 1 美元的数据采购怎样发生？
假设开发者运营一个研究 Agent，希望它购买支持 x402 的数据接口，且任何单次支出不超过 3 美元。
这是根据公开组件组合的概念流程，不是实测。实际项目还要完成账户认证、钱包入金、指定网络和支付方式、处理失败并保存交易记录。服务商必须支持相应付款方案；不是任意 API 都能自动购买。服务发现、钱包和支付处理各自是不同组件。
产品能力与控制边界
| 问题 | 官方资料能说明什么 | 还需要核实什么 |
|---|---|---|
| Agent 如何接入？ | 官网列出认证、入金、转账、交易等技能 | 目标框架、API 版本和凭证轮换 |
| 私钥在哪里？ | 官网称私钥留在隔离的 Coinbase 安全基础设施中，不暴露给 Agent 提示词或模型 | 可否导出、恢复、迁移，以及谁可修改访问规则 |
| 如何限制资金？ | 支持单次与会话支出上限 | 限额单位、跨会话累计、何种交易纳入及变更流程 |
| 如何识别风险？ | 官网描述交易筛查（KYT） | 筛查覆盖哪些网络、资产和拒绝后的处理 |
| 能支付什么？ | x402 付费服务与 Base 上相关交易是重点场景 | 目标服务是否支持、网络与资产是否匹配 |
“私钥不暴露给模型”不等于“任何 Agent 行为都安全”。 Agent 掌握可调用钱包的凭证后，仍可能在既定权限内购买错误数据或向允许的服务支付过多。签名之前的预算限制、商家范围和工具权限需要一起设计。不同 CDP 钱包并非同一产品，不能把 Server Wallet 的所有网络或安全能力直接套到 Agentic Wallet。
收费与商业模式
| 收费项目 | 本次结论 |
|---|---|
| Agentic Wallet 独立月费或交易费 | 未找到足以确认的统一报价；不能据此认定免费 |
| 网络费用 | 依网络、交易和谁承担费用而变；官网所谓 gasless 不等于所有成本为零 |
| 兑换、交易与底层服务 | 按具体路径、地区及账户核对，不能套用其他 Coinbase 产品费率 |
| 商业逻辑 | 钱包可能带来开发者、支付和交易业务的协同；属于推断 |
与 Circle、Stripe Link 如何选择？
如果主要任务是 Agent 向链上付费接口支付，Coinbase 的钱包加 x402 路径值得优先评估；Circle 的 Agent Stack 更强调 USDC、策略与服务发现的组合；Stripe Link 的 Agent 钱包则连接既有卡和银行账户，尤其适合用户逐笔批准的场景。它们解决的问题相邻，但资金来源与商户覆盖不同。
上线前建议让供应商回答：额度在什么组件执行？被盗 API 凭证能否转账？如何撤销？支付成功但交付失败如何查证？测试环境和实际地域是否可用？ 本文没有验证这些问题，不能以产品宣传代替安全测试。
两种接入方式：CLI 和 MCP 不是同一套权限
Agentic Wallet 官方文档把产品分成 CLI 和 MCP 两条路。CLI 结合 Agent Skills 和 awal 命令，官方列出认证、发送、交易、x402 付款；MCP 由服务器及配套钱包应用构成，方便兼容 MCP 的客户端发现和支付服务。文档表格称两者都可进行 x402 付款，但 MCP 中的 Agent 只能发现和付费，不支持发送与交易。
这一区分对安全设计很实际：只需要支付数据接口时，不必默认授予任意发送和交易能力。但 MCP 付款并不自动安全，依然需要确认每次请求的价格、网络、收款方和限制。反过来，要求 Agent 每日做链上资产调配的团队，即使 MCP 能付 API，也不能据此认为它有完整交易能力。
| 选择前提 | 更应研究的入口 | 采购时的追问 |
|---|---|---|
| Agent 只访问付费 API | MCP 的发现和支付 | 每次或累计支出怎样限制，支付前是否可审批 |
| Agent 需转账或交易 | CLI 列出的发送与交易能力 | 能否对目标地址、资产和每项动作分别授权 |
| 需要企业级编排 | 分别评估 CLI、MCP 与 CDP 接口 | 能否多 Agent 分账户和导出审计记录 |
官网写的会话和单笔上限是钱包控制的产品声明，但公开页面没有完整解释所有策略适用操作、是否能够被不同凭证绕过，以及规则数据如何修改。采购方应索取版本化策略文档，用受限账户尝试超额、重新认证、重启进程和并发支付，检查是否按预期拒绝；上限应由执行系统判定，而不能只写在提示词里。发布说明
一次小额请求的经济账
Coinbase 与 Exa 的 公开示例描述服务返回 HTTP 402、价格和网络，客户端支付后携带签名重新请求。文中示例价格为 0.007 USDC，网络为 Base。假设请求 1,000 次且每次价格不变，仅服务标价就是 7 USDC；这不包括可能存在的钱包服务、网络、兑换、失败请求或接入成本。这个示例说明 API 标价如何累计，不是 Coinbase Agentic Wallet 的实际收费表。
服务商侧也不同于买方钱包：Coinbase Business 的 Agent 收款页面介绍商家接入 x402 后管理、核对及提取款项。商家账户、付款方钱包和 facilitator 是否有各自价格，需要分别确认；某一方宣称免收卡拒付不代表服务失败后一定无争议或自动退款。
三个故障场景与判断
场景一：服务返回 402，但价格高于预算。 预期是 Agent 停止购买；如果支付前必须调用钱包才能发现价格，应用要先确认如何读取付款要求，不能先签名再检查。
场景二：支付完成后接口超时。 用户看到的是“没有数据”，但链上可能已有付款。系统应先查询付款凭证和服务商订单状态，再按接口规则处理；盲目重试可能造成第二笔付款。要问服务商是否提供幂等标识或凭证复用，不应假设 x402 本身统一解决。
场景三：Agent 凭证泄露。 私钥位于隔离环境并不能阻止持证者尝试调用合法接口；这时要测试是否能立即停用凭证、隔离单个 Agent、查询在途支付，以及剩余余额如何回收。托管方风险和本地开发环境风险也要分别评估。
对于只有少量、已知数据供应商的团队，购买稳定币 API 可能很顺；若绝大多数供应商要求信用卡或线下合同，它就不能单凭钱包解决商家覆盖。把“服务商能收什么”和“Agent 能用什么”一起评估，才是选型起点。
哪些公开费用可以参考，哪些不能混为一谈？
Coinbase 的 Polygon x402 Facilitator 发布公告曾列出每月 1,000 笔免费、之后每笔 0.001 美元的方案。它是公告中特定 facilitator 服务的报价，不是 Agentic Wallet 月费，也不能认定适用于其他链或今日合同。按该公告的简化计算，若当月 2,000 笔均适用这一方案，超出的 1,000 笔对应 1 美元 facilitator 费；还需核对最新费率、计费主体和其他费用。
另一个具体实例是 CDP SQL API 发布介绍列出使用 x402 查询时每次 0.10 美元，这是查询服务价格，而非钱包使用费。其普通 API key 路径按月开票，说明同一数据服务可以存在不同计费方式。最终采购应核对服务当前价格与条款，而非只复制当时公告。
Coinbase 开发平台条款指出收费服务的价格以注册或使用具体工具时显示的条款为准；因此本文把单独 Agentic Wallet 的定价保留为未确认，而不是把上面两项收费相加并声称是完整成本。