聊天应用日志 vs 接口日志：为什么网页控制台和脚本看到的历史不一样
浏览器聊天会话与直接调用接口留下的日志在记录主体、粒度、保存位置和保留策略上存在本质差异，导致同一操作在网页控制台和脚本中看到的历史不一致。本文解释这些差异的成因，并给出审计时对齐两边记录的可操作步骤。
为什么两边看到的历史不一样
同一模型调用，通过网页聊天界面完成和通过脚本直接调用 API，留下的记录往往对不上。这不是某个平台的 bug，而是两种交互方式在日志记录上的设计目标不同。
理解差异，才能在做审计、排查费用或复现问题时把两边对上。
记录主体不同：会话状态 vs 请求事件
网页聊天控制台通常以「会话」为单位组织历史。它记录的是对话列表、每条消息、模型选择、时间戳等，目的是让用户能继续对话。
裸调接口则以「请求」为单位。每次 HTTP 调用是一条独立记录，包含请求 ID、模型、token 用量、状态码、耗时等。它不关心这些请求是否属于同一个对话。
结果：网页看到的是「一段对话」，脚本看到的是「一串请求」。
记录粒度不同：消息合并 vs 逐次调用
网页界面可能把一次用户发送合并为一条记录，即使背后触发了多次模型调用（例如重试、工具调用、流式分段）。
裸接口日志则是逐次调用记录。一次用户操作如果产生三次 API 请求，日志里就是三条独立条目。
这会导致两边「条数」无法直接对应。
保存位置不同：浏览器侧 vs 服务端
网页聊天历史通常部分保存在浏览器本地（localStorage、IndexedDB）或平台自己的会话存储中，用户清缓存、换设备就可能丢失。
接口日志保存在 API 提供方的服务端，按请求 ID 和 API key 归属，与浏览器无关。
所以同一账号在两处看到的历史范围可能不同：网页侧可能只有当前设备的历史，接口侧则覆盖该 key 的所有调用。
保留策略与归属维度不同
网页会话通常按用户账号归属，保留时间取决于产品策略。
接口日志按 API key 归属，按请求保留。一个 key 可能被多个脚本、多台机器使用，日志里不会区分来源。
如果多个脚本共用一个 key，网页侧看到的「一个会话」可能对应接口侧来自不同环境的多个请求。
审计时如何把两边对上
目标是建立「网页操作」与「接口请求」之间的对应关系。可以按以下步骤做：
- 固定时间窗口
先确定要审计的时间段，两边都按同一 UTC 时间范围过滤。注意网页显示可能是本地时区，接口日志通常是 UTC。
- 用请求 ID 或时间戳做锚点
网页端如果能看到请求 ID，直接用它去接口日志里匹配。看不到时，用精确到秒的时间戳做近似匹配，并接受一定误差。
- 按模型和 token 用量交叉验证
同一操作在两边应使用同一模型。对比输入输出 token 数，可以判断是否对应同一次调用。
- 区分「用户操作」与「接口请求」
在审计表中为每个用户操作建立一行，再列出它对应的所有接口请求。不要试图让两边条数相等。
- 处理重试和流式分段
如果接口日志里出现相邻的、参数相同的多条请求，可能是客户端重试或流式分段。把它们归并到同一个用户操作下。
- 核对归属 key
确认网页会话使用的 key 与接口日志中的 key 一致。如果平台允许多 key，先按 key 分组再匹配。
- 记录无法匹配的条目
有些请求可能没有对应的网页操作（例如其他脚本调用），有些网页操作可能没有接口日志（例如请求失败未到达服务端）。把这些单独列出，不要强行对齐。
实践建议
- 在脚本里为每次用户操作生成并记录一个自定义标识（如放在请求头或日志里），便于后续和网页侧关联。
- 不要依赖网页聊天历史做费用审计，以接口日志的 token 用量为准。
- 如果使用聚合站，注意其计费按官方价乘以系数，审计时应以聚合站提供的用量记录为基准，而不是网页界面的显示。
- 保留原始接口日志，不要只依赖网页控制台的会话记录。
两边历史不一致是正常的。审计的关键不是让它们相等，而是建立可追溯的对应关系。