先讲一个真实翻车现场。

上个月，我给一个调研 Agent 配了一张「共享额度」的 API Key，让它跑一个竞品监控任务。任务本身设计得很保守：每天最多 50 次调用，每次估下来不到几分钱。结果第三天晚上我看账单，一天花了 $37。

发生了什么？Agent 在跑一个子任务时进入了重试循环——API 报错、重试、换个参数再试、再报错、再重试。50 次的日上限早就过了，但它通过不同 endpoint 各算各的配额，把我自以为设好的限制绕开了。

$37 不算大钱，但这件事让我意识到一个问题：我从来没真正设计过「Agent 怎么花钱」这件事。 我给它的是「一张能花的卡」，而不是「一个有预算、有边界的工作账户」。

这篇文章就是后来我总结出来的那套方法。不需要等 Cloudflare 的完整功能开放，现在就能用起来。

问题不在于「能不能花」，而在于「花多少、花在哪」

当 Cloudflare 推出 Account Wallet + Virtual Wallet 之后，一个更清晰的问题浮出水面：

如何设计一套既不频繁打扰你、又能防止失控的支出策略？

这跟给员工发公司卡的逻辑几乎一模一样，只是对象从人换成了 Agent。而我之前犯的最大错误，就是把它当成了「不设防」的机器。

实用的护栏设计框架

1. 额度分层，而不是一个总额度

别给 Agent 一个「本月总预算」就完事。预算只有在能拆到任务粒度时才有意义：

  • 日常探索额度：$5–20 / 周，让 Agent 自由试用 API、跑实验。花完这周就停，下周再说。
  • 项目预算：按具体任务一次性注入。比如「把这份竞品清单的定价全部抓下来」= $10，任务完成或预算耗尽就回收。
  • 紧急审批通道：超过阈值需要人工确认。Agent 需要更多额度时，把它当成「申请」，而不是「自己刷」。

关键点：额度要在 Agent 看到之前就设好，而不是等它花了再砍。 事后砍只会让它下次想办法绕。

2. 白名单优先于黑名单

这是我改观最大的一个习惯。

我以前是「黑名单思维」：默认什么都能买，看到危险再禁。结果每个新服务都是风险面，追着堵。

现在换成白名单思维：默认什么都不能买，只有我明确放行的才能买。

  • 先只放行你信任的几个服务：OpenAI、Anthropic、你自己常用的数据源。
  • 验证没问题的再逐步放开。
  • 任何一个新服务，Agent 想要访问，走「申请」流程，而不是直接给权限。

白名单的粒度还可以更细：不只「能调用哪个 API」，还包括「每次最多花多少」「每天最多花多少」。我那次 $37 的事故，如果白名单里写死了「每日上限 $5 / 单日调用 200 次」，重试循环根本撑不到第三轮。

3. 单笔上限 + 异常检测

总额度有剩余，不代表单笔交易可以随便花。

我在所有 Agent 账户上加了硬规则：单次交易超过 $2 触发人工复核。 这不是为了防 Agent 变聪明，而是防它「突然决定买一堆贵服务」这种不可预测的行为。

另外加一层异常检测：调用频率、失败率、花费速度，任何一个指标异常就自动冻结。最省事的做法是让 Agent 的支出通道只在「预算 > 0 且没有异常告警」时才可用——这几乎不需要额外写代码。

4. 身份可见性

这是最容易忽略、但长期回报最高的一条。

让 Agent 在需要时声明自己的归属：它是 你的名字.cloudflare.pay 的代理，而不是一个来路不明的随机账户。

为什么重要？因为当 Agent 开始大量访问第三方服务时，商家更愿意给「有明确归属的 Agent」试用额度，也更愿意在异常时沟通而不是直接封号。一个连名字都没有的支付主体，在商业世界里举步维艰——不管它是人还是 Agent。

这和域名是同一套逻辑：ip:8090 没人敢信，yourname.com 别人愿意打交道。我在 Dynadot 评测 里讲过「域名是信任资产」，现在这套逻辑原样搬到了 Agent 身上。

现在就能做的 3 件事（不用等完整功能）

  1. 盘点支出面。 把你目前让 Agent 调用的所有付费服务列出来，记下每个的月均花费。大多数人的第一反应是「我应该没花多少」，但把账单翻出来之后往往不是这样。
  2. 给每个主要 Agent 定一个「心理预算」。 不需要精确，一个数字就行。写下来，然后把它变成代码里的硬上限——不是记在备忘录里。
  3. 用独立 API Key + 独立账户隔离 Agent。 一个 Agent 一套 Key，账单分开看、额度分开设、出问题单独切断。所有 Agent 共用一套凭证，等于把风险堆在一起。

这三件事加起来不超过一个小时，但它能改变你和 Agent 的信任关系。

我的原创思考：硬约束换自由

很多人把「Agent 自主支付」理解成「完全放手」。我的实践结论正好相反：

真正可持续的做法，是用基础设施级的硬约束，换取更大的自主空间。

你想想两种状态：

  • 一个 $10 的护栏下，你可以放心地让 Agent 去试 50 个服务。它每试一个你都不用管，因为它花不穿那 $10。
  • 一个 $1000 的无限制账户，你反而会紧张得整夜盯着账单，Agent 每调一个接口你都要怀疑。

$10 的约束给了你自由，$1000 的放纵反而让你失眠。这就是为什么我强烈认同 Cloudflare 那套双层钱包的设计思路——它把「该不该信任 Agent」这个哲学问题，变成了一个「额度设多少」的工程问题。

关于 Cloudflare Wallets 的具体拆解，我写在另一篇：Cloudflare Wallets 解析：AI Agent 终于能自己付钱了。如果你也在研究 Agent 的联网能力，可以再看看 AI Agent 能自己买 eSIM 吗。

结尾

下一次当你的 Agent 又多花了几美元时，先别急着骂它。

先检查你的护栏是不是设得太松了。

一个真正设好了护栏的 Agent 系统，你的日常应该是：偶尔看到「预算耗尽，已暂停」的提示，然后该续费续费、该调整调整——而不是每天醒来先看一遍账单。