指南/输入 Token 膨胀
AI 请求输入 Token 莫名变多：中转层可能加了什么
用户输入的文字没有变，响应里的输入 Token 却突然增加。这个差异可能来自客户端附带的历史与工具，也可能出现在协议转换或中转层。判断前要先确认计量对象，再把客户端出站请求、响应 Usage 和请求次数分开核对。
输入 Token 计算的不止用户消息
界面里能看到的提问，通常只是模型输入的一部分。系统提示词、对话历史、工具名称与参数结构、图片和文件也可能进入计数。Anthropic 的Token 计数文档明确把 system、tools、images 和 PDFs 纳入结构化输入；Gemini 的计数接口同样说明完整请求会包含系统指令与函数声明。
因此，「用户消息字数没变」与「模型输入没变」是两项不同事实。要解释输入 Token 增长，必须看到应用序列化后发出的完整请求；聊天框截图无法覆盖隐藏在应用配置里的 system、developer、tools 或历史消息。
模型也会影响计数。同一段内容交给不同 tokenizer，Token 数可能不同。模型别名移动、固定版本迁移和调用协议变化都要记入排查范围，相关版本边界见模型名称没变，后端行为为什么会漂移。
先分清增加发生在哪个计量单位
「Token 变多」可能指四种记录，它们不能混算：
| 看到的数字 | 它描述什么 | 先核对什么 |
|---|---|---|
| 单个响应里的 Usage | 服务方为这一笔响应报告的输入分项 | 原始 JSON、模型、协议与请求 ID |
| 中转站的一条消费明细 | 中转站如何把请求记账 | 明细是否对应一次上游调用，倍率是否另算 |
| 某个时间段的汇总 | 时间窗口内多笔请求的总量 | 请求数、失败数、自动重试与跨时区边界 |
| 一次用户操作的成本 | 应用为了完成一个动作发出的所有调用 | 主请求、工具续轮、后台摘要与重试记录 |
自动重试主要增加调用总量，不会自然地把某次上游响应的 input_tokens 变大。OpenAI 官方 JavaScript SDK 的重试说明写明部分连接错误、429 与服务端错误默认会重试；Gemini 的故障排查文档也说明官方 SDK 对部分暂时性错误带有自动重试。若中转站把多次尝试合并成一条账单记录，只有它的计费实现或上游日志才能确认。
比较前还要统一字段公式。某些接口把缓存输入列在输入总量里面，再额外给出缓存明细；另一些接口把未缓存输入、缓存写入和缓存读取分开返回。把分项再次相加，可能把同一批 Token 计算两遍。账户扣费又可能在 Usage 之外应用价格倍率，余额减少与响应 Token 数不能直接画等号。
厂商提供 Token 计数接口时，它可以作为补充证据。使用已经获准处理并完成脱敏的原始请求，按请求当时的模型与完整结构计数；只送一段用户正文，会漏掉 system、tools 和历史。Anthropic 同时提醒计数结果属于估算，创建消息时的实际输入可能有小幅差异。计数结果能验证当前请求在官方 tokenizer 下的规模，无法展示中转层最终转发的内容。
哪些内容可能在途中增加
应用附带了更多上下文
聊天框仍显示同一句话，客户端可能已经重发整段历史、上一轮工具结果或自动摘要。Agent 框架还会随请求发送工具清单；工具说明与 JSON Schema 较长时，输入 Token 会明显高于可见消息。Gemini 官方文档把系统指令和工具计入输入，Anthropic 的计数结果也覆盖 messages、system 与 tools。
这类增加发生在客户端。证据是出站请求本身包含新增字段或更长历史，不需要猜中转站行为。
兼容层重组了消息
不同协议对角色与字段的定义不同。Anthropic 的 OpenAI SDK 兼容文档说明，兼容层会提取 system 与 developer 消息并拼到对话开头，部分字段会被转换或忽略。中转服务若在 OpenAI、Claude、Gemini 协议之间转换，也可能重组消息、工具结构和多模态内容。
客户端出站 JSON 与模型收到的上游 JSON 此时不是同一个对象。只有调用方自己控制的网关日志，或中转服务提供的脱敏上游记录，才能直接展示转换结果。仅凭 Token 差额，可以把协议重组列为解释，不能确认具体增加了哪段文字。
中转层加入了系统说明或工具
网关可能为了内容安全、模型路由、工具适配或输出格式加入说明，也可能把自己的工具定义发给上游。这在技术上可行，但某个渠道是否这样做，需要上游请求或服务方文档支持。
输入 Token 增加与回答风格变化同时出现，只能提高对「请求内容或模型环境有变化」的怀疑。它仍无法区分系统提示词、模型版本、参数变化和后处理。
计数口径或模型变了
同一厂商的接口也会拆分未缓存输入、缓存读写、思考和工具用量。只拿一个总数跨协议比较，很容易把字段包含关系当成膨胀。三家的字段口径见OpenAI、Claude、Gemini 的 Token 为什么不能直接横向比较，账单与响应 Usage 如何分开见Token 虚标与倍率对账。
用证据等级组织排查
| 证据等级 | 当前能确认什么 | 仍缺什么 |
|---|---|---|
| 可观察事实 | 客户端序列化后的字段、响应 Usage、请求 ID、应用记录的调用次数 | 中转层转给上游的完整内容 |
| 有依据的解释 | Token 增长与工具清单、历史长度、协议或模型变化时间相符 | 上游请求或服务方配置记录 |
| 缺少证据 | 只有聊天框截图、账户余额变化或模型自述 | 原始响应、计费明细、出站请求与请求次数 |
复核时先保存事故时间附近的原始响应与请求 ID，再确认数字属于单次 Usage 还是时间汇总。客户端能够记录出站请求时，按 system、messages、tools、文件和历史分别核对有无变化；涉及业务或客户内容时只保存经过授权的脱敏副本，也可以保存字段、长度与摘要值而不留原文。
随后检查 SDK 与框架升级记录、重试日志、模型版本和协议转换配置。若证据停在客户端到中转站这一段，应把结论写成「输入 Token 增加，来源尚未定位」，并向服务方索取对应请求 ID 的上游计数或转换说明。
排查记录还要保留失败样本。只保存那次返回正常的响应，会漏掉自动重试之前的超时与 5xx；只保存账户汇总，又无法把费用映射到具体请求。请求 ID、客户端调用 ID 与准确时间能把这些记录关联起来，但中转站是否把同一标识透传给上游仍需它说明。
这个现象不能单独证明什么
输入 Token 增加不能单独证明中转站恶意注入提示词、偷取 Token、掉包模型或泄露其他用户对话。系统工具、历史重发、tokenizer 更新和统计口径都可能产生相似结果。反过来，响应数字恢复正常也不能证明途中从未改写请求。
能确认到哪一层，就把结论停在哪一层。公开描述优先写时间、协议、模型、Usage 分项、调用次数与已掌握的请求字段；运营方动机和具体上游身份需要额外证据。
LinkyMonitor 记录请求、响应、Usage 与监控配置的变化；输入 Token 偏离历史时，可以回到对应上下文复核。