BP19 · 用户级 credit 配额#

定位：面试官追问成本控制、计费设计、防薅策略时的拷问预备。

---

核心口述（30 秒）#

“项目已有两层 token 记账——事后测量（只看不拦）和单任务成本闸（拦单次爆炸）。但两层都挡不住「同一个人连发一百条合规 query」。缺一把跨会话、跟人绑定的尺子。按成本（美元）而非裸 token 计——prompt cache 命中的 token 单价 1/4，按 token 记等于罚追问多的用户。对外换算成整数 credit（1 credit = $0.001）。账本主键 (user_id, date_utc)，单行汇总 O(1) 读，换天自动换行不需定时任务。“

---

拷问链#

Q: 为什么按成本而不按 token 数计费？#

prompt cache 命中的 input token 单价只有原价 1/4。按 token 裸数记账等于把缓存省下来的钱当真花的——追问越多罚越狠，而追问恰恰是购物 Agent 最希望用户做的事。按成本计，缓存省下来的钱真的省给用户。

Q: 为什么一行汇总而不是流水表？#

配额判定是最热读路径（每次发任务 + 前端余额条都查）。流水表要 SUM() 全表扫，一行汇总主键命中 O(1)。审计不需要另存：每轮对话的 token 和成本早就落在对话消息里了。

Q: 日重置怎么实现的？#

不靠定时任务清零。账本主键是 (user_id, date_utc)，新的一天第一次记账自然 upsert 出新行、从 0 起算。老行留着就是历史账单。重置是「换了一行」的副作用——没有定时任务就没有「定时任务挂了全体用户第二天用不了」的事故。

Q: 最后一次任务能透支多少？#

入口闸判「有余额就放行」，放行后没人管——剩 $0.01 照样能烧满 $0.50 的任务。修法：开跑时取 min(单任务预算, 今日剩余) 压成本次上限。两把闸各管各的维度（单次 / 全天），在这里咬合成连续防线。

Q: 取消任务的账怎么算？#

取消后 finally 里照样记全树已消耗的 token。判定原则：记账依据是「花没花钱」不是「任务成没成功」。超时同理。取消信号向上传播，但记账本身跑在 shield 里不被打断。

Q: 额度耗尽为什么不锁输入框？#

Agent 会主动向用户提问（ask_user），那轮任务早在入口放行了。锁输入框 = 用户回不了话 → 任务等到超时 → token 照样烧了。正确粒度：只禁「起新任务」，不禁「打字回复」。

---

压力题#

Q: 配额在鉴权关闭时生效吗？#

不生效。鉴权关闭时所有人共用假身份，对假身份记账 = 一个人烧完全体停用。没有可信身份就没有可执行的配额——两者捆绑。