Data Agent 的七层架构：从数据接入到可信交付

Mon, 07 Sep 2026 00:00:00 +0000

业务负责人问：“这个月新客转化为什么下降了？”

如果系统立刻吐出一条 SQL，这通常不是效率高，而是跳过了最危险的部分。它还不知道“新客”按注册时间还是首购时间认定，不知道转化窗口是 7 天还是 30 天，也不知道本月渠道口径是否刚刚调整。SQL 可以运行成功，结论仍然可能是错的。

一个可用于生产的数据智能体，必须把这类模糊问题变成一条可检查的证据链：确认意图，找到被批准的数据和定义，制定分析计划，在受控环境里执行，验证结果，最后把结论和限制交给有权限的人。模型只负责其中一部分。

下面这张图把这条链路拆成七层。它不是厂商产品清单，而是一张职责地图：当结果不可信时，团队可以据此定位究竟是哪一层失守。

Data Agent 七层职责地图。点击查看原图。

先看清三张相互叠加的网

七层并不是一条只能从上往下走的流水线。一次分析会在规划、执行和验证之间多次往返，而权限、审计与评估贯穿始终。更准确的理解，是三张网叠在一起：

数据面负责让智能体找到数据、理解业务语义并运行工具；
控制面决定智能体可以看到什么、调用什么、在什么成本和风险范围内行动；
评估面检查单次答案，也持续衡量系统在一组真实任务上的表现。

很多原型只有数据面最显眼的一小段——“问句转 SQL”。一旦进入生产，真正拉开差距的往往是另外两张网：系统能否拒绝不该做的事，能否说明结论从何而来，失败后能否定位和修复。

第一层：接入与任务入口

入口可以是聊天框、Notebook、BI 侧边栏、API，也可以是定时触发的工作流。它的责任不是“做一个像 ChatGPT 的界面”，而是收集完成任务所需的最小上下文：用户身份、业务范围、时间窗口、期望输出和风险等级。

仍以转化率下降为例。一个合格的入口至少要知道提问者能看哪些地区的数据，并在定义不明确时主动追问：“这里的新客按注册还是首购计算？”

这一层的典型失败，是系统流畅地解决了另一个问题。产品设计上应允许用户低成本纠正假设，而不是把澄清隐藏在一长段回答之后。

第二层：语义、本体与可信上下文

物理表告诉模型有哪些字段，语义层告诉它这些字段在业务上意味着什么。这里需要管理指标、维度、实体关系、同义词、时间口径、Join 路径、负责人和版本。

例如，“新客转化率”可能被定义为：首个有效触点后 14 天内完成首购的新用户数，除以符合条件的新用户数。这个定义还要说明排除哪些渠道、退款如何处理、历史版本何时失效。只有把这些知识变成可检索、可引用、可执行的对象，智能体才不必每次凭字段名猜测。

上下文也不等于把所有文档塞进提示词。系统需要按任务路由：指标问题优先取指标定义和血缘，客户问题取实体关系和权限，重复出现的分析则可参考已验证的历史查询。上下文越多不一定越好；过期定义和相似但错误的 SQL 会把错误包装得更像答案。

第三层：规划与编排

规划器把目标拆成有依赖关系的步骤。对“新客转化下降”这类问题，一份可检查的计划可能是：

确认指标版本和比较周期；
先复算整体指标，确认下降确实存在；
按渠道、地区、设备和新客来源做贡献分解；
对主要异常分组检查漏斗步骤与数据质量；
运行替代口径或对照查询，排除定义变更；
汇总证据，标出不能从现有数据确认的部分。

规划的价值不在于写出一段漂亮的步骤说明，而在于让依赖、预算和停止条件显式化。某个分组样本过小，就不该继续生成强结论；关键数据延迟，系统应停止并提示，而不是用昨天的数据补齐今天的故事。

