北京
我运行着一小队AI代理，部署在单台机器上。一个月，云账单开始攀升。还没看到证据，我心里已经有了嫌疑人：一个我每天都在用的CLI工具，用来消耗Gemini订阅额度。它是整个链路里最新加入的部分，我频繁使用，时间点也对得上。 我打开审计日志，准备确认已有的判断。 但我错了。而且错的方式才是真正的教训——不是老生常谈的“要检查假设”，而是一个关于计量凭证的结构性事实：拥有一个密钥，和你为该密钥产生的用量付费，是两种完全不同的关系。shell配置文件会静默地把它们混为一谈。 被我怀疑的那个工具与Google后端通信，而它的GitHub维护者早已在公开issue中声明：不支持API密钥认证，只支持keychain托管的OAuth。这是一个我可以用自己的日志核对的声明，而不是需要轻信的断言。 日志给出了三个独立信号。 第一，92条会话日志，全部标记为OAuth consumer认证方式，计费项目字段为空。第二，在这个时间窗口内，5409次模型调用全都路由到免费层的consumer端点，而非计费端点。第三，工具自身的内部状态里，没有任何project ID记录。 三个信号指向同一个结论：这个工具在结构上就不可能命中我的计费项目。 然后我算出了那个真正一锤定音的数字。我把这个工具的每日调用量与计费项目的每日请求量对齐，计算相关性。皮尔逊 r = 0.089，斯皮尔曼 ρ = 0.133，几乎和噪声无异。我使用工具最多的一天，恰恰是计费项目流量最少的一天。如果它真的是花钱者，相关性应当强烈为正，而不是约等于零。 我的头号嫌疑人拥有完美的不在场证明，而我刚才差点给它定罪。 这件事的启示比“别被偏见蒙蔽”更硬核：在按量计费的凭证体系里，不要把“谁产生了调用”等同于“谁的账单”。OAuth消费端、计费项目ID、审计日志中的认证字段——这些细节才是真相所在。 本文最初发表于 hexisteme notes。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
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.
