Data Agent 产品设计

【注】本文梳理 data agent 产品的设计思路，聚焦产品形态、核心能力框架与关键技术判断，不涉及太细节的实施方案。撰写过程中，结合个人数据科学领域的学习和实践经验，并借鉴了 OpenAI、Meta 等科技大厂团队推进 data agent 产品落地的经验，追求以科学、严谨、贴近前沿的方式做事。

过去两年 coding agent 突飞猛进，出现了 claude code 这样颠覆性的产品形态，而 data agent 始终停留在"高级辅助"的水平。这并不是因为数据分析比写代码更难，而是因为：

写代码这件事自带验算器——编译器、单元测试、运行结果会立刻告诉 agent"你错了"。agent 能自己试错、自己发现错误、自己修正，这个闭环正是 RL 与 agent loop 能够起飞的前提。

而 data agent 缺少这个闭环—— SQL 跑通了不代表算对了业务口径；一份归因结论看起来很合理，也可能完全是错的。没有现成的"对错信号"，agent 就无法自我纠正，产品也就无法持续进化。

一、产品定位与核心功能

产品价值

业务方：自助取数与分析，每位业务 Owner 都能独立完成数据查询与诊断，无需等待排期、无需会写 SQL，决策提速从几天到几分钟。

数分 / 数科：从重复性 SQL 调试中解放，升级为洞察生产者——精力聚焦于定义指标、验证假设和产出高质量数据洞察，而非被临时取数请求消耗。

核心功能

Data Agent 服务于真实的业务场景，核心是把"业务方的自然语言问题"转化为"可信赖的数据洞察"。四大核心功能：

智能取数与可视化
将用户自然语言提问转化为精准的查询 SQL，并自动选择最优可视化图表，直观呈现数据洞察。

业务原型问题：「帮我查看过去一年某产品的销售表现」
数据分析
依托 LLM 推理能力、算法库及数据科学领域标准方法论，完成指标归因分析、异常检测、预测等任务，产出可落地的洞察。

业务原型问题：「为什么上个月 GMV 下滑了 20%？」
深度对话分析
面对开放式、需多步探索的问题，通过多轮对话逐层深挖根因，产出专家级分析报告。过程中借助 human-in-the-loop 主动追问、澄清模糊意图，先与用户对齐分析思路再执行。

业务原型问题：「过去一段时间，某类用户群体留存为什么下降？应该采取什么策略？」
仪表盘导航
根据需求自动生成 Dashboard，实现高频业务场景的数据化监控。解决"找 BI 排期做看板"的痛点，响应更快。

业务原型问题：「做一个客户分层运营看板，追踪各层级关键指标变化，支撑个性化客户运营策略上线」

产品 Demo 演示

以下为 Mock 数据与交互原型，用于展示 Data Agent 的「数据分析」能力与确定性归因分析链路。

示例问题

你想了解什么增长问题？

近30天GMV下降的原因

最近30天 gmv Agent Loop · GMV Recipe ✓ 校验通过

总体变化：本期 GMV 下滑 23.25%，较上期变动 R$ -246,285.35。

一级贡献：订单量效应拉低 R$ 178,578.56（贡献度 72.5%）；客单价效应拉低 R$ 67,706.79（贡献度 27.5%）。

重点细分因素：品类「relogios presentes」拉低 R$ 41,518.95（占总变动 16.9%）；州「BA」拉低 R$ 30,810.62（占总变动 12.5%）；州「RJ」拉低 R$ 29,071.34（占总变动 11.8%）。

口径提醒：细分因素来自品类、州、商家等不同观察维度，可能覆盖同一批订单，用于定位重点对象，不能跨维度直接相加。

数据锚点：2018-09-03　|　本期 2018-08-05 — 2018-09-03　|　对比期 2018-07-06 — 2018-08-04

窗口汇总

周期	开始日期	结束日期	GMV（R$）	订单量	AOV（R$）
本期	2018-08-05	2018-09-03	812,994.75	5,262	154.50
前期	2018-07-06	2018-08-04	1,059,280.10	6,375	166.16

GMV = 订单量 × AOV

因素	变动贡献（R$）	贡献占比
订单量效应	-178,578.56	72.5%
AOV 效应	-67,706.79	27.5%

