Workbuddy 怎么给每个 API 密钥设置消费上限，只有总额告警能不能做到超额自动停用？

Workbuddy 的 API 密钥消费上限不是创建密钥时填一个数字就能生效，而是在控制台的用量与计费设置中先建立预算额度和告警阈值，再把密钥绑定到对应的项目或分组，限额才会对该密钥的调用计费产生约束。这个入口只对工作区管理员或持有计费权限的账号开放，普通成员只能看到自己名下密钥的用量曲线，改不了额度。个人账号、试用账号，以及部分尚未开放预算模块的版本，通常只有总额告警而没有逐密钥硬上限，这种场景要另外设计兜底方案。 消费上限要分组织级和密钥级两层看，只设其中一层都会留下缺口。组织级预算管的是整个工作区一个月最多花多少，防止单个成员或单条自动化脚本把整体费用推高；密钥级额度管的是某条具体凭证能被谁、在什么任务里用掉多少，防止一把密钥被复制到多个环境后失去归属。两层都设之后，实际生效的是两者中先被触发的那一个，所以密钥额度的总和通常要略低于组织预算，留出临时扩容的余量。 预算里的告警阈值和硬性停用是两个独立开关，前者只发通知，后者才会真正阻断调用。只开告警不开停用，等于把决定权交给了值班的人；只开停用不开告警，则会在没有任何预兆的情况下让线上任务失败。稳妥的做法是把额度分几档设置，在接近上限时先触发通知，到达上限时执行停用，中间留出一段可以人工判断、提额或切换备用密钥的时间窗口。 把密钥绑定到项目或分组，比逐条密钥单独设额度更耐用。逐条设置的问题是密钥一旦轮换，新密钥不继承旧额度，限额就形同虚设；而绑定到分组后，组内所有密钥共享同一份额度，轮换只会换掉凭证，预算边界不动。对需要定期轮换密钥的团队，这条比额度数值本身更重要，配置时应当先建分组、定预算，再往里投放密钥。 速率限制和消费上限管的是两件事，不能互相替代。速率限制约束的是单位时间内的请求数或并发数，防止瞬时打爆服务；消费上限约束的是累计金额，防止长期跑量把预算吃穿。在速率限制之下，一条低频但调用高价模型的密钥依然可以在一个月内产生可观费用，所以两项配置需要同时存在，缺一项都会留下盲区。 同一个密钥调用不同模型的单价差距很大，上限按金额设而不是按调用次数设，才能覆盖模型混用的情况。如果只限制请求次数，调用便宜模型的批次会把次数额度快速耗尽，而调用高价模型的长文本任务反而可能没有触发限制就已经把花费推高。更细的做法是把高价模型单独拆到一条密钥或一个分组里，给它单独的额度，让成本波动被隔离在局部。 告警必须指定接收人和处理方式，否则阈值只是一个数字。配置时需要确认通知发到哪里，是邮件、群机器人还是工单系统，并明确收到通知后由谁判断是提额、切模型还是停任务。缺少这一步时，告警会在夜间或周末被忽略，等发现时额度已经用完，业务侧看到的只是调用失败，排查成本远高于提前处理。 超额之后是直接停用还是降级到低价模型，取决于这条密钥是否承载生产链路。面向内部的批处理、数据清洗、测试验证类任务适合硬停，停掉只是延后，不会影响外部用户；面向线上客服、实时问答的任务更适合配置降级或切换备用密钥，避免额度耗尽直接变成服务不可用。这条策略要在配置额度时就写清楚，而不是等超额当天临时决定。 控制台没有逐密钥硬上限时，可以在调用链上自己加一层配额。常见做法是把所有请求收敛到自建网关或统一的中转入口，由网关按密钥标识累计用量并在超限时返回错误，业务侧只需要换一个调用地址。这样做的代价是多一跳延迟和一层运维，但换来的是与供应商无关的配额控制，换模型、换账号时策略不用重写。 对账要在每月固定时间做一次，按密钥、项目、成员三个维度核对用量和实际扣费。核对顺序通常是先看总花费是否与预算一致，再看有没有哪条密钥的花费曲线出现台阶式上升，最后确认这条密钥对应的任务是否正常。出现异常增长时，优先排查密钥是否被复制到测试环境、是否有循环重试未设上限、是否有成员把生产密钥用在了个人脚本里。 配置里最常见的三个错误，是只设总额不设单密钥、把测试密钥和生产密钥放进同一个预算、以及轮换密钥后忘记迁移额度。第一种会让整个工作区被一条失控的密钥拖住；第二种会让测试跑量挤占生产额度；第三种会让限额在新密钥上直接失效，但控制台看起来一切正常。这三类问题都不会报错，只能靠定期核对发现。 最小可用的配置顺序是：先建组织级月度预算并设置接近上限的告警，再按项目或环境建分组并分配组内额度，然后把密钥投放到分组而不是单独设额度，最后确认告警接收人和超额后的处理动作。四步做完，才算真正有了消费上限；只做完第一步，得到的只是一个提醒，而不是一条边界。Workbuddy 各版本开放的配置项不同，具体入口名称和可设范围以控制台实际显示为准。