最近我们团队做了一件很接地气的事把市面上叫得上名的 Data Agent 产品扒了一层皮专门研究它们的技术栈和技术架构。所谓 Data Agent你可以理解为一个能听懂人话的数据分析师——你告诉它“帮我看看最近三个月华东区的销售趋势”它会自动拆解任务、找数据表、写查询、做分析最后把结论和图表推到你面前。无论是做企业数据中台、BI 升级还是企业内部数据分析平台Data Agent 都是绕不开的方向。这篇调研笔记分享给两类人一类是准备自研数据助手的后端或全栈工程师想看别人怎么搭架构、踩坑另一类是产品经理或者技术售前想快速搞懂市面产品的技术底细免得被厂商话术带偏。我尽量把抽象架构落到具体组件和可复用的代码思路上不写空话。1. 市场现状与 Data Agent 的分类1.1 为什么突然 All in Data Agent传统的数据分析链路是“人找数据”业务方提需求数据工程师写 SQL、出报表再反复沟通口径。链条长、响应慢而且大量临时性取数请求占用了分析师的时间。Data Agent 的核心价值就是“数据找人”把自然语言变成可执行的数据库操作把以前需要几天的取数流程压缩到几分钟。从我这几个月的调研看2026 年的企业级 Data Agent 已经不是实验品而是开始批量上生产环境的阶段。市场上叫 Agent 的产品很多但真正能落地的基本都在解决同一个问题如何把大模型的“语言能力”和数据库的“计算能力”安全、稳定地接在一起。这背后涉及的不只是模型 API 调一下而是完整的技术栈选型、任务编排、流式传输、权限控制、缓存降级等一系列架构问题。我调研了十几个产品包括国外开源的、国内私有化部署的、云 SaaS 的发现它们的架构虽然各有差异但底层骨架高度相似。调研中我特别关注了“AI 交互逻辑是怎么封装的”。很多产品看起来界面很炫但交互层其实就是一个普通的前端聊天框改造真正拉开差距的是后端的 Agent 编排能力和数据连接器的深度。这也是我写这篇调研报告的初衷——搞清楚技术栈才能不被演示效果迷惑。1.2 按技术路线划分的三类产品市面上的 Data Agent 可以粗暴分成三类Text-to-SQL 厂商、通用 Agent代码执行型厂商、对话式 BI语义层型厂商。这三类不是按公司大小分的而是按技术路线分了岔路。第一类Text-to-SQL 厂商。它们的核心是让模型直接生成 SQL然后执行、返回表格。这类产品技术栈相对简单一个大模型 API、一个 SQL 解析/校验器、一个数据库连接池。典型代表是很多开源项目比如 Vanna、sqlchat 等以及国内一些私有化部署工具。优点是实现快、对固定模式的数据查询效果好缺点是面对复杂多表关联、业务口径不清时容易崩而且口径理解不了“为什么这么算”。第二类通用 Agent代码执行型厂商。它们把 Data Agent 当作通用 Agent 的一个垂直应用不仅让模型写 SQL还包括写 Python、调 API、生成图表。典型代表是 OpenAI 的 Code Interpreter 思路、LangChain 生态里的各种 Data Agent 模板。这类产品技术栈最复杂一般要引入代码沙箱、文件系统、任务队列。它们的核心能力是“能干的活多”但稳定性和安全边界是最大挑战。第三类对话式 BI语义层型厂商。这类是传统 BI 厂商在转型比如 ThoughtSpot、国内的一些 BI 厂商。它们会把底层数据仓库抽象成统一的语义层用自然语言翻译成语义查询而不是直接翻译成 SQL。这样做的好处是口径统一、权限好做、稳定性高缺点是前期语义层建模成本高业务表结构经常变的话维护很痛苦。三类产品我做了简单对比类型核心能力典型技术难点落地速度Text-to-SQL模型写 SQL复杂查询准确率、口径理解最快Agent代码执行模型自由操作沙箱安全、执行稳定性中等对话式 BI语义层语义模型翻译语义层建设、元数据管理较慢没有哪一类绝对好关键看你的数据环境和企业阶段。后面我会逐一拆它们的架构细节。2. Data Agent 的核心技术栈拆解2.1 AI 推理层大模型与 Agent 框架先说 AI 推理层。所有 Data Agent 最底层都是一个大模型但“怎么用”差别很大。一种是最简单的直接 Prompt 拼 SQL模型文本进文本出另一种是走 Agent 框架让模型具备“观察-思考-行动”的循环能力。2026 年主流 Agent 框架无非 LangChain、LlamaIndex、AutoGen 这类开源库但生产级产品一般不会直接裸用而是在框架外面再包一层自己的状态机。为什么要包一层因为开源的 Agent 框架大多是给开发者写 Demo 用的分支循环写得很抽象出问题时你根本不知道卡在哪一步。我们在调研某国外开源 Agent 模板时发现它对 SQL 执行超时没有任何内置重试机制任务失败后整个会话就卡住了。生产级产品一般会把 Agent 的行动步骤拆成节点计划节点、查表节点、执行 SQL 节点、校验节点、画图节点每个节点有独立的超时控制和日志埋点。这一步本质上是把不可预测的大模型行为收敛成可管控的业务流程。技术栈上AI 推理层一般涉及模型 APIOpenAI/Claude/国内模型、函数调用Function Calling、结构化输出JSON Mode、上下文管理Message History、Embedding 模型用于相似问题召回。特别注意很多产品不只是用模型写 SQL还会把历史成功查询作为 Few-shot 示例放进 Prompt或者用 Embedding 从历史问题库里检索相似 query。这个机制能显著提升准确率也是 RAG 思路在数据分析领域的应用。在选模型时除了关注准确性还要关注延迟成本。Data Agent 查询往往涉及多轮迭代一次任务可能调用模型 3~5 次。如果用的是昂贵的大模型单次分析成本会很高。我看到很多产品的做法是“大小模型混合”小模型做分类和抽取大模型只负责复杂的 SQL 生成。这个思路值得借鉴后面在架构演进里我还会展开。2.2 数据访问层语义层、连接器与执行引擎数据访问层是 Data Agent 和普通聊天机器人的最大区别。普通聊天机器人只需要访问知识库Data Agent 必须连接真实的数据库、湖仓、BI 服务。这一层的技术栈核心是连接器Connector、查询引擎、元数据管理、语义层。连接器就是各种数据库驱动的封装比如 JDBC、ODBC、HTTP API。但生产级环境远不是连上就能用要处理的问题包括连接池管理、超时控制、SSL 证书、代理、不同数据库方言的语法差异MySQL、PostgreSQL、ClickHouse、Doris、Hive 等。我在调研中发现很多 Agent 产品会在连接器层做“方言标准化”也就是先把模型的通用输出转换为目标数据库的方言。比如把LIMIT 10翻译成 SQL Server 的TOP 10把日期函数做适配。这一步如果漏掉模型生成的 SQL 在别的库上根本跑不了。查询引擎负责执行 SQL 或代码。轻量一点的产品直接复用数据库连接执行重量级的产品会引入 DuckDB、Polars 这样嵌入式分析引擎把查询下推或者把数据拉到本地再分析。引入本地分析引擎的好处是能支持更复杂的 Python 计算坏处是数据安全风险和内存压力。很多 SaaS Data Agent 会在后端跑一个沙箱用 Kubernetes Job 动态拉一个 Python 执行环境几分钟内跑完就销毁。语义层是这一两年 Data Agent 技术栈里很火的一个概念。它不是简单的表字段映射而是把业务口径、指标定义、维度层级、权限规则都建模到一层。ArchiMate 这类架构设计方法论里经常强调组件之间的职责边界在技术实现上语义层中间件比如 Cube.js、AtScale、LookML会把上层查询转换为底层物理 SQL。调研里印象比较深的一个国产 Agent 产品它们的语义层甚至能把同一个指标自动适配“额”、“金额”、“销售额 GMV”等不同叫法。这种能力极大提高了用户输入的宽容度但代价是语义层的建模投入非常大。2.3 前端交互层流式输出、渲染与中止控制前端交互层通常被低估但它是用户体验的胜负手。Data Agent 执行任务往往需要几秒到几十秒如果前端只是一直转圈用户早就关页面了。2026 年主流产品的做法是采用SSEServer-Sent Events流式输出让大模型的 Token 逐字推到前端配合 abort controller 实现“停止生成”操作。SSE 技术上比 WebSocket 更简单它建立在 HTTP 上服务端可以持续推送数据前端用EventSource天然接收。但实践中有一个坑EventSource 不支持自定义请求头。很多产品为了鉴权不得不退回到 fetch ReadableStream 来手动解析 SSE。我调研的某产品就是用 fetch 流式读取然后配合AbortController来取消请求。前端拿到流后要按特定的事件格式解析比如用data:分隔文本块用event: status标识任务状态。除了文本流Data Agent 前端还需要渲染结构化数据表格、图表、异常提示、SQL 片段。所以交互层技术栈通常包含前端框架 React/Vue、表格组件AG Grid/tanstack table、图表库ECharts/Chart.js以及一套自定义的消息渲染器。好的产品会把模型输出的结构化 JSON 拆分成多种“消息卡片”比如table_card、chart_card、sql_card、error_card。前端按卡片类型渲染用户会感觉像在用专业分析工具而不是一个干巴巴的对话窗。中止控制也是一门学问。用户点击“停止”按钮时前端不是只断掉网络请求就行后端还要通知正在执行任务的 Agent 线程停止后续动作同时回滚未完成的事务。我见过有产品没做后端中止逻辑导致用户取消了但 SQL 还在跑数据库被拖慢。这个细节看似小却是架构上“交互-执行联动”的重要考点。3. 主流技术架构模式剖析3.1 编排调度架构Plan-Execute vs ReAct市面上 Data Agent 的后端执行架构主要有两种模式Plan-Execute和ReAct。这两种模式决定了 Agent 的思考流程也决定了代码怎么组织。Plan-Execute 模式很好理解第一步模型先生成一个完整执行计划比如“先查订单表再按类别聚合最后生成柱状图”第二步系统按计划逐步执行每一个子任务执行完再拼装结果。这种模式的优势是流程可控、每一步都有明确输入输出特别适合对准确率要求高的 SQL 查询场景。而且计划一旦生成你可以对计划做合法性检查拦住那些“读取全表”的危险操作。ReAct 模式则是“边想边做”模型每走一步观察执行结果再决定下一步。比如模型先列出数据库的表发现没有“用户等级”字段就回去改成查“用户积分表”。这种模式灵活性极高能处理意外情况但代价是循环不可控、Token 消耗大、响应时间不稳定。调研的多个 Agent 产品里凡是跑复杂分析的最终都转向了 Plan-Execute 或者“混合模式”。混合模式是现在比较推荐的方案先用一个规划模型生成计划然后用一个轻量级执行器逐节点执行如果某个节点失败就把错误信息重新喂给规划模型让它调整计划。实现上我建议用一个简单的事件总线来解耦规划器和执行器。规划器只产出“任务图”执行器从任务图里取节点执行执行状态通过 Redis Stream 或 Kafka 异步发布。这样即使执行器崩溃重启任务图还在可以断点续跑。在代码层面不要直接写死一串if-else来模拟 Agent 编排。用状态模式或状态机库管理任务节点会更清晰。比如定义节点状态PENDING、RUNNING、SUCCEEDED、FAILED、CANCELLED然后一个循环调度器扫描状态把可运行的节点推给线程池。这种实现既好调试也方便后面加监控。3.2 流式架构SSE、WebSocket 与任务状态机流式输出是 Data Agent 的标配。但流的不只是文本还有任务状态、SQL 执行日志、图表数据。我建议不要把所有信息都塞到一个流里而是设计多通道流或者事件类型区分。比如用 SSE 的不同事件类型token事件推大模型的文字status事件推任务状态tool_call事件推当前正在执行的工具。前端监听这些事件分别更新页面上的不同区域。SSE 和 WebSocket 怎么选从技术栈角度如果只是服务端到客户端的单向推送SSE 足够而且天然支持自动重连配合 HTTP 2 也更友好。但如果需要双向交互比如用户在执行过程中发送额外的指令那 WebSocket 更合适。实际上很多 Data Agent 产品把 WebSocket 用于会话管理SSE 用于 Token 流两者并存。任务状态机是整个流式架构里容易被忽略的部分。一个查询任务通常要经历created - planning - querying - rendering - done。每一步都要可观测并且要能推送给前端。状态机的线程模型也很有讲究如果每个任务占一个线程并发高了线程池会打满。我看到的生产级做法是任务状态机用事件驱动任务进入队列后由 Worker 线程执行状态变化通过回调发布。前端通过长轮询或者 SSE 获取状态。注意任务状态机一定要持久化不然服务重启后任务就丢了。用 Redis 或者数据库表存储任务状态配合一个定时恢复任务能大幅提高可用性。关于前端的“中止”逻辑我再多说一句。配合AbortController前端发送终止信号不仅要在 HTTP 层面上取消请求后端还需要有对应的 token 来消费这个信号。很多框架里比如 Go 的context.Canceled、Java 的Future.cancel()都能把取消信号传递到正在执行的 SQL 查询。如果你用的是 Python FastAPI可以在后台任务里轮询一个threading.Event来判断是否需要取消。这个联动如果没做好用户的点“停止”是假的。3.3 会话与持久化多轮上下文与缓存设计Data Agent 不是一次性查询工具用户往往会进行多轮追问比如“按地区分下呢”“把同期对比也加上”。所以上下文管理非常关键。技术实现上不能把全部历史对话塞进 Prompt否则 Token 会爆炸。要把对话历史做结构化提炼只保留“当前的数据集状态”和“用户最近的意图变化”。具体做法是每一轮查询成功后生成一个context摘要比如“用户选择了2024年华东区订单数据使用了聚合查询关注维度是省份和销售额”。下一轮追问时把摘要和最近两轮用户问题拼入 Prompt。有的产品还会存一个“查询快照”把上一轮生成的 SQL 和结果 schema 存到 Redis下一轮如果是基于上一轮结果继续分析就直接用快照不用重新查库。缓存设计对 Data Agent 的性能影响巨大。同一份报表A 用户查了B 用户大概率也会查。很多产品会在语义层或查询层做一级缓存缓存 key 由 SQL 哈希、数据源标识、参数组合生成。缓存要注意权限隔离如果用户的行级权限不同即使 SQL 完全一样返回结果也可能不同所以缓存 key 里必须带上用户权限指纹否则会越权。持久化层面消息记录、SQL 执行记录、错误日志都要落库。这一块常见的技术栈是 PostgreSQL 存结构化元数据对象存储存历史报表快照ClickHouse 存日志。数据 Agent 的审计需求很强企业会要求能追溯“谁在什么时候问了什么问题系统给出了什么答案”所以每次查询的原始输入、生成 SQL、执行结果校验、最终展示内容都要存一个不可变记录。调研中我看到一家头部产品甚至记录了每一步 tool call 的输入输出这就是 Agent 的不透明问题倒逼出的审计方案。3.4 安全权限与审计多租户隔离和行级安全安全部分是 Data Agent 和企业内部系统对接时最难啃的骨头。最基础的是统一身份认证一般接企业已有的 SSO/LDAP。但更复杂的是数据权限传统 BI 里是通过报表或数据集做权限控制而 Data Agent 直接面对数据库权限控制必须下推到行级。常见做法是提前在语义层或连接器层注入权限过滤条件。比如用户属于华东区系统在生成的 SQL 后自动拼接WHERE region 华东用户永远查不到其他区域的数据。实现这一层需要在元数据里维护“权限维度字段”和“用户属性映射”。有些产品会把数据源包一层 APIAgent 只能通过这个 API 查询而不是直连数据库。这样权限控制就集中在 API 层了。多租户隔离也是 Data Agent 架构里的关键点。SaaS 型产品通常一个 Agent 服务后面挂了多个客户的数据源一旦隔离没做好就是重大事故。技术栈上一般用“租户上下文”贯穿整个链路数据库连接按租户分池、Redis key 带租户前缀、流式消息里带租户 ID。更严格的还会让每个租户的任务跑在独立的 Kubernetes Pod 里避免互相影响。审计和安全不能只靠代码还要靠制度。我在调研中看到一些产品会设置“危险查询拦截”规则比如限制DELETE语句、限制超大型JOIN、限制全表扫描。拦截规则既可以是静态的 SQL 正则也可以由模型判断还可以设置“手动确认”机制——当 Agent 要执行高成本查询时需用户点击确认才真正执行。这个机制在企业私有化部署中很受欢迎也是架构上值得提前预留的开关。4. 典型产品架构横向对比4.1 Text-to-SQL 规则校验型产品这类产品架构最简单也比较适合作为参考起点。它的技术栈大概是前端 React Next.js后端 Python FastAPI 或 Node.js模型走 Claude/文心/通义等 API数据层用 SQLAlchemy 连接各类数据库。核心流程是自然语言 - 模型生成 SQL - 正则和 AST 校验 - 数据库执行 - 返回结果。别看架构简单校验环节做得好不好决定了产品上限。好的 Text-to-SQL 产品会做三层校验第一层语法校验用 SQL Parser 解析确保语法无误第二层黑名单校验拦截DROP、TRUNCATE、UPDATE等危险操作第三层耗时预估如果 SQL 涉及的表行数巨大且没有分区过滤就拒绝执行并让用户加条件。我们调研时专门用十个复杂查询测过带三层校验的产品错误率从裸模型直出的 30% 降到了 7% 左右。这类产品的局限在于没有“容错机制”。如果模型生成的 SQL 使用了不存在的字段它不会像 Agent 一样主动去看表结构来自我纠正。改进方案是加入一个“重试循环”当 SQL 执行报错时把错误信息反馈给模型让它修改 SQL。这一步能让很多本来失败的场景救回来也是从“工具人”变成“Agent”的分水岭。我在自己实践时会用一个简单的 prompt 模板拼错误信息然后让模型重新输出 SQL最多重试三次。实测数据复杂查询的最终成功率能提升 15~20 个百分点。4.2 Agent 自主规划 代码执行型产品第二类产品架构上最复杂主要体现在 Agent 自主性和代码沙箱。这种产品一般不区分查询阶段和计算阶段模型可以自己决定用 Python还是写 SQL或者调用第三方 API。典型技术栈后端 PythonAgent 框架LangGraph/LlamaIndexDocker 沙箱Celery/RQ 任务队列Redis 存储状态MinIO 存临时文件。这种架构的价值在于灵活但也带来了两大核心问题——执行环境安全和任务输出稳定性。代码沙箱是这类产品的最重模块。为了保证模型生成的 Python 代码不破坏宿主环境几乎所有生产级产品都会用 gVisor、Firecracker 或 Docker 轻量级容器隔离。容器内限制 CPU/内存超时就杀掉禁止外网访问文件系统只读除非显式挂载临时目录。还要注意容器内的库依赖模型可能生成依赖 pandas、numpy 的代码沙箱需要预装常用数据分析库否则每跑一个任务都要重新装包延迟不可接受。任务输出的稳定性也是这类产品的痛。模型代码可能跑出乱七八糟的结果比如返回一个内存巨大且毫无意义的 DataFrame。生产级产品通常会对模型代码的输出做 schema 校验如果结果不是表格形式或者列名超出预期就报错让模型重新生成。调研中某开源产品就是靠这个校验把“能跑但没用的结果”拦截在门外。顺便说一句这类产品里模型输出了什么格式的图表很多时候取决于模型本身。所以不少产品会限定“图表必须用 ECharts 的 option 配置形式输出”前端拿到直接渲染这一招在统一图表风格上非常有效。4.3 对话式 BI 可视化探索型产品第三类产品更像是“披着 CHatGPT 外衣的 BI 工具”。它的核心架构里多了一层语义模型查询不直接打数据库而是打到语义层。典型技术栈数据建模工具dbt、语义层Cube.js 或自研、大模型作为语义转换器、前端 BI 可视化组件。这种产品的思路是与其让大模型胡乱写 SQL不如让大模型把自然语言翻译成语义查询语句比如 MDX、JSON 查询格式再由语义层固定翻译成 SQL。这样 SQL 生成过程是确定的准确率自然高。在产品演示里这类产品通常很惊艳因为语义层处理好了业务口径用户问“毛利率”时系统不会真的去搜一个有“毛利率”字段的表而是去找语义层里的“毛利率”指标定义自动关联分子分母。这种体验是前两类产品很难企及的。代价是语义层需要人工建模而且建模质量直接影响 Agent 效果。如果一个企业有成百上千张变动频繁的表语义层维护成本会非常高。架构层面这类产品还要额外考虑元数据同步和 Schema 映射。用 dbt 做数据清洗和建模再通过元数据 API 同步到语义层这个过程最好做成自动化。很多产品会每天定时拉取数据源 schema识别新增表和字段自动生成候选指标。大模型在这里可以用来辅助对齐比如把“用户数”映射到COUNT(DISTINCT user_id)。这个方向我很看好因为企业真正需要的是“口径统一”而不是花式写 SQL。5. 选型建议与技术栈清单5.1 小型团队 MVP 技术栈推荐如果你的团队只有两三个人想快速做一个 Data Agent 原型或者内部工具我建议不要一上来就搞 Agent 框架而是走“简化版 Text-to-SQL 重试循环”的路线。技术栈可以很小前端 Next.js Tailwind后端 FastAPI数据库直接用 PostgreSQL不用 Redis 也行模型用功能 calling 能力强的国内大模型成本低然后自己包一个简单的 SQL 校验工具。这里我给出一个非常务实的 MVP 模块拆分会话接口POST/api/chat接收用户问题返回 SSE 流。中间层用async generator把模型响应流转成 SSE 事件。Agent 逻辑先让模型输出 JSONJSON 里包含thought和sql两个字段用 Pydantic 做响应校验。执行层SQLAlchemy 连接池动态绑定数据库 schema。纠错机制捕获数据库异常把错误信息拼回 Prompt重试最多 3 次。别小看这个简化方案它够你在两周内跑通核心链路。等验证了业务价值再逐步加缓存、状态机、沙箱。很多开源项目最终能撑起一个小团队产品就是用这个思路做起来的。5.2 中型企业级架构演进方向用户量上来了数据源复杂了MVP 架构就撑不住了。这时候需要向企业级架构演进我梳理了五个演进方向第一把 SQL 执行节点和 Agent 编排节点拆开做成独立的微服务第二引入消息队列Kafka / RabbitMQ所有任务执行都走异步事件第三加入 Redis 缓存和任务存储支撑断点续跑第四把数据连接升级为多租户连接池按租户隔离查询第五增加审计日志服务每次 Agent 执行的 tool call 都落盘。企业级架构里还有一个关键决策大模型部署方式。如果数据不出域你需要私有化部署模型比如用 vLLM 跑 Qwen 或 ChatGLM 系列如果对性能要求高可以走云端 API 但只传脱敏后的 schema不传实际业务数据。很多企业客户把“数据不出域”作为底线所以你的技术栈里要提前支持模型切换。抽象出一个统一的LLMProvider接口后面接 OpenAI 还是私有化部署都只是配置项的问题。另外多 Agent 协同也是企业级方向之一。比如一个 Agent 负责意图识别一个 Agent 负责写 SQL一个 Agent 负责审查 SQL一个 Agent 负责生成图表解释。各 Agent 之间通过消息传递结果整体形成流水线。这种架构相当于把一个大而全的 Agent 拆分成了多个小 Agent便于单独升级和排查。我建议如果团队超过 10 人就往这个方向演进不要一个人维护一个巨型 Agent 文件。5.3 关键架构决策点清单做技术选型时可以拿下面这些决策点过一遍每个点都决定了架构的走向模型在哪跑云端 API 还是私有化部署影响网关设计和数据脱敏逻辑。是否引入语义层前期可以不做但如果口径问题频繁出现就要考虑。较早在语义层投入会在后期节省大量返工成本。流式用什么协议SSE 还是 WebSocket我建议方案选 SSE二次开发成本低监控也方便。任务状态存哪别用内存状态直接上 Redis。沙箱要不要如果只是 SQL 查询不需要如果允许模型写 Python必须上。缓存粒度是按 SQL 结果缓存还是按整张报表缓存需要结合权限模型设计。这些决策点没有标准答案但你要能在方案评审时回答“为什么这么选”。否则后面每一次架构调整都会很痛。6. 常见问题与排查心得6.1 流式中断与重放机制第一个常见问题是前端中断。我们用 SSE 时发现的坑是用户网络闪断EventSource 会自动重连但服务端推送的消息已经丢了前端界面会卡在中间状态。处理方案是引入“消息游标”前端每次连接时带一个last_event_id服务端根据游标从消息缓存比如 Redis List里重新推送缺失的事件。这个思路类似消息队列的消费者重新拉取实践下来能解决大部分断线问题。还有个容易被忽略的点AbortController的取消信号不仅要关 HTTP还要清理后端正在跑的查询线程。我们曾经遇过用户点停止后服务端线程还在执行长 SQL把数据源的连接池占满。后来在 FastAPI 里用BackgroundTasks加一个取消事件查询循环每秒检查一次取消状态发现被取消就立刻断开数据库连接。排查这类问题时日志是关键。我会在服务端为每次 Agent 任务生成一个trace_id贯穿模型调用、SQL 执行、SSE 推送全流程。前端报错时带上trace_id后端就能把整个链路的日志拉出来。没有这个机制流式任务一断你根本无从下手。6.2 SQL 生成的稳定性问题SQL 生成不稳定是 Data Agent 最大的真实痛点。模型可能因为一个字段名理解错或者多了一个空字符就生成废 SQL。我自己的实操经验是把“小样本”和“纠错重试”组合使用。再一个很有效的技巧是给模型提供详细的表注释和字段注释最好连罕见字段的示例值都给。模型对示例值的理解能力超出想象比如“模型不认识 channel 字段如果你给一个示例值 online它就能推测出这是渠道”。你可以用数据库的信息 schema 自动生成表结构注释再拼到系统 Prompt 里。为了控制 Token只把最近常用表放进去。如果表很多可以做一层“表选择器”先用 Embedding 把用户问题和表描述做向量检索选出 Top 5 张候选表再把这些表结构喂给模型。这一招大大降低了 SQL 生成难度。稳定性上线后还要做回归测试准备一个 SQL 测试集比如 50 条有代表性的人工标注问题每次改 Prompt 或者换模型都跑一遍。我见过的小团队通常不重视这个导致模型升级后某个查询突然大面积失败。有了回归测试至少能提前发现退化趋势。6.3 上下文长度与性能衰减上下文长度是 Data Agent 的多轮交互中一定会遇到的问题。对话历史如果一股脑全塞进 Prompt模型注意力会分散SQL 生成的准确性反而下降。我们把上下文拆成了短期和长期短期存最近三轮对话原文长期存每一轮的关键信息摘要。摘要由模型生成比如“前一轮查询了华东区 2024 年订单总销售额结果按省份展示用户正在追问环比”。性能衰减还表现在 Agent 的“思考”越来越长。有些模型在上下文长时会输出大量无关的解释导致 Token 浪费和延迟上升。处理办法是做输出约束要求模型只输出 JSON字段里禁止出现解释性文本。其实这招能卡掉非常多废话。前端渲染时JSON 里的thought字段可以折叠显示用户需要看再看。最后一个心得流式输出的首字延迟而不是总时间决定了用户感知的流畅度。我们调优时发现如果模型首字返回太慢用户会觉得系统卡了。解决方法是把“任务状态更新”排在模型文本前面推。比如用户发问后立即推一个planning事件显示“正在分析语义”然后再推 token 流。虽然总等待时间没变但用户的体验会好很多。Data Agent 是一个实践驱动的方向光看架构图不够真正踩过一遍坑才有体感。上面这些坑只是我们调研和对比中的一部分。我很建议你拿着这些技术栈清单去翻两三个开源项目跑通一条 Text-to-SQL 链路再对比你实际业务里最痛的 10 个查询需求判断哪些架构组件是必须的。市场调研报告终归是别人的地图自己走一趟才知道哪里该补路、哪里该拐弯。