日志与对账：把 token 消耗算到项目维度

先解决「记录什么」

一个够用的调用日志，七个字段：

两个关键点：

1. tokens_in / tokens_out 必须分开。输出单价通常是输入的 3–5 倍，合在一起统计会让你完全误判成本结构。
2. key_id 与 project 要分开。同一个项目可能用多个 Key，同一个 Key 也可能服务多个项目。两个维度都有，才能做双向追溯。

cost 要不要自己算：要。站方后台给的是总额，而你需要的是按维度拆分的金额。自己维护一张单价表（模型 → 输入价 / 输出价），每次调用按 usage 折算。

落在哪里

原则：日志不能影响主流程。

• 异步写：不要在每个请求里同步写数据库（会增加延迟，且日志库出问题会拖垮业务）；
• 先写本地队列 / 文件，再由独立进程批量入库；
• 失败不阻塞：日志写失败就丢弃并计数，绝不能让日志问题变成业务故障。

一个廉价的起步方案：写 JSONL 文件，每天一个。查问题时 grep 足够；需要统计时用脚本聚合。这个方案能撑到相当规模，不要一开始就上数据库。

三种对账方法

方法一：与站方账单对（验证）

做法：拿你自己的 sum(cost) 与站方后台的扣费对比。

判据：

• 差异 < 5% → 正常（token 计数口径的细微差异）；
• 差异 5%–20% → 需要查。可能是某些调用没记到日志、或单价表过时；
• 差异 > 20% → 有问题。可能是站方的计费口径与你的理解不同（比如它按输入输出同价算），或存在你没记录的调用。

这一项的价值：它是唯一能发现「站方计费与公示价格不一致」的方法。 不做对账，你永远不会知道。

方法二：与自己估算对（预测）

做法：对每个业务动作，预估它的 token 消耗，然后与实际对比。

例如：「每次生成一篇文章大约消耗 2000 输入 + 1500 输出」。如果实际是 8000 + 6000，说明有额外的消耗来源（上下文累积、重试、或者系统提示过长）。

判据：实际 > 预估 2 倍以上 → 找原因。

常见的三个原因：

1. 上下文累积（Agent 每轮都带完整历史 → 输入呈平方增长）；
2. 重试（失败后自动重试，每次都计费）；
3. 系统提示过长（工具定义、角色设定占了大量输入）。

方法三：与业务量对（合理性）

做法：总成本 ÷ 业务量，得到单位产出成本。

例如：每生成一篇内容的成本、每处理一个文档的成本、每次用户会话的成本。

判据：这个数突然跳变 → 立刻查。

这一项是最有价值的，因为它把技术指标转换成了业务可理解的数字。向团队解释「这个月 API 花了多少」很抽象，而「每篇内容成本从 0.3 元涨到 1.2 元」是所有人都能理解的问题。

三条能发现异常的判断规则

规则一：单个请求的输入 token 超过阈值

指向的问题：上下文累积、系统提示突变、或误把大文件塞进去了。

处置：把超过阈值的请求详情打出来（不要只记数字），看内容里有什么。

规则二：同一个 key_id 在短时间内的请求数陡增

指向的问题：循环调用、失控的重试、或者 Key 泄露。

处置：先看请求内容。如果内容重复，是循环；如果内容模式陌生，是泄露。

规则三：失败率突然上升但业务量没变

指向的问题：供应商侧故障、你的配置变更、或者上游限流。

处置：按 status 分组看失败原因。区分 4xx（你的问题）与 5xx（它的问题）。

一个务实的实施顺序

第 1 步：把 base_url / Key 收敛到统一出口（半天）
第 2 步：加 usage 记录（写 JSONL，异步）（半天）
第 3 步：维护一张单价表（模型 → 输入价/输出价）（2 小时）
第 4 步：做一个按 project + 按天的汇总脚本（半天）
第 5 步：设一条告警：「单日用量 > 近 7 日均值 2 倍」（1 小时）

加起来约两天。 这两天带来的收益是：你从此知道钱花在哪、能发现异常、能向团队解释成本。

相比之下，在「看不见用量」的情况下做成本优化，等同于闭着眼睛调参数 —— 你无法判断改动是否有效。

最后一点

本站无法替你完成对账（因为你用的是自己的 Key），但两件事可以帮上忙：

1. 详情页的核验状态与实测数据，用于判断这家站值不值得继续用；
2. 官方的价目基准表（/model/lists），用于维护你的单价表 —— 尤其是判断它的倍率是否合理。

对账这件事，最终只能由你自己做。但它不难，难的是开始做。