1. 从"能聊"到"能干"：Data Agent 到底在解决什么层面的问题

过去两年，我参与过三个不同规模的数据平台智能化改造项目，从最初把大模型接进 BI 工具做"自然语言查数"，到后来搭建能自主规划、调用工具、校验结果的 Data Agent 系统，踩过的坑几乎覆盖了这条链路上的每一个环节。2026 年再来看这个赛道，一个明显的分水岭已经出现：能聊的 ChatBI 遍地都是，能真正干活的 Data Agent 依然稀缺。

这个稀缺不是模型能力不够造成的。GPT-4 级别的模型在 SQL 生成、意图理解上早就够用了，真正卡住工程落地的是另外三件事：上下文怎么组织、工具怎么编排、结果怎么校验。这三件事恰好构成了 Data Agent 技术栈的核心骨架，也是这次调研想讲清楚的东西。

先把概念边界划清楚。Data Agent 不是"套了个壳的 ChatGPT"，也不是"加了自然语言入口的报表系统"。它是一套具备感知—规划—执行—反思闭环的智能体系统，输入是一句模糊的业务问题（比如"上个月华东区哪些品类的复购率掉了"），输出是经过校验的可信结论，中间要自主完成：理解业务语义、定位数据资产、生成并优化查询、执行、发现异常、调整策略、最终给出带解释的答案。

适合读这篇内容的人有三类：正在做 Data Agent 选型的技术负责人、准备从零搭建智能问数系统的数据工程师、以及想搞清楚"这东西到底难在哪"的产品同学。我会尽量把技术栈的每一层拆开讲，包括为什么这么选、实测中会遇到什么、以及那些文档里不会写的坑。

2. Data Agent 技术栈的分层拆解：每一层在扛什么责任

2.1 交互层：SSE 流式输出为什么成了事实标准

先说最外层。用户感知最直接的就是"回答是不是一个字一个字蹦出来的"。这背后是流式输出机制，而目前主流方案几乎都收敛到了SSE（Server-Sent Events）。

为什么是 SSE 而不是 WebSocket？我实测下来的结论很直接：Data Agent 的交互模式是单向的、服务端持续推送，客户端主要是接收和渲染，不需要高频双向通信。WebSocket 虽然能力更强，但要维护长连接状态、处理心跳、做断线重连，复杂度高出一截。SSE 基于 HTTP，天然支持断线重连（浏览器会自动重试），实现成本低，配合text/event-stream就能跑。

一个典型的 SSE 输出链路是这样的：

// 前端接收流式响应 const response = await fetch('/api/agent/query', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ question: userInput }), signal: abortController.signal // 关键：支持中断 }); const reader = response.body.getReader(); const decoder = new TextDecoder(); while (true) { const { done, value } = await reader.read(); if (done) break; const chunk = decoder.decode(value); // 解析 SSE 格式：data: {...}\n\n renderChunk(chunk); }

这里有个容易被忽略的点：Abort 机制。用户问了一个问题，Agent 正在跑一个耗时 30 秒的复杂查询，用户等不及想换个问题，这时候必须能中断。前端用AbortController，后端要监听连接关闭事件，及时释放正在执行的查询资源和模型调用。我见过不少项目只做了前端中断，后端还在傻跑，结果数据库连接池被打满。

提示：SSE 在 HTTP/1.1 下有单域名 6 连接的限制，如果页面同时有多个 Agent 会话，建议走 HTTP/2 或者做连接复用，否则会出现"新问题发不出去"的诡异现象。

2.2 编排层：Agent 的"大脑"怎么组织推理逻辑

编排层是 Data Agent 和普通问答系统的本质区别所在。普通系统是"输入→模型→输出"的直线流程，Data Agent 需要多步推理 + 工具调用 + 状态管理。

目前主流有三种编排范式，我做个对比：

实际项目中我倾向于混合方案：用 Plan-and-Execute 做顶层任务分解，每个子任务内部用 ReAct 处理不确定性。比如"分析华东区复购率下降原因"这个任务，顶层规划成"查数据→找异常维度→下钻分析→生成结论"四步，其中"找异常维度"这一步用 ReAct 去尝试不同的维度组合。

编排层还有一个绕不开的话题是上下文管理。Data Agent 一轮对话可能涉及表结构、字段注释、历史查询、业务规则等大量信息，全塞进 prompt 会爆 token，塞太少模型又会瞎猜。我的做法是分层注入：系统层放业务规则和表元数据摘要，会话层放最近几轮对话，任务层放当前子任务相关的详细 schema。这样既保证模型有足够信息，又不至于把上下文撑爆。

