你的 agent 不知道自己在花多少钱。谁在看着？

2026-10-08 — 在一个失败测试上反复打转的 coding agent，感受不到账单。它会重试、拉起一个子助手、再重试。每一步在局部都合理，总和不合理。钱在别处：在你供应商的计费面上，而 agent 的进程只看得到发出去请求。

为什么支出上限对 agent 是难题

• 成本不在进程里。本地工具根本看不到钱；诚实的工具会直说，而不是编一个数
• 供应商级上限太粗。账户预算和阈值告警抓的是「这个月」，不是「失控的那一小时」；告警响起时，活已经干完、账已经记上
• 网关看得见请求，看不见 agent。它可以计量流量，却说不清你机器上六个 agent 里是哪个起了循环、又孵化了哪个子进程

今天能诚实度量什么

• 数 agent 做过的事，用它伪造不了的单位：运行时长、计费请求数、CPU 时间、持有内存、LLM 调用数。上限就按这些单位设，每一次越界都记录下来
• 没有出处的数字是「未知」，不是零——一本诚实的账胜过一本让人安心的账
• 这正是 20131 的 cost guard 今天做的事：本地、开源、只观察。它只做记录，还不拦截任何东西

上限要能熬过它自己的断供

每个控制都依赖某个会失效的东西。如果你的支出上限需要去问一个远程端点，而这次调用超时了、被限流了、或返回了垃圾，就有两种偷懒的答案：全部放行，或全部拦死。两个都错。我们对着设计的合同是：外部情报失效时，运行时回退到确定性的本地策略，按动作的可逆性与影响面分级处理——绝不二值化。一个会随自己的网络调用一起消失的支出上限，不是上限，是一条带延迟的建议。

还不存在的那部分

观察告诉你发生了什么。一个同时跑好几个 agent 的团队，要的是一个能把下一个动作扣住、等人点头再放行，并且在所有人机器上保持一个视图的上限。我们正在决定要不要把它做成 Team plan。它今天不存在，没有定价，这篇博客里没有任何话跑到代码前面。

如果你在跑 coding agent，并且「账单失控」是你宁愿提前拦住、而不是事后重建的那类事故——加入<a href="/zh-cn/early-access/">抢先体验等候名单</a>，或写信到 <a href="mailto:[email protected]">[email protected]</a>，描述你真会用的上限形状。每封邮件都有真人读。如果没有人提这个需求，它就保持不建——这就是这一页背后的诚实实验。