数据与分析智能体

数据分析智能体很容易显得神奇：上传一份电子表格，提出一个问题，然后得到图表、结论，有时还能得到生成它的代码。在企业场景中，同一模式会延伸到 SQL 生成、指标探索、notebook 起草、数据质量检查和业务报告。

风险在于，分析表达的流畅性可能掩盖最关键的工作。智能体访问了哪些数据？哪些行被排除了？哪个 join 改变了答案？运行了哪些代码？图表能复现吗？指标定义和业务问题一致吗？因此，数据分析智能体应通过可执行证据和验证来判断，而不是看最终解释是否像分析师写的。

核心论点

当数据访问受到限定、分析步骤可执行且可检查、结果经过领域与统计检查验证，并且最终解释保留假设、不确定性和可复现性时，数据分析智能体才适合委托。

已接受结果不是一张图或一段文字，而是一个可检查、可重跑、可挑战，并能连接到数据与权限来源的分析产物。

从分析约定开始

每个分析请求都应转化为分析约定：

分析要支持的决策或问题；
数据集、快照、源系统和新鲜度要求；
群体、过滤条件、时间窗口和分析单位；
指标定义和业务语义；
允许的工具、库和执行环境；
隐私、租户和导出约束；
必需的验证检查；
结果形式以及需要披露的不确定性层级。

“收入为什么下降？”还不是一个分析任务。它可能需要明确收入定义、产品分组、时区、退款、币种换算、季节性、获客渠道和数据延迟假设。智能体可以帮助澄清这些假设，但不应悄悄选择它们，然后把结果呈现为事实。

数据访问是权限边界

分析智能体经常需要访问敏感数据。它们可能查询数据仓库、检查上传文件、生成临时表、导出图表，或组合内部与外部来源。每一步都可能泄露信息，或产生未经授权的推断。

访问模型应说明：

智能体代表哪个主体行动；
可以访问哪些数据集和列；
是否适用行级、租户或目的限制；
生成产物是否可以离开环境；
代码执行是否具备网络访问；
临时文件和缓存结果如何保留；
访问如何记录和审查。

如果智能体能看到用户无权知道的信息，系统就制造了一个高风险的高权限组件被借权滥用路径。如果用户只要求聚合结果，智能体却能导出原始行，系统就把影响扩大到了分析目的之外。数据最小化应由工具和查询层强制执行，而不是留给提示词措辞。

查询和代码是中间产物

OpenAI 的数据分析产品文档展示了一个具体模式：模型介导系统可以检查上传文件、运行 Python，并创建输出产物（OpenAI Help）。持久的工程经验是：代码和查询是答案的一部分。它们应被捕获、审查，并连接到结果。

对于 SQL 智能体，生成的查询应可见，至少应可恢复。对于代码智能体，notebook、脚本或执行记录应可用。对于仪表盘，应说明语义层或指标定义。没有这些产物，审查者无法判断模型是否：

用错了 join 键；
错误过滤了 null；
混用了时区；
把缺失数据当作零；
重复计算实体；
把样本当成总体；
选择了误导性图表；
从相关性推断因果。

Spider 和 BIRD 等 Text-to-SQL 基准说明，即使有 Schema 和执行检查，数据库驱动的自然语言问题仍然很困难（Yu et al., 2018；BIRD）。在生产中，问题更难，因为业务定义、权限和数据新鲜度与 SQL 有效性同样重要。

验证应进入回路设计

分析智能体不应等到最终答案时才发现数据错了。有用的验证包括：

Schema 和类型检查；
过滤前后的行数；
缺失数据与异常值摘要；
检查 join 是否造成重复；
与已知报表核对总数；
抽样行与源记录对照；
将指标定义与语义层比较；
从干净环境重跑代码；
对关键假设做敏感性检查；
对有后果的结论进行审查者挑战。

当 computational notebook 保留叙述、代码、数据、依赖和执行顺序时，它可以支持可复现性（Rule et al., 2019）。但如果单元格陈旧、依赖缺失，或隐藏状态影响结果，notebook 也会制造误导性信心。智能体生成的 notebook 需要同样的纪律，还要额外追踪模型介导选择。

