Google Cloud Data Agent：三类上下文如何共同收敛

Tue, 22 Sep 2026 00:00:00 +0000

Agent 知道表在哪里，不等于知道怎样回答业务问题。Google Cloud 的 Conversational Analytics 把 Data Agent 描述为“上下文 + 工具”的组合：上下文提供业务信息和数据，SQL、Python 与可视化工具负责执行。

三类上下文承担不同责任

数据上下文说明可查询对象、字段、关系与数据位置；业务上下文解释术语、指标、过滤规则和经过验证的查询；会话上下文保存用户在多轮对话中的范围、假设和追问。

把三者混成一个“知识库”会带来问题。字段元数据不能代替指标定义，历史对话也不应覆盖受治理语义。数据 Agent 应明确每类上下文的来源、有效期和优先级。

已保存 Agent、内联上下文与会话状态

API 支持引用已保存的数据 Agent，也可以在请求中直接提供上下文。多轮交互又可选择有状态会话，或由应用在无状态模式下自行管理历史。选择哪种方式，取决于复用、隔离、审计和数据驻留要求，而不只是开发便利。

语义资产怎样减少歧义

在 BigQuery 或 Looker 场景中，团队可以补充表字段元数据、解释指令和 verified queries。比如“top performers”究竟按收入还是订单数排序，应由业务语义约束，而不是让模型临场猜测。

生产边界

身份与访问仍由 IAM 和数据源权限控制。数据库数据源和部分能力的成熟度不同，可视化支持也不是所有来源完全一致。Google 官方明确提醒生成结果可能看似合理但事实错误，重要输出仍需验证。

适合的试点不是“让所有人随便问所有数据”，而是选择一个语义稳定的主题，为常见问题准备 verified queries，记录生成的 SQL、工具调用和结果，并把失败归因到上下文、执行或呈现层。

Google Cloud 的路线说明：上下文越多不一定越好。真正有效的是相关、授权、可追踪且能在多轮状态中保持一致的上下文。

建议的评测切片

同一问题至少要在四种条件下测试：语义信息完整、字段说明缺失、会话中途改变范围、用户权限不足。分别记录 Agent 选择的数据源、生成的查询、最终答案和拒绝原因。这样可以看出系统是在可靠使用上下文，还是只在理想演示里表现良好。

对有状态会话还要测试“上下文污染”：前一轮对某个地区或时间窗口的限定，是否被错误带入新的主题。对无状态集成则要检查应用是否完整传回必要历史，并避免把敏感内容带到不相关请求。状态管理本身也是数据治理的一部分。

参考：Conversational Analytics API 概览、BigQuery Conversational Analytics

Data Agent 厂商地图：按系统位置比较，不按名字排队

Thu, 17 Sep 2026 00:00:00 +0000

Data Agent 市场最容易画错的一张图，是把云平台、BI 应用、内部自建系统、开源框架和学术项目放成一排 Logo，再暗示它们彼此竞争。它们可能解决不同任务，处在技术栈不同位置，也承担不同的生产责任。

更有用的地图以系统位置为纵轴，以交付形态为横轴。先找同类，再比较能力。

第一轴：产品位于系统哪一层

数据平台

Snowflake、Databricks、Google BigQuery、Microsoft Fabric、AWS Redshift 等平台拥有数据、计算、权限与治理入口。平台原生 Agent 的优势是能复用这些控制面，限制则是能力通常围绕自身生态展开。

例如 Snowflake Cortex Analyst建立在 Snowflake 语义模型与访问控制上；Microsoft Fabric Data Agent面向 Fabric 数据源并按用户权限查询；Google 同时提供面向分析、数据科学和数据工程的不同 Agent 入口。

语义与治理

这类能力维护指标、实体、关系、血缘、质量和权限。它们不一定以“Data Agent”命名，却决定 Agent 是否理解“收入”和“客户”。选型时要问：语义资产能否被 BI、Agent 和其他应用共同引用，版本和责任人如何管理，而不是只看是否有聊天框。

Agent 平台

平台提供模型、连接器、工具协议、运行时、状态、评测和治理，让团队构建自己的数据工作流。2026 年 9 月发布的 ChatGPT Work Data agent已是面向企业的产品，与 OpenAI 1 月分享的内部自建 Data Agent不是同一个交付边界。内部案例能提供架构经验，不能直接等同于可采购 SKU。

分析应用

BI、Notebook 和分析工作区把 Agent 放进业务用户或分析师已有界面。它们通常在问数、探索、代码分析、图表与报告交付上做得更完整，但底层语义、权限和执行可能依赖外部平台。评估时要沿调用链确认责任，不能只看前端体验。

数据工程与运维

这类 Agent 面向元数据、质量、dbt/Dataform、管道、成本和故障处置。它们可能产生代码或变更建议，甚至写入生产，因此测试、审批、幂等和回滚比问数准确率更重要。

第二轴：它以什么方式交付

形态	适合什么情况	需要承担什么
内部自建	数据和流程独特，已有强数据平台团队	架构、评测、安全、运维和长期迭代全部自担
平台原生	核心数据已集中在一个平台，希望快速复用权限与语义	生态绑定、跨源能力和区域可用性要核实
独立应用	需要跨平台体验或特定分析工作流	连接器、身份透传和数据出口责任要厘清
开源框架	需要可控部署、研究或深度定制	生产语义、权限、维护和支持不会随代码自动获得
学术项目	研究新方法、基准和能力边界	论文结果不等于生产 SLA 或产品支持

同一家厂商可以横跨多层，同一产品也可能在不同版本提供不同形态。地图不是互斥分类，更不是市场份额图。

Google Cloud on DataAgentX