主要维度贡献

维度	对象	本期 GMV（R$）	前期 GMV（R$）	变动贡献（R$）	占总变动
品类	relogios presentes	63,489.30	105,008.25	-41,518.95	16.9%
州	BA	20,452.69	51,263.31	-30,810.62	12.5%
州	RJ	93,558.73	122,630.07	-29,071.34	11.8%
州	MG	92,484.03	114,015.12	-21,531.09	8.7%
州	PE	10,814.51	31,336.94	-20,522.43	8.3%

结构性变动贡献

Top 维度贡献

以下 SQL 来自本次确定性归因 Recipe 实际使用的查询模板，以当前窗口参数化执行（示例为「窗口汇总」证据查询）。

WITH bounds AS (
  SELECT CAST(MAX(order_purchase_ts) AS DATE) AS anchor_dt
  FROM   vw_fact_items
),
labeled AS (
  SELECT
    CASE
      WHEN CAST(f.order_purchase_ts AS DATE)
        BETWEEN b.anchor_dt - INTERVAL 29 DAY AND b.anchor_dt
        THEN 'current'
      WHEN CAST(f.order_purchase_ts AS DATE)
        BETWEEN b.anchor_dt - INTERVAL 59 DAY AND b.anchor_dt - INTERVAL 30 DAY
        THEN 'previous'
      ELSE NULL
    END                       AS period,
    f.order_id,
    f.customer_unique_id,
    f.line_gmv,
    b.anchor_dt
  FROM   vw_fact_items f
  CROSS JOIN bounds b
  WHERE  CAST(f.order_purchase_ts AS DATE)
    BETWEEN b.anchor_dt - INTERVAL 59 DAY AND b.anchor_dt
)
SELECT
  CAST(MAX(anchor_dt) AS VARCHAR)                          AS anchor_date,
  CAST(MAX(anchor_dt) - INTERVAL 29 DAY AS VARCHAR)        AS current_start,
  CAST(MAX(anchor_dt) AS VARCHAR)                          AS current_end,
  CAST(MAX(anchor_dt) - INTERVAL 59 DAY AS VARCHAR)        AS previous_start,
  CAST(MAX(anchor_dt) - INTERVAL 30 DAY AS VARCHAR)        AS previous_end,
  COALESCE(SUM(CASE WHEN period = 'current'  THEN line_gmv ELSE 0 END), 0) AS gmv_current,
  COALESCE(SUM(CASE WHEN period = 'previous' THEN line_gmv ELSE 0 END), 0) AS gmv_previous,
  COUNT(DISTINCT CASE WHEN period = 'current'  THEN order_id END)          AS orders_current,
  COUNT(DISTINCT CASE WHEN period = 'previous' THEN order_id END)          AS orders_previous
FROM   labeled;

LangGraph 有限循环 · 最多 3 个工具步骤 · 展示结构化动作与验证记录，不展示模型隐藏思维链

理解业务问题

识别指标 gmv，任务类型 metric_diagnosis，时间范围最近 30 天。

验证结构化意图

IntentValidator

已校验指标、时间、粒度与维度，并给出 gmv_attribution 能力提示；具体工具由单一 Agent Controller 在 Policy Gate 内选择。

组装分析上下文

ContextBuilder

加载 1 条指标口径、1 个相关 Schema 与输出契约。

决定下一步动作

GMV Attribution Recipe

run_gmv_recipe：执行标准 GMV 拆解，分离订单量与 AOV 的变动。

执行 GMV 归因 Recipe

DuckDB · GMV Attribution Recipe

比较 2018-08-05 至 2018-09-03 与前一等长窗口，完成 GMV、订单量、AOV 及维度贡献拆解。

验证归因结果

Attribution validators

完成 4 项确定性校验；全部通过。

决定下一步动作

finish：确定性执行与结果校验已通过，现有证据足以回答问题。

生成证据化洞察

deterministic summary

仅基于通过校验的 GMV Recipe 结果生成结论。

二、产品整体架构

整体采用分层架构，自底向上：底座 → 基础能力 → 分析能力 → 编排层 → 产品形态。

产品

Insights
Chatbot

智能取数与可视化

