过去两个月，我把市面上能拿到的 Data Agent 相关产品和开源方案都翻了一遍。起因很实际：我们团队在给客户做数据分析平台重构，业务方反复问“能不能让系统自己把报表跑了”，“能不能让它自动查一下订单为什么跌了”，传统的 BI 工具解决不了这类开放式问题，而内部随手用大模型 API 拼的问答机器人又太不可控。于是 Data Agent 就成了绕不开的话题。
先说清楚我理解的 Data Agent，再展开调研内容。我这里用的是一个比较务实的定义：以大语言模型为推理核心，能够主动调用数据读写接口，完成多步骤数据任务（取数、清洗、加工、分析、产出结论）的智能体。它不是一个套着聊天框的 SQL 查询工具，也不是单纯生成一段分析文字的 Chatbot。它需要对数据基础设施负责，对执行过程负责，最终交付可验证的结果。
这篇调研不是给你列一堆产品名字就完事。我重点聊三件事：市场上有哪几类 Data Agent 产品形态，每类技术栈的核心构成是什么，以及技术架构上的分岔点在哪里。最后给我自己做选型时使用的评估思路，这套思路目前已经用在客户项目里，筛选过三轮产品，相对完整。
如果你也在做数据分析平台、指标平台或者企业内部 AI 助理，又刚好卡在“Demo 能跑通但生产环境不敢上”的阶段，这篇应该能帮你减少一些试错成本。
1. 为什么现在都在提 Data Agent：调研动因与概念边界
1.1 需求端的变化：从“人找数”到“数找人”
过去几年企业的数据分析流程基本是：业务提需求，数据团队写 SQL，验证口径，做成图表，再解释结论。这个流程的最大瓶颈不在 SQL 难写，而在需求沟通和口径确认。一个报表需求平均要 3 到 5 天，其中真正写 SQL 的时间不到半天，剩下的时间全部消耗在“业务说的指标和数据团队理解的指标是不是同一个”这件事上。
于是出现了两个方向的产品：一是指标平台，把口径和指标定义固化下来；二是 BI 自助分析，让业务自己拖拽图表。这两个方向的共同点，是仍然要求人主动操作。业务方还是得知道“我要看什么”，“从哪里看”，甚至还要理解“这个按钮点了之后会发生什么”。
Data Agent 要解决的是更往上一层的问题：能不能让我用自然语言描述目标，它自己完成“理解口径 -> 生成查询 -> 执行取数 -> 分析结果 -> 输出报告”这条链路。这个需求在业务端确实存在，而且越来越强。我们调研的一家零售客户的运营负责人原话是：“我不想知道 SQL 怎么写，也不想记住指标口径在哪页文档里，我就想知道华东区这个月的退货率为什么涨了。”
这句话基本概括了 Data Agent 的核心场景：把分析过程中机械的部分自动化，把经验型的判断交给模型推理能力去覆盖。
1.2 Data Agent 与 Chatbot、Copilot 的差异
调研过程中我发现很多团队把 Data Agent 和 Chatbot 混为一谈，这是最大的误区。三者的差异非常明显：
Chatbot 的核心是“对话”。它的目标是把答案组织成通顺的文本，至于答案背后调没调数据、调的数据对不对，不是首要责任。传统问答机器人连数据库都不必连，靠知识库检索就能跑。
Copilot 的核心是“辅助”。它嵌在某个应用环境里，比如代码 IDE、Excel 或者 BI 报表工具，根据用户当前操作的上下文给出建议和补全。它不主动替你完成一个跨模块的任务，而是你做一步、它帮一步。
Data Agent 的核心是“目标执行”。给它一个目标，它自己拆解，自己选工具，自己调用，自己校验结果。它的输出未必是一段漂亮的文字，可能是：一张表、一份 CSV、一个更新后的看板，甚至是一次数据质量检查报告。
我常用一个类比：Chatbot 是前台接线员，给你指路；Copilot 是副驾驶，提醒你操作；Data Agent 是外包项目的项目经理，接了需求之后自己协调资源把活干完，中途只需要你验收结果。这个区别会在架构设计上产生完全不同的一系列需求，尤其是权限控制和异常处理。
1.3 调研样本说明
这次调研覆盖了三类样本。第一类是商业平台型产品，包括几家云厂商推出的数据问答服务、传统 BI 厂商的 Agent 化模块，以及指标平台衍生出来的智能分析能力。第二类是开源框架，包括通用 Agent 框架（LangChain、LlamaIndex、Dify、CrewAI、AutoGen）以及专门面向数据场景的：Vanna.AI、Dataherald 等 Text-to-SQL 项目。第三类是企业自研案例，主要是我们接触过的几家客户在 LangGraph 或自研编排器上搭的多 Agent 系统。
调研的方式不是看官网文档，而是每个产品至少跑一个真实查询场景，用同一套业务问题和同一份测试数据集去试。有些商业产品在演示环境里表现很好，放到我们自己构造的复杂 schema 上就明显吃力。这一点我会在后面选型框架里展开。
2. 市场产品横向分层：平台型、框架型与嵌入组件型三条路线
2.1 平台型：全托管、以界面交付为主
平台型产品是目前市场上数量最多、宣传最猛的一类。它们通常包含：大模型接入能力、Agent 编排后台、数据源连接器、可视化对话框、权限管理和审计日志。用户上手路径基本都是“先在控制台配好数据库连接，然后拖几个组件，填一下提示词，发布一个应用”。
这类产品的优点是开箱即用，对业务团队非常友好。尤其适合两类情况：第一，企业没有自研 AI 工程能力，想快速验证 Data Agent 在内部场景是否可行；第二，数据量不大（几千到几百万行），查询以单表聚合和简单多表 join 为主。
但平台型的短板在实际使用中也很明显。一是定制能力受限，你只能在平台预设的插件体系里做扩展，如果数据源比较特殊（比如自研 MPP 引擎、某国产数据库的方言），可能等很久都不支持。二是敏感数据的合规问题，很多 SaaS 型平台要求数据经过它的云端服务，这在金融、政务、医疗行业直接卡死。三是黑盒问题，Agent 的执行链路、提示词策略、模型选择都掌握在平台手里，出了错误只能提工单，没法自己排查。
调研中我遇到一个印象很深的案例：某企业采购了一个头部 BI 厂商的 Data Agent 模块，用它做销售看板的自然语言问答。前期演示很顺利，但实际把几百张表的元数据同步进去之后，回答准确率从演示时的 80% 出头掉到不到 50%。厂商的解决方案是让用户“优化提问方式”或者“给表增加描述信息”，但涉及根本的文本转 SQL 能力瓶颈，平台并没有透出有效的调整手段。
2.2 框架型：开源生态、代码控制，灵活同时复杂度前移
框架型产品以开源 SDK 为主，典型代表包括 LangChain/LangGraph、LlamaIndex、Dify（偏应用平台但可自托管）、CrewAI 和 AutoGen。这些框架的价值在于：它把 Agent 的基本要素（模型接入、工具调用、上下文管理、Agent 循环）封装成了可编程的组件，开发者可以自己决定架构形态。
数据领域的开源框架还有专门的 Text-to-SQL 方向，比如 Vanna.AI 和 Dataherald。它们做的事比通用框架更垂直：通过训练/提示词把用户问题转成 SQL，再执行并返回结果。这类项目通常还会内置“反馈学习”机制，比如人工纠正过的 SQL 会被沉淀成训练样本。
框架型的最大优势是灵活性和可演进性。你可以随时替换底层模型（从闭源 API 换成私有化部署的开源模型），可以自定义任何工具（包括调用内部数据血缘系统的 API），可以完全掌控数据流向，不依赖外部服务。
代价是复杂度前移。你需要自己解决的问题包括：Agent 编排逻辑的异常处理、多轮对话中的状态保存、工具调用的可观测性、权限与审计、模型成本控制、以及最核心的——回归评测体系。说白了，框架给了你自由度，也把工程责任全部交给了你的团队。
我用一个典型的 LangGraph 场景说明这种复杂度。假设你要做一个支持多渠道查询的数据 Agent，LangGraph 可以把“路由到 SQL 引擎”、“调用报表 API”、“生成文本总结”三个节点串成图。但你需要自己定义节点间传递的数据结构、失败重试策略、以及每个节点超时之后的回落动作。这些细节在一个简单 Demo 里无所谓，生产环境就是另一回事。我见过不止一个团队在 Demo 阶段很兴奋，上线两周后却被各种边缘 case 拖垮。
2.3 嵌入组件型：不直接面向用户，但提供关键数据能力
嵌入组件型的产品我没有把它们算作完整的 Data Agent，但它们在实际架构里必不可少。这类组件包括：语义层/指标层中间件（比如 Cube、dbt MetricFlow，或者自研的指标注册中心）、向量数据库（Milvus、pgvector、Qdrant、Chroma）、数据虚拟化网关（如 Trino、Doris 的外表能力），以及各种 RAG 中间件和重排（Rerank）服务。
它们在 Data Agent 架构里扮演的角色是“数据能力的解耦层”。比如语义层：它把指标口径（例如“销售额=已支付订单金额-退款金额-取消金额”）固化成可被 Agent 调用的 API，而不是希望大模型通过读文档记住口径。再比如向量库：它用于存放历史问答案例、数据字典解释、权限规则描述，帮助 Agent 在生成查询之前先找到“该怎么做”的参考。
很多数据 Agent 产品最后比拼的不是大模型推理能力，而是这些支撑组件做得好不好。一个老辣的 Agent 框架会主动调用语义层 API 获取指标定义，再生成 SQL；一个粗放的做法是把几百页的数据字典文档塞进上下文里让模型自己翻。后者在表少的时候还行，表一多必然崩溃。
2.4 分层视角下的选型倾向
把这三类放在一起看，我的结论是：它们不是互斥关系，更像是不同交付层次。平台型适合“我要快速用起来”，框架型适合“我要长期掌控”，嵌入组件型适合“我要解决某个特定瓶颈”。
如果企业有 5 人以上的 AI 工程团队，并且数据环境复杂（多引擎、多租户、强治理要求），我建议不要纠结平台型产品，直接把聚焦点放在框架 + 嵌入组件的组合上。如果企业只有 1 到 2 个数据工程师，且业务紧迫性很强，那么平台型先跑通流程、同时留出走框架型迁移的空间，是更现实的路径。
3. 技术栈全景拆解：从 LLM 选型到结构化数据访问的细节
3.1 推理层：大模型选型不是拍脑袋
调研过程中，几乎每个产品都声称支持“业界最强模型”。但实际拆分下来，大模型选型需要考虑四个维度：推理能力、稳定性、成本、以及部署约束。
推理能力决定了 Agent 处理复杂多跳问题的上限。比如“对比华东和华南两个区域近两个季度的退货率差异，并分析差异是否主要由新品贡献”，这种问题需要模型在规划阶段就把时间维、区域维、指标维和归因逻辑拆开。实测下来，当前闭源第一梯队模型（GPT-4 级别、Claude 类系，以及国内同档模型如 Qwen-Max 或 GLM 的旗舰版本）在任务规划和工具选择的稳定性上明显高于中型模型。
稳定性则体现在两个地方：一是生成结果的格式稳定性，尤其输出 JSON 会不会偶尔多一个逗号导致解析失败；二是行为稳定性，同样的 prompt 和多步轨迹，下一次执行会不会选择完全不同的工具路径。这两个问题在中小模型上非常突出，这也是为什么很多生产级项目宁可花更高的 token 成本也要用旗舰模型。
成本和部署约束放在一起考虑。如果数据敏感，模型必须私有化部署，那么你就得从可私有化的开源模型里选（比如 Llama-3 类、Qwen 类、DeepSeek 类）。此时要接受一个现实：私有化模型在复杂工具调用上的准确率普遍比闭源旗舰低一截。应对方法通常是增加验证环节，比如引入一个更小的校验模型，或者做多轮自检，用额外的推理成本换准确率。
我推荐的做法是“分级路由”：简单查询（单表聚合）走低成本中型模型，复杂分析走旗舰模型，由前置的路由器根据意图复杂度分配。这样能在成本和准确率之间取得比较好的平衡。
3.2 结构化数据访问：Text-to-SQL 与语义层的双轮驱动
Data Agent 和数据仓库之间最核心的技术环节就是 Text-to-SQL。这个方向看起来技术成熟，但实际坑很多，我把主要技术链路拆一下。
第一步是 schema 上下文构建。LLM 并不是天生知道你的库长什么样，你需要把表的 DDL、字段说明、表关系、以及枚举值的含义提供给模型。这里有个关键问题：如果库表有几百张，每个表的字段几十个，把所有 DDL 都塞进上下文是不现实的，token 不够，模型也会注意力涣散。生产级方案通常采用“schema 裁剪”：通过关键词匹配、向量检索或者预定义的业务主题标签，把可能相关的表和字段召回，再拼接成精简后的 schema 上下文。
第二步是 SQL 生成与自校验。模型拿到问题、schema 上下文和少量示例（few-shot）后生成 SQL。好的系统会做一次“预执行校验”，比如检查限制条件（生成的 SQL 是否包含必要的过滤条件、是否命中了不存在的字段），再决定是否直接交给数据库执行。
第三步是执行与错误恢复。SQL 报错是常态——列名不存在、类型不匹配、语法不兼容。Agent 需要把错误信息回传、结合错误内容修正 SQL。实测下来，具备“错误自修复”能力的系统在复杂 schema 上的成功率能提高 10 到 15 个点。这也意味着你选择的数据库方言越常见，模型见过的样本越多，修复效果越好。
但 Text-to-SQL 只能解决“怎么写 SQL”的问题，解决不了“口径是否正确”的问题。这就是语义层出现的原因。语义层不是数据库引擎，而是一个中间表达层，它把“销售额”“客单价”“GMV”这些指标绑定到确定的计算逻辑和维度定义上。Agent 的正确工作方式是：先通过语义层的 API 找到目标指标，拿到指标的计算逻辑定义，再把它映射成具体的 SQL 片段。
举一个我们实测翻车的例子。某个测试数据集里有“订单金额”“退款金额”“运费”三个字段，业务上“销售额”的口径是“订单金额-退款金额（不含运费）”。在没有语义层的情况下，模型直接生成SUM(order_amount) - SUM(refund_amount)作为销售额。看起来没问题，但它把运费也减掉了，和财务口径不一致。这个错误在 Text-to-SQL 评测里根本发现不了，因为 SQL 语法正确、表字段正确，但业务语义错了。
所以我的结论是：Data Agent 的准确率上限不是由 LLM 决定的，而是由“数据基础设施是否提供了语义级抽象”决定的。没有语义层的 Agent 就像让一个聪明实习生在不了解公司流程的情况下做账，聪明是真聪明，错也是真会错。
3.3 记忆与上下文管理：多轮任务的关键支撑
Data Agent 说到底是“多轮交互中执行多步骤任务”，所以记忆（Memory）设计直接影响体验和成本。我把它拆成三层：
会话短期记忆：保存当次对话中用户设置的条件和数据筛选状态。比如用户先说“看华东区的数据”，下一句“加上华南区一起对比”，系统需要理解这是在修改筛选条件，而不是新建一个查询。大部分框架用消息历史实现这一层，但要注意控制历史长度，避免上下文越滚越长、成本飙升。
任务长期记忆：跨会话沉淀用户偏好和历史高频问题。比如某客户总看“上月的退货率”，Agent 可以在新会话里主动询问“还是看退货率吗”。长期记忆一般用向量库存储历史交互摘要，检索相关上下文注入到系统提示词中。
结果缓存记忆：同一个查询（哈希一致的 prompt + 参数）在短期内不重复执行，直接返回缓存结果。这对高频看板查询非常有用，能省下大量调用成本和数据库压力。实现上需要设计合理的缓存键（去掉时间类变量）和过期策略（比如 5 分钟 TTL）。
记忆设计中最大的坑是“过度记忆”。有次我们测试一个开源框架，它在多轮之后把上一轮已经过滤掉的维度条件带到了新问题里，导致结果不符合预期。原因是框架把历史工具调用结果全塞回了上下文，没有区分“全局条件”和“当次条件”。生产系统里，记忆层应该有自己的结构化状态机，而不是依赖模型的隐式理解。
3.4 工具调用框架：把数据能力封装成确定性的 API
Agent 的行动能力通过工具（Function Calling）实现。一个设计良好的工具层，意味着 Agent 面对的是一组定义清晰的 API，而不是直接面对数据库连接串或 Python 执行环境。
工具定义的核心是 JSON Schema，它描述了工具的名字、功能、输入参数类型、必填项和示例。下图是一个典型的只读 SQL 查询工具定义结构：
{ "name": "execute_readonly_sql", "description": "对数据仓库执行只读 SQL 查询，返回结果集。仅允许 SELECT 语句，禁止任何写操作，涉及行级权限会自动过滤。", "parameters": { "type": "object", "properties": { "sql": { "type": "string", "description": "完整 SELECT SQL，必须以 SELECT 开头，不支持多语句。" }, "limit": { "type": "integer", "description": "返回最大行数，默认 100，最大值 1000。" } }, "required": ["sql"] } }工具层的工程要点我在实际使用中总结了几个。第一，每个工具都必须有明确的边界描述，不能写上模糊词；模型很容易在工具描述含糊时选择错误工具。第二，工具要有超时、限流和幂等控制；比如报表导出工具如果执行到一半失败，重复调用会不会产生重复数据。第三，工具的返回结果要考虑大小上限；一个查询返回 100 万行的结果集不能让 Agent 直接吞进上下文，通常采用“返回摘要统计 + 分页抽样”的策略。
还有一个容易被忽略的点：工具参数里的“枚举值”。比如状态字段只有 [待支付、已支付、已退款、已关闭] 四个值，你最好在工具的 description 里写出来，并提示模型如果用户用了词表外的词（比如“失败的订单”），需要先转换成枚举值。这一步能明显减少 SQL 过滤条件的错误。
4. 技术架构模式之争：单 Agent 循环、多 Agent 编排和分层架构
4.1 单 Agent 的自主循环：简单任务的首选
单 Agent 模式是最基础的架构，核心是 ReAct 循环：思考（Thought）-> 动作（Action）-> 观察（Observation），如此往复直到任务完成。在 Data Agent 场景里，一个典型的单 Agent 执行流程是这样的：
- 用户输入目标，Agent 识别意图、检索相关上下文。
- Agent 规划：决定第一步是查语义层获取指标口径，还是直接生成 SQL。
- Agent 调用工具（执行 SQL、调用 API）。
- 系统返回结果摘要，Agent 判断结果是否满足用户需求。
- 如果不满足，回到第 2 步；如果满足，生成最终答案。
这种模式的优点是好实现、好追踪、token 开销相对可控。它对数据分析这种“路径有限”的任务其实够用，因为大部分分析场景无非就是筛选、聚合、对比、排序、归因，步骤之间线性为主。
缺点也很明显：单 Agent 在一个上下文里承担了规划、生成、纠错、总结多重职责，一旦任务链路拉长，容易出现“步骤漂移”。比如用户的问题是“先看总体，再看各品类，最后聚焦到退货率最高的单品”，Agent 可能在完成第二步之后忘了最初还有一个大的时间范围限定。针对这个问题的工程手段是维护一个显式的“任务状态记忆”，把用户的所有约束条件结构化存储，每步生成时都注入当前状态，而不是完全依赖模型记住上下文。
4.2 多 Agent 的项目组模式：复杂任务的放大器
多 Agent 架构，尤其是 Supervisor-Workers（主管-工人）模式，在 Data Agent 市场调研里被大量提及。它的核心思路是：一个主管 Agent 负责理解用户需求、拆解任务、分配子任务；多个 Worker Agent 并行执行各自子任务（查销售、查库存、查竞品数据）；再有一个汇总 Agent（或主管兼任）整合结果。
听起来很合理，但实测下来最容易踩的坑是“为多而对”。我曾用一个 5 人规模的多 Agent 系统跑一个本来单 Agent 就能搞定的报表查询，结果端到端延迟从 8 秒涨到 40 秒，token 消耗涨了 6 倍，准确率并没有提升。原因是任务之间本不需要并行，主管和 Worker 之间每轮都要同步上下文，消息传输和重新理解造成了大量开销。
我的判断是：多 Agent 架构适合两种场景。第一种是“数据源割裂”，比如要同时查业务数据库、CRM API 和日志系统，每个 Worker 对应一个数据源，独立获取数据再由主管合并，这种并行确实能加速。第二种是“需要不同视角”，比如一个 Worker 做定量分析、一个 Worker 做定性归因、再有一个 Worker 做反向验证，最终汇总。
实施多 Agent 时，最重要的工程决策是 Agent 间通信协议。不要让 Worker Agent 返回大段自然语言文本，而要定义结构化输出：状态码、数据摘要、置信度、异常说明。主管 Agent 基于结构化结果决定下一步，而不是再让 LLM 去阅读并理解一大段可能含幻觉的文本。
4.3 分层架构：把思考、执行和数据访问拆开
在多 Agent 和单 Agent 之外，还有一条更稳的路线：分层架构。它不关心 Agent 数量单体还是群体，而是强调“职责边界”必须分离。我推荐一个三层模型：
规划层（Planning Layer）：负责理解用户意图、检索上下文、生成任务计划。它可以是一个 Agent，也可以是一组 Agent，核心是“做决策”。
执行层（Execution Layer）：负责调用具体工具、执行 SQL、调用 API、处理文件。这层尽量做成确定性的服务，不依赖 LLM 推理，而是精确执行参数化指令。
数据接入层（Data Access Layer）：针对不同数据源封装统一的访问接口，包括权限校验、数据脱敏、查询路由。任何数据访问都必须经过这层，禁止 Agent 直接操作原始数据连接。
这个分层带来的直接好处是安全性和可替换性。安全性上，权限检查可以强制放在执行层和数据接入层，不依赖 Agent 的自觉。可替换性上，你可以在不改变执行逻辑的前提下，把规划层的模型从闭源 API 换成私有化开源模型，只影响规划质量，不影响数据链路稳定性。
我在调研不少金融行业落地案例时发现，最终能过合规评审的架构基本都是分层架构。合规团队最反感的是“Agent 什么都能干”，最放心的是“Agent 只能通过受控工具做受控操作，且全程可审计”。
4.4 用 Archimate 视角看 Data Agent 内部组件关系
调研技术架构时，我用 Archimate 做了一次内部元素关系梳理。很多技术团队不熟悉 Archimate，我用一张表格把它在 Data Agent 架构里的核心关系表达出来。Archimate 分业务层、应用层和技术层，对应到 Data Agent 场景：
| 层级 | 元素 | 主要职责 | | 业务层 | 业务用户、数据分析师 | 提出分析目标，消费分析结果 | | 业务层 → 应用层 | 交互服务 | 门户页面 / 自然语言入口，承接用户请求 | | 应用层 | Agent 编排组件 | 理解意图、规划任务、路由子任务 | | 应用层 | Worker Agent 服务 | 执行具体查询、生成 SQL、调用语义层 | | 应用层 | 语义层服务 | 统一指标口径、提供元数据和权限映射 | | 应用层 → 技术层 | 数据网关服务 | 封装数据库连接、执行只读查询、记录审计日志 | | 技术层 | 数据仓库节点、对象存储、消息队列 | 数据存储与系统间通信 |
从这套关系能引出两个结论。第一，业务用户不直接触碰数据，所有交互通过 Agent 编排组件；这意味着“用户体验”和“数据访问”是完全解耦的两段，前端可以随便改，不影响数据链路。第二，语义层是承上启下的关键枢纽：上层 Agent 依赖它理解口径，下层数据网关依赖它做权限和数据范围过滤。如果把整个系统比作一台车，语义层就是变速箱，它决定上层动力（Agent 智能）能不能正确传递到下层轮子（真实数据）。
4.5 三种架构的取舍对照
我把三种架构放一个对比里，方便你做初步判断：
| 维度 | 单 Agent 自主循环 | 多 Agent 编排 | 分层架构 | | 实现难度 | 低 | 高 | 中 | | 并行能力 | 无 | 强 | 取决于执行层设计 | | Token 成本 | 最低 | 最高 | 中 | | 可解释性 | 较好 | 较难 | 好 | | 安全控制 | 弱（依赖自身判断） | 中 | 强（强制网关） | | 最适合场景 | 单数据源、线性查询 | 多数据源并行获取 | 企业生产环境、强合规场景 |
我的观点是：不要把它当成三选一的互斥题。最稳的组合是“分层架构 + 单 Agent 主流程”，在多数据源并行需求出现时，再局部引入 Supervisor-Workers 模式。先保证链路确定性，再为特殊场景增加弹性。
5. 企业级选型的五维评估框架：准确率、安全、成本、集成与运维
5.1 准确率：用测试集说话，不凭演示截图
选型评估里最容易犯的错误是“看演示”。厂商准备的数据集、问题集和业务 schema 都是精心挑选的，很多问题在演示环境里本来就能答对。我建议任何严肃选型都要建立自己的回归测试集，至少准备 20 到 30 个真实业务问题，覆盖：简单查询（单表聚合）、中等复杂（多表 join）、高复杂（多步条件 + 时间窗口）、以及边界问题（带口径歧义的问题）。
评估时不仅要看最终答案对不对，还要看 SQL 对不对。有时候答案数字碰巧对，但 SQL 的过滤条件和业务意图并不一致，这种属于“假阳性”，会在数据集变化后暴雷。我给客户做评估时，会同时记录四个指标：端到端准确率、SQL 正确率、首次执行成功率（不需要模型自动修复）、以及平均执行轮数（轮数越多说明模型越犹豫，成本和延迟越高）。
5.2 安全边界：权限模型是最难补的课
Data Agent 的安全问题比传统 BI 更复杂，因为它多了一个“模型可能猜”的环节。传统 BI 的权限由报表和数据集承载，用户看得到就是看得到，看不到就是看不到。Data Agent 里，模型可能在生成 SQL 时把权限外的字段也写进查询，虽然执行层面可以拦截，但用户体验会变得很怪：用户问了一个正常问题，系统回答“无权限查询”。
正确的安全设计是三层联动。第一层是数据源权限：Agent 使用的数据库账号必须是只读账号，且最好配置行级安全策略（比如区域销售经理只能查自己区域的数据）。第二层是语义层权限：语义层的指标和维度也按角色过滤，用户看不到的指标不进上下文，模型根本不知道有这个东西，这比事后拦截强得多。第三层是审计：每次 Agent 执行了什么 SQL、调用了什么工具、返回了多少行数据，必须全部记录，而且审计日志要不能被 Agent 自身篡改。
我在调研中发现，有些团队为了图方便，直接给 Agent 配了一个 DBA 权限的数据库账号，理由是“Agent 需要看到所有表才能回答问题”。这个做法非常危险。正确的做法是让 Agent 用最小权限账号 + 元数据层完整描述，二者并不矛盾：Agent 可以知道有哪些表，但实际数据访问被账号权限限定住。
5.3 成本与延迟：不要忽略 token 放量后的账单
Data Agent 的成本结构和传统软件完全不同，它的大部分成本是变动的，跟着调用量走。我在评估时用了一个简单的成本模型：
单次查询成本 ≈ 输入 token 数 × 单价 + 输出 token 数 × 单价 + 数据库查询资源消耗。
输入 token 数往往被低估。一次复杂查询可能需要：系统提示词（2K-4K token）、schema 上下文（3K-10K token）、历史对话（2K-6K token）、工具返回结果（2K-8K token）。加起来轻松超过 1 万 token，如果再算上错误重试（一次失败重新生成可能再花 5000 token），一个分析问题的真实成本可能是你预先估计的 3 到 5 倍。
控制成本的方法包括：分级路由模型、缓存复用、以及最关键的结果摘要策略——不要让 Agent 把所有查询结果全文读入上下文再总结，而是让执行层先返回聚合统计和抽样数据，Agent 只处理精简结果。这个策略能把单次查询 token 消耗降低 40% 以上，代价是需要设计好“摘要模板”，避免丢失关键信息。
5.4 集成与可迁移性：开放性比界面美观重要
选型时还要特别关注产品的集成能力，包括 API 可用性、Webhook 支持、与现有 SSO/权限系统的对接，以及数据源连接器是否覆盖你实际使用的引擎（不只是常见的 MySQL、PostgreSQL，还有 Doris、ClickHouse、Hive、Trino 等）。
我见过一个失败案例：某团队选了一个界面很好看的数据 Agent 产品，满足了所有业务方对“科技感”的期待，但落地时发现它不支持对接公司的自研权限系统，也没法把 Agent 的查询记录同步到已有的审计平台，最终被迫放弃。
评估可迁移性的一个技巧是问一个问题：“如果这个产品明天不维护了，我们能不能在不重写业务逻辑的情况下换掉它？”如果答案是“很难”，说明系统的集成绑定太深，不建议选。分层架构在这里再次体现出优势：只要交互层通过标准 API 与编排层通信，换掉某一个组件的影响范围就是可控的。
5.5 运维可观测性：Agent 的黑盒问题必须正面面对
传统系统的运维看指标（CPU、内存、错误率），Agent 系统的运维看轨迹。一个生产级 Data Agent 必须支持全链路追踪：用户问题 -> 规划结果 -> 工具调用序列 -> SQL 执行的原始语句 -> 返回摘要 -> 最终答案，每一步都要可回放。模型给大家的感觉就是“黑盒”，你无法完全理解它为什么在一个场景里选择这样的步骤，因此至少要让链路本身敞开。
选型时我会重点考察产品的事件日志详细程度。好的产品会记录每次工具调用的输入输出全文（至少保留 SQL 文本），并支持按会话维度查询 token 消耗和耗时明细。不记录详细事件日志的产品，在生产环境出问题时你连排查的抓手都没有。
测试环境还有一个运维要求：模型版本的可控性。生产系统最忌讳“模型的 prompt 没变，但回答质量变了”——这通常是因为厂商悄悄更新了模型版本。可控的 Agent 平台应当允许你锁定模型版本，或至少提供清晰的版本变更通知。
5.6 综合评估矩阵：把五维权重落实到打分
五维评估不能平权，不同企业的权重差异很大。我给一个参考权重，这是我做客户选型时用得比较多的一组：
| 评估维度 | 参考权重 | 核心考察点 | | 准确率 | 30% | 回归测试集上的端到端准确率、SQL 正确率、执行轮数 | | 安全边界 | 25% | 最小权限支持、行级权限、语义层过滤、审计日志 | | 成本与延迟 | 15% | 单次查询 token 成本、端到端时延、缓存能力 | | 集成可迁移性 | 20% | API 开放性、数据源覆盖率、SSO 对接、替换成本 | | 运维可观测性 | 10% | 链路追踪、日志细节、模型版本可控性 |
打分方式是：每个维度先确定你公司的底线（比如“必须支持私有化部署”“必须支持行级权限”），低于底线的直接淘汰，不进入打分环节。底线之上再按分数排序，总分 = 各维度得分 × 权重。这样做的原因是防止被某个维度的亮点带偏，比如界面特别好看但安全不达标的产品直接出局。
6. 落地经验：从调研到 POC 的三次踩坑和一套可复用的推进路径
6.1 踩坑一：口径问题不能靠提示词解决
我们第一次做 Data Agent POC 时，一位同事写了长达 3000 字的提示词，把所有指标定义、字段解释、业务规则全塞进去。第一天效果很好，因为测试问题就那几个，模型“背答案”就够用了；换一批新问题之后立刻翻车，准确率从 85% 掉到 35%。核心原因是提示词里的口径描述是静态文本，模型在生成 SQL 时并不能确定该把哪个业务概念映射到哪个字段。
后来我们把口径管理从提示词里搬出来，做成了独立的语义层服务。Agent 在生成 SQL 之前，先调用语义层 API 查询指标定义，拿到结构化的口径说明和实际字段映射，再生成 SQL。改造之后准确率稳定在 74% 到 78% 之间（剩余错误主要是复杂时间窗口和罕见业务逻辑），更重要的是不再依赖提示词碰运气。
这里的经验是：如果团队同时做指标平台或数据治理，一定要把 Data Agent 和指标层打通，否则 Agent 永远只是个 Demo 玩具。
6.2 踩坑二：多 Agent 的冲动要克制
另一个团队在 POC 时提出要上多 Agent 架构，理由是“我们有 5 个数据源，需要 5 个 Agent 并行”。我给他们的建议是先做一个简化版：一个主管 + 一个数据查询 Agent，让主管负责路由，但把多数据源合并的逻辑写在执行层里（用一个数据网关同时连多个源，返回统一结构），而不是把每个数据源都做成一个独立 Agent。
对比结果很明显：简化版单次查询耗时 12 秒，token 成本 1 个单位；多 Agent 版耗时 60 秒，token 成本 5 个单位，准确率没有显著差异。多源的场景其实需要的是数据网关，而不是多 Agent。记住：并行 Agent 解决的是“需要独立推理路径”的问题，不是“需要连接多个数据源”的问题。后者用连接器解决。
6.3 踩坑三：忘记给 Agent 准备“元数据同步”流程
Data Agent 对元数据的依赖远比传统 BI 强。传统 BI 的表结构变了，报表可能会报错，但至少错误信息是明确的；Data Agent 的 schema 变了，它可能生成一个针对旧字段的 SQL，执行时报错后尝试修复，一旦修复失败，表现为“答非所问”，用户很难理解原因。
我们第三次踩坑就是上线一周后，一张大表新增了三个字段，表注释和字段注释都没同步到 Agent 的元数据缓存里。结果用户问“新增的会员标签字段是什么含义”，Agent 一脸懵。解决办法是做一个定时同步任务：每天从数仓的元数据服务拉取 DDL 变更，更新到 Agent 的 schema 缓存和向量索引中，并记录版本号，遇到版本不一致时自动重新加载。别小看这个环节，它是最容易在 POC 转生产时被遗漏的。
6.4 爬坑的最终建议
结合三轮调研和 I 八个月的客户落地经验，我给一份可以照做的推进路径。不要从 100 个场景开始，选 3 个最痛、最稳定的数据场景（比如“销售日报分析”“库存异常预警”“客户流失归因”），构建回归测试集，选一个开源框架（LangGraph 或 Dify 自托管）加一个语义层中间件，用一个只读数据网关把权限边界卡死。先跑单 Agent + 分层架构的版本，跑通后再按需扩展多 Agent。
数据集要控制在 50 个问题以内，但每个问题都要带“标准答案 SQL”。上线前至少连续跑两周回归，记录每一轮的准确率和错误类型分布。把错误分成四类（SQL 语法错误、口径错误、规划错误、工具选择错误），按比例决定下一步优化方向。常见的情况是口径错误占比最高，这时候不要加大模型，先去把语义层打磨好。
我自己最大的体会是：Data Agent 的难度不在 AI 部分，而在数据治理和数据接口这些几十年前就存在的基建问题上。大模型只是把问题集中暴露了出来，谁的基础设施承载能力越强，谁就能更快把 Agent 从“好玩”变成“好用”。如果你的团队现在还在为元数据混乱、口径不清和不规范的 SQL 访问入口发愁，那就不急着上 Agent，先把这层地基修好，Agent 值才会真正体现出来。
