Workbuddy 怎么设置 API 密钥消费上限，只配单密钥预算会被哪些调用绕过？

Workbuddy 的 API 密钥消费上限要分两层设置：密钥级预算决定单个密钥能花多少，工作区或组织级配额决定整体盘子，只配前者，同账号下新建的密钥仍可继续产生费用。设置入口通常在密钥详情页的预算字段与用量管理页的配额项，字段包括计费周期、上限金额、告警阈值和超额后的动作，菜单名称随版本变化，以官方说明为准。 三层口径各管一段，混成一个数字就会互相干扰。密钥级预算管单个调用方，工作区配额管团队总支出，模型维度的单价权重管贵模型被滥用。三者合并成同一个额度，结果要么是某个密钥超额时整组人被一起熔断，要么是最贵的模型先把预算吃光、便宜模型反而调不动。 预算周期必须与结算周期对齐，否则上限会在不该生效的时候生效。把周期设成与账单一致的固定区间，并确认未用额度不累计，可以避免月初一次批量任务把整月额度占满、后面正常业务全部被拒。跨月结算的场景还要确认配额在周期切换时是按自然时间重置，还是按账单出账时间重置。 告警阈值和硬熔断是两件事，必须分开配置。只设告警不设熔断，密钥在触发阈值后仍会继续消费直到额度耗尽；只设熔断不设告警，调用方会在没有任何预警的情况下突然收到全部失败。可行的组合是阈值触发时通知到密钥负责人，继续消耗时降速或排队，触及上限时拒绝新请求。 单密钥上限最容易被三种操作绕过。一是同一账号下新建密钥不受旧密钥预算约束，二是子账号或协作者签发的新密钥沿用默认预算，三是客户端超时重试在服务端被计成多次调用。对应的做法是给新建密钥设默认预算模板、收紧密钥创建权限、在客户端关闭无上限的自动重试。 上限数字怎么估，取决于计费口径。输入与输出 token 分别计价，不同模型的单价差异很大，长上下文请求会把输入侧成本明显放大。估算时按实际会用到的最高单价模型乘以预估调用量，再留出余量，而不是照最便宜模型的价格随手填一个数，否则限额形同虚设。 重试、循环调用和缓存未命中，是预算表上看不见的增量。带自动重试的智能体在工具调用失败后会重新发起完整上下文，一次任务可能产生多轮计费；缓存命中率下降也会让同样的任务成本上升。做法是在任务层限制最大轮次，并持续观察单任务平均消耗是否发生漂移。 平台内设置的上限，不覆盖绕开平台的调用。团队成员若用模型供应商的原始密钥直连接口，Workbuddy 侧看到的用量为零，预算不会触发，也不会告警。需要把密钥持有范围收敛到平台侧签发的凭证，禁止把供应商密钥分发到个人开发环境，再谈限额才有意义。 想把核算集中到一处，可以在 Workbuddy 与模型供应商之间加一层网关或 API 中转，由它按密钥、项目、调用方分别计量并执行拒绝。这一层的价值是预算规则不必依赖每个客户端自觉，代价是多一跳延迟，实时性要求高的场景要先测过再决定是否套用。 上限配完必须验证，不能只看配置页面是否保存成功。做法是发一把低额度测试密钥，跑一次超额调用，确认告警是否真的到达负责人、熔断后返回的错误信息是否符合预期、额度恢复后是否自动放行；再拿平台用量与供应商账单对一次账，看差额集中在哪个维度。 边界要说清楚：密钥消费上限是费用控制手段，不是权限控制手段。它挡不住密钥泄露后的滥用，也替代不了吊销、轮换和最小权限分配。真正的止损顺序是先吊销异常密钥、再查调用来源，最后回头调整预算规则，反过来做只会让异常调用继续跑。 日常运维可以按月复盘每个密钥的实际消耗与上限的比值。长期远低于上限的密钥可以合并，长期贴着上限跑的密钥说明业务量变了、需要重新定档；同时给密钥设置有效期和轮换计划，让预算规则跟着密钥生命周期一起更新，而不是设完一次就再也不看。