1. 事故现场：一个协程跑掉 3000 万 Token 的那晚
先说结论：单个 Agent 协程如果没有任何预算约束，它可以在无人值守的 8 小时里把一篇格式错乱的 PDF 反复递归推理，最终烧掉 3000 万 Token。这不是段子，是我上周真实经历的事故复盘。
那晚的链路很典型：后台有个异步总结文章的 Agent，输入是一篇排版混乱的 PDF。解析器把表格拆成了碎片，Agent 拿到碎片后判断"信息不完整"，于是重新调用 LLM 补全，补全结果又被判定为"不完整"，再次调用。这个循环没有退出条件，也没有 Token 上限，协程就这么一直跑。第二天早上财务发来邮件，API 账单比平时多了近 1500 美金，Prometheus 上那个协程的 Token 计数器是一条笔直向上的斜线。
问题的本质不是代码写错了，而是我们把 LLM 调用当成了普通函数调用。传统服务里，一个死循环最多吃满 CPU，你重启就行；但 LLM 调用是按 Token 计费的非确定性操作，死循环的代价是真金白银。多 Agent 并发场景下，这种风险会被放大——十个协程同时失控，账单就是十倍。
所以这篇文章要交付的是一套可复制的**预算闸门（Budget Gatekeeper）**方案：在协程维度给每个 Agent 装上 Token 熔断，配合 TaoToken 统一 Key 通道做集中计量，把非确定性的 LLM 调用关进可观测的预算笼子里。适合正在跑多 Agent 并发、被账单吓过一次、或者想提前防住的工程团队。
2. 前置准备：用 TaoToken 统一 Key 通道收口所有调用
预算闸门要生效，前提是所有 LLM 调用都走同一个可计量的入口。如果每个 Agent 各自持有不同的 Key、直连不同的上游，你根本没法在网关层做统一扣减和熔断。这就是我选 TaoToken 的原因：它提供一个统一的 API 通道，所有 Agent 协程的请求都从这里过，计量和限流才有落点。
接入本身很简单，三步：
第一步，在 TaoToken 控制台创建一个 API Key。地址是 https://taotoken.net/api-keys ，创建后复制保存，这个 Key 就是所有 Agent 协程共用的通道凭证。
第二步，确认你的调用基址。TaoToken 的 API 入口是 https://taotoken.net/api ，兼容 OpenAI 风格的/v1/chat/completions，所以现有代码基本不用改，只换 base_url 和 api_key 即可。
第三步，如果你用的是 Claude Code 这类编码 Agent，TaoToken 也提供了对应的接入文档，地址在 https://taotoken.net/doc ，里面有 Anthropic 协议的具体配置方式。
注意：统一 Key 通道的意义不只是省事，而是让"预算扣减"有一个权威的计量点。协程本地的计数器可能因为异常退出而丢失，但网关侧的用量是持久的，两者对账才能发现漏网之鱼。
这里有个容易踩的坑：很多人把统一 Key 理解成"所有环境共用一个 Key"。生产、测试、本地开发一定要分开建 Key，否则测试环境的压测流量会污染生产预算，熔断阈值根本没法设。我建议按"环境 + 团队"维度建 Key，比如prod-agent-summary、staging-agent-summary，这样在控制台看用量时能直接定位到是哪个业务在烧钱。
3. 可复制配置：预算阈值骨架与协程级熔断
配置分两层：一层是声明式的预算阈值文件，一层是代码里的熔断逻辑。先给阈值骨架。
我习惯用config.toml管理多级预算，因为 TOML 支持嵌套表，读起来比 JSON 清爽：
# config.toml —— 多级 Token 预算闸门配置 [gatekeeper] # 单次 LLM 调用上限（含 prompt + completion） per_call_limit = 8000 # 单协程 Session 硬上限，超过立即熔断 per_session_limit = 100000 # 单用户单日上限 per_user_daily_limit = 2000000 # 系统单日总上限，触顶后暂停低优先级任务 system_daily_limit = 50000000 [gatekeeper.alert] # 单 Session 消费超过此值推送告警 session_warn_threshold = 50000 # 单小时系统消费超过此值（美元）暂停批量任务 hourly_cost_pause_usd = 50.0 [taotoken] base_url = "https://taotoken.net/api" # Key 从环境变量注入，不要硬编码 api_key_env = "TAOTOKEN_API_KEY" default_model = "gpt-4o-mini"如果你更习惯 JSON，等价的settings.json长这样：
{ "gatekeeper": { "per_call_limit": 8000, "per_session_limit": 100000, "per_user_daily_limit": 2000000, "system_daily_limit": 50000000, "alert": { "session_warn_threshold": 50000, "hourly_cost_pause_usd": 50.0 } }, "taotoken": { "base_url": "https://taotoken.net/api", "api_key_env": "TAOTOKEN_API_KEY", "default_model": "gpt-4o-mini" } }阈值怎么定？我的经验是从单次调用上限倒推。先看你的业务里最长的 prompt 加最长的 completion 大概多少 Token，乘以 2 作为per_call_limit；再看一个正常 Session 平均调用几轮，乘以单次上限再留 3 倍余量作为per_session_limit。上面这套值是我们线上跑了两周后收敛出来的，单 Session 10 万 Token 的硬顶，正常业务根本碰不到，但失控协程会在第 13 轮左右被拦下。
接下来是协程级的熔断代码。核心是线程安全的原子计数器，加上调用前后的双重扣减：
package budget import ( "context" "errors" "fmt" "sync/atomic" ) var ErrBudgetExceeded = errors.New("session token budget exceeded") // Gatekeeper 协程级 Token 预算闸门 type Gatekeeper struct { maxSessionTokens int64 usedTokens int64 warnThreshold int64 onWarn func(used int64) } func NewGatekeeper(maxSession, warnThreshold int64, onWarn func(int64)) *Gatekeeper { return &Gatekeeper{ maxSessionTokens: maxSession, warnThreshold: warnThreshold, onWarn: onWarn, } } // Consume 原子扣减预算，超额立即返回熔断错误 func (g *Gatekeeper) Consume(tokens int64) error { newTotal := atomic.AddInt64(&g.usedTokens, tokens) if newTotal > g.maxSessionTokens { return fmt.Errorf("%w: used=%d limit=%d", ErrBudgetExceeded, newTotal, g.maxSessionTokens) } if g.onWarn != nil && newTotal >= g.warnThreshold { g.onWarn(newTotal) } return nil } func (g *Gatekeeper) Used() int64 { return atomic.LoadInt64(&g.usedTokens) }然后在 LLM 调用包装里做拦截。关键点是调用前预估 prompt Token 先扣，调用后按实际 completion Token 补扣，这样即使调用中途 panic，预算也不会漏记：
func CallLLMWithBudget(ctx context.Context, g *Gatekeeper, client *LLMClient, prompt string) (string, error) { // 1. 调用前预估并预扣 prompt Token estimatedPrompt := int64(EstimateTokens(prompt)) if err := g.Consume(estimatedPrompt); err != nil { return "", err } // 2. 实际调用，走 TaoToken 统一通道 resp, err := client.Chat(ctx, prompt) if err != nil { return "", err } // 3. 调用后按实际 completion Token 补扣 actualCompletion := int64(resp.Usage.CompletionTokens) if err := g.Consume(actualCompletion); err != nil { return "", err } return resp.Content, nil }每个 Agent 协程启动时创建一个独立的Gatekeeper，Session 结束就丢弃。这样协程之间互不影响，一个失控不会拖垮其他协程的预算。
4. 验证请求：确认熔断真的会触发
配置写完不验证，等于没写。我设计了一个最小验证用例：把per_session_limit临时调到 2000，然后跑一个会持续调用的循环，看它是否在第 N 轮被拦下。
func main() { // 临时小预算，方便验证熔断 g := NewGatekeeper(2000, 1500, func(used int64) { fmt.Printf("[WARN] session token 已达 %d，接近上限\n", used) }) client := NewLLMClient(os.Getenv("TAOTOKEN_API_KEY"), "https://taotoken.net/api") for i := 1; i <= 10; i++ { _, err := CallLLMWithBudget(context.Background(), g, client, "继续推理下一步...") if err != nil { if errors.Is(err, ErrBudgetExceeded) { fmt.Printf("[CUTOFF] 第 %d 轮成功熔断: %v\n", i, err) break } fmt.Printf("第 %d 轮其他错误: %v\n", i, err) break } fmt.Printf("第 %d 轮成功，已用 Token: %d\n", i, g.Used()) } }预期输出是这样的：
[WARN] session token 已达 1520，接近上限 第 1 轮成功，已用 Token: 1520 [CUTOFF] 第 2 轮成功熔断: session token budget exceeded: used=3040 limit=2000看到[CUTOFF]那行，说明闸门生效了。这时候再去 TaoToken 控制台的用量页面核对一下，确认网关侧记录的 Token 数和本地计数器基本吻合。如果差异超过 10%，通常是 prompt 预估函数偏差太大，需要校准EstimateTokens。
提示：验证阶段建议用便宜的小模型（比如
gpt-4o-mini）跑，别拿gpt-4o做熔断测试，不然验证本身就成了新的账单事故。
5. 本篇常见错排查
错误一：熔断没触发，协程还是跑满了。最常见的原因是Consume用了非原子操作，多 goroutine 并发时计数丢失。检查是否用了atomic.AddInt64，而不是g.usedTokens += tokens。另一个可能是预扣逻辑被跳过——有些 SDK 的流式接口不返回 usage，导致 completion Token 没扣上，需要在流结束时手动估算。
错误二：ErrBudgetExceeded被上层吞掉。如果 Agent 的调用层有recover()或者宽泛的if err != nil { continue }，熔断错误会被当成普通错误忽略，循环继续。务必用errors.Is(err, ErrBudgetExceeded)精确判断，命中后break或return，不要continue。
错误三：TaoToken 返回 401 或 404。401 通常是 Key 没注入环境变量，检查TAOTOKEN_API_KEY是否 export；404 多半是 base_url 写错了，正确值是https://taotoken.net/api，注意不要多加/v1后缀（SDK 一般会自动拼）。如果用的是 Anthropic 协议，参考 https://taotoken.net/doc 里的配置说明。
错误四：本地计数和网关用量对不上。差异来源通常是重试。如果 SDK 内部对失败请求做了自动重试，本地只扣了一次，网关却记了两次。解决办法是在CallLLMWithBudget里禁用 SDK 自动重试，把重试逻辑收到预算闸门内部，每次重试都走一次Consume。
错误五：告警阈值设得太低，天天被骚扰。session_warn_threshold如果设成 10000，正常业务每轮都触发。建议先跑一周只记录不告警，观察 P95 的 Session 用量，再把阈值设在 P95 的 1.5 倍左右。
6. 把预算闸门接进你的 Agent 流水线
到这里，单协程的熔断已经能跑了。但多 Agent 并发场景还需要补两块：一是把Gatekeeper的用量定期上报到 Prometheus，做全局可视化；二是当系统单日消费触顶时，自动暂停低优先级的批量任务，保住核心链路。
上报这块，我是在onWarn回调里加了一个 Prometheus Gauge，每次扣减后更新agent_session_tokens_used，标签带上agent_name和session_id。这样在 Grafana 上能直接看到哪个 Agent 在异常增长，不用等账单出来才发现。
至于长期跑编码类 Agent 的团队，如果调用量大、需要更稳定的通道配额，可以了解一下 TaoToken 的 Coding Plan，地址是 https://taotoken.net/coding-plan ，它针对高频编码场景做了通道优化。日常调试和验证模型行为，用模型对话页面 https://taotoken.net/models 就够了，不用每次都写代码。
最后说个我踩过的坑：预算闸门上线后，别急着把阈值调到最紧。先宽松跑一周，收集真实的 Session 用量分布，再逐步收紧。我一开始把per_session_limit设成 5 万，结果正常的长文档总结业务被误杀了好几次，后来调到 10 万才稳定。熔断是保险丝，不是油门，它的目标是拦住失控，不是限制正常业务。
