作者：zhanbo · 2026-10-10
声明：本文为独立方法论沉淀，基于公开资料与个人实践整理，不代表任何雇主或客户观点；本工作室不承接游戏（含手游 / 休闲 / 中重度）行业相关咨询。
tl;dr
- 做什么：让业务人员用自然语言完成问数、异常诊断、监控与决策建议。首期只落地一个专业域（如 ROI 异常诊断），不做"全公司什么都能问"的超级 Agent。
- 为什么是现在：临时取数淹没数据团队、问题到决策链路长、口径各执一词；而主流厂商路线已全部收敛到"语义层 + Agent + 行动"，开源组合已足以支撑 PoC。
- 成功标准不是"能回答很多问题"，而是在目标场景里业务人员少找一轮分析师：一次解决率、诊断耗时、建议采纳率与可量化的业务结果。
- 首期严格只读：不自动改预算、不调生产写 API，建议必须人工确认。
- 权限、行列级安全、审计第一天内置，不能上线后补。
一、为什么大多数 Data Agent 会失败
三个常被数据验证的事实：
- 对 4,602 条错误 SQL 的分析显示，81.2% 的错误发生在 schema / 语义层，语法错误只占 18.8%（arXiv 2501.09310）。
- 企业真实查询在没有语义层时准确率仅 10–31%，补齐 context stack 后可达 94–99%。
- MIT NANDA 研究：95% 的 GenAI pilot 拿不到可衡量的损益影响，根因是没有嵌入业务流程，而不是模型差；LinkedIn SQL Bot 嵌入现有工具后，采用率比独立聊天框高 5–10 倍。
结论很直接：瓶颈在数据与语义、在运营，不在模型。 只采购一个模型、做一个聊天 UI，几乎注定得到"demo 惊艳、上线僵尸"。
二、六件事，而不是一个聊天框
Data Agent 的产品边界覆盖六件事，聊天 UI 只是最表层：
[1] 入口层 Chat / BI / IM / 内嵌面板 —— 入口必须在现有工作流里
[2] Agent 运行时 意图 → 计划 → 工具调用 → 检查 → 解释 → 建议
[3] 语义/上下文层 指标 / 实体 / 维度 / join / 同义词 / 规则案例
[4] 工具层 metric_query / 新鲜度 / 异常检测 / 贡献拆解 …
[5] 治理层 RBAC / 行列级安全 / 审批 / 审计 / 限流
[6] 评测与证据层 trace / 引用 / 黄金问题 / 用户反馈 / 业务结果
└──→ 失败聚类 → 修复语义 → 离线评测 → 发布门禁 → 再发布
三条关键架构原则：
- Agent 不直连裸表，路径固定为
Agent → 语义/策略层 → 受控查询 → 数仓。 - 能力沉淀为可审计的工具，而不是全塞进 prompt。
- trace 是产品数据，不是工程日志——它驱动评测与迭代。
能力分层：首期做 L1–L3
| 层级 | 典型问题 | 首期 |
|---|---|---|
| L1 信息获取 | “昨天某区域收入 / D1 ROI 多少？” | 做 |
| L2 分析解释 | “为什么 D7 ROI 掉了？哪里拖累？” | 做 |
| L3 持续洞察 | “每天监控，异常时告诉我原因” | 做 |
| L4 决策建议 | “预算怎么分？” | 试点，需人审 |
| L5 执行动作 | “把符合规则的计划降 20%” | 禁止自动执行，仅人工 |
三、第一个场景怎么选
不要选"覆盖最广"的场景，选五个条件同时满足的：高频、数据基础强、口径明确、可解释、业务结果可量化。
以"ROI 异常诊断"为例，Agent 要能回答：
| 业务问题 | 输出 |
|---|---|
| 昨天整体 ROI 为什么下降？ | 结论 + 证据 + 影响金额 |
| 某区域 / 某媒体 ROI 下滑原因？ | Top 原因 + 置信度 |
| 哪些计划该重点关注？ | P0 / P1 / P2 清单 |
| 预算浪费在哪里？ | 机会矩阵 |
| 是真问题还是回传问题？ | 数据质量判定（先排除"假异常"） |
统一的回答结构必须是：结论 → 证据（可追溯到查询引用）→ 判断 → 分级建议 → 可信度。护栏要拦截把相关性、候选因素说成因果结论的陈述。
语义层的具体建模样例（指标如何定义为业务公式、粒度与时间口径、join 路径如何预定义）、最小数据表结构、以及完整工具清单，篇幅较长，可在 1v1 中按你的数据现状展开。
四、技术选型：开源组合，不从零造
| 能力层 | 选型 | 理由 |
|---|---|---|
| 语义层 | Cube 或 dbt MetricFlow（已有 dbt 资产首选 dbt） | 统一指标 / 维度 / join / 权限，确定性底座 |
| 受控取数 | DBHub（只读 + 审计）/ dbt-mcp | 通用、稳、自带审计 |
| Agent 编排 | DB-GPT 或 WrenAI | PoC 快，可二开 |
| Trace / Eval | Langfuse / Phoenix / MLflow 三选一 | 排障与评分附着 trace |
| LLM | 多 provider 可替换 | 不把业务逻辑写死在模型里 |
选型纪律：star 数 ≠ 企业成熟度；多许可组件商用前要逐件过法务；避开已停更 / archive 的项目（如 Vanna、Dataherald、PandasAI），它们可作架构参考，不能当新底座。
Build / Buy / OSS 的结论：数仓、BI 沿用现有；语义层、评测体系、运营体系必须自建——这是长期核心资产；Agent 运行时和 NL2SQL 用开源起步。
五、12 周路线
| 阶段 | 周次 | 重点 | 门禁 |
|---|---|---|---|
| 0 选域 + 基线 | 1–2 | 定域、访谈、收 50 个真实问题、记旧流程基线 | Top 20 问题明确、基线可量化 |
| 1 语义层 MVP | 3–4 | 实体 / 指标 / 维度 / join / 权限 | 黄金问题达可用准确率 |
| 2 Agent MVP | 5–6 | 编排、SQL、证据链、正确拒答 | 50 题可重复评测 |
| 3 业务试点 | 7–8 | Champion、小范围上线、嵌入工作流 | 复用率 / 解决率显著提升 |
| 4 监控 + 运营 | 9–10 | 失败分类、质量看板、案例库迭代 | 每周新增 verified 问题 |
| 5 业务闭环 | 11–12 | 加入监控 / 建议 / 审批一小段 | ≥1 个流程跑通"数据→建议→动作" |
成功标准分四层看
| 层 | 指标 |
|---|---|
| 活跃 | WAU、有权限者活跃占比（登录 ≠ 采用，只导 CSV 算假活跃） |
| 效率 | 单次诊断耗时、分析师节省工时、一次解决率、人工接管率 |
| 质量 | 语义准确率、查询正确率、证据覆盖、拒答率、重复一致性 |
| 业务结果 | 建议采纳率、被触发动作数、预算 / 素材调整、ROI 改善或损失避免 |
运营上要配 Domain Champion（约 1:20 的高频用户）、可直接点击的黄金问题、内嵌入口（不另开"AI 网站"），并把每个失败按类型转成特性：语义缺失→指标、口径歧义→说明、高频问题→已验证查询。
Trace 的三级采集策略（默认只采元数据、脱敏 payload 按需、原始内容严格限制）、完整安全治理矩阵和发布门禁清单，涉及具体合规场景，建议单独对齐，不在公开文章展开。
六、启动前先回答这几个问题
- 第一个 Agent 场景和主要用户是否明确？
- 任务成功和业务 outcome 是否定义清楚（不止模型评分）？
- 是否已有统一的指标口径 / catalog？没有的话，是否接受"语义层窄启动 + 限定可问域 + 人工兜底"？
- 凭证与敏感字段是否默认不入库、行列级权限和审计是否就位？
- 是否有专职 owner 对采用率和价值复盘负责？
如果第 3 条答不上来，说明该先做数据成熟度自检，而不是直接上 Agent——在垃圾数据上自动化，只会更快地得到错误答案。
下一步
如果你的团队在评估自建 Data Agent，却不确定数据底座够不够成熟、第一个场景该选哪里、自建和开源该怎么分工：
延伸阅读：