看过很多 Data Agent 产品，真正开始建设时，团队仍会回到几个朴素的问题：它到底替谁完成什么工作，应该使用哪些数据，怎样安全执行，如何证明结果可靠，失败后谁负责。
这五个问题比厂商名单更耐用，也把定义、架构、自治等级、评测和落地串在了一起。
下面这张图进一步把问题映射到一条端到端工作链：任务怎样进入系统，数据语义怎样约束规划与执行，证据、审批、回读和反馈又怎样闭环。
一、先决定它接手哪类工作
企业问数、端到端分析、自动化数据科学、多源研究和数据工程是不同路线。问数要求稳定语义和只读权限；开放分析要求多步证据链；数据工程还涉及变更、审批和回滚。
不要先决定“做一个万能 Agent”。选一个具体工作流，写清输入、交付物和失败影响。路线回答做什么，L0–L5 回答人和 Agent 怎样分工，两者不能混为一谈。
二、正确答案从找对数据开始
SQL 能运行，只证明程序没有报错。Data Agent 还要在当前身份范围内找到权威数据，确认 Schema 与数据水位，再绑定指标、实体、时间、粒度和 Join 规则。
数据目录回答“有什么”，语义层回答“代表什么、怎么算”。模型可以检索和整理这些知识，却不应自行决定收入、客户和退款口径。没有版本化语义，系统每次都在用自然语言临时猜企业规则。
三、七层架构服务于一个任务
一条完整链路可以概括为：
- 接入与路由找到相关、授权、足够的数据；
- 语义层绑定业务定义和关系；
- 规划与编排把目标变成可恢复状态机；
- 受控执行校验、授权并运行 SQL、代码和工具；
- 验证与评测检查来源、语义、程序、分析和交付；
- 治理与安全贯穿身份、策略、缓存、文件和动作；
- 交付与行动把声明、证据、制品、审批和反馈连接起来。
这些层不是采购七个系统，也不是强制微服务拆分。它们是一组责任边界：团队必须知道每项控制在哪里实施、失败回到哪里。
四、自治升级等于责任转移
L1 提供草稿，人执行；L2 能调用工具，人编排；Proto-L3 在限定目标内自主规划，人监督。越往后，Agent 获得越多发起、规划、执行和验证权，治理与恢复要求也越高。
同一产品可在不同工作流上处于不同等级。只读问数可能是 L2，生产变更仍保持 L1。等级应标注在“工作流 × 环境 × 权限”上，而不是品牌上。
五、公开榜单只能帮你找候选
Text-to-SQL、代码分析、异构数据和报告基准测量的是不同边界。看排名时记录数据版本、Oracle 输入、模型与工具、重试、评分器、成本和日期。
最终决策需要企业自己的任务集：正常任务之外，还要有歧义口径、迟到数据、同名测试表、越权、工具故障和无法回答的样本。比较任务成功、证据支持、人工修改、p95 延迟和总成本，并把越权与错误写入设为独立阻断项。
产品案例应该变成检查问题
不同厂商案例最有价值的部分，不是功能名单，而是设计线索：
- 内部 Data Agent 提醒我们，数据发现和组织上下文可能比 SQL 生成更难；
- Skills 模式说明分析经验可以变成可复用、可评审的工作协议；
- 云平台产品展示了数据、语义、身份和运行时如何复用现有控制面；
- 只读设计说明查询与业务动作应拥有不同权限边界；
- 多 Agent 架构只有在职责、上下文或权限需要隔离时才有意义。
把每条线索变成自己的 POC 问题，而不是照抄厂商架构。
一张可以直接使用的试点任务卡
| 字段 | 示例：每周净收入复盘 |
|---|---|
| 用户与决定 | 区域负责人；决定先排查哪个渠道 |
| 目标 | 比较本周与过去四周，解释主要变化贡献 |
| 指标 | 净收款 v3；退款按发生日；Asia/Shanghai |
| 数据 | 已授权生产漏斗与支付模型；水位至少到周日 |
| 工具 | 只读 SQL、受限 Python、图表；禁止外发与写入 |
| 验证 | 独立复算总量；分解贡献之和在容差内等于整体变化 |
| 交付 | 一页摘要、结果表、口径、限制和排查工单草稿 |
| 停止条件 | 数据不全、口径冲突、权限不足或预算超限 |
| 责任人 | 业务 Owner、指标 Owner、系统 Owner |
先用 20–50 个真实案例跑通这张任务卡，在沙箱和影子流量中验证，再开放有限生产。写操作与外发另设审批和恢复，不由只读 POC 自动继承。
最后带走的一句话
Data Agent 不是一个更会聊天的查询界面，也不是模型、工具和多 Agent 数量的总和。它是一套把数据工作逐步交给软件、同时保留业务含义、验证证据和责任边界的系统。
先把一个任务做可信，再把更多工作交给 Agent。这比追求一个“什么都会”的演示慢一点，却更接近能够长期使用的产品。