部署完 DevAssistant ProGrafana 上devassistant_tokens_consumed_total的曲线一直在涨TaoToken 控制台里这把 Key 的 Token 统计却是另一个数字。TaoToken 官网https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end可以帮你把这次排查变成一次可控实验创建一把专用 Key把模型 Base URL 切到 https://taotoken.net/api用同一段 prompt 重放请求逐层核对返回体 usage、cost-control 日志和监控指标。应用侧 CostTracker 记录着 inputTokens、outputTokens、costUsdPrometheus 的计数器也在正常暴露指标可和通道侧的实际消耗就是对不上。与其靠感觉改统计代码不如先确认分叉点到底在应用统计层还是在模型接入层。下面这套重放流程走完你就能对着 Grafana 和账单说出“问题出在哪儿”而不是继续拍脑袋调参。1. 先理清是 CostTracker 还是 Prometheus 的账错了1.1 DevAssistant Pro 内部的三套统计口径DevAssistant Pro 里至少有三处会记录 Token。第一处来自packages/shared/src/cost-control.ts的 CostTracker每次 Agent 调用结束后recordUsage会把 inputTokens、outputTokens、costUsd 写入 Redis 的日/月累计键同时落一条event: cost.tracked的结构化日志。第二处是packages/shared/src/metrics.ts暴露的 Prometheus Counter名为devassistant_tokens_consumed_total带 model、type、project_id 三个 label。Grafana 上的消耗曲线、成本告警基本都是从这个 Counter 来的。第三处在通道侧。接入 TaoToken 之后控制台也会按 Key 聚合调用次数和 Token 数这部分统计和 DevAssistant Pro 的应用内计数器是两套独立系统。对账的本质是拿同一个请求去撞这三处统计看它们在哪一步开始分裂。只看总量几乎不可能定位因为每套记录的时间点、计价口径、持久化方式都不一样。1.2 重放请求为什么是最高效的定位方式生产环境里 Agent 请求都是并发的一个 session 会交织多轮对话、工具调用、RAG 检索想单拎一个请求对账光靠日志聚合就要花很长时间。重放把条件压缩到最简单一个固定 prompt、一个固定 project_id、一次调用所有统计入口都只受这一条请求影响。重放还能固定参数。比如把 temperature、max_tokens、context 长度都定下来inputTokens 和 outputTokens 的范围基本可预测。只要这条请求能在三层统计里对得上生产流量的分叉问题就一定是特殊场景触发的而不是全局统计 bug。前提是有一把能稳定复现的 Key以及一个能单独观测请求的 Base URL。2. 准备一把重放专用的 TaoToken Key2.1 注册并创建 API Key保存为 YOUR_API_KEY在 TaoToken 注册并登录进入控制台创建一把新 Key复制后保存为YOUR_API_KEY。创建页面只展示一次完整 Key刷新就看不到了。建议这把 Key 单独命名成replay-check不要和生产共用后续在控制台看用量时才能精确过滤。注意这里说的 Key 是给 DevAssistant Pro 转发模型请求用的不是 DevAssistant Pro 自己的登录凭证。TaoToken 只提供 Key 和 Base URL真正跑请求、数 Token、写日志的是 DevAssistant Pro 自己TaoToken 不会替你埋点也不进你的生产容器。2.2 在模型广场确认当前模型 ID去 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 的模型广场找到 DevAssistant Pro 里配置的那个模型 ID。这一步不能凭印象写。CostTracker 的MODEL_PRICING表是按模型 ID 取价格的如果表里没有这个模型calculateCost会 fallback 到默认价格重放完你就会发现 costUsd 和实际账单不一致但 inputTokens/outputTokens 又完全对得上容易被误判成“通道计价不准”。所以先把模型 ID 记下来后面填配置和查日志都拿它当关键字。模型 ID 以模型广场当时列表为准不要用文档示例里的旧 ID。3. 把 DevAssistant Pro 的模型接入指到 TaoToken3.1 修改 .env 里的模型接入配置DevAssistant Pro 的模型调用走环境变量。以.env为例加入或替换这几项ANTHROPIC_BASE_URLhttps://taotoken.net/api ANTHROPIC_AUTH_TOKENYOUR_API_KEY ANTHROPIC_MODEL以 TaoToken 模型广场为准 OPENAI_BASE_URLhttps://taotoken.net/api OPENAI_API_KEYYOUR_API_KEY这里要分清两个地址的职责注册、创建 Key、看模型广场、看用量走落地页 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 填进程序环境变量的是接口地址 https://taotoken.net/api末尾不要加/v1也不要带任何 UTM 参数。一个给人点一个给程序用混了会导致连接失败或鉴权失败。如果 DevAssistant Pro 是 docker compose 部署确认docker-compose.yml里确实把这两项透传给了 api 容器而不是只在.env文件里写了一遍。环境变量没映射进去重启多少次都不会生效。3.2 重启 API 并检查健康状态改完配置后重启 api 服务docker compose restart api容器起来后先打一次健康检查curl -sf http://localhost:3000/api/health返回 ok 后从日志确认没有模型接入报错docker compose logs api --tail 200 | grep -E error|ECONNREFUSED|401如果 Base URL 填错这步就能看到连接失败或鉴权失败不用等到重放再查。4. 用同一 prompt 重放请求核对 usage 字段4.1 重放前记录 Prometheus 基准值先用 PromQL 查一下当前计数devassistant_tokens_consumed_total{project_idreplay-check}记下返回值。如果这个 label 之前没出现过结果是空也没关系重放后它会出现。对比时看增量不看总量。Counter 在进程重启后会清零所以重放前后各取一次值做差是最稳的比法。4.2 调用 DevAssistant Pro 的 /api/agent/query用 curl 向 DevAssistant Pro 自己的接口发起一次同样请求认证头按你项目里的实际要求填这里只关注 usage 字段curl -s -X POST http://localhost:3000/api/agent/query \ -H Content-Type: application/json \ -H Authorization: Bearer devassistant-api-token \ -d {prompt:请列出 DevAssistant Pro 的生产运维检查清单,project_id:replay-check}返回 JSON 里找到 usage 对象里面的 inputTokens 和 outputTokens 就是这次请求真实消耗的 Token 数。这个数字是后续所有比对的基准。再次强调curl 打的是 DevAssistant Pro 的地址不是 TaoToken 的地址。TaoToken 的 Key 和 Base URL 只负责让 DevAssistant Pro 能把请求转给模型真正触发logTokenUsage、Prometheus 计数的是 DevAssistant Pro 自己的代码。4.3 对照三层账目确认分叉位置重放完成后把四处的数字放一起比数据来源要看的字段判断标准返回体 usageinputTokens / outputTokens本次请求的真实消耗cost-control 日志event: cost.tracked数值应等于 usagePrometheus 增量devassistant_tokens_consumed_total增加量应等于 usage 总和TaoToken 控制台该 Key 的调用记录请求数应出现 1 次如果前三处一致说明 DevAssistant Pro 内部统计链路是通的。如果只是 costUsd 和控制台金额差一点问题多半出在计价模型上。TaoToken 控制台里的用量明细登录 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 后就能看到对账时以控制台的请求计数做交叉验证重点看单价差异。5. 重放后仍然对不上的四个典型原因5.1 MODEL_PRICING 表里没有当前模型CostTracker 的calculateCost先从MODEL_PRICING表按模型 ID 查价格查不到就 fallback 到默认模型的价格。如果 DevAssistant Pro 是旧版本表里没有你新配的模型 ID日志里的 costUsd 就是按默认价算的和控制台实际账单当然对不上。重放后如果看到 inputTokens/outputTokens 一致、costUsd 却偏低或偏高先查MODEL_PRICING表是否包含当前模型 ID把模型广场里的真实模型 ID 和价格补进去。不要凭记忆填版本号以模型广场当时列表为准。5.2 缓存命中的 Token 被当作普通输入计价logTokenUsage里有cacheHit字段。部分模型会把缓存命中的输入 Token 和普通输入 Token 分开计价而 CostTracker 的calculateCost只按总 inputTokens 算账没有拆分缓存部分。如果重放请求命中了缓存偏差就会体现在 costUsd 上。修正方式是在recordUsage入参里把缓存命中的 Token 数单独传进去计价时按不同单价计算或者在日志里保留 cacheHit 标记对账时手动扣掉缓存部分的价差。5.3 Counter 重启清零导致 Grafana 曲线下跌devassistant_tokens_consumed_total是 prom-client 的 Counter只保证单调递增进程一旦重启就会归零。K8s 滚动更新或 docker compose 重建容器后Grafana 上直接展示 counter 值的面板会出现断崖式下跌看起来像 Token 统计丢了实际只是计数基准被重置。对账不要看 counter 的绝对值应该用rate()或increase()函数或者像 4.1 那样重放前后取差值。这样可以过滤掉“统计基准被重置”的干扰专注真实消耗。5.4 ELK 日志链路里丢了一条 token_usage 事件原文的日志方案是 pino 结构化日志送到 Elasticsearch。如果 Logstash filter 对 event 字段解析有问题或者 Filebeat 只收集了部分容器日志就会出现 Prometheus 有计数、日志里却找不到cost.tracked的情况。重放时用 requestId 作为关联键在 Kibana 里过滤这次请求的全链路日志。如果预期时间窗口内确实没有cost.tracked那就是日志管道的问题和模型侧计费无关。修 Logstash 配置后重放一次即可验证。跑完这一轮重放DevAssistant Pro 内部的三层统计是否一致、TaoToken 控制台里的 Key 用量是否能对上就都有结论了。验证通过后devassistant_tokens_consumed_total才有资格作为每日对账的正式依据。后续如果要把这把重放专用的 Key 留作日常观察去 API Keys 控制台 能直接看到它的调用记录想确认模型连通性先到 模型对话 发一条测试消息。Agent 任务长期跑的话顺便看看 Coding Plan 的套餐结构按项目维度评估成本会更轻松。