治理与运维

预算与成本

智能体每一轮对话都在花钱，而一个带环的图或一个公开嵌入能很快花掉不少。上限就是那个把「糟糕的一天」变成「一次被停掉的运行」的控制手段。

真正花钱的是什么

模型调用，按输入和输出的令牌计费。其余都是零头。让费用比预期涨得更快的因素有：

成因	为什么花钱
检索到的上下文	每个检索到的分块，在每一轮携带它的对话里都算输入令牌。
对话历史	长对话每一轮都会重发历史——成本随对话增长。
工具循环	每次工具往返都是一次完整的模型调用，且带上此前的全部对话记录。
集群扇出	并行分支让调用次数成倍增加；循环节点再乘一遍。
深度文档生成	一份大型演示文稿等于一个大计划，加上一遍渲染校验的视觉处理。
公开嵌入	数量不受限的陌生人，花的是你的钱——最需要设上限的就是这种情况。

设置上限

有两套彼此独立的机制，值得先弄清你设的是哪一个。

按用户的上限

属性	取值
存放在	`budget_settings.monthly_cap_usd`
范围	某个人自己的消费，涵盖他做的一切
周期	自然月
默认值	一个很大的数字——在你设定之前实际上等于无限制

按范围的上限

设置位置： 可观测性 → 预算管理；按用户组的设置在 管理 → IAM → 预算。共有三种范围，由数据库约束强制执行：

scope_type	应用范围	为什么要设它
`group`	某个 IAM 用户组的所有成员，共享一份额度	一个团队合计的月度上限
`embed_key`	某一处公开嵌入	最该设的一个——数量不受限的陌生人，花的是你的钱
`swarm_api_key`	某一个集成	为别人代码里的重试风暴设一道边界

字段	类型	说明
`monthly_cap_usd`	numeric(10,2)	必须大于零。以美元计的自然月上限。
`is_active`	布尔值，默认 true	在不删除的前提下关掉某个上限。

注意

当多个上限同时适用时， 最严格的那个生效。一个个人上限 50 美元、但所属用户组上限为 20 美元的用户，实际受限于 20 美元。

强制拦截需要显式开启

上限只有在部署上设置了拦截时才会真正 ENFORCE_BUDGET_CAP 生效（接受的取值： 1, true, yes）。不设置的话，它们仍会统计并告警，但每次调用都照常放行。

为什么这样设计

默认关闭是因为 monthly_cap_usd 出厂时是一个没人主动选过的很大数值。升级时就强制生效，会让那些从没打算真正约束的实例开始拒绝模型调用。等你的上限反映了真实情况之后再有意识地打开它——而在暴露公开嵌入之前一定要打开。

这项检查默认失败即放行——除非你另行指定

上限判定发生在调用分发之前。如果消费额 查询本身 出错，默认会继续放行，而不是让平台因为一个记账问题把自己卡死——强制拦截是成本控制，不是安全边界，它的故障不该把你的智能体一起拖下水。

设置 BUDGET_FAIL_CLOSED=true 可以反转这一行为，让查不出数字时直接拒绝调用。两种情况下失败都会记录；区别在于把「读不到的数字」当成「大概没问题」还是「未证明安全」。选后者的常见理由就是公开嵌入。

未知不等于零

查询失败会被记为未知，绝不会记成花了 0 美元。这个区分正是上面那个设置能够存在的全部理由：曾有一段时间两种结果给出同一个数字，于是一次慢查询被静默解读为「还没花钱」，所有上限都通过了。

实操示例：公开站点上的客服机器人

这就是让人意外花钱的那种形态——任何人都能用的嵌入，花的是你的额度，又没有登录态可供限流。下面是完整配置，按该做的顺序排好。

1
在嵌入公开之前打开强制拦截
设置 ENFORCE_BUDGET_CAP=true 和 BUDGET_FAIL_CLOSED=true ，然后重启。缺了第一项，上限只会告警。缺了第二项，一次超时的消费查询会被读成「未证明超额」，调用照常放行。
2
给自己设一个个人上限
可观测性 → 预算管理，把 monthly_cap_usd 设成一个你真的不希望被突破的数字。这是兜底，不是控制手段——你名下的一切都计入它，包括你自己的测试。
3
给嵌入密钥本身设上限
这才是关键的一项。在 embed_key 上设一个范围上限，能限定那一处嵌入最多花多少，不论使用者是谁——于是一枚泄漏的密钥、或者一个发现了这个组件的爬虫，耗掉的是你选定的那个数，而不是你的全部额度。先设低一点；有了一周真实流量之后再往上调。
4
把告警阈值设在上限之下
阈值在每个自然月各触发一次，取已越过的最高那一档，所以繁忙的一下午不会产生一串邮件。选那些还留给你行动时间的数值——50 和 80 算预警；95 基本只是在通知你事情已经发生了。
5
跑一天流量之后核对归属
在分析，确认该嵌入的调用确实归到了那枚密钥上，而不只是归到你名下。如果没有正确归属，按密钥的上限就无从统计，实际只有个人上限在起作用。

