Google Gemini Enterprise Agent Platform推理请求元数据日志正式可用，内容不入日志

Google Cloud在2026年10月30日的Gemini Enterprise Agent Platform更新日志中，将推理请求元数据日志标为正式可用。启用后，服务可为项目处理的每个支持的推理请求写入一条Cloud Logging结构化记录，字段包括模型、区域、令牌数、预留吞吐量使用、延迟及错误码，而不记录提示词或回答正文。“正式可用”指这项功能的发布阶段，并不意味着所有项目已默认打开，也不意味着所有模型和API方法都会产生记录；本站刊期为11月2日。

支持边界需要先于操作步骤说明。更新日志列出Gemini模型的`generateContent`和`streamGenerateContent`，以及Claude模型的`rawPredict`和`streamRawPredict`；支持文档进一步指出其他合作模型不会按此机制记录。按量付费和Provisioned Throughput路径都在支持范围内，但运维人员仍应核对具体请求是否走这些方法。若把未支持的调用混入同一个流量报表，日志缺口可能被误读为零调用。Cloud Logging中的结构化记录提供使用与运行元数据，并不是对完整请求和回答的归档；如需内容，文档指向另一个request-response logging功能，其权限和隐私风险必须另行评估。

开启方式包括Google Cloud控制台的Provisioned Throughput页面和REST API，可为整个项目或指定区域内的某个模型配置。日志配置可能数分钟后才生效，因而启用前后应记录准确时间并发送可识别的测试请求。支持文档列出修改发布者模型配置和管理日志存储桶所需的IAM权限。它还指出，如要用SQL查询Observability Analytics或在控制台查看详细指标，需要升级`_Default`日志桶；这一升级不能撤销，升级前写入的记录也不能事后用SQL查询。因此启用日志、升级存储桶、授权分析人员是三个不同的变更，不能在教程里合并成一个无风险的开关。

成本和保留期同样不能省略。文档说日志写入与存储按Cloud Logging计费，Observability Analytics查询按Cloud Monitoring使用量计费，默认桶保留期为30天。请求标签越多，单条日志可能越大；大规模代理系统如果每次调用都记录，日志费用会随请求量增长。部署者可先在代表性工作负载上测一天的摄入量，再估算月成本并设置保留、访问和告警策略。日志不含提示词或回答正文有助于缩小数据范围，但自定义标签仍可能包含敏感标识，因此标签命名和权限也要审核。

新功能的一个实际用途是区分团队、应用或租户的使用情况。调用方可加上`x-goog-agent-platform-observability-label-`前缀的请求头，再用Observability Analytics按标签查询；记录还可用于分析模型和区域的令牌消耗、错误、延迟，以及预留吞吐量的占用与溢出。标签不是自动生成的业务归属，若客户端没有正确传递或各服务使用不同约定，查询结果不能代表全部成本。比较账单时应明确令牌统计口径和缓存令牌字段，特别要区别请求元数据与实际收费金额。

验证流程可从小范围项目开始：确认所需IAM和日志桶选择，显式启用配置，等候生效，分别用一种支持的Gemini方法和一种支持的Claude方法发送标记请求，再在Logs Explorer或已准备好的分析环境中核对记录。还要用预期外的方法确认不会把“无日志”错误解释成“无请求”，并检查错误码和延迟字段。关闭时应确认配置恢复、日志的保留与访问权限仍按既定政策处理。由于功能可能影响日志成本与访问面，生产启用应先审查，不应把阅读本报道视作已执行配置。

在审计语境中，日志存在不等于业务请求一定成功：错误请求也有记录，错误对象使用固定代码和原因字段。相反，记录缺失也可能是配置尚未生效、方法不受支持或查询权限不足。调查时应保留调用端的请求计数与时间窗口，和Cloud Logging逐项对照，并区分数据采集故障、权限故障与真正的流量变化。这样才能避免仅凭仪表盘空白做错误判断。

这次更新提供了更细的推理运行与费用归因证据，但其价值取决于方法覆盖、主动启用、权限和记录质量。团队应按实际请求核对日志，再决定是否升级存储桶或建立持续查询；不能把元数据日志说成完整提示词审计。