Google Cloud扩展BigQuery与Looker的数据智能体可观测性，将运行指标、会话日志和评估结果连接起来，部分日志与监控功能已正式可用，词元配额和原生评估仍处于预览。企业仍需区分问答记录与完整执行轨迹，并自行管理日志权限、保留期限、评估工具安全及成本边界，不能将这些能力视为完整审计保证或总费用硬上限。
Google Cloud在2026年11月13日至14日公布了一组面向企业数据智能体的可观测性与评估更新：将BigQuery和Looker中的运行指标、会话记录及评估结果连接起来，让企业不仅能部署智能体，也能检查它如何运行、消耗多少资源，以及修改后是否答得更好。
这不是一套所有功能同时正式上线的产品。按照官方公告，BigQuery会话日志、BigQuery Studio智能体监控，以及Looker的Conversational Analytics System Activity仪表板已正式可用；每日输入和输出词元（token）配额、Looker部分反馈审阅功能及BigQuery原生智能体评估仍处于预览阶段。
公告的日期记录存在差异：网页提取版本标注11月13日，实时页面显示11月14日；出版元数据为11月13日20时00分03秒、时区为UTC−5。这里将其作为11月13日至14日公布的更新，而不把各项已有能力都描述为当天首次推出。
把运行记录放回企业自己的数据仓库
Google提出的共同路径是：从智能体采集遥测数据，写入客户拥有的BigQuery表，再由开发者和管理员使用BigQuery Studio、Looker或自建仪表板分析。
第一方对话式数据分析智能体可提供运行遥测；使用Agent Development Kit（ADK）或LangGraph构建的自定义智能体，则需要开发者通过SDK接入。BigQuery Studio预置仪表板关注使用情况、活跃会话、常用知识源和延迟；Looker的System Activity仪表板关注参与度及词元使用量，适用于Looker（Google Cloud core）和Looker（original）。用户评分与Responses & feedback标签中的查询审阅，不能与已正式可用的仪表板混为一谈。
统一存放并不意味着每类智能体记录相同内容。项目层面的Cloud Monitoring指标和经过清理的第一方Cloud Trace跨度，不包含用户提示词、模型回答、内部思考或生成的SQL。要保存完整问答，所有者或编辑者仍须对每个智能体单独启用会话日志；它不是项目级监控自动附带的一份完整对话档案。
会话日志文档进一步限定了适用范围：这一托管日志功能支持BigQuery表智能体，并不因此覆盖Looker、Cloud SQL或Spanner等所有数据源。它记录问题、回答、延迟、模型词元用量，以及用于关联智能体、会话和用户的标识，但通常不保存生成的SQL与工具调用参数。例外是用户要求智能体展示或解释SQL时，SQL可能出现在回答正文中。
自定义智能体可以通过BigQueryAgentAnalyticsPlugin等接入方式记录更完整的工具执行树。因此，“问答日志”和“完整执行轨迹”是不同层次的能力，不能用同一个日志开关概括。
隐私检查有边界，日志也不是完整审计保证
把对话写进企业自己的表，有利于沿用数据集权限、加密及网络边界，也会产生新的数据副本。官方文档提醒：能读取日志表的人，可能看到智能体向其他用户返回的数据，即使他们原本没有源表读取权限。日志数据集应单独评估最小权限和保留期限；Google不会自动删除这些日志行。
系统会在每轮处理前检查知识源表的元数据。如果发现行级访问策略、列级策略标签或动态数据脱敏，或者无法确认这些保护不存在，就跳过该轮日志，但仍回答用户的问题。
这项检查不会穿透视图核查底层表。也就是说，受保护的表如果通过视图作为知识源，仍可能通过检查并产生日志。管理员必须检查视图背后的数据权限；日后为源表增加策略，也不会自动删除已经写入的日志。
日志写入本身采用尽力而为机制。权限缺失、配额耗尽或写入失败不会让对话失败，聊天界面也不会因此报告记录错误；有限重试还可能产生重复行，需要按事件标识去重。一次成功回答，既不能证明相关对话已被保存，也不能证明这套记录满足完整审计要求。
这些限制不是对全部遥测能力的否定，而是说明企业必须分别管理运行监控、内容留存和审计证据，不能把三者视为同一种保证。
看得见消耗，不等于已有总账单硬上限
公告把成本治理列为另一重点：BigQuery会话日志可记录输入、输出、思考、缓存及总词元数，Looker则提供估算的输入与输出词元用量。这些指标有助于发现异常消耗，但用量可见性本身不会阻止支出。
对于实际查询，企业可以配置单次扫描字节上限。根据成本管理文档，智能体先通过试运行估算扫描量，超过配置上限的查询会失败，不产生该次查询的按需扫描费用。文档同时说明，这类查询成本控制适用于按需计费，不适用于使用槽位预留的项目；项目和用户的BigQuery查询配额，也不等于一个覆盖智能体所有资源的统一预算。
公告另外提出，BigQuery和Conversational Analytics API的每日输入、输出词元配额仍为预览，可按项目、用户或智能体设置。它与上述扫描字节限制针对的是不同消耗口径，不能合并表述为“智能体总费用已被硬性封顶”。
会话日志没有独立的Conversational Analytics收费项，也不等于免费：底层BigQuery数据写入、存储及分析查询仍按相应规则计费。持续记录对话、运行仪表板和分析历史轨迹，都会影响资源消耗。
监控解释发生了什么，评估检验改动是否更好
日志和追踪主要帮助定位生产环境中的行为；上线前评估则要回答另一类问题：更换提示词、模型或数据结构后，智能体是否在关键业务问题上退步？
Google在公告中介绍了开源工具Prism，可对基于BigQuery表或Looker Explores的Conversational Analytics智能体运行可复用测试套件，并把评估结果与生产日志一起放到BigQuery中分析。BigQuery原生第一方智能体评估则仍处于预览，可通过API和引导式Colab笔记本使用。
Prism代码仓库提供了重要补充：它不是Google正式支持的产品；评估结果写入BigQuery需要启用相应导出配置，PostgreSQL仍承担应用运行状态存储。仓库还明确警告，Prism本身不提供身份认证或授权，部署者必须在前方增加访问控制，否则可访问服务的人可能读取记录、修改智能体配置，并启动产生真实费用的评估任务。
因此，开源评估工具不是安装后即可直接暴露到公网的托管安全服务，接入同一数据仓库也不意味着评估数据会自动、无条件地完整同步。
企业数据智能体的可靠性，还取决于它理解的业务上下文。AIFlux此前关于Knowledge Catalog自学习上下文增强预览的报道，讨论的是如何从交互中发现业务定义缺口并审核修订；此次更新则更多解决运行过程能否被观察、成本能否被约束，以及改动能否被测试的问题。
这组能力的意义，在于把智能体运维从“有人投诉才排查”推进到持续观察与评估，而不是证明智能体已经不会出错。企业仍须自行确定关键测试问题、日志访问者、保留期限和可接受的成本边界，并逐项核对正式可用与预览功能的差别。