这两年做数据平台规划，被问得最多的早就不是“报表怎么做”，而是“我们能不能直接问数据”。Data Agent 这个说法，我最早是在几家指标平台的文档里看到的，当时大家都还叫它 ChatBI、NL2SQL，但实际用起来总觉得和“智能体”差着不少意思。到了 2026 年再回头看，市场上的产品已经从“一个能聊天的查询框”，长成了技术栈分层、架构形态各异、连内部组件关系都要单独建模的一整个赛道。
这篇调研记录，写给正在做数据平台规划、准备选型或者打算自研数据智能体的团队。我会先给 Data Agent 画一个清晰的能力边界，再按产品形态做一次市场全景分类，接着拆解主流技术栈每一层怎么选，最后用 ArchiMate 的视角把内部架构元素之间的关系讲透，并附上我实操中踩过的坑和排查经验。
1. 先把边界画清楚：Data Agent 到底解决什么问题
1.1 从 ChatBI、NL2SQL 到 Data Agent
很多人把 Data Agent 理解成“更聪明的 ChatBI”，这个方向对，但不完整。早期的 ChatBI 本质上是一个 Text2SQL 工具：用户输入一句自然语言，模型生成 SQL，执行后把表格返回。它的核心链路非常短，问题是出错的概率也很高，一旦表结构复杂、字段命名不友好、需要多表关联，生成的 SQL 基本不能直接用。
Data Agent 把这条链路拉长了。它不再只是“文本转 SQL”，而是先理解用户的业务意图，再决定要查哪些数据、要不要先做指标口径校验、需不需要调用外部接口补充上下文，甚至查完之后还能对结果做二次分析，生成结论和解释。我自己的体会是，ChatBI 解决的是“查得出来”，Data Agent 解决的是“问得明白、答得可靠、查完能干活”。
这里有一个很容易被忽略的点：Data Agent 的长处不只是生成 SQL 的能力，而是它具备任务拆解和工具调用的机制。比如用户问“这个季度华东区销售额为什么下滑”，单纯查数只能得到“下滑 12%”这个事实，但一个完整的 Data Agent 会拆成几个子任务——先定位同比环比数据、再按城市和产品线做拆解、查历史活动计划、把异常原因列出来。这种多步骤的推理和行动闭环，才是它和 ChatBI 的本质区别。
1.2 能力分层与运行闭环
从技术视角看，市面上的 Data Agent 能力大致可以分层：
- 感知层：理解用户提问、识别查询意图、抽取业务实体和筛选条件。
- 规划层：把主任务拆成子任务，确定执行顺序，识别需要的数据源和工具。
- 执行层：调用查询引擎、API、代码执行环境，生成 SQL/指标查询并执行。
- 记忆层：保存多轮对话上下文、业务偏好、历史查询结果，减少重复理解。
- 反馈层：对结果做可信度判断、解释生成、异常提示，甚至触发人工复核。
这五层并不是所有产品都有，但凡是真正标榜 Data Agent 的，至少会覆盖前三层。运行机制一般是一个“感知-规划-执行-反馈”的循环，和通用 Agent 的 ReAct 模式类似，只不过每一步都在和数据基础设施打交道，因此对权限、口径、数据质量的要求更高。
我见到的失败案例里，十个有八个不是模型能力不够，而是只做了“感知+执行”两层，中间靠提示词硬撑。一旦问题稍微复杂一点，模型就开始编 SQL 字段名，或者干脆带偏上下文。所以后面所有章节我都建议先按这个分层去对照产品，再看技术栈。
2. 市场全景：现在有哪些 Data Agent 开发平台值得关注
2.1 五条产品路线与代表案例
我这次调研按产品形态把市场分成了五类：传统 BI 的智能增强、云厂商数据平台内置、数据智能体创业公司、开源编排框架、以及指标层平台向上延伸。每一类的技术栈取向和适用场景都很不一样。
| 产品路线 | 代表方向 | 典型产品/平台 | 技术栈特点 | 适合场景 |
|---|---|---|---|---|
| BI 智能增强 | 老牌 BI 厂商在现有分析产品里加 Copilot | Power BI Copilot、Tableau Pulse、ThoughtSpot Sage | 基于既有语义模型，LLM 只做查询生成和解释 | 已有 BI 体系完善、分析师主导的企业 |
| 云厂商数据平台内置 | 数据仓库/湖平台原生支持自然语言查询 | Microsoft Fabric、AWS 数据平台内置问答、阿里云 DataWorks 相关能力 | 与云数仓深度集成，权限链路完整 | 云上数据资产集中、希望少维护一套系统的团队 |
| 数据智能体创业公司 | 以 Agent 形态做垂直数据问答与洞察 | 各类 Text2SQL/Agent 创业产品、指标平台智能助手 | 通常自研语义层 + Agent 编排，接口开放 | 需要开箱即用、快速验证业务价值的部门 |
| 开源编排框架 | 用 Agent 框架组装数据工具链 | LangChain、LlamaIndex、Dify、Haystack | 组合度高，需要自己接模型、接数据、做权限 | 技术团队强、要做私有化深度定制的企业 |
| 指标层平台向上延伸 | 从语义层/指标仓库起步，再叠加 Agent | dbt 生态、语义层产品加 AI 助手 | 强在口径统一，Agent 能力多依赖第三方 | 对指标治理要求极高、已有语义层建设的团队 |
这里多说一句 BI 增强这条线。Power BI 和 Tableau 的 Copilot 依赖的是它们内置的语义模型，理论上答案口径有保障，但灵活性偏弱，跨数据源、跨部门的复杂问题经常接不住。云厂商内置方案的优势在于权限和血缘天然打通，但绑定厂商生态，换平台成本很高。创业公司的产品这两年迭代极快，尤其在语义层和“解释原因”这类场景上有不少创新，但要小心长期服务稳定性。
开源框架线是最容易出现“看起来便宜、实际很贵”的选项。LangChain、LlamaIndex 的技术底座很强，但只提供骨架，语义层、权限、缓存、评测全要自己搭。Dify 和 Haystack 这类平台化开源产品把一部分工程问题解决了，可企业级数据治理相关的坑仍然绕不开。指标层平台向上延伸的路线，本质是从“口径即服务”切入，对数据团队本身要求很高，适合已经有完整指标体系的组织。
2.2 平台型与自研型的本质差异
调研做完，我最大的感触是“平台型产品重闭环，自研型产品重组合”。平台型的目标是把数据问答这件事包装成一个开箱即用的产品，整个链路是黑盒中的灰盒：语义层、权限、评测、界面全都帮你做完了。对绝大多数非技术背景的业务团队来说，这是最稳妥的起点。缺点是定制和扩展会遇到各种限制，尤其当你需要接私有数据源、自定义复杂的业务规则时，平台的通用解法往往不够用。
自研型则是另一条思路，适合数据团队强、数据资产复杂、或者有私有化合规要求的组织。自研的关键不是“用哪个 Agent 框架”，而是有没有能力把数据工程基础打好。很多团队以为买一个开源 Agent 框架回来接上大模型就能跑，结果发现 80% 的时间都在处理元数据不全、字段口径混乱、权限模型无法下沉这类基础问题。
我的建议是：如果企业数据团队少于 5 人，优先考虑平台型产品，把精力留给业务梳理；如果数据团队在 10 人以上，并且已经有数仓、已经有指标层，自研或基于开源深度定制是更长远的路。最尴尬的是中间态——既不想完全用平台，又没有足够的工程资源自研，最后开源框架只用来做了个 demo，生产环境完全跑不起来。
3. 技术栈拆解：谁在底层支撑 Data Agent
3.1 应用层与 Agent 编排框架
应用层没什么悬念，绝大多数 Data Agent 产品的对外服务端选型集中在 Python 和 TypeScript 两派。Python 生态在数据处理、AI 编排方面的积累确实太强了，LangChain、LlamaIndex、Pandas、DuckDB 几乎都是 Python 优先，所以面向数据分析核心链路的后端基本都是 Python。前端和交互部分则更多是 TypeScript 的天下，聊天界面、可视化配置台、结果解释卡片这些都需要成熟的前端框架支撑。
Agent 编排框架是技术栈里最容易被过度讨论的部分。我的观点是：如果是产品化自研，框架最多帮你在前期快速搭骨架，生产环境里最终都会长出自己的编排逻辑。LangChain 的价值在于生态丰富，模型接入、工具调用、记忆、回调都有现成组件，但到了复杂场景，LCEL 和各类抽象层反而会成为排查问题的障碍。LlamaIndex 在数据接入和 RAG 方面更强，适合做“检索+问答”为核心的 Agent，但从“文档问答”扩展到“企业级数据问答”，还有很多工程细节要补。
如果你不想被框架绑架，用原生代码实现 Agent 循环也不复杂：维护一个消息列表，循环调用大模型，解析工具调用请求，执行工具，把结果拼回去，直到模型给出最终答案。这个思想是我建议所有做自研的团队先掌握的，理解了这个循环，再用 LangChain 或 Dify，你就知道哪些能力是框架给的，哪些能力得自己写。外部工具的调用规范建议用 OpenAI 兼容的 function calling 格式，这样模型、网关、工具层的兼容成本最低。
3.2 数据基础设施选型
数据层是 Data Agent 的“老底”，也是技术栈里最不该追新的部分。一般来说，底层数据系统继续用你现有的数仓、数据湖、OLAP 引擎就好——ClickHouse、Snowflake、BigQuery、StarRocks、Doris 都可以，关键不在于引擎本身，而在于接入 Agent 的方式。
我强烈建议给 Agent 提供统一的数据访问网关，而不是让它直连底层引擎。原因有三：一是权限可以集中控制，行级、列级过滤都能在网关层做掉；二是可以对 SQL 做安全校验，避免危险查询或恶意注入；三是可以统一缓存和限流，防止用户一句话把集群资源打满。我在实际项目中见过不少为了省事直接让 Agent 用数据库账号查询的，最后都因为权限和稳定性问题被迫改造。
向量数据库和缓存是很多团队喜欢一上来就接的东西，但它们的位置需要摆正。向量库用于 RAG 检索，也就是把指标定义、数据字典、历史问答对做成向量索引，帮助模型理解业务语义，这一层要放在语义层旁边，而不是替代语义层。缓存方面，Redis 依然是最通用的选择，至少存三样：热门的查询结果、语义层的元数据快照、以及对话状态。至于 PostgreSQL 自带的 pgvector，在中等规模下完全够用，没必要为了“向量搜索”单独上重组件。
工具链层面，目前出现频率最高的是 DuckDB。它很适合做本地快速查询、示例数据探查，Agent 在生成 SQL 之前先用 DuckDB 跑一些对表结构和分布的探查，能显著降低生成错误 SQL 的概率。数据处理脚本继续用 Pandas / Polars 都没问题，图表解释这块可以交给 Plotly 或 ECharts 生成描述性的结果卡片，不要只给用户看一张表。
3.3 模型层与评测体系
模型选型是 Data Agent 调研里最热闹的部分，但也是最容易趋于一致的部分。面向复杂任务的主模型，现在大家基本集中在 GPT-4.1、Claude 系列和 DeepSeek 这些能力较强的模型上；简单任务则用更便宜的模型做路由，比如意图识别、实体抽取、查询改写这些环节用中小参数模型就够。
我比较推荐的做法是做一个模型路由层，而不是全链路死磕一个模型。以 Text2SQL 为例，简单查询用快速小模型，准确率不差且成本低；复杂多表查询再切到大模型。训练一个专门的 SQL 生成模型当然值得探索，但多数团队的数据规模和场景复杂度，还没到非要微调模型的程度，先把提示词、语义层和评测做好，收益要大得多。私有化部署的团队可以看开源模型，Qwen 和 DeepSeek 系列在 SQL 生成和工具调用上的表现在逐步靠近闭源第一梯队，量化后在几张 GPU 上就能跑起来，完全符合合规要求。
评测体系是技术栈里最容易缺席的一层。我的经验是，不建立评测集就上线的 Data Agent，基本都会在用户压力下快速“翻车”。公开基准比如 Spider、BIRD 可以参考，但要建立自己的评测集：从真实用户反馈里收集高频问题，标注正确 SQL 和答案，再按难度分成冒烟级、常规级、复杂级。发布新版本或更换模型时，先跑一轮评测集，用准确率、执行成功率、平均延迟、Token 成本四个指标做回归对比。这个评测集才是 Data Agent 迭代的“驾驶仪表盘”。
4. 技术架构剖析：用 ArchiMate 看 Data Agent 内部关系
4.1 核心模块与运行闭环
从架构图的角度，一个完整的企业级 Data Agent 至少包含五个应用组件：意图识别与任务规划器、语义层服务、数据访问网关、工具执行器、以及反馈与记忆管理器。这些组件不一定是独立的微服务，但在逻辑上必须边界清晰，否则后期维护会成为灾难。
运行闭环可以这样理解：用户请求先到意图识别器，它把自然语言转换成结构化的任务描述，比如“查华东区 Q2 销售额、按城市拆解、并把数据下载为 Excel”；任务规划器再决定需要调用哪些工具，按什么顺序；每调用一个工具，由数据访问网关负责把语义请求转成物理查询，同时套上权限过滤；执行结果回传给规划器，由它决定是继续查询、还是生成最终答案。整个过程产生的中间信息和结果，都要写入记忆管理器，用于多轮对话的上下文维持和后续查询的优化。
这个闭环看起来简单，但每个环节都有一堆细节。任务规划器并不是越复杂越好，我自己见过的失败方案，都是想一次性做太多事：把意图识别、SQL 生成、结果分析全都交给模型自由发挥，最后上下文乱成一锅粥。好的架构是每个组件只干一件事，用明确的接口契约把它们串起来，模型负责“理解”和“决策”，系统负责“纪律”和“执行”。
4.2 ArchiMate 元素关系举例
ArchiMate 是企业架构建模里常用的语言，核心思路是用标准化的元素和关系，把业务、应用、技术三层之间的协作讲清楚。在做 Data Agent 的技术架构评审时，用 ArchiMate 的关系类型来描述内部元素之间的依赖，比画一张流程图更能暴露设计问题。下面是我这次调研中整理的几组典型关系。
| ArchiMate 关系类型 | 关系方向 | Data Agent 中举例 | 说明 |
|---|---|---|---|
| Realization（实现） | 应用组件 → 应用服务 | 任务规划器 实现 查询编排服务 | 查询编排能力是由任务规划器这个组件落地的 |
| Serving（服务） | 应用组件 → 应用组件 | 意图识别器 服务 任务规划器 | 规划器依赖意图识别的输出，上层消费下层的服务 |
| Composition（组合） | 父组件 → 子组件 | 数据访问网关 组合 权限过滤器、SQL 校验器、缓存组件 | 网关是容器，内含多个子组件，子组件不被外部直接访问 |
| Access（访问） | 应用组件 → 数据对象 | 语义层服务 访问 指标字典 | 组件需要读取数据对象才能完成职责 |
| Assignment（分配） | 技术元素 → 应用组件 | pgvector 技术节点 分配 语义检索服务 | 语义检索服务运行在 pgvector 这个技术组件上 |
| Triggering（触发） | 行为 → 行为 | 用户提问 触发 意图识别行为 | 行为之间严格的时间先后关系 |
| Used by（使用） | 应用服务 → 应用组件 | 查询编排服务 被 工具执行器 使用 | 服务消费者到服务提供者之间的依赖方向 |
举一个更具体的例子：用户问“为什么华东区这个月销售额下降”，意图识别器先产出“分析销售额下降原因”的任务描述，这是 Serving 关系；任务规划器随后把任务拆成“查华东区月度销售额”“按产品线交叉分析”“检索近期营销活动记录”三个子任务，这是 Triggering 关系；数据访问网关在执行查询前，通过权限过滤器做行级过滤，这就是 Composition 关系里子组件在干活；最后反馈生成器把结论输出给用户，用的是 Realization 关系——反馈生成器实现了结果解释服务。
很多团队做架构评审时只看“模块图”，画几个方块连几条线，但从不标注连线的关系类型。用 ArchiMate 这套关系语言之后，你会立刻发现几个问题：某个服务到底由哪个组件实现？这条依赖方向是否反了？权限过滤是被哪个组件触发的？这些一旦在架构图上说不清，代码里一定是耦合的。关系类型本身不复杂，难的是坚持用同一套语言去沟通，避免“模块图各画各的”。
4.3 架构设计里几条不能省的底线
第一，语义层必须独立存在，不能只是“在提示词里写字段说明”。独立语义层的核心价值是把业务口径固化成机器可读的模型，模型生成查询时参考的是定义好的指标和维度，而不是靠记忆猜。没有语义层，Text2SQL 就是裸奔——字段一多、命名一乱，模型基本靠猜，准确率断崖式下跌。
第二，权限过滤必须站在数据访问网关这一层，且默认拒绝一切未授权访问。Data Agent 架构最忌讳的是“Agent 可信、直接放行”，实际使用中用户完全可能通过巧妙的提问绕过默认过滤条件。行级权限要下沉到网关层自动拼接，列级权限要在语义层直接屏蔽敏感字段。这块最好像做 API 网关一样严格：进网关的请求必须有身份上下文，出网关的查询必须被权限校验。
第三，从第一行代码开始接可观测性。Data Agent 的排查难度比普通服务高得多，因为一个错误可能来自意图识别、规划逻辑、工具执行、模型输出任一步骤。建议从设计阶段就要求每一次任务分配一个 trace id，把每轮 plan、每个工具调用参数、每次模型返回的结构化结果都记录下来。没有这套东西，线上的任何奇怪问题都只能靠猜，猜的代价远高于一开始接 trace 的成本。
第四，模型输出必须结构化。无论是 function calling 还是 JSON Schema，Agent 与模型之间的交互都要用可解析的结构化格式，禁止让模型输出自由文本再靠正则解析。这听起来像常识，但在调研中我发现不少自研团队早期都走偏了，结果每次换模型都重写一轮解析逻辑。
5. 选型指南：五个决策维度与落地路径
5.1 场景匹配决定产品形态
选 Data Agent 产品，先别急着比技术参数，先把场景钉死。我这次调研整理出三个典型场景，对应的产品倾向完全不同：
| 场景 | 用户特征 | 核心诉求 | 建议路线 |
|---|---|---|---|
| 领导驾驶舱/高管问数 | 非技术背景，问题宽泛开放 | 不求深，但答案必须稳定可信、口径统一 | 平台型产品优先，自带语义层和可视化，别自研 |
| 分析师自助取数 | 有一定技术能力，问题具体复杂 | 能查明细、能下钻、能复用分析思路 | 指标层平台或开源框架自组装，保留灵活性 |
| 客户/员工服务嵌入 | 外部或海量内部用户，问题重复度高 | 高并发、低成本、权限严格 | 模型路由 + 自研语义层 + 数据网关，走工程化路线 |
第一种场景我见过不少团队踩坑：拿开源框架接一个最强模型，demo 很惊艳，给高管演示时多问两轮就开始胡编，最后项目被否。第二种场景对 Agent 的要求反而是“少打扰”，分析师要的是能精确复现的查询逻辑，而不是花哨的对话。第三种场景最考验工程能力，重复问题多看起来简单，但权限和并发是两道硬门槛。
决定路线之前，最好先做一个“问题集”测试：收集真实用户会问的 100 个问题，分好类，分别跑一遍候选产品的试用版，看看各家的准确率、失败模式、以及解释质量。这个测试成本不高，但能直观暴露出平台型产品“通用但浅”或自研型产品“灵活但重”的差异。
5.2 成本与自主可控怎么权衡
成本不只有模型 Token 费用。我把选型成本拆成四部分：模型与推理成本、平台或框架授权成本、集成与维护人力成本、以及隐性治理成本。模型 Token 费用这两年因为开源模型和推理优化已经降了不少，成本的绝对重心转移到后两项。
平台型产品的授权成本通常不低，但它的隐含价值是帮你省掉语义层自建、权限打通、评测体系搭建的工程量。自研型的显性成本是少，但隐性成本很高——每个环节都要自己补全，而且数据架构一变，Agent 代码就要跟着动。自主可控要看怎么理解：开源框架确实代码在自己手里，但不代表你能控制质量；更关键的是对语义层和评测集的掌控，这两块一旦外包给平台，后期想迁移的成本极高。
我的个人倾向是：治理基础薄弱的团队先用平台型，快速验证价值，同时用半年的时间把指标字典和评测集沉淀下来；等技术团队理解了整套逻辑后，再决定要不要自研替代。最忌讳的是“先自研后怀疑、再换平台”，中间浪费的时间基本都在补数据基础。
5.3 最小可行架构的落地顺序
如果最终决定自研，别一上来就铺大架构。我给一个我自己验证过的落地顺序，按这个顺序走最少返工：
- 先把语义层建起来。梳理核心指标、维度、常用过滤条件，整理成机器可读的指标字典。这一步和 Agent 无关，但决定了后续所有环节的质量。
- 搭一个最小的 Text2SQL 闭环：模型 + 语义层 + 数据源。不要加 Agent 编排，不要加记忆，先把“单轮查询”的准确率做及格。
- 接入数据访问网关，套上权限和 SQL 校验。越早越省事，不要在裸查询上继续叠加功能。
- 再上 Agent 编排：意图识别、任务规划、工具调用。每一步都要有 trace 日志。
- 建设评测集，从真实日志里挑问题，开始做回归测试。
- 最后才上多轮记忆和主动反馈，这两项是体验增强，不是地基。
这个顺序的核心思想是“先保准确，再加智能”。很多团队反着来，先把 Agent 编排做得天花乱坠，结果最底层的 SQL 生成不准，所有上层能力都变成负资产。地基没打好之前，所有花哨的能力都是在放大错误。
6. 实操复盘：高频问题、排查思路与经验沉淀
6.1 高频故障与排查速查表
把调研中和实战里的问题放在一起看，Data Agent 的高频故障种类其实很集中。下面这份速查表，基本覆盖了上线前后最容易遇到的坑。
| 故障现象 | 常见根因 | 排查方向 | 解决建议 |
|---|---|---|---|
| 生成的 SQL 字段不存在 | 语义层没有覆盖该字段/表 | 查 trace 中语义层返回的字段列表 | 补语义层元数据，不要改提示词 |
| 多表关联结果重复或漏数据 | 表关系定义不完整 | 检查语义层中的 join 路径 | 显式定义常用关联关系，限制模型自行 join |
| 用户提到时间条件但查询没过滤 | 意图识别的参数抽取失败 | 看意图识别器的结构化输出 | 增加时间实体识别的规则后处理 |
| 同一个问题不同人得到不同口径 | 语义层被绕过或定义不全 | 核对 trace 中使用的指标定义 | 强制所有查询走统一指标层 |
| 查询高并发把数据库打满 | 无缓存、无限流、无超时控制 | 看网关层请求日志 | 网关层加缓存、限流和查询超时 |
| 多轮对话后开始胡言乱语 | 记忆管理策略丢失上下文 | 检查记忆管理器的历史摘要 | 给对话记忆做摘要和窗口截断 |
| 某些用户能查到未授权数据 | 权限过滤没下沉到网关 | 检查 SQL 拼接日志中的权限条件 | 行级权限必须在网关强制拼接 |
先说明一下为什么表里反复出现“语义层”和“网关”这两个答案。我的经验是，Data Agent 的故障很少是模型“笨”，而是数据没有准备好。语义层缺失时模型只能靠猜，权限没下沉时安全早晚出问题。排查的第一步永远是看 trace，而不是重新提问测试；没有 trace 就开始调提示词，那是在碰运气。
6.2 我踩过的那几个坑
第一个坑是早期让模型直接读表结构。当时以为大模型能力强，给全量 DDL 让它自己理解就够了。结果字段一多，模型选择性地忽略了很多字段，而且频繁把“下单时间”当成“支付时间”来用。后来把语义层建起来、只暴露业务友好的字段名和指标定义，准确率才上来。
第二个坑是权限模型上线太晚。一开始只在应用层做了“该用户属于哪个部门”的判断，以为这样够了。直到业务安全团队模拟了一个低权限账号，通过绕开前端条件的方式查到了别的部门明细，我们才真正把行级权限下沉到数据访问网关，让它成为所有查询的强制环节。这块能早做就早做，越晚改造成本越高。
第三个坑是评测集建设落后于功能开发。我们上线两周后发现线上频繁出问题，但每次修完都不能确定是否复发了。后来才花大力气从日志里清洗出了 300 多条真实问题，做成回归评测集。之后每次改模型、改提示词、改语义层，先跑一遍评测集，心里才有底。这也是我后来在所有 Data Agent 项目中第一条要求建设的东西。
6.3 下一代 Data Agent 值得留意的方向
做调研的时候，我顺带留意到几个正在下沉的技术趋势，它们不能算空想，已经能在部分产品里看到雏形。第一个是多智能体协作，把数据治理、指标解释、异常分析拆成多个 Agent，让它们通过任务黑板协作。这个方向适合治理复杂的大型组织，但要小心过度工程化。第二个是主动式 Agent，不是等人提问，而是根据数据监控规则主动推送异常和归因分析，这比被动问答更贴近数据平台的价值。第三个是评测即服务，未来会有更多面向数据 Agent 的第三方评测平台，把 NL2SQL 准确率、工具调用成功率、成本效率做成标准指标，企业可以拿自己的私有评测集去对比选型。
这些都是加分项，不是地基。地基仍然是语义层、权限网关、评测体系这三样。如果团队精力有限，先把这三样做到极致，比追任何一个新概念都管用。
我自己的体会是，Data Agent 的调研和落地，本质上不是大模型竞赛，而是数据工程能力的竞赛。模型迭代快是好事，但如果企业内部的数据还是“脏乱差”，再强的模型也撑不起一个可信的数据问答产品。先回到数据本身，把口径、权限、质量这些老问题解决掉，Data Agent 才能从一个演示功能变成真正每天都在用的生产力工具。