从 Tool Calling 到 Data Agent：企业数据智能体的生产化路径

返回资讯

数据见闻

2026年9月9日

从 Tool Calling 到 Data Agent，拆解企业数据智能体生产化落地路径

本文根据云器科技 AI 产品总监巴志欣在 AICon 深圳的主题分享整理。

当模型走进生产环境，问题才刚刚开始

把一个大模型接上几个工具，可以完成基础的数据分析。但当任务进入 ETL 开发和项目上线，问题就不再只是“能不能生成 SQL”，而是能否找到正确的数据、保持业务口径一致，并在长链路中稳定完成任务。

企业对 AI 的关注焦点亦在悄然迁移。早期的核心诉求在于"产品是否具备差异化能力";而历经多轮落地实践之后,关注点已转向"其可信度与可控性能否支撑规模化应用"——差异化能力不再构成准入门槛,可信与可控方为真正的分水岭。

云器科技 AI 产品总监巴志欣在 AICon 深圳的分享，讨论的正是这段从“能调用”走向“能交付”的过程。核心判断很明确：Data Agent 的竞争力，不在于比通用 Agent 更“全能”，而在于能否把数据语义、工程流程、安全边界和质量评估组织成一个可持续运行的闭环。

通用 Agent 与 Data Agent：差别不只是“会不会写 SQL”

如今，写代码、调 API、操作各类系统，已经成为通用 Agent 的基础能力。既然如此，数据领域为什么还需要专门的 Data Agent？关键不在于谁“更聪明”，而在于两者的产品定位不同。定位不同，面对的场景需求不同，产品演进的重点和策略也会随之分化。

从产品目标来看，前者关注的是完成工具调用：借助 Skill、MCP server、CLI 或 API 理解用户意图并操作外部系统；后者则聚焦数据领域，把数据平台能力做成产品的原生能力，进一步围绕数据语义、工程流程和结果交付展开。

但在数据工程场景中，模型生成了 SQL 或创建了任务，并不等于任务已经完成。数据工程还涉及业务口径、数据模型、任务依赖和上线安全；模型的幻觉率，也使“看起来完成”和“真的可以上线”之间存在差距。

具体到企业数据场景，这种定位差异会进一步落到工作环境和上下文上。Data Agent 面对的是数仓、湖仓、表、指标、报表、数据目录和权限，依赖的核心上下文包括 Schema、元数据、血缘、语义模型和业务口径。它要解决的是数据领域的全链路落地，而不只是一次工具调用。

PPT 中给出的例子是“昨天华东区 GMV 为什么下降”。对于这类问题，Data Agent 需要先找到正确的语义对象，再选择执行路径，并在过程中保持口径一致、权限可控、结果可验。通用 Agent 的重点是调用工具，Data Agent 的重点是围绕数据场景完成工作。

一个借工具做数据，一个为数据而生。

因此，Data Agent 的应用范围更窄，但在数据领域更专。分享中引用的 Databricks 评测页对 401 个真实数据任务进行了比较：数据原生的 Genie Code 任务准确率为 76.6%，单任务成本为 0.55 美元；对比的三个通用 Coding Agent 准确率分别为 72.1%、55.9% 和 56.1%，单任务成本分别为 1.09、0.91 和 1.16 美元。演讲借此说明，围绕明确的数据业务方向持续迭代 Agent 和工程能力，可以获得更好的任务完成效果和成本表现。

图 1：通用 Agent 与 Data Agent 差异

三次转向：从“调用工具”到“交付结果”

先让模型能做事

早期的做法是把数据平台能力封装为 MCP server 或 CLI，交给企业已有的通用模型调用。这个阶段的价值很直接：产品经理或业务人员不必掌握复杂 SQL，也能通过自然语言完成基础分析；数据平台也开始提供面向 Agent 的系统能力。

但数据工程不止是分析。对于 ETL 开发和项目上线，模型说“已经开发完成”“已经上线”，并不能直接证明结果可信；幻觉带来的不确定性，使第一阶段的结果无法直接用于生产。

