北京
这个月，我为一个小型AI代理集群支付了比以往更高的云账单。在找到任何证据之前，我心里已经有了怀疑对象：一个我每天在用的CLI工具，它消耗着我Gemini订阅的配额。它是整个链路里最新的组件，我高频使用，时间点也吻合。我打开审计日志，准备确认我早已认定的结论。
我错了。而犯错的方式，才是这篇文章真正想说的——不是“要检查你的假设”这种老生常谈，而是一个关于计量凭证的结构性事实：拥有一个密钥，和被这个密钥计费，是两种完全不同的关系。大多数单人环境在不知不觉中违反了这一点——shell配置文件悄悄地把两者混为一谈。
我先说那个被洗清嫌疑的工具。它调用Google的后端，但它的GitHub维护者早就在公开issue里声明：该工具不支持API密钥认证，只走钥匙串OAuth。这是一个我本可以核对日志验证的声明，而不是凭直觉相信。
日志给出了清晰的答案。92份会话记录，全部标记为OAuth消费者认证方式，billing-project字段为空。在这个时间段内，5409次模型调用全部经由免费消费者端点，没有一个走付费通道。工具自身的内部状态里，也没有记录任何项目ID。三个独立的信号，指向同一个方向：这个工具在结构上就不可能触达我的付费项目。
真正定案的是一个相关性计算。我把工具每日调用量与付费项目的每日请求量对齐，计算相关性：皮尔逊r=0.089，斯皮尔曼ρ=0.133。基本为零。我使用该工具最多的一天，恰好是付费项目流量最低的一天。如果工具是花钱的元凶，相关性应该显著为正，而不是与噪声无异。我的头号嫌疑对象拥有完美的不在场证明。
问题出在一个我从未检查过的地方：shell配置文件。这是我后来才意识到的盲区——密钥的所有权和密钥的计费归属是两回事，而配置文件的默认行为，是让它们看起来像同一件事。真正的教训不是“怀疑要谨慎”，而是：在计量凭证体系里，一个密钥被谁拥有，和它被谁计费，是两个独立的维度。如果没有明确分离这两层关系，任何对“谁在花钱”的判断都可能被配置的隐蔽逻辑带偏。
我保留了审计的原始记录。92份日志、5409次调用、三个信号、一个几乎为零的相关系数——这些数字共同指向一个结论：我的怀疑是错的，但错得有价值。它揭示了一个大多数单人环境都在无意中违反的结构性事实。下次账单异常时，我会先检查配置，而不是先责怪工具。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