数据分析

智能追问与多轮对话

仪表盘导航

编排层

Workflow

Agent

原子功能

意图识别

关键词提取

智能选表

Text2SQL

SQL 评估

数据可视化

时序预测

异常检测

漏斗分析

归因分析

分析能力

模型底座

通用推理 / Text2SQL / 分析

GPT

Claude

Gemini

DeepSeek

Qwen 等

专用预测模型

XGBoost

Prophet

LSTM 等

语义检索模型

text-embedding-3

BGE 等

Hive

指标定义

数据仓库

数据目录

数据底座

2.1 模型底座

根据任务特性选择合适的模型：

通用推理 / Text2SQL / 分析：GPT、Claude、Gemini、DeepSeek、Qwen 等
专用预测模型：XGBoost、Prophet、LSTM 等
语义检索模型：text-embedding-3、BGE 等，用于数据目录召回与上下文组装

2.2 数据底座

数据仓库、指标定义、数据目录（详见核心技术实践 4.2）。

2.3 基础能力（原子功能）

意图识别、关键词提取、智能选表、Text2SQL、SQL 评估、数据可视化。

2.4 分析能力

类型	方法	适用场景
确定性判断（指标拆解法）	横向拆解 + 纵向下钻	适用于指标之间有明确数学逻辑关系的场景，追求贡献度可量化、可相加
可能性判断（机器学习+因果推断）	XGBoost + SHAP + A/B Test	当指标间缺乏直接公式联系，或因素过多、关系复杂时使用。

2.5 编排层：Workflow 与 Agent 的边界

两者融合使用，判断标准是"问题路径是否可预定义"：

	Workflow	Agent
适用	高频、路径确定的问题	长尾、需多步探索的问题
例子	标准取数、固定口径的异动归因	开放式根因分析、多轮追问
优点	稳定、可控、可评估、便宜	灵活、覆盖长尾
代价	覆盖面有限	慢、贵、结果方差大

原则：能用 Workflow 解决的，绝不交给 Agent。 Workflow 路径确定，更容易对输出结果进行评估；Agent 是兜底，承接 Workflow 覆盖不到的长尾，但需要做好产品透明化，将决策权交给用户

三、前沿科技大厂落地 Data Agent 产品经验总结

OpenAI：Inside Our In-House Data Agent

OpenAI 内部 Data Agent 服务全公司，覆盖 70,000+ 数据集、600PB 规模，由此衍生出一套在大规模下维持准确性的工程实践。

六层上下文架构：如何让 Agent"读懂"数据

在这个规模下，靠人工标注静态数据目录根本维持不住。OpenAI 的核心工程贡献在于构建了一套六层自动化上下文组装系统，让 agent 在查询时能实时拼出足够准确的数据背景：

6运行时兜底

5对话记忆

4机构知识

3代码语义增强

2人工标注

1表使用元数据

从底层批量自动化数据，到顶层在线实时兜底——自动化程度递减、实时性递增（精准与成本不随层级单调变化，如人工标注最贵也最精准）

层	内容	关键细节
表使用元数据	Schema 结构、数据血缘、历史查询，按可信度排序	三类信号合并为一层；历史查询按可信度分级——看板 / 生产 SQL 权重高，一次性探索查询权重低甚至有害
人工标注	owner 手写的业务含义与"坑"	无法自动化的部分靠人补；是最贵但最精准的一层
代码语义增强（Codex Enrichment）	夜间批跑读取 pipeline 代码，推断表粒度、join key、字段口径	代码比文档更诚实：字段名可能骗人，建表逻辑不会。这是人工标注覆盖不到时的自动兜底
机构知识	Slack、Wiki、设计文档	带访问控制——不同角色读到不同上下文，敏感讨论不会越权流出
对话记忆	历次对话中的纠错与口径修正	分全局 / 个人两种范围；下次对话自动复用，无需重新解释口径
运行时兜底	离线上下文缺失或过时时，实时查数仓补齐	最慢但最准确；作为离线层的安全网

核心判断：OpenAI 的 agent 架构：单 LLM + 运行时 + 上下文组装 + 精简工具集（工具从初期约 40 个砍到 13 个精选）。它能在 70k 数据集、600PB 规模下成立，不依赖于复杂的 agent 编排，而是底下那套统一扎实的上下文与数据底座。

