独立解读
Bankr：钱包 API、交易 Agent 与 x402 服务如何组成产品？
结论先行：Bankr 面向链上交易与 Agent 开发，既提供直接钱包操作接口，也提供自然语言 Agent 接口及付费 API 服务。分析它必须把 Wallet API、Agent API、Bankr Club 和 x402 Cloud 分开；它们的能力与收费单位不同。
资料核查 2026-10-28；本篇没有注册、调用接口或进行交易。
产品背景与目标用户
Bankr Wallet API 文档将其定位为直接操作钱包的接口，可用于查询余额、兑换、转账、签名和广播；Agent API则以 Agent 能理解的请求执行任务。前者适合开发者已知精确动作，后者适合使用自然语言编排的场景；二者不能因都出现“Agent”就当成同一接口。
| 组成 | 面向谁 | 主要任务 |
|---|---|---|
| Wallet API | 需要明确钱包操作的开发者 | 查询、转账、签名、广播、兑换 |
| Agent API | 想让 Agent 解释并执行请求的开发者 | 输入任务，由 Agent 处理 |
| Bankr Club | 使用 Bankr 终端与相关功能的订阅者 | 订阅使用额度与功能 |
| x402 Cloud | 提供付费端点的服务商 | 托管及按次收费的服务 |
同一个任务，两条路径
假设一个研究 Agent 需要访问收费数据 API。开发者如果已经知道 API 地址和金额，可以调用钱包支付接口；如果希望 Agent 先理解复杂任务，也可能通过 Agent API 编排。两者授权范围、运行过程和失败处理不同。
图仅表达概念组合，不证明所有 Agent API 请求都通过同一 Wallet API。官方文档说明 Wallet API 的读操作与交易操作使用不同权限；/wallet/x402-pay 支持请求付费 URL，并在文档所述范围内设置最高付款金额。实际调用参数和版本请查接口文档。
接口能力与风险边界
| 能力 | 用户得到什么 | 应核验的问题 |
|---|---|---|
| 钱包余额查询 | 查看资产及持仓 | 数据延迟与支持网络 |
| 签名和提交 | 自动化链上操作 | API key 是否可转移全部资产 |
| Swap 和转账 | 兑换与移动资产 | 报价、滑点、失败及网络费 |
| x402 支付 | 为支持的付费端点准备交易 | 限额按次还是累计、失败如何重试 |
| Agent 请求 | 通过自然语言执行任务 | 如何控制工具权限及审批 |
开发者安全文档强调 API 凭证安全。权限开关不是完整预算体系：一个能签名或转账的凭证，若没有额外约束，可能比一次付费 API 所需的权限大得多。必须分别验证目的地址限制、每日累计额度、密钥撤销及审批能否满足自身要求。
商业模式：订阅和服务交易费分别计算
截至查阅日，Bankr Club 文档列出每月 20 美元或每年 198 美元，终端和 Agent API 的不同使用上限应分别看；这不是 Wallet API 或所有交易的统一价格。
x402 Cloud 价格页描述卖方服务：免费档每月最多 1,000 个结算请求；Pro 列示 5% 平台费，Enterprise 列示 3% 且需联系。文档对超出免费额度后的适用方式及特殊资产另有规则，部署前应核对现行页面与合同。平台费不是 Agent 支付者的通用钱包费。
| 收费单元 | 示例 | 不等于 |
|---|---|---|
| Club 订阅 | 终端与 Agent 服务套餐 | 所有 API、交易和网络免费 |
| x402 Cloud 平台费 | 卖方向调用者销售付费接口 | 每个钱包转账都收取相同费率 |
| 链上 / 交易费用 | 网络和兑换成本 | 固定月费已覆盖 |
与 Coinbase 和 MetaMask 的区别
Coinbase 更突出受控钱包与 x402 支付的开发平台入口；MetaMask 更突出用户设置链上交易规则与审批；Bankr 同时有直接钱包 API、Agent 和服务端变现产品。要比较，应把同一个 $1 API 支付拆为权限、签名、限额、失败恢复和完整收费，并要求供应商解释具体钱包托管和恢复机制。
仍需验证：钱包密钥控制、权限执行点、地区资格、资产和链支持、重复支付保护，以及 API 凭证泄露后的实际冻结效果。本文未进行接口或交易测试。
从 API key 到真实权限：先理解谁能做什么
Bankr API key 文档说明 key 是账户级凭证，各 key 可以独立设置权限；文档提醒新 key 默认可读写，并建议按需启用接口、限制 IP、将生产 Agent 放在单独账户与钱包中。只给研究 Agent 一个“能查余额”的 key，与让它拥有签名、广播和转账能力，是完全不同的风险级别。
一次可复核的上线流程应当是：先在测试或独立账号准备钱包；创建只满足当前任务的 key；设置可用接口、只读或写入、IP 及收款人限制；小额资金验证后，再记录每个请求和结果。是否支持每个产品都需要的交易限额，必须按实际配置确认。转账目的地址允许名单也不能替代对所有合约调用和签名消息的理解。
| 凭证泄露情况 | 可能暴露的动作 | 使用者要准备的应对 |
|---|---|---|
| 只读凭证 | 账户和资产信息 | 撤销 key、检查访问日志 |
| 可写钱包凭证 | 文档列出的受权钱包操作 | 立即停用 key、冻结相关入口并检查在途交易 |
| Agent API 凭证 | 可触发授权的 Agent 任务 | 限制任务可调用工具，避免将密钥写入模型上下文 |
| 主账户与 Agent 共用 | 难以隔离受影响范围 | 预先使用独立钱包和有限资金 |
上表是威胁建模，不代表本站已经验证所有控制都能覆盖每个操作。关键问题是：单独调用签名和广播接口时，是否同样受收款对象或金额规则约束？
用公开收费做两个简单测算
场景一：Bankr Club。 官方 Club 定价列每月 20 美元或每年 198 美元。如果以整年持续订阅为例，按月支付是 240 美元，年付标价为 198 美元，相差 42 美元；这只是订阅费用比较，不包括交易费用、网络费用及其他服务用量。Agent API 的请求上限与终端消息限制按文档分别计算。
场景二：x402 Cloud。 假设某服务每次成功结算价格为 0.01 美元，某月合计 2,000 次，毛收入是 20 美元；如果合同明确适用 5% 平台费，则按计费范围计算的平台费用可能是 1 美元，但是否对全部请求或仅特定部分收费必须以实际账单与方案说明为准。不同代币及自定义报价另有条款；这个假设不应当成费用承诺。x402 Cloud 定价
这两个场景的付费主体也不同：Club 订阅者为其使用服务付费，x402 Cloud 费用则围绕卖方提供付费端点。不能把卖方的 5% 当作买方的钱包手续费。
独立服务开发者的完整链路
假设一个开发者出售天气数据：先配置一个付费端点与标价，再通过 x402 Cloud 发布；买方 Agent 请求资源，按约定付款；服务端返回数据，卖方在平台查看请求与收入。与此同时，买方的钱包、余额、支付上限和失败重试可能由另一系统负责。服务端平台的收入记录不一定能证明买方已成功消费数据，两边需要一个可关联的请求或交易标识。
一个常见反例是 API 已扣款但后端超时。买方直接重试可能第二次付款，卖方也可能不知道第一次响应没有送达。上线前要问：收据和请求如何对应？可否安全重试？退款由谁触发？限额是否覆盖并发请求？这些都是对具体集成的验证问题，并非文档已给出的统一答案。
如果用户只是想让 Agent 定期查询余额，直接钱包 API 的只读权限会比自然语言 Agent 执行复杂交易更容易审核；如果任务包含市场判断，Agent API 能提供更丰富的交互，但需要单独验证提示注入、工具授权、输出审核和异常暂停。