再把 Agent 放进产品

第二阶段是把 Agent 内置到数据平台，在产品内搭建 Loop，结合第一阶段的工具运行。这样可以结合页面状态、权限和业务对象，在产品内形成闭环。

但新的问题也随之出现：数据工程任务并不是单点调用工具。以任务运维为例，拿到错误日志后，还要检查数据血缘、上游链路和执行日志，汇总信息后才能定位根因和解决方式。

最后回到真实用户故事

第三阶段不再从“模型还能调用什么工具”出发，而是从线上真实行为中寻找高频、完整的用户故事。分享提到，团队对上线后沉淀的上万条用户数据进行分类，最终聚焦三个场景：数据 ETL 开发、任务诊断和数据质量（DQC）。

这三个场景背后都有完整的用户故事，也是后续场景化迭代的重点。

图 2：Data Agent 的三阶段演进路线

真正上线前，必须回答四个问题

问题一：它理解的，真的是企业的业务吗？

简单问题往往会制造一种错觉：只要把 GMV 或销售额定义清楚，模型就能准确回答。但真实经营分析通常是“最近三个季度销售额上升、人员却下降的区域有哪些”这类复合问题。它不仅需要指标定义，还需要正确的维度、表关系、过滤条件和分析路径。仅靠 RAG 或大模型自由生成 SQL，难以保证每次都走对。

语义层还面临两个工程问题。第一，业务系统与数仓系统容易出现口径割裂：消费侧改了指标，生产链路却没有同步，最终看板、查询和模型分析各说各话。第二，语义创建本身就很复杂，需要探查表结构、分析维度关系、确认指标关联，再把业务话术沉淀成标准定义；当指标达到数百上千个，治理就不可能靠人工记忆完成。

云器的做法是把语义下沉到数仓原生体系中，以 Semantic View 作为与结构化表、非结构化 Volume 同等级的数据对象。指标口径、维度、行业黑话、场景化查询翻译以及相关关系，都成为可管理、可追踪的元数据，而不是只存在于某个 BI 工具或提示词里。这样，语义既能服务查数和经营分析，也能成为后续 ETL、RAG 或本体建模的底层依据。

图 3：Semantic View 将自然语言需求、业务口径和 Agent 执行连接起来

围绕 Semantic View，平台把语义的创建、度量优化、消费和血缘追踪放进同一套能力里：既能对接企业已有指标管理库，也能借助 Agent 从历史问答中提炼元数据；既能用评测发现语义缺口、补充行业术语和知识库，也能通过 API、CLI 或 MCP 对外提供统一查询能力。语义定义发生变化时，下游加工链路也可以被追踪到，减少逐个排查和同步的成本。

语义 Agent 本身也不能只靠一个大 Prompt 自由发挥。分享中总结了三层机制：基础层用场景 Skill 和结构化工具约束创建、查询与部署行为；理解层采用 Discovery-First，分析问题先寻找已有语义，再根据复杂度选择路径；验证层覆盖创建和查询两个环节，对潜在的星状关系等风险给出提示，并对查询结果做双向校验。

其中，双路径查询对应两类情况：问题简单、能够直接映射到已知指标和维度时，通过 Semantic View 查询；问题复杂时，先使用语义层中已有的指标、维度和关系信息，再生成 SQL；如果仍然找不到语义对象，则使用当前对话中的表信息、血缘关系和历史查询作为兜底。

问题二：一条很长的任务，怎样不走丢？

数据工程的上下文有几个特殊难题：工具返回的结果大小不可预测，一条探查 SQL 可能从几行变成十万行；完整 ETL 需要经历需求理解、语义沉淀、建模、节点选择和 Pipeline 设计，是天然的长链路对话；真实用户又不会严格为每个场景新建会话，数据探查和任务排错常常交错发生，信息很容易串线。

他们把解决方案拆成三层。

