不分子 key 时如何在一把聚合站 key 上拆分团队 USDC 预算

共用一把 key 为什么会失控

聚合站通常按 key 计费：一个 key 对应一份 USDC 余额，所有请求都从同一份余额里扣。团队为了省事让几个人共用一把 key 时，问题很快出现——账单上只有一条总消耗，看不出是谁、哪个项目花的。等到余额见底，没人能说清钱去哪了。

好在扣费是按请求发生的，如果我们能在请求上留下结构化标记，就能把一份共享余额还原成按人、按项目的账。下面是一套不依赖后台功能的实操做法。

第一步：给每个客户端打标

大多数 OpenAI 兼容接口都会把请求头原样带入网关日志，因此最轻量的办法是在请求里加自定义头：

• X-Project：项目或环境标识，例如 web-prod、batch-eval
• X-Developer：使用者标识，可以是工号或短名
• X-Purpose：用途标签，例如 chat、embedding、offline-test

在客户端侧统一注入：SDK 的默认头、CLI 的包装脚本、环境变量三处任一都可以。要点是让标记由代码自动带上，而不是靠人记得手写——靠自觉的标记，一周后就会消失。

如果你的客户端无法设置请求头（例如某些图形界面工具），退而求其次：给每人分发一个封装脚本，脚本里固定注入标记后再转发请求。

第二步：建立项目记账表

标记只是原料，还需要一张表把请求映射到预算。建议维护一份简单的映射表：

• 项目 → 月度预算（以 USDC 计）
• 项目 → 负责人
• 项目 → 允许的模型范围

这张表不需要复杂系统，一份表格就够。它的作用是给出判断口径：当某个项目的消耗接近预算时，谁该被通知、是否要限流。

第三步：定期拉取用量并对账

按周或按天导出用量明细，按 X-Project 汇总，与预算表比对。对账时关注三类异常：

1. 无标记流量：说明有客户端没按约定注入头，需要补配置。
2. 项目间比例突变：某个项目消耗突然翻倍，往往是调试脚本忘了关或误用了高价模型。
3. 单次请求异常大：长上下文或大批量调用，值得单独看一眼。

对账结果直接反馈到预算表，形成闭环。

第四步：用预算而非权限做隔离

共用一把 key 意味着无法在密钥层面做权限隔离，所以隔离要靠预算和流程：

• 软隔离：按项目设定预算，超额前提醒，超额后由负责人决定是否追加。
• 模型约束：在客户端配置里限制项目可用的模型，避免测试流量误用高成本模型。
• 独立 key 兜底：对消耗大或安全要求高的项目，宁可单独申请一把 key，把共享 key 留给低频使用者。

共享一把 key 的价值在于简化充值和管理，而不是取消边界。边界用标记和记账建立，比用密钥建立成本更低。

充值侧的一点提醒

聚合站支持用 Base 上的 USDC 充值、无需 KYC，团队可以把充值动作集中到一个人或一个流程里，其他人只负责消耗。这样余额变动有单一来源，对账时更容易解释每一笔差额。充值记录与用量记录分开保存，月末核对一次即可。

什么时候该放弃共享 key

如果出现以下情况，说明共享模式已经不划算：

• 无标记流量长期无法清零；
• 项目间预算冲突频繁，需要人工仲裁；
• 出现安全事件，需要立刻吊销某一个使用者的访问。

此时按项目拆 key 是更干净的方案。共享 key 适合小团队和早期阶段，随着人数和项目数增长，拆分是自然演进。