AI Evals 体系：快速迭代而不失信任

OpenAI 把"评估"做成发布流程的硬门禁，每次模型或 prompt 变更，必须通过三类测试才允许发布：

类型	验证内容	说明
Correctness	对错	golden test set 比对，SQL 结果是否符合预期
Bias	口径 / 样本偏差	结果是否因选表或过滤条件错误而系统性偏移
Leakage	越权访问	agent 是否被诱导查询了用户无权访问的数据

golden test set 从真实线上问题采样、由业务专家标注，每次迭代必须跑回归——防止"改好一个、改坏三个"
模型版本、指标定义、数据血缘全部打快照，出问题可追溯可回滚
关键原则："不是测得越多越好，而是测的方向要对"——三类风险覆盖是最小必要集合

智能体安全性与鉴权

权限与数据目录绑定：用户能访问哪些表，agent 生成的 SQL 就只能查哪些表
机构知识按访问控制分级嵌入：不同角色看到的上下文不同，敏感的内部讨论不会流出
查询日志全量记录：每次 agent 操作可追溯到发起人和具体 SQL，满足合规审计要求
数据字段脱敏与 SQL 限制：敏感字段在数据目录中标注，查询时自动屏蔽或脱敏

原文：Inside Our In-House Data Agent — OpenAI ↗

Meta：Inside Meta's Home-Grown AI Analytics Agent

Meta 的 Analytics Agent 是一个从内部需求出发、完全自研的数据分析智能体，最终成为全公司最高频使用的内部工具之一。

Analytics Agent 是如何工作的

核心设计哲学：利用上下文丰富用户提示词（数据发现 + 背景收集），再提供正确的推理逻辑（迭代推理循环）。答案呈现时，把透明度作为信任的基石。

Step 1 — 发现数据与收集上下文

用户的问题往往是模糊的，数据则极其复杂（成百上千张表、互相嵌套的指标定义）。Analytics Agent 的第一步不是直接生成 SQL，而是先把问题说清楚：

语义搜索数据目录，自动找到相关表和指标
拉取该领域的 Cookbook，了解这个业务域的惯用分析套路
查找匹配的 Recipe，看有没有现成的分析 SOP 可复用
解析 Ingredient 中的字段口径（如"l7_active = 近 7 天活跃且排除流失账号"）

Step 2 — 迭代推理循环

生成计划 → 执行（SQL / Python）→ 验证结果 → 发现问题 → 修正 → 再执行

每一步执行结果都会反馈给下一步用于校正，agent 能在循环中自我纠错。遇到数据异常、逻辑矛盾或结果超出常识范围时，会主动触发澄清追问或重试。

Step 3 — 全透明原则（非确定性 LLM 的最务实解法）

"在分析场景里，一个被自信地给出的错误数字，比没有数字更糟糕。"

每一个呈现给用户的数据点，背后生成它的 SQL 都被放在最显眼的位置。用户随时可以核对口径，把验算的能力部分还给用户。

三层知识系统：Cookbook / Recipe / Ingredient

层级	类比	内容	由谁维护
Cookbook	领域入口	某业务域的分析入口，打包该域的惯用方法、背景知识、参考专家	业务 / 数据负责人
Recipe	分析 SOP	标准分析流程，如"做留存分析应当这样拆解""归因时需要控制哪些混淆变量"	数据分析师
Ingredient	语义原子	字段定义、指标口径、历史纠错记录，如"l7_active = 近 7 天有行为且排除已流失账号"	数据工程

知识由专家录入一次，所有对话复用。这比单纯堆 RAG 文档更有结构，更重要的是：它让业务方从使用者变成共建者。

核心启示与落地数据

Meta 在正式立项前，先分析了一批历史业务问题，发现其中 88% 的分析类问题在上下文充分的情况下 LLM 能稳定回答。这个数字是项目成立的硬依据——证明了问题是"有界的"。

指标	数字
上线 6 个月内周活用户占比（数据科学家/工程师）	77%
非数据岗采用率 vs 数据岗	5 倍（数据工作真正民主化）
社区共建 Recipe 数量	4,500+
Recipe 累计使用次数	150,000+

