Google Cloud发布Knowledge Catalog的“自学习上下文增强”与重设计的Knowledge Studio预览功能，旨在从用户与智能体交互中发现并修订业务上下文，生成可审核的元数据更新以改善企业AI答复准确性。同时公告强调预览限制、治理与合规模块尚未完备，数据驻留、VPC服务控制和自动发布门槛等需企业审慎评估。
Google Cloud近日公布了Knowledge Catalog的“自学习上下文增强”功能，以及重新设计的Knowledge Studio，两者均处于预览阶段。它试图解决企业AI智能体的一类常见问题：模型能够写出查询语句，却未必知道公司内部的指标究竟如何定义、哪些数据表应该关联，以及业务规则是否已经改变。
按照Google Cloud公告，新功能将分析用户与智能体的交互，寻找缺失或过时的业务上下文，再从企业文档、代码库等来源提取知识，生成可审核的目录修订。不过，公告结尾明确表示，这些功能将在未来数周向客户逐步开放，并提供申请提前访问的渠道。这不是面向所有客户的全面正式上线。
公告的日期呈现也存在差异：本次核验时，原链接的浏览器页面显示2026年10月23日，网页提取版本显示10月22日。本文将其作为10月下旬公布的预览进展，不将10月24日的核验时间当作发布日期。
要补的不是更多数据，而是业务含义
Google在公告中举了一个例子：用户询问“上季度欧洲、中东和非洲地区的净收入是多少”，智能体不仅要找到收入数据，还要知道企业怎样计算净收入、相关表之间如何连接，以及合作伙伴抵扣等项目如何处理。这些信息可能分别保存在财务手册、GitHub代码和Confluence页面中。
如果财务部门调整计算规则，智能体仍沿用旧定义，即使查询执行成功，也可能得到业务上错误的答案。单纯把更多表结构塞进提示词，并不能自动解决这种口径变化。
Knowledge Catalog并非此次才出现。AIFlux此前对Google Cloud Next ’26的报道已介绍其自动标注和连接企业知识的方向。这次新增的重点，是把实际使用中的问题反馈纳入上下文维护，并通过新版Studio集中管理修订，而不是重新发布一个静态数据目录。
根据公告，增强任务可以按需或定时运行，提出业务定义、表与列描述、表连接关系、经过验证的参考查询，以及面向特定任务的智能体指令。每项建议附带来源引用和置信度；源材料变化后，系统还会识别过时定义与相互冲突的信息。
这里的“自学习”指向元数据和业务上下文的持续修订，不是让企业每次对话都去训练基础模型。Google表示，客户数据不会用于训练其模型。
从一次答错，到一项可以审核的修改
增强任务文档给出了更具体的反馈链路：系统可以读取Gemini Enterprise应用、BigQuery智能体分析表和限定范围的Cloud Logging日志，寻找用户反复追问、智能体无法解释术语或缺少业务定义的地方。
这些交互轨迹首先是发现知识缺口的信号，并不意味着用户的每次纠正都会直接成为企业标准。系统还需要结合文档和查询记录起草修订，并通过评估与发布政策决定下一步。
企业可以提供测试问题及对应SQL作为评估集。文档称，系统会测试拟议元数据，并使用留出的测试查询计算回归错误率；启用自动发布后，如果回归错误超过允许阈值，自动发布会停止，建议转交人工审核。
人工审批并非所有修改都不可绕过的固定流程。公告说明，管理员可以启用或关闭自动发布，并自行设定置信度门槛；低于门槛的建议，以及删除等敏感更新，需要由数据管理员批准、编辑或拒绝。公告中的85%只是可配置门槛的示例，不是系统准确率，也不是经过独立验证的安全保证。
Google还称，每项变化都会记录来源与变更历史，并支持回退。这使维护人员有机会检查“为什么改、依据是什么、改后有没有退步”，但不等于系统已经保证业务定义永远正确。企业仍需决定哪些材料具有权威性，以及谁有资格批准口径变化。
上下文集控制知识范围，不替代数据权限
新功能的重要组织单位是“上下文集”（context sets）：把某个部门、领域或任务需要的定义、指标、连接逻辑和查询模板打包，而不是让所有智能体无差别搜索整个企业目录。
例如，销售与财务可能对同一个收入指标采用不同口径。上下文集允许它们在同一目录中分别维护定义；专用智能体可以绑定指定集合，也可以按任务动态寻找相关集合。
上下文集文档明确区分了知识权限与数据权限：IAM身份与访问管理控制谁能读取或修改上下文集，但获得集合访问权，不等于获得底层BigQuery表或Cloud Storage文件的访问权。真正执行查询的身份，仍须具有相应数据资源权限。
这一点尤其重要。上下文集提供的是业务语义和数据资产引用，不是绕过原有授权的“万能通行证”；它缩小检索范围，也不能仅凭这一设计就被视为执行任意操作的完整安全沙箱。
Knowledge Studio则承担工作台角色，把对话式数据探索、可视化上下文图、修订审核和任务运行监控集中起来。下游智能体可以通过模型上下文协议（MCP）或Knowledge Catalog API读取整理后的上下文。不过，预览阶段的增强任务管理仍以Google Cloud控制台为主，不能把“智能体能够查询上下文”理解为“任务创建和管理已有完整公开REST API或命令行支持”。
企业级治理承诺，仍需对照预览限制
Knowledge Studio官方文档将产品标为Preview，并列出多项企业部署必须注意的边界。
目前不支持VPC Service Controls；文档还列明数据驻留承诺、客户管理的加密密钥（CMEK）及Assured Workloads合规机制等限制。数据可能在企业严格配置的地理边界之外存储或处理。对于依赖这些控制的组织，不能因为产品具有IAM权限和审批界面，就认定其已满足现有合规要求。
区域限制也需要分别理解：上下文集必须与所包含资产的区域边界对齐，不代表整个预览功能因此具备严格的数据驻留承诺。
成本同样不是零。官方说明，Knowledge Studio不新增独立产品计费项，但使用仍涉及底层Gemini Reasoning Engine、BigQuery和Cloud Storage等资源消耗。因此，“没有独立SKU”并不等于免费，尤其在持续分析日志、定时更新和运行评估时。
Google在公告中宣称，Knowledge Catalog在内部基准中使智能体准确性接近原来的四倍，延迟最多降低33%，词元（token）使用量最多减少75%。这些是厂商内部测试结果，不能据此推定每家企业都能获得相同提升，也不能直接换算成等比例的总成本下降；本文没有进行独立复测。
这次更新的实际意义，是尝试把企业AI的上下文维护从一次性整理，变成“发现缺口、提出修订、测试、审批或自动发布、追溯回退”的持续流程。它是否能在真实环境中减少错误，最终仍取决于企业提供的知识质量、评估问题是否覆盖关键业务，以及预览阶段的安全和可用性边界是否符合部署要求。