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

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

三类上下文承担不同责任

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

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

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

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

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

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

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

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

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