AI代理支出闸门实战：43次决策拒绝35次的深度复盘

为什么一个"说不"的机器比仪表盘更重要

大多数团队谈论AI代理成本控制时，想到的是仪表盘——一个事后报告工具，告诉你钱花在了哪里。但这篇文章描述的是一种截然不同的思路：在提供商调用发生之前，运行一个确定性检查，决定"允许"还是"拒绝"。每一次决策都写入一个无法被悄悄篡改的账本。不是"监控发票"，而是"先阻断，再记账"。

作者的设计目标很窄但很锋利：公司里没有任何代理能在未经确定性检查的情况下花钱，无论允许还是拒绝，每个决策都必须落在一个不可静默编辑的账本中。这个目标本身就值得玩味——它承认了仪表盘的局限性：报告只能告诉你已经发生的事，而闸门可以阻止尚未发生的事。

闸门的技术架构：六层检查如何在请求离开主机前拦截

这个闸门部署在一个本地代理之上，六个代理不再直接与提供商通信，而是指向 http://127.0.0.1:8899/anthropic。闸门以一个 systemd 单元运行在该回环端口上，持有真实密钥并转发到上游——代理本身从不持有密钥。

请求离开主机前，闸门会依次检查以下内容：

身份验证。 代理通过每个代理令牌的 sha256 摘要来识别。配置文件只携带摘要——文件自身的注释写得清清楚楚：明文闸门令牌绝不能出现在其中。没有令牌，或者令牌无法映射到任何代理：拒绝，请求永远到不了提供商。

额度上限。 单次请求 0.50 欧元；每日 300 次请求和 4.00 欧元；每月 3,000 次请求、20.00 欧元和 4,000,000 tokens。可按提供商配置——fal 图像调用按 0.004 欧元估算，Anthropic 按 0.03 欧元。

调用前预算预留。 每个请求先预留最坏情况成本，随后按实际计量成本结算。预留是一次原子的"检查并递增"操作，在锁下验证每一项上限，因此两个代理无法同时通过检查并共同突破限制。

失效关闭。 如果保险库查找失败或上游出错，预留被释放，请求被拒绝。

网络层还有第二道更粗暴的机制：一组 nftables 规则丢弃专用服务 uid 的出站 80/443 流量，因此"直接调用 API"对这个账户来说不是一个可选项。

什么是 “检查-预留-结算” 模型？

这是分布式资源配额系统中一个经典模式，通常称为 reserve-then-settle。它的核心是：在一个请求真正消耗资源之前，先按最坏情况占用一份额度（预留），等请求完成后，再按实际消耗回填账单，把多预留的部分释放掉。这样做是因为实际成本往往在请求返回前无法知道——例如一个 token 计费的推理调用，你知道的只是提示词长度，不知道模型会生成多长。

不预留的话，两个并发请求可能各自看到“预算只剩 0.5 欧”，然后都花掉 0.4 欧，共同冲破上限。预留机制通过一次原子的“检查并递增”操作在锁下验证每一项上限，从而杜绝这种竞态条件。文章提到的“0.05 欧元预留、0.004 欧元实际结算”就是这套模型的直接体现：多出来的 0.046 欧在请求结束后归还预算池。理解这个模型，才能理解为什么闸门可以在调用前就做出“允许/拒绝”判断，而不必等账单到来。

前43次决策的真实记录：33次是因为令牌问题

账本是追加式 JSONL。每条决策一条记录，每条都携带一个 prev 字段包含前一条记录的哈希，另有单独的头文件保存当前末端。改动任何历史行，链就会验证失败。截至文章数据读取时点，账本共有 43 条记录：35 次拒绝，8 次允许。

拒绝才是最有意思的部分。35 次拒绝中有 33 次是 bad_or_unscoped_token——调用方带着一个无法解析到代理的凭证到达。另有各一次因未知提供商和当日请求上限触发。其中几次是作者自己在配置过程中摸索令牌格式。闸门不在乎调用方"显然"是合法的。它没有代理身份，所以什么都不会离开主机。

允许则分两类，其中一类令人尴尬：

两行是测试装置行，由测试工具在演练允许路径时写入了生产账本。其中一行上游返回了 401——但仍然消耗了约 0.03 欧元的估算计量支出，因为提供商可以对失败的请求计费。任何发票对账都必须手动排除这些行。

六行是真实的：构建代理通过 fal 生成图像，每次调用预留 0.004 欧元，预留时持有 0.05 欧元，实际成本每次 0.004 欧元。

43 次决策中有 35 次是"不"。这就是作者想放在任何认为代理支出门控只是一个仪表盘的人面前的数字。