速度优于完美："最大的风险不是发得太早，而是发得太晚"
把早期用户当共建者，而非小白鼠：让用户能录入 Recipe / Ingredient，贡献知识资产
Sanity Check 是性价比最高的自动验算器：如"WAU 不可能 > 80 亿""环比波动 > 500% 需复核"

原文：Inside Meta's Home-Grown AI Analytics Agent — Medium ↗

四、核心技术实践

Agent 内部流转流程

当用户提出问题时，Agent 内部按以下流程流转：

注：● 确定性校验可在 loop 内自动闭环（执行成功、结果非空、权限、粒度）；● 业务语义正确性无法在 loop 内自证，需结合第五章评估体系（golden set + 反馈闭环）持续校准，并通过透明化（每个数字附来源 SQL）让用户兜底。

综上，从工作流拆解来看，做好 data agent 核心需要解决以下几点：

如何让 LLM 理解业务问题，收集上下文——意图识别、Query 改写、Initial Context Assembly 的工程质量，决定了 agent 从第一步就能走对方向。
如何保证 LLM 选对表与字段——数据目录的完整性与元数据质量，是 Text2SQL 准确率的天花板，也是动态检索能否命中的基础。
如何构建好的迭代推理循环，让 agent 自主纠错——Plan → Retrieve → Execute → Observe & Validate → Reflect 的闭环设计，是 agent 能否从"高级辅助"走向"自主分析"的关键。
保证产品的透明化——每个数字附上来源 SQL，把验算能力还给用户，是 AI 分析产品建立信任的最务实路径。
设计好 AI Evals，让产品迭代有据可依——没有评估体系，agent 每次升级是好是坏都无法验证，产品也就无法持续进化。

4.1 如何让 LLM 理解业务问题

让 LLM 从"懂语言"到"懂业务"，分四步：

1）传递核心业务知识

提炼业务核心概念（如广告投放、销售分析、客户分群分析等），整理成千余字的业务概述，作为 System Prompt 注入，提供基本业务背景。

2）引入业务术语与知识库

高频术语与黑话：直接写入 System Prompt；
全量术语、指标定义等复杂知识资产：存入向量数据库，通过 RAG 动态检索，辅助模型理解细节问题。

3）用户意图识别

将业务问题分为四类，对应四大功能：智能取数与可视化、数据分析、深度对话分析、仪表盘导航。把常见业务问题整理进向量库，用 RAG 提升意图识别准确率，再路由到相应模块。

4）关键词提取与 Query 改写

意图识别后做结构化抽取，精准识别维度、查询指标、过滤条件、时间区间、时区等关键词。同时把业务知识嵌入知识库，解决别名/同义问题（如电商业务中"GMV"与"销售额"同义）。最后结合上下文将口语化提问改写为结构清晰、逻辑严谨的查询/分析请求。

4.2 智能数据查询：数据目录与元数据管理

建立数据目录和元数据管理系统，对数仓统一梳理标注。这是智能选表与 Text2SQL 准确率的地基，涵盖：

数仓概述：分层架构、数据来源、表的种类、业务场景等高层描述。
表的详细说明：每张表的功能及在数据产品中的应用场景。
表的选择逻辑：明确适用范围与不适用场景，避免误用导致分析偏差。
字段详情：字段类型、是维度还是指标、含义、取值范围；维度字段标注关联维度表。
- 衍生指标：解释计算逻辑与业务含义（如"新客户 = 统计期内首次下单的客户"）。
字段唯一性保障：梳理跨表同名/同义字段，明确语义一致性，特殊情况详细标注。
SQL 限制条件：列出查询限制，如敏感字段访问限制、特定业务逻辑下的检索约束，确保合规与准确。

如何把目录"喂"得更准

仅靠人工标注的静态目录会很快过时、覆盖不全。第三章 OpenAI 的六层上下文给了参考方法——靠多层信号自动组装，而非全靠人写。

为什么不直接用 Markdown？ 表少、业务知识较少时完全可以用 Markdown 静态注入，类似索引文件的方式构建知识库，简单有效。随着数据源扩展、表数量增多，全量注入成本急剧上升。Embedding 动态召回只把语义最相关的少量表元数据送给 LLM，精准、省 token、降噪。

