Data Agent 怎么做：把 23 篇内容收成一张工作地图

Sun, 04 Oct 2026 00:00:00 +0000

看过很多 Data Agent 产品，真正开始建设时，团队仍会回到几个朴素的问题：它到底替谁完成什么工作，应该使用哪些数据，怎样安全执行，如何证明结果可靠，失败后谁负责。

这五个问题比厂商名单更耐用，也把定义、架构、自治等级、评测和落地串在了一起。

下面这张图进一步把问题映射到一条端到端工作链：任务怎样进入系统，数据语义怎样约束规划与执行，证据、审批、回读和反馈又怎样闭环。

一、先决定它接手哪类工作

企业问数、端到端分析、自动化数据科学、多源研究和数据工程是不同路线。问数要求稳定语义和只读权限；开放分析要求多步证据链；数据工程还涉及变更、审批和回滚。

不要先决定“做一个万能 Agent”。选一个具体工作流，写清输入、交付物和失败影响。路线回答做什么，L0–L5 回答人和 Agent 怎样分工，两者不能混为一谈。

SQL 能运行，只证明程序没有报错。Data Agent 还要在当前身份范围内找到权威数据，确认 Schema 与数据水位，再绑定指标、实体、时间、粒度和 Join 规则。

数据目录回答“有什么”，语义层回答“代表什么、怎么算”。模型可以检索和整理这些知识，却不应自行决定收入、客户和退款口径。没有版本化语义，系统每次都在用自然语言临时猜企业规则。

一条完整链路可以概括为：

这些层不是采购七个系统，也不是强制微服务拆分。它们是一组责任边界：团队必须知道每项控制在哪里实施、失败回到哪里。

L1 提供草稿，人执行；L2 能调用工具，人编排；Proto-L3 在限定目标内自主规划，人监督。越往后，Agent 获得越多发起、规划、执行和验证权，治理与恢复要求也越高。

同一产品可在不同工作流上处于不同等级。只读问数可能是 L2，生产变更仍保持 L1。等级应标注在“工作流 × 环境 × 权限”上，而不是品牌上。

Text-to-SQL、代码分析、异构数据和报告基准测量的是不同边界。看排名时记录数据版本、Oracle 输入、模型与工具、重试、评分器、成本和日期。

最终决策需要企业自己的任务集：正常任务之外，还要有歧义口径、迟到数据、同名测试表、越权、工具故障和无法回答的样本。比较任务成功、证据支持、人工修改、p95 延迟和总成本，并把越权与错误写入设为独立阻断项。

不同厂商案例最有价值的部分，不是功能名单，而是设计线索：

把每条线索变成自己的 POC 问题，而不是照抄厂商架构。