Snowflake计划调整看板Agent选表：图表没展示的字段，问答能查询吗？

官方文档给出的计划起始日是10月26日，采用渐进推出，日期可变；它不属于月度behavior change bundle。原页没有独立发布日期，本文不把计划日期当成公告发布日期，也不称为所有账号已经开放。

需要关注的是在Snowflake CoWork中使用Agent或profile回答看板问题的团队。只在普通对话里使用Agent、不围绕看板提问的使用方式，不受这一属性的看板数据追加行为影响。本文的具体配置讨论以单个Agent为主；文档未说明Agent与profile同时配置时的优先级，不作推断。

新属性dashboard_data_access设置在Agent或profile上。变更生效后，TRUE会为当前看板对话加入看板底层表，范围按表计算，同表中没有出现在图块里的其他列也可能进入查询范围。每条查询仍以调用者权限运行，不能读取该角色无权读取的数据。

可以用一个虚构的订单看板理解这件事：图块只展示“本月销售额”，底层订单表还包含“发货城市”。如果用户角色本来就可读这张表及该字段，图块没有展示发货城市，并不会自动阻止Agent在看板对话中围绕它提问。能否产生正确查询和答案，仍要实际核对；这不是一次已执行的产品测试。

如果业务要求对话也只能围绕汇总指标工作，需要把这一要求落实到可查询对象和权限设计中。仅从看板移除一列，不能作为数据库权限已经收紧的证据。通用行列权限的实现见文末相关文章，这里重点检查此次新增的数据路径。

官方说明：变更生效后，未显式写入dashboard_data_access也按TRUE处理，从未设置过该属性的Agent，其DESCRIBE输出不会显示这个属性。显式FALSE只停止追加看板表，Agent原有数据配置保持不变。

因此要记录“是否写入”与“按当前产品规则如何解释”两个值。若需要验证FALSE是否按预期工作，应选一张只属于看板、尚未包含在Agent原配置中的表；否则仍能查询可能来自原路径。

还要区分“属性未写入”和“看不到配置”。官方DESCRIBE文档说明，secure agent在owner role未激活的会话中，agent_spec可能为NULL。此时不能把NULL当成空配置或FALSE，应请有权查看完整定义的负责人核对；不要为读配置而取消secure设置。

先确认账号是否收到该变更，再解释隐式默认值。如果属性尚不支持或控制项尚未出现，记录账号、核对时间和实际现象，并以当前官方说明或支持答复确认，不把“界面没有开关”记成已经关闭。

下面是未执行的教学演练。用非生产对象和虚构订单数据准备一张表T；看板展示销售汇总，但T另有“发货城市”。每组使用独立新对话，避免把前组已取得的数据带入比较。除该组指定变化外，固定同一Agent版本、看板、测试角色和问题。先验证角色权限，再比较数据路径；问答失败不一定是权限拒绝。

建议记录：账号与核对时间、Agent或profile、配置是否显式写入、对话是否来自看板、看板底层对象、Agent原有对象、测试角色、问题、实际查询对象、结果与处理人。保留“未生效”“配置不可见”“模型未选择该来源”“查询被拒绝”等不同状态，别把它们都归为通过或失败。

如果现有界面或权限不足以取得查询证据，明确记录这个缺口，交给有权核对的管理员。本文没有假定CoWork提供某个专门的审计接口；不要仅凭回答措辞判断它读过哪张表。

公告中的Agent示例把属性放在orchestration.capabilities.dashboard_data_access。通过ALTER AGENT修改live specification时，新specification会完整替换旧值，未包含的字段会移除。因此，仅复制几行关闭属性的片段，可能同时删掉原来的工具、说明或预算配置。

如果Snowsight中已出现Dashboard data开关，官方说它设置同一属性；开关是否可见仍以账号实际状态为准。修改后要重新读取配置和执行对照。本文不提供缺少上下文的生产修改SQL，也没有在任何账号执行配置变更。

如果业务只想开放销售汇总，先写明允许回答的指标、允许使用的对象和不应返回的数据，再让数据负责人检查角色权限与数据路径是否支持这个范围。FALSE可以帮助保留原Agent选表方式；若原配置或角色本来就过宽，还需要另行处理，不能靠这一开关代替。

本次可以先完成一条记录：选一张看板，列出它的底层表及Agent原配置对象，标出哪些表是潜在新增来源。拿到账号实际推出状态后再做对照；暂时无法验证时保留原因和负责人。不要把计划推出日直接填成账号验收通过日。