上限是天花板，不是刹车

强制拦截是在调用分发之前判定的，而月度累计消费有短暂缓存，因此上限真正生效之前的最后几次调用可能让你略微超出。把上限当成「我最多愿意损失多少」来设，而不是「我会被精确收多少钱」，并配合速率限制一起用——参见向量嵌入.

一个数字是怎么变成成本的

本页每个数字都是 平台自己算出的估算值，不是提供商开出的账单行。知道它可能在哪两处产生偏差，能让你月末不至于对错了账。

令牌数：实测，或估算

当提供商返回 usage 字段时，直接采用其中的计数。当它不返回时——某些流式响应、某些网关——会按大约每 3.8 个字符一个令牌来估算文本，并在追踪上标记 tokens_estimated ，这样你在这里就能区分两者：分析.

单价：按提供商与模型分别解析

同一个模型在各处的价格并不相同——网关会加一层加价，云厂商有自己的价目表——所以单价是按 提供商与模型的组合来查的，顺序如下：

层级	来自哪里	为什么它优先
运维方覆盖值	由管理员设定	承诺用量价和企业协议价都不是标价，任何公开来源都不知道你的价格
同步的价目表	内置进仓库的公开价格数据	覆盖面广，且在版本控制里评审，而不是运行时去拉取
内置价目表	随应用一起发布	让离网安装也能给自己的调用定价
自托管	Ollama、vLLM	跑在你已经付过钱的硬件上——这是一个已知的零，不是未知的零

没人定过价的模型按 0 美元计

如果上述各层都不认识某个模型，这次调用会以真实令牌数、零成本记录下来，并在追踪上标记 pricing_missing。它仍会出现在你的用量里，但对上限毫无贡献。在相信某个月度合计之前先按这个标记筛一遍，凡是筛出来的都补一个覆盖单价。

注意

历史记录保留写入当时适用的单价。厂商调价不会悄悄改写上个季度的消费额——审计需要的正是这一点，而当某个数字与今天的价目表不符时，也请记得这一点。

降低支出

机械性的步骤用小模型。 路由、分类和抽取很少需要前沿模型——而在集群里，每个节点都可以各自选型。
少检索一些。 少而精的分块，在成本和准确率上都胜过多而平庸的。
缩短对话。 记忆摘要的存在，就是为了让长对话不必永远重发全部内容。
给循环迭代设上限 。无界循环是最经典的失控场景。
用导入而不是直接查询 ，适用于很多人会打开的仪表板。
去分析中心看谁花得最多。 通常是某一个智能体或某一个集成，而不是普涨。

保留期

值得设边界的不只有成本。有三个保留期限可配置，每一个都由定时清理任务强制执行：

数据	在哪里设置	默认值
对话历史与生成的文档	智能体构建器 → 记忆（按智能体)	7 天（最少 7 天，可调大）
嵌入会话记录	按嵌入密钥	30 天
审计事件	长期保留，可导出	365 天

对话历史被清理时，随它保存的生成文档也会从存储中删除——文件不会比产生它的那次对话活得更久。

注意

保留期既是存储控制，也是隐私控制。在仍能满足用途的前提下，窗口越短越对——尤其是公开嵌入，那里会有陌生人把个人信息敲进对话框。

告警

预算会在拦下任何东西之前先预警——到 100% 才硬停、事先毫无提示，团队就只能靠「被挡住」来知情。阈值默认为 50%、75% 和 90%，每一档每月各发一封邮件：这项检查在每次模型调用之后都会跑，所以「越线即通知」必须理解为只通知一次。越过 100% 会发出独立的消息，单独记录，因此 90% 的预警不会把它压掉。

范围	邮件发给谁	默认值
个人上限	该预算所属的那个人	开启——参见可观测性 → 预算管理
用户组上限	超级管理员——也就是能调高它的人	关闭 ——在「管理 → IAM → 预算」下按用户组启用

团队告警发给管理员，不发给团队

只有超级管理员能调高用户组上限，所以他们才是能对预警采取行动的人。给每个成员都发邮件，同时也把团队的总消费额公开给了整个团队，而这是一个没人在设预算时做过的披露决定。如果你确实希望成员收到通知，那应该是一个有意识的选择，而不是给他们设上限的副作用。

告警与拦截是两个独立开关

一个用户组可以只被预警而不被拦截，也可以只被拦截而不被预警。正因如此，引入上限才是安全的：先打开告警，用一个月的真实消费对照你猜的那个数，确认猜得没错之后再启用拦截。

归属

每次模型调用都会记录触发它的用户、智能体和凭据，因此消费额可以追溯到某个人、某个集群、某枚嵌入密钥或某个 API 密钥。参见分析与审计.