跳转到主要内容
一个卡在重试循环、扇出一千个子任务，或干脆在计划中途失控的推理智能体， 可能在任何人注意到之前就花掉真金白银。cap_cost 防火墙判定就是针对 那个的断路器：你一次性编写一个逐运行的分上限，一旦一次运行累积的花费越过 它，网关就拒绝下一次工具调用——在那次调用到达模型或工具之前。 这是在网关上执行的 AI 智能体成本控制，而非拼装到你的智能体循环上。 像每个 防火墙判定 一样，一条 cap_cost 规则存在于一条工作区策略中，绑定到一个密钥，并在下一次调用时生效，无需 重新部署。

​
1. 逐运行的花费断路器

cap_cost 是一个你用一个额外字段编写的规则判定——cap_cost_cents，即该 运行以美元分计的花费上限。当该规则匹配一次工具调用时，引擎把智能体运行 累积的花费与那个上限比较：
  • 在上限之下 → 该调用被允许；评估继续。
  • 在上限之上 → 该调用被拒绝，原因点名该运行的总额相对于上限。那是 终端的、断路器式的结果——该运行在一次新运行之前无法再发出另一次受治理的 调用。
该上限以智能体运行为键，而非单个请求。一次已经烧掉了大部分预算的长 运行，即便它的下一次调用本身便宜，也会在那次调用上被拒绝——断路器在 运行总额上跳闸，而非边际成本。
运行范围，带一个逐请求回退。 当请求携带一个智能体运行 id 时，该上限 适用于该运行累积的花费。一次没有运行关联的调用（例如一次没有转发会话的 裸 MCP 派发）则回退到一次逐请求比较。无论哪种方式，断路器都在超预算调用 被派发之前跳闸。

​
2. 一个具体示例

把一个密钥上的任何运行封顶在累积花费 $5.00。一条单一的通配符规则即可 做到——cap_cost_cents 是 500（分）： 
{
  "label": "run cost ceiling $5",
  "tool_name_glob": "*",
  "verdict": "cap_cost",
  "cap_cost_cents": 500
}
在你已创建的一条策略上的控制台规则编辑器中编写它（参见 创建并绑定一条策略）。编写一条规则 是一个 Developer+ 操作。通过 firewall_policy_id 把该策略绑定到一个 密钥，或将它设为工作区默认，那么该密钥驱动的每一次运行现在都有了边界。 你可以把上限限定得比”每个工具”更紧。收窄 工具名 glob，这样只有一个昂贵的调用 家族计入断路器——例如对 *.search 加 cap_cost 以约束网络搜索扇出，同时 让廉价的本地工具不被计量。
用优先级叠加一个更便宜的警告层。一条在更高优先级（更低数字）上、上限更低的 audit 规则，让你在执行性的 cap_cost 规则跳闸之前，先在 事件信息流 中观察 一次运行接近它的预算。首个匹配生效，所以把观察者排在前面。

​
3. 它在哪里触发——以及它不能在哪里

cap_cost 只在一次调用被派发之前才有意义——那是停止该调用仍能防止 花费的那一个点。所以它在两个派发前 执行面 上是活跃的，而在派发后的执行面上 被拒绝：
执行面cap_cost？
inbound（声明的工具）执行。
mcp（tools/call 派发）执行。
response（模型发出的调用）保存时拒绝——已没有东西可停止。
egress（出站目的地）保存时拒绝——已没有东西可停止。
一条钉到 response 或 egress 的 cap_cost 规则在保存时被拒绝，所以一条 规则绝不会显示为活跃却永远无法拒绝。把执行面留空以覆盖两个派发前执行面， 或把它钉到 inbound / mcp。
cap_cost_cents 对一条 cap_cost 规则是必需且非负的。控制台和 API 拒绝一条没有上限的 cap_cost 规则，所以一个配置错误的上限不能静默地放 每一次调用通过。

​
4. 断路器跳闸时是什么样

一次超预算的调用是一次正常的防火墙 deny：
  • 在 inbound 上，中继返回 HTTP 400，带有错误码 firewall_blocked。 该拦截在上游模型调用之前触发，所以它不消耗任何模型 token，并被标记 为 skip-retry——重新运行同一个调用只会再次让断路器跳闸。
  • 在 mcp 上，它作为一个工具错误返回，所以模型看到这次拒绝，能停止 或询问用户，而非崩溃。
该拒绝原因点名具体数字，例如 cap_cost: estimated run cost $5.40 exceeds cap $5.00，所以一个阅读 事件信息流 的 操作者准确看到断路器为什么跳闸。
事件永不携带一个字面的 cap_cost。 你把判定编写为 cap_cost，但引擎 在事件被记录之前把它解析为一个具体的 allow 或 deny。该信息流显示 智能体实际看到的 allow/deny——运行成本上限是那个原因，而非判定标签。 这与 判定如何解析 相对应。

​
5. 安全地上线它

因为一个跳闸的断路器会硬停止一次运行，在执行之前先验证它。在该策略上打开 影子模式：cap_cost 规则仍然评估，而 一次本来会发生的拒绝被降级为 audit，前缀为 [shadow] would …。观察事件 信息流以确认该上限在你预期之处跳闸——且只在你预期之处——然后关闭影子模式 以开始执行。 你也可以在 Test 标签（一个 Developer+ 沙箱）中对照一个样本调用 dry-run 一条策略，以在任何东西依赖它之前看到解析 出的判定和匹配到的规则。

​
6. 它如何契合防火墙的其余部分

cap_cost 是六个判定中的一个。它自然地与同一条策略上的其他控制搭配：

判定

完整集合——allow、audit、deny、sanitize、pending_approval，以及 cap_cost 如何解析。

拦截危险工具

直接拒绝破坏性 shell、删除以及其他高风险调用。

规则参考

完整的匹配语言——glob、参数子句、序列。

异常检测

对照一个学习到的周内小时基线标记的成本尖峰。
一个运行成本上限是一个静态的、确定的后盾；防火墙还会学习每个工作区 正常的成本形态，并在一个 Member 可读的异常信息流上对照一个 14 天周内小时 基线标记尖峰。用 cap_cost 做硬停止，用异常做早期信号。
密钥本身上的配额限制（credit_limit_usd）约束跨所有运行的总花费； cap_cost 约束单次运行。它们组合——一个失控循环会在它耗尽密钥终身额度 之前很久就让逐运行断路器跳闸。参见 范围：密钥、策略、工作区。

​
接下来去哪里

创建并绑定一条策略

创建一条策略、挑一个默认判定、把它绑定到一个密钥。

影子模式

在一个上限改变流量之前衡量它。
关于一个花费上限作为后盾应对的失控智能体威胁，参见 过度代理 与 危险工具调用。