五、AI Evals

LLM 是自回归地做 next-token prediction，输出带有概率性——AI Evals 正是应对这种不确定性、保障产品可靠并驱动持续迭代的核心机制。

5.1 评估全景：如何定义 Data Agent 产品质量

质量不能只用"SQL 能不能跑通"衡量——结果即使成功返回，也可能口径错误、过程跑偏、结论缺乏数据支撑。评估体系应从结果、过程、产品价值、工程与安全四个层面展开。

层面	核心问题	代表指标
结果质量	最终答案对不对	Groundedness、Answer Relevance（见 5.2）
过程质量	是不是用对的方式做的	Context Relevance、Plan Quality、Plan Adherence（见 5.3）
产品价值	用户是否真被帮到	任务完成率、业务采纳率、满意度（见 5.4）
工程与安全	系统稳不稳、安不安全	P50/P95 延迟、单次成本、越权拦截率

5.2 结果评估：最终答案对不对

指标	检查什么
SQL / 查询正确性	语法、执行是否成功、结果是否与 golden case 比对一致、口径与粒度是否正确
Groundedness（结果扎根度）	结论能否追溯到查询结果，防止模型凭空"编"
Answer Relevance（答案相关性）	是否直接回答了用户的问题，而不是跑题
Completeness	有没有漏掉关键指标、维度或限制条件
澄清 / 拒答	信息不足时有没有正确追问；数据不支持时有没有诚实拒答

有明确答案的部分（SQL、口径、权限）用确定性 grader 直接判对错；开放性的部分（相关性、完整性）用 rubric + LLM-as-judge，配合人工抽样校准打分一致性。golden case 的建设是持续工程：从线上真实问题中采样、由业务专家标注、纳入回归测试，防止"改好一个、改坏三个"。

加一层"业务常识校验"：在结果呈现给用户前，用独立的规则/LLM 做体检，例如"WAU 不可能 > 80 亿""环比波动 > 500% 需复核"。这类轻量 sanity check 成本极低，却能拦住不少离谱结果。

5.3 过程评估：错在哪一步

过程评估把 agent 的执行轨迹（trace：每一步的输入、输出、中间产物）按真实链路拆开，逐环节打分：

环节	指标	回答的问题
意图识别	Intent Accuracy	是否正确理解任务、指标、时间和粒度
上下文检索	Context Relevance	召回的表/字段/业务定义是否真的相关
任务规划	Plan Quality	计划是否足以达成用户目标，有没有遗漏关键步骤
规划执行	Plan Adherence	实际执行是否严格按计划走，还是中途跑偏
工具执行	Tool Success	工具调用参数是否正确，是否满足权限与规则
执行效率	Execution Efficiency	有没有重复取数、多余调用等冗余步骤
整体链路	Logical Consistency	目标、计划、执行之间有没有自相矛盾

过程评估的价值在于定位：同样是结果不理想，Plan Quality 低说明"一开始就想错了"，Plan Adherence 低说明"想对了但没照做"，Execution Efficiency 低说明"绕了远路"——只看最终答案分不出这几种情况，需要拆开轨迹逐环节评估。

5.4 在线评估：产品是否真正产生价值

洞察对不对已经在 5.2 判断过；这里看的是上线后有没有用、能不能稳定跑：

维度	指标
用户价值	任务完成率、澄清后成功率、用户纠错/重新生成率、满意度、业务采纳率
系统运行	P50/P95 延迟、单次成本、失败率、安全拦截率

5.5 反馈闭环：把 Bad Case 变成产品能力

把线上每一次交互，都变成一份可沉淀、可复用的反馈：

显式反馈：👍/👎、"这个口径不对"等；
隐式反馈：用户是否追问、是否复制 SQL、是否导出报告；
闭环：反馈 → 评分（复用 5.2/5.3 的确定性校验或 LLM-judge）→ Bad Case 归类（意图 / 口径 / 检索 / 执行 / 规划 / 证据不足 / 该澄清没澄清）→ 沉淀进 golden 集、修复 prompt 或数据目录 → 回归验证 → 灰度发布。