独立解读
Tempo Wallet CLI：让命令行里的 Agent 为 API 付款
产品分析｜资料核对：2026-10-28｜基于公开资料，未运行或完成真实支付
研究 Agent 要调用一个收费的数据接口，传统做法是让开发者为每家服务单独注册和管理密钥。Tempo Wallet CLI 的切入点，是让 Agent 用命令行发起请求，并在服务要求付款时处理机器支付。它是客户端工具；Tempo 是网络，MPP 是支付交互协议，这三者不能混作一个产品。
产品从哪里来，服务谁？
Tempo 围绕稳定币支付网络和机器支付构建工具。其开源 wallet-cli 仓库 面向开发者及能够调用 shell 的 Agent；项目由钱包操作和付费 HTTP 请求能力构成。历史 wallet-rs 仓库 已归档并指向新仓库，版本与部署状态应以现行仓库为准。
| 角色 | 任务 | CLI 的位置 |
|---|---|---|
| 开发者/用户 | 登录、准备资金、授权 | 配置和监管钱包 |
| Agent | 访问需要付款的接口 | 调用命令并处理结果 |
| 服务商 | 提供资源、声明支付条件 | 决定收费和交付 |
| Tempo 网络 | 按支持的路径执行链上操作 | 提供交易环境，不等于 CLI 本身 |
一次调用是如何发生的？
这是根据官方文档整理的概念流程，不保证每种 MPP 方法均以相同顺序结算。当前仓库说明登录使用设备码在钱包应用中批准；服务请求可用 dry-run 查看费用，但对非 GET 请求的探测仍可能产生服务端副作用。服务同时提供会话时默认偏向 session；一次性 charge 可以显式选择。session 会锁定押金，直到会话关闭并提取未使用资金。当前实现说明
权限和风险如何判断
| 关注点 | 官网描述与选型问题 |
|---|---|
| 密钥 | Agent 所在环境持有受限访问密钥；泄露后攻击者可能在范围内操作，仍需保护机器和日志 |
| 限额 | 当前仓库写明 charge 和 session 默认上限为 10 个付款代币单位，可设置 max-spend；此默认上限不约束循环订阅，具体累计口径和续期需核验 |
| 错误恢复 | 请求超时不等于没付钱；要检查凭证、交易和服务响应，避免重复付费 |
| 覆盖 | 服务商需支持相应 MPP 方法，CLI 不使所有普通网站自动支持它 |
商业模式与成本
公开仓库展示开源软件，未找到该 CLI 单独定价。用户可能承担服务商收费、链上网络费，以及通过其他服务入金或换币的费用；这些不能直接写成 CLI 收费。分析推断：降低开发者接入成本，可能增加 Tempo 网络与生态的使用，但未见 CLI 独立收入披露。
适合谁，下一步看什么
对希望让 Agent 调用支持 MPP 的 API、并能接受命令行与链上资金管理的开发者，CLI 值得试用。对需要银行卡、报销、组织级审批或不支持 MPP 的商家，仍需配套服务。上线前应核对可用地区、当前网络及资产、支出上限的强制位置、密钥撤销、支付失败与重复请求。本文没有运行代码，不能证明这些能力在指定环境中可用。
如果今天开始评估，应怎样走一遍？
假设研究 Agent 需要访问一家支持 MPP 的天气数据接口。这个例子仅用于说明评估步骤，不代表我们已对该接口付款。
- 确认运行环境。 先看当前 CLI 的网络要求、软件版本和供应链校验方式；选好 Agent 所在机器与持有人授权的设备。
- 登录并查看身份。 官方 quick start 中
tempo wallet login启动设备码批准，tempo wallet whoami检查钱包和访问密钥；批准界面所展示的权限应由用户阅读。 - 准备资金。
tempo wallet fund打开入金流程并给出链接，但官方明确说该命令不会等待或确认到账；再用tempo wallet balance检查。 - 确认服务与费用。
tempo request --dry-run <服务地址>探测付款要求并预览，但非 GET 探测也可能触发服务端副作用；检查服务条款、币种、网络与请求方式。 - 设定支出控制。 显式确认
--max-spend和授权密钥权限；需要一次性付费时考虑指定--payment-intent charge。默认限制不适用于循环订阅。 - 执行和核对。 成功后检查服务结果、交易和收据；如果提示支付结果未知，不应直接当作失败重复支付。官方建议查询状态，并可使用
--write-meta保存元数据。当前仓库
这套路径的价值是机器可调用、无需为每个支持 MPP 的服务单独设计付款交互；限制是它仍依赖钱包可用、用户完成授权和充值、服务商实现兼容协议。访问不支持机器支付的普通商品页面时，CLI 自身不能解决结账。
用一次性请求和会话，费用会怎样不同？
假设一家数据商对查询每次收取 0.01 个付款代币，Agent 需要查询 100 次。忽略网络费与额外服务费，服务内容价就是 1 个单位。这不是实际报价。一次性 charge 的账单逻辑是每次请求对应一笔收费；session 则可能先锁定押金，再根据会话内实际使用和约定进行结算。
| 需要确认 | 一次性 charge | 会话 session |
|---|---|---|
| 开始前 | 每次服务要求和上限 | 押金大小、有效期和可用余额 |
| 运行中 | 是否每次产生交易和费用 | 用量凭证、余额及中断处理 |
| 结束后 | 核对每笔状态 | 关闭会话并处理未使用押金 |
| 不确定结果 | 先查状态再重试 | 核对会话与服务商账本 |
请求上限、访问密钥额度、钱包余额和会话押金不是同一口径；设置 10 单位上限，也不能据此推断 100 次请求不会累计超过 10。要按当前文档逐层检查。尤其是循环订阅，官方说明默认 cap 不限制它；如果任务不需要订阅，应明确选择合适的 payment intent，而不是依赖默认值。
对照其他方案，什么时候应选它？
与 AWS AgentCore Payments 相比，Tempo CLI 更接近 Agent 本机的调用入口；AWS 更强调托管编排、连接钱包和云端观测。与 ZeroDev 相比，CLI 包含命令和 MPP 请求工具，ZeroDev 更侧重智能账户权限组件。两类方案可以在不同架构中配合，不应只按“哪个钱包更好”排序。
选型时请用三个反例测试：Agent 主机失窃，受限密钥还能花多少？服务返回超时但扣款已发生，如何取得证据？连续任务结束后，谁负责关闭 session？若团队无法回答，就应先在测试环境和服务条款中查明，再扩大额度。