哈希链账本与 “可静默篡改” 的区别

普通日志文件是可变的：任何有写权限的人都可以删掉一行、改一个数字，事后没人能确定。哈希链（hash chain）账本借用了区块链的思想：每条记录里存一个 prev 字段，内容是上一条记录的哈希值。这样任何一条历史记录被改动，它后面所有记录的哈希都会对不上，验证立刻失败。另有一个头文件保存当前链末端，防止有人悄悄追加伪造记录。

关键在于：哈希链并不阻止修改，它只让修改可被发现。对一个内部支出闸门来说，这恰好够用——攻击者可能是团队自己的成员，你不是要防外部黑客，而是要让“我改了账本”这件事无法藏在沉默里。它把“我们记录了每一笔决策”变成“我们的日志要么验证通过，要么不通过”，成本极低，信任收益却很高。文章里 43 条决策中每一笔的 prev 字段，就是这条链的具体体现。

诚实的缺口：为什么作者拒绝称支出为"已封顶"

这套系统由团队构建，然后由一位独立审计员攻击。审计员的发现才是最有价值的部分：

告警仅是文件形式。 拒绝被写入 alerts.jsonl，而闸门的通知命令是空的。发生拒绝时，没有人被告知。"告警已触发"会夸大实际状态——那只是一个不断增长的文件。

拒绝日志的遗漏。 审计时配置的 denials.jsonl 是 0 字节，而 alerts.jsonl 承载了拒绝记录，因此阅读那个声称记录拒绝的文件的运维人员会得出"没有拒绝"的结论。更关键的是，没有任何记录携带限制值：你能看到某个上限触发了，却看不到你差多少就越界。

费率是占位符。 配置文件自己说了：在费率匹配提供商当前价目表之前，成本追踪只是估算。

最大的问题：执行边界不在作者所说的位置。 nft 规则只阻止了一个 uid；生成工作进程的通道以另一个 uid 运行，拥有免密 sudo 和 docker 组成员资格，因此可以直接访问提供商主机并读取真实密钥。审计的结论很直白：这个切片是纵深防御，不是强制执行。作者正在修复主机架构；在此之前，他不会在任何文章中将自己的提供商支出描述为"已封顶"。

最后一点是作者决定发布这篇文章的全部原因。一个可以绕过的闸门仍然有价值——它让默认路径可被审计，它捕获了 33 个畸形请求包括作者自己的——但称它为牢笼就是在说谎，那种读起来像能力、直到发票到来才暴露的谎言。

如果重新构建，会先做什么

拒绝路径才是产品。 允许路径只需五行代码。价值在于原子化的"预留-检查-拒绝"、失效关闭释放，以及被拒绝的请求从不打开套接字这一事实。

第一天就对账本做哈希链。 添加成本低廉，却把"我们记录一切"转化为"日志要么验证通过，要么不通过"。

让测试行远离生产账本。 在你将要与发票对账的文件中出现一行 agent: "probe" 都嫌多。

告警不是可选项，也不是一个文件。 没有到达任何人的拒绝，只是一个怀着良好意图的日志条目。

在声称强制执行之前检查 uid。 这是作者最希望其他人跳过的错误。

截至撰写时的实时记录：43 次决策，35 次拒绝，整个公司计量外部支出 0.024 欧元，以及围栏上一个有据可查的洞。

这篇文章由 AI 辅助撰写——它所描述的代理起草了它，每个数字都对照固定来源做了核实。

背景补充

nftables 与“执行边界”到底在哪一层

nftables 是 Linux 内核的包过滤框架，基于 Netfilter，取代了旧的 iptables。它的规则在内核网络栈里生效，按 uid、端口、协议等条件丢弃或放行数据包，比用户态防火墙更难绕过——一个进程即使想直连外部 API，只要它的 uid 命中“拒绝出站 80/443”规则，数据包在离开网卡前就被丢了。

但它的边界是按 uid 画的，不是按“这个人”或“这个容器”画的。文章审计发现的缺口正是这里：nft 只封锁了跑闸门的那一个 uid，而真正生成工作进程的通道以另一个 uid 运行，那个 uid 不在规则覆盖范围内，而且它还拥有免密 sudo 和 docker 组成员资格。docker 组成员在多数 Linux 配置下等价于 root——可以起一个挂载宿主文件系统的容器，直接读到真实密钥。所以 nft 规则是一种纵深防御（defense in depth），不是强制执行（enforcement）。前者是层层设卡、增加绕过成本；后者是物理上不可能绕过。作者拒绝说“支出已封顶”，就是因为把前者当后者宣讲，是对读者的误导。