解释结果，但不要隐藏工作

面向用户的解释应回答：

回答了什么问题？
使用了哪些数据，来自哪个日期或快照？
做了哪些转换？
哪些检查通过或失败？
哪些假设会实质性影响答案？
仍有什么不确定性？
这个结果支持什么决策，不支持什么？

执行摘要可以很短，但证据应保持可用。图表应包含定义和过滤条件。预测应说明预测周期和评估限制。比较应说明分母。令人意外的结果应包含使其可信的检查，或说明它仍然只是暂定结论的原因。

设计选项

选项	最适合	主要风险
上传文件分析	单个电子表格或 CSV 探索	隐性隐私风险、陈旧文件和不可复现本地状态
SQL 助手	在受治理数据上起草查询	SQL 有效但业务语义错误
Notebook 智能体	探索性分析和可复现叙事	单元格陈旧、依赖漂移和未审查假设
指标 copilot	通过语义层解释受治理 KPI	过度信任预定义指标或隐藏异常
自主分析监控	周期性异常检测或报表生成	告警疲劳、静默数据漂移和无人拥有的结论

对于重复性业务指标，受治理语义层和确定性仪表盘可能优于智能体。当指标路径已经受控时，再用智能体进行解释、调查和异常处理。

失效模式

可执行的胡话。 代码成功运行，却回答了错误问题。
语义不匹配。 智能体使用原始字段，而不是已批准指标定义。
数据泄露。 分析暴露了用户授权范围之外的行、列或推断事实。
快照陈旧。 答案依赖旧数据或部分数据，却没有披露。
产物不可复现。 缺少代码、数据、环境或执行顺序，结果无法重跑。
统计过度延伸。 智能体声称因果、显著性或预测置信度超出设计。
图表说服。 可视化选择让薄弱或噪声很大的结果显得确定。

本手册的判断

将数据分析智能体视为可执行系统。捕获代码、查询、参数、数据快照和环境。保持数据访问目的限定。先验证中间步骤，再相信最终文本。

对于重复性业务问题，优先使用受治理定义，而不是让智能体直接发现原始表。当智能体偏离语义层时，要求它说明原因并展示后果。

把不确定性具体化。“销售下降 8%”是不完整的，除非说明时间窗口、币种、退款处理、缺失数据处理和基线。用户不需要每个追踪 Token，但需要知道哪些假设会改变决策。

检查清单

分析问题是否绑定到决策、群体、时间窗口和指标定义？
数据集来源、快照、新鲜度和权限边界是否记录？
智能体是否在受治理执行环境中运行代码或查询？
生成的 SQL、代码、参数和产物是否可检查或可恢复？
join、过滤、缺失数据、行数和总数是否经过验证？
解释是否说明假设、不确定性，以及结果不能证明什么？
导出产物是否经过隐私和租户泄露检查？
审查者能否从记录输入中重跑或重建分析？

参考文献及其使用方式

OpenAI Help, “Data analysis with ChatGPT” - OpenAI 帮助中心的 ChatGPT 数据分析产品文档，用作该产品界面支持模型介导文件分析和代码执行模式的带日期证据。
Yu et al., “Spider: A Large-Scale Human-Labeled Dataset for Complex and Cross-Domain Semantic Parsing and Text-to-SQL” - 经同行评审的基准论文，用于支持跨领域 SQL 难度和评估。
BIRD benchmark 和 BIRD paper - 基准证据，用于说明更现实的数据库驱动 Text-to-SQL 难度。
Rule et al., “Ten simple rules for writing and sharing computational analyses in Jupyter Notebooks” - 经同行评审的可复现性资料，用于 notebook 和计算分析产物。
NIST AI 600-1, “Generative Artificial Intelligence Profile” - 自愿性风险管理资料，用于数据来源与流转记录、隐私、沿袭和生命周期风险。
pandas user guide - pandas 项目维护者文档，用作数据转换、缺失值和库行为属于分析表面的具体证据。