代理支付风控应落在工具执行层

给自主 Agent 配上钱包、浏览器和 Shell，再让它赚钱，风险不只来自模型乱花钱。超时重试、网页里的恶意指令、付款前被替换的收款地址，都可能让一次工具调用变成真实支出。作者的 Agent 赚到了 $0.34，但他更关心钱会从哪里漏出去。

他的答案是为 Hermes Agent 做一个插件 SpendWarden：在工具执行前，用确定性规则检查付款。这个思路值得看，因为它把「希望模型遵守预算」变成了「执行层是否允许付款」，同时也暴露了插件能守住和守不住的边界。

为什么预算不能只写在提示词里

「永远不要花超过 $5」可以帮助模型理解任务，却不能充当可靠的付款限制。

作者列出的风险覆盖了几条不同路径：任务说明混入指令，网页评论藏入恶意文本，超时后的重试重复付款，x402 在报价与签名之间更换 payTo，以及 cron 循环在无人值守时持续消耗预算。它们有些影响模型判断，有些发生在支付流程里，单靠一句提示词无法覆盖。

SpendWarden 使用 Hermes 插件的 pre_tool_call hook，在工具执行前检查工具名和参数，提取付款意图，再运行普通 Python 策略。{"action": "block", "message": "..."} 会阻止调用；{"action": "approve", "message": "..."} 会把请求送到 Hermes 自身的审批关口。

付款是否获准，应由模型之外的规则再判断一次。

下面这份配置把预算、审批门槛和收款范围写成可检查的条件：

mode: enforce
daily_limit_usd: 5.00
monthly_limit_usd: 50.00
per_call_limit_usd: 2.00
approval_threshold_usd: 0.50
unknown_recipient_action: ask
recipient_allowlist:
  - "0x1111111111111111111111111111111111111111"
asset_allowlist: [USDC, USDT, OUSD]
network_allowlist: [base, tempo, bsc, near, solana]

要关注 approval_threshold_usd 与 per_call_limit_usd 的区别：需要审批和超过单次限额是两种判断，审批门槛不能直接当作预算上限。

检查入口够广，才有机会拦住付款

插件会识别名称类似付款的工具，包括 wallet_*、x402_*、*pay*、*transfer*、*swap*、*bridge*、*send*、*withdraw*、*deposit*，也会检查 MCP 工具中的嵌套付款参数。

Shell 是另一个入口。原文列出的识别范围包括：携带原生币金额或 ERC-20 transfer 的 cast send、bitcoin-cli sendtoaddress、near call ... --deposit，以及带 X-PAYMENT 请求头的 curl。

这里存在明确取舍。漏识别会放过支付，误识别则会阻塞正常任务。作者建议先运行 observe 模式，查看一天的事件、调整策略，再切换为 enforce。这是部署建议，原文没有提供误报率或漏报率。

x402 则需要检查付款条款。它是一种按请求付费的 HTTP 流程：服务端返回 402 和 PAYMENT-REQUIRED 请求头，客户端签署 EIP-3009 授权，再由 facilitator 完成结算。关键风险点位于解析挑战之后、签名之前。

x402_inspect 可以解析挑战或已经签名的 X-PAYMENT，整理条款并执行同一套策略：

{
  "network": "base",
  "asset": "USDC",
  "amount_atomic": "250000",
  "amount_usd": 0.25,
  "payTo": "0x1111111111111111111111111111111111111111",
  "resource": "https://api.example.com/market-data",
  "decision": {"action": "allow", "reasons": ["within policy"]}
}

要核对 payTo、金额与 resource 是否符合预期。这个工具会对不支持的 scheme、缺失或为零的地址、非 HTTPS 资源、异常长的付款窗口和未知资产发出警告；它不持有密钥，也不签名。

不过，原文没有说明检查结果如何与最终签名内容强制绑定。因此，「能检查地址」还不能直接等同于「已经解决检查后地址被替换的问题」。

本地账本能记清支出，但不能包办支付安全

SpendWarden 为记录的付款生成收据，以唯一 payment_id 避免重试导致重复记账。已经发生、但违反策略的付款也会计入总额，并标记为 over_budget 或 unapproved。

这里要分清：账本去重不等于支付端不会重复扣款。 原文证明的是记录具有幂等性，没有展示支付端如何使用同一个标识阻止重复结算。

状态示例显示，已花 $0.25、共 1 笔付款，当日剩余 $1.75、当月剩余 $19.75；当前为 enforce，单次限额 $1.00，审批门槛 $0.30，决策计数为 allow 2、ask 1、block 1。这组展示参数与前面的 YAML 不同，不能当作同一次配置的连续结果；决策次数也不等于付款笔数。

账本使用本地 SQLite，插件本身不发网络请求，没有遥测。

作者还用一个临时 Hermes profile 和 mock OpenAI-compatible provider 做了演示：模型请求通过 cast send 在 Base 上发送 5 USDC，hook 返回 block，终端命令没有执行，模型收到拦截消息后解释原因。48 秒视频还展示了独立策略检查、审批升级、账本和不签名的 x402 解析。

这是具体路径的功能验证。公开仓库和 Hermes catalog PR 当时仍在准备，原文也没有给出更大规模的测试结果。

我的判断

把付款限制放到执行层，这个方向成立。相较于只写系统提示词，它增加了独立检查；相较于每笔都人工确认，预算与白名单也提供了减少打扰的空间。

但它成立的前提，是付款路径确实经过 hook，而且 Agent 不能随意修改规则、数据库或关闭插件。作者明确承认：能编辑数据库或停用插件的进程可以绕过它，自定义脚本转账也超出解析范围。它不是硬件钱包、多签或沙箱。

另外，ETH、SOL、BNB 等波动资产如果没有明确 USD 金额，插件会请求审批，不会自行估价。这种保守处理合理，但也说明美元预算依赖可用的计价信息。

因此，我会把它视为付款流程中的一层检查。实际减少了多少损失、带来多少误拦截，作者没有对照数据，不能仅凭演示替它背书。

能拿来做什么

• 给能够购买 API 数据或操作钱包的 Agent 加预算时，把单次、每日、每月限额及未知收款人处理方式写进执行层，并先用观察模式检查实际调用。
• 在 Node 工具服务或 MCP 服务中暴露付款能力时，把金额、资产、网络和收款人设计成明确参数，方便执行前检查，避免全部藏进任意 Shell 文本。
• 接入 x402 时，在签名前核对付款条款，并确认签名使用的内容就是检查过的内容；原文没有交代这一绑定机制，需要单独验证。
• 排查超时重试时，分别检查账本去重与支付端防重，不能因为 SQLite 中只有一条记录，就认定外部只付款了一次。