2.3 数据访问层：Text-to-SQL 只是冰山一角

很多人以为 Data Agent 的核心就是 Text-to-SQL，把自然语言转成 SQL 就完事了。真做过项目就知道，SQL 生成只是数据访问层的一个环节，而且往往不是最难的那个。

完整的数据访问链路包括：语义解析 → 资产定位 → SQL 生成 → 语法校验 → 执行优化 → 结果处理。其中"资产定位"是最容易被低估的一环。企业数据仓库里动辄几千张表，模型怎么知道"复购率"对应的是dws_user_repurchase这张表而不是ods_order_detail？靠的是语义层/指标层的建设。

我的经验是，没有语义层的 Data Agent 都是玩具。语义层要做的事包括：把业务指标（复购率、客单价、转化率）映射到具体的计算逻辑和物理表，把业务术语（华东区、上个月）映射到维度和时间范围。这层做扎实了，模型只需要做"意图识别 + 参数填充"，难度大幅下降。

-- 语义层定义的指标示例 { "metric": "复购率", "expression": "COUNT(DISTINCT CASE WHEN order_count > 1 THEN user_id END) / COUNT(DISTINCT user_id)", "source_table": "dws_user_order_summary", "dimensions": ["region", "category", "time"], "default_time_grain": "month" }

SQL 生成之后还有一道安全校验关。必须做的是：禁止 DDL/DML 语句、限制查询返回行数、加超时控制、做权限过滤。我见过有系统直接让模型生成的 SQL 裸奔到生产库，结果一个SELECT *把内存打爆的事故。

2.4 执行与反思层：让 Agent 知道自己错了

这是区分"能用"和"好用"的关键层。Data Agent 生成的 SQL 第一次跑失败是常态——字段名拼错、聚合逻辑不对、时间范围理解偏差，各种问题都有。反思层的价值就是让 Agent 自己发现并修正错误。

具体机制包括：SQL 执行报错时，把错误信息回传给模型让它修正；查询结果为空或异常（比如数值明显不合理）时，触发重新规划；多轮结果不一致时，做交叉验证。我实测下来，加了反思层之后，端到端的查询成功率能从 60% 左右提升到 85% 以上。

但反思层有个陷阱：不能让 Agent 无限重试。我设的规则是最多重试 3 次，超过就返回"无法完成，请补充信息"，避免陷入死循环烧 token。

3. 技术架构选型：从单体到分布式的取舍逻辑

3.1 架构演进的三个阶段

Data Agent 的架构不是一步到位的，我观察到的演进路径大致分三个阶段。

第一阶段是单体架构：模型调用、SQL 生成、执行、结果处理全在一个服务里。优点是简单，部署快，适合验证阶段。缺点是任何一环出问题整个服务挂掉，而且模型调用是 IO 密集、SQL 执行是 CPU 密集，混在一起资源调度很别扭。

第二阶段是分层架构：把 Agent 编排、模型服务、数据访问拆成独立模块，通过内部 API 通信。这是目前大多数中型项目的选择。好处是各层可以独立扩缩容，模型服务可以换供应商而不影响其他层。

第三阶段是分布式 Agent 架构：每个能力（查询、分析、可视化、报告生成）都是独立的 Agent 服务，通过消息队列或编排引擎协同。这种架构适合大型企业，但复杂度也最高，我一般建议团队规模不到 10 人别碰。

3.2 关键组件的选型对比

编排引擎这块，LangGraph、AutoGen、以及自研状态机是三个主流选择。我的实测对比：

我个人的选择是中小项目用 LangGraph，大项目自研。LangGraph 的图结构对 Agent 流程的表达很自然，状态管理也做得不错，但它的抽象层有时候会挡住一些底层控制，遇到需要精细调优的场景会有点憋屈。

向量库这块，做语义检索和相似问题匹配会用到。Milvus、Qdrant、pgvector 我都用过。如果团队已经在用 PostgreSQL，pgvector 是最省事的选择，不用额外维护一套存储；如果数据量上亿级别，Milvus 的性能优势才体现出来。

3.3 一个真实的分层架构参考

我最近一个项目的架构大致是这样组织的：

• 接入层：Nginx + SSE 网关，负责连接管理、限流、鉴权
• 编排层：LangGraph 驱动的 Agent 服务，管理推理流程和工具调用
• 能力层：SQL 生成服务、语义解析服务、结果分析服务，各自独立部署
• 数据层：语义层元数据库 + 向量库 + 业务数据仓库
• 可观测层：全链路追踪，记录每一步的输入输出和耗时