单智能体配工具、Planner–Executor–Verifier、多智能体协作都可以实现这一层。角色越多，协调和状态管理成本越高。先把计划、工具契约和验证点做扎实，通常比先增加 Agent 数量更重要。

第四层：工具与受控执行

智能体通过 SQL 引擎、Python 沙箱、Catalog、文档检索、可视化组件和业务 API 把推理变成证据。每个工具都应该像一个受约束的服务，而不是给模型一把万能钥匙。

一个可上线的工具契约至少应写清：输入参数、输出结构、身份传递、数据范围、超时、成本上限、幂等性和失败码。查询默认只读；大扫描、敏感字段和写操作需要单独的审批或策略门槛。代码在隔离环境运行，产物和日志可追溯。

这也是 Agent Harness 的核心工作：把模型调用、上下文装配、工具选择、策略检查、状态与记忆连接起来。模型可以替换，Harness 中积累的权限、工具契约和失败处理才是系统工程的主体。

第五层：验证、反思与修正

“工具调用成功”只说明系统得到了一份结果，不说明结果值得相信。验证层需要同时检查计算和结论。

计算侧可以做 SQL 编译、空值与基数检查、时间范围检查、与可信总数对账、替代查询比较；结论侧要检查每个判断能否回到数据证据，相关性是否被误写成因果关系，以及样本量和数据延迟是否足以支撑措辞。

当验证失败时，系统应回到规划或执行层修正，而不是简单地“再生成一次”。例如两个渠道的合计对不上整体，正确动作是检查重叠归因或 Join 扩张；让模型换一种说法，并不会修复数字。

Data Agent 的 L0–L5：升级的不是功能，而是责任

Sun, 06 Sep 2026 00:00:00 +0000

一个系统会写 SQL，另一个系统会调用 SQL 和 Python，遇到错误还能重新规划。后者连接的工具更多，但这还不足以证明它更“自主”。真正的区别是：谁决定目标，谁组织过程，谁有权执行，谁验证结果，出了问题又由谁恢复并负责。

因此，Data Agent 的等级不是功能数量表，而是一张责任转移图。每升一级，Agent 接手的不只是更多操作，也包括更多判断与风险。

这套 L0–L5 框架来自 2026 年论文 Data Agents: Levels, State of the Art, and Open Problems 及其配套的 Data Agent 研究资料库。作者将公开研究的主体现状放在 L0–L2，把正在探索端到端自主编排的系统称为 Proto-L3；L4 和 L5 主要是未来愿景。它适合用来讨论人机分工，不是厂商排行榜，也不是采购认证。

判断等级，要看五种权力归谁

同一个产品在不同工作流上可能处于不同等级。判断时可以沿五个维度逐项追问：

维度	关键问题
发起权	任务必须由人提出，还是系统能主动发现问题？
规划权	人预先定义步骤，还是 Agent 能拆解、选工具并重新规划？
执行权	只能建议、可以只读执行，还是能触发写入与外部动作？
验证权	谁判断结果足够可靠、任务可以结束？
恢复与责任	失败时谁停止、回滚、接管并解释发生了什么？

只要其中一个关键维度仍由人控制，系统的实际等级就会受到它限制。例如 Agent 可以自动写并执行 SQL，但每一步由人指定、结论也由人验收，它更接近 L2，而不是 L3。

L0：人是唯一的操作者

在 L0，分析师或工程师自己找数据、写 SQL 或代码、检查结果并决定下一步。数据库、BI 和 notebook 是工具，但不会代替人做判断。

L0 并不等于落后。在财务结账、监管报送、重大生产变更等高风险流程中，完整人工控制可能是合理设计。它的问题是吞吐依赖个人经验，过程难以规模化，隐性知识也容易留在个人电脑和脑中。

生产门槛：建立版本、评审、数据口径和操作记录。没有这些基础，接入 Agent 只会把原本不透明的人工过程自动化。

评估 on DataAgentX