首先是输入控制：由规划 Agent 决定当前任务是探查、规划还是执行，再把工作路由给相应的子 Agent；探查、规划和执行彼此隔离，工具与 Skill 也按需加载。其次是运行时截断：对话窗口只保留有限的结果展示，超出部分写入对象存储，提供可下载的完整文件。最后是上下文压缩：先按轮次截断冗余工具调用；仍然超限时，保留最近两轮完整内容，把更早信息压缩为目标、动作、产物、决策和待办事项等摘要，最后才以强制截断兜底。

图 4：输入控制、运行时截断与上下文压缩共同管理长链路任务

问题三：怎样让 Agent 不会把生产环境弄坏？

生产数据场景的风险，不只来自权限配置，还来自 Agent 可以一次性执行大量写入、脚本或删除操作。模型幻觉可能影响线上表和任务；用户也可能因为误操作，把本来不该删除的对象交给模型批量处理。

因此，安全不能只写在提示词里。分享给出的三层防护是：第一层用沙箱隔离 Agent 的探查和规划，避免它直接影响生产数据；第二层由系统识别高风险行为并施加边界；第三层在工具层做硬拦截，高风险动作必须经过用户明确确认后才能执行。删除任务的示例说明了这一点：系统先识别风险并弹窗，用户确认后，底层工具还会再次拦截校验。

这一机制既拦截高风险操作，也保留了批量管理脏数据和测试任务的能力。演讲中提到，明确的防护机制提升了用户对 Agent 的信任度。

图 5：沙箱隔离、系统约束和工具拦截共同构成生产安全边界

问题四：上线之后，怎样知道它还可靠？

Agent 的质量不能靠一次 Demo 判断。分享中提到的可靠性方法是“前—中—后”闭环：上线前为每个功能建立测试数据集和 Golden Set，达到预设标准后再发布；上线中记录用户行为、工具调用、回答结果和 Token 消耗等全链路 Trace；上线后定期人工复盘真实错误，把遗漏的业务场景加入产品，把新话术和调用偏差反哺测试集。

演讲以“功能效果达到 90% 才上线”作为示例：上线前先为每个功能定义测试数据集，达到规范要求后再发布；上线后通过 Trace 追踪用户行为、工具调用准确性和 Token 消耗，再把真实错误案例纳入产品迭代和测试集。

两个场景，说明 Agent 交付的为什么是链路

场景一：数据链路开发

业务说“帮我看华东区上月复购率趋势”，表面上像一个 text-to-SQL 问题，实际上至少包含五步：先确认复购率定义和分析维度，再决定临时查询还是建设可复用模型；随后完成 SQL、Python 或逻辑节点开发，配置依赖和调度，最后交付可复用的数据资产。

Data Agent 要覆盖的正是这条链路。用户输入业务话术后，系统先沉淀标准化的需求文档，再将确认后的口径落到 Semantic View；接着按企业规范进行数仓建模，规划 Pipeline，最后完成上线。过去在沟通和会议中完成的业务信息，由此可以在产品内沉淀下来，形成有迹可循的过程。

图 6：数据链路开发覆盖需求理解、语义沉淀、数仓建模和 Pipeline 上线

场景二：从人工夜排到 Agent 自主诊断

夜间任务失败时，值班同学通常需要翻日志、查血缘、找上游任务，再对照运维知识判断根因。Data Agent 的诊断链路包括：自动收集任务日志和血缘信息，汇总相关执行上下文，到知识库中匹配解决方案，并先在沙箱中验证方案，确认可靠后再交给用户。

演讲分享的上线效果是，相关能力可以覆盖企业日常业务线约 70%—80% 的运维诊断场景。PPT 还展示了一个示例口径：平均定位时长从 45 分钟降到 8 分钟，一次性定位准确率达到 85% 以上，夜间人工介入下降 60%。这些数字应理解为演讲中的案例/示例数据，实际效果仍需结合具体企业的任务规模、日志质量和知识库完备度验证。