这套架构跑下来，单次查询的 P95 延迟在 8 秒左右，其中模型调用占了大头。如果对延迟敏感，可以考虑把一些高频问题的结果做缓存，或者用小模型做意图识别、大模型只负责复杂推理。

4. 落地过程中那些文档不会写的坑

4.1 语义层的建设成本被严重低估

几乎所有 Data Agent 项目在立项时都会低估语义层的建设成本。大家想的是"接个模型就能查数了"，实际做起来发现，把企业几百个指标、几千个字段的业务含义梳理清楚，本身就是个耗时数月的大工程。

我的建议是不要追求一次性建全。先挑最高频的 20% 指标和表做语义映射，覆盖 80% 的查询需求，剩下的按需补充。而且语义层要设计成可迭代的，每次 Agent 查询失败或结果不对，都是一次补充语义定义的机会。

4.2 模型幻觉在数据场景下格外危险

通用场景下模型胡说八道顶多是答非所问，数据场景下模型幻觉会直接导致错误的业务决策。我遇到过模型把"环比"理解成"同比"，生成的 SQL 逻辑完全正确但口径错了，结果数字看着合理实际全错。

防幻觉的手段我总结了几条：关键指标的计算逻辑必须走语义层而不是让模型自由发挥；结果返回时必须附带口径说明；对异常数值做合理性校验（比如复购率超过 100% 直接拦截）。还有一条经验是，让模型在生成 SQL 的同时输出它的理解，人工或规则校验这个理解对不对，比直接校验 SQL 更有效。

4.3 权限控制是个容易被忽略的硬骨头

Data Agent 让"人人都能查数"听起来很美，但数据权限必须严格控制。销售只能看自己区域的数据，HR 数据只有特定角色能访问，这些规则必须在 Agent 层就做好过滤，而不是指望模型自觉。

我的做法是在语义层就给每个指标和维度打上权限标签，Agent 生成查询时根据用户角色自动注入过滤条件。这块如果做不好，轻则数据泄露，重则合规事故。

4.4 成本控制：token 烧起来比想象中快

一个复杂查询可能触发十几轮模型调用，每轮都带着大量上下文，token 消耗非常可观。我做过统计，一个日活 500 的内部 Data Agent，如果不好好优化，每月模型成本能到几千美元。

优化手段包括：意图识别用小模型、复杂推理才用大模型；上下文做压缩和摘要；高频问题做结果缓存；设置单次会话的 token 上限。还有个小技巧是把表结构信息做成向量检索，只注入相关的表，而不是把所有 schema 都塞进 prompt。

5. 2026 年的选型建议：什么团队该走什么路线

5.1 按团队规模和技术储备分档

如果是5 人以下的小团队，我建议直接用现成的平台产品，把精力放在语义层建设和业务适配上，别自己造编排引擎的轮子。这个阶段自研的投入产出比很低。

5 到 20 人的团队，可以考虑基于 LangGraph 这类框架做半自研，核心的编排逻辑自己控制，外围能力用开源组件。这个规模最适合做深度定制，既能满足业务需求，又不至于陷入基础设施的泥潭。

20 人以上的团队，如果有长期投入的打算，自研全套架构是合理的。但要有心理准备，这不是一个季度能搞定的事，语义层、编排引擎、可观测体系都需要持续打磨。

5.2 评估供应商时该问的几个问题

如果考虑采购现成方案，我建议重点问这几个问题：语义层能不能自己维护和扩展？支不支持私有化部署？模型能不能换？查询失败时的排查链路透不透明？这几个问题能筛掉一大半华而不实的产品。

特别是"模型能不能换"这点很关键。2026 年模型迭代速度依然很快，如果产品把模型焊死了，半年后你可能就被锁在一个过时的能力水平上。

5.3 一个务实的落地节奏

最后说说节奏。我的经验是先做窄场景的深度验证，再横向扩展。选一个业务价值明确、数据相对干净、查询模式相对固定的场景（比如"销售日报自动生成"），把它做到 90% 以上的准确率，跑通完整链路，再往其他场景复制。一上来就追求"什么都能问"的通用 Agent，大概率会做成一个什么都能问但什么都答不准的鸡肋。

这个领域变化很快，我上面讲的很多判断可能半年后就需要修正。但有一条是不变的：Data Agent 的价值不在于模型多强，而在于工程做得多扎实。语义层、权限、校验、可观测，这些"不性感"的活儿，才是决定项目成败的关键。