To B 领域最易实现的 Agent 应用场景(一):DataAgent
引言
随着 AI 浪潮的奔涌而来,企业之间(B2B)的竞争越来越激烈,企业也在不断寻求利用先进的技术来提升效率、降低成本并增强竞争优势。其中,Agent 技术以其灵活性和智能化成为 2B 市场的一大亮点。Agent 技术,尤其是数据分析 Agent,正在重新定义企业如何处理和分析大量数据,以便更好地理解市场动态、客户需求和业务运营。
数据分析与商业智能 (BI) 在中大型企业的日常运营中的重要性毋庸置疑,无论是基本的财务数据分析,还是涵盖了对复杂的客户和运营数据进行深入洞察的需求,都需要借助专业的工具。传统 BI 工具使用门槛高、过度依赖技术部门、结果产出周期长的问题在 AI 时代可以借助大模型的能力得以缓解。
基于大模型的数据分析助手 (Data Agent),可以以自然语言处理的方式进行数据分析任务,无需深入了解复杂的查询语言或编程技巧。这些 Data Agents 能够将自然语言指令转换为具体的数据操作,如 API 调用、数据库查询,甚至编写专门的数据分析脚本,实现数据的提取、分析和结果的可视化。这种方法的底层架构和工作原理将 AI 的先进能力与数据分析需求进行结合,可以降低 BI 工具的使用门槛,加快洞察的获取速度。

在一个 DataAgent 的开发过程中,主要涉及 3 个维度的核心关键因素:数据源、大模型、应用及可视化。
一、数据源
数据分析的第一步永远要回答一个问题,我们的数据从哪里来?针对现在主流 LLM 应用以及企业用户应用场景,大概可分为以下几个数据源。
结构化数据
结构化数据应是目前作为首要考量的数据类型,一方面结构化数据处理难度更低,更好快速实现。另一方面企业中大部分数据都以结构化数据为主,这包括企业内部的各种业务系统,如销售系统、采购系统、库存管理系统、客户关系管理系统(CRM)、企业资源计划系统(ERP)等。
- 关系型数据库(至少可以要考虑支持 MySQL,Oracle,Microsoft SQL Server,PostgreSQL)
- 电子表格(如 Excel, Google Sheets)
- JSON/XML(轻量级数据交换格式)
- (可选)Hive(大数据仓库软件,用于处理存储在 Hadoop 中的大规模数据集)
- (可选)Spark DataFrames(分布式数据集合)
普通结构化数据需要在加载时对数据进行说明来帮助 LLM 理解数据,或者上传一个文件来帮助理解。对于数据库来说可以有两种交互方式,直接让 LLM 与数据库连接的侵入式,或者非侵入式。侵入式原理相对简单,LLM 直接连接数据库获取数据库的 schema 和 comment 来理解表单。而非侵入式一般依赖于特殊的架构,我们会在后面讨论。
半结构化数据
- Log 文件(如 Apache log, syslogs 等)
- Markdown(轻量级标记语言)
非结构化数据
- 照片(如 JPEG, PNG, GIF 等图像文件)
- 视频(如 MP4, AVI, MKV 等视频文件)
- 音频(如 MP3, WAV, FLAC 等音频文件)
- PDF 文档
- Word 文档(如 DOC, DOCX)
- PowerPoint 演示文稿(如 PPT, PPTX)
- 电子邮件(如 Outlook PST, MBOX 等格式)
- Web 页面(HTML, CSS)
- 源代码(如 Python, Java, C++ 等)
传统的数据分析来讲一般不太涉及半结构化数据以及非结构化数据。一般为了从半结构化数据以及非结构化数据中提取有效信息,需要开发算法/模型进行数据的加载,如 OCR 模型,PDF 加载器。这部分数据是长久以来都是人们忽视的数据,但其中可能蕴含很多重要信息。比如,工业生产中的流水线机器日志,通过训练一个模型给他一份机器日志,预测机器是否损坏,损坏的部位,产生的零件良品率等。从多模态的角度来讲,视频音频的引入固然可以为大模型带来自然语言无法描述或记录的数据/知识,但现阶段多模态分析性能并不理想。此外虽然现在主流数据分析 Agent 是以数据分析为主要目标,但未来也可以考虑将更底层的数据治理也包含进解决方案中,具体可参考像 GrowingIO,DOMO,谷歌 Trend 这样的数据平台。
二、模型
无论是对本地的 Excel 数据文件分析,或者对数据库中的关系型数据分析,又或者对互联网的非结构化数据分析,当前大模型实现数据分析的技术途径基本还是以三种方式为主:自然语言转 API、自然语言转 SQL、以及自然语言转代码。
自然语言转代码
因为模型在训练数据中就有代码部分,所以大部分模型本身就有生成数据分析代码/SQL 语句的能力,并且参数越大的模型表现性能一般会更好。但需要注意的是参数越大也意味着需要硬件的性能也越高,一般情况下在 16 位的精度下 1B 参数需要 2-3GB 的显存。
自然语言转 SQL
在预训练模型的基础上,我们可以针对数据或 text to SQL 做一些微调大模型,这样的好处有三:
- 在减少模型参数的情况下提升性能:下图是一个 SQL 微调模型和 GPT4 的性能对比,可以看出 34B 的模型就可以超过参数有 100B 以上的 GPT4,可以大幅减少硬件成本。

- 开源:性能好的通用大模型一般都不开源,但存在很多开源的微调模型或微调框架,一方面增强的安全性,另一方面,有更高的灵活性可以针对某些特定场景进行微调。最后,我们可以再次基础上对 Agent 的架构做一些调整,我们会在后面进一步讨论这点。
- Prompting:另一个明显可以改善大模型性能的技巧,可以提前封装一些提示词模版。可以用的技巧包括:
- 针对特定的数据库专门设计一套提示词
- 提示词中一定要加入 schema(面对数据量大的场景下,因为输入有限,这可能没法做到,我们需要利用 LLM 或向量检索来帮我们压缩 schema)
- few shot CoT 或动态 few shot CoT
自然语言转 API
自然语言转 API 是一种将用户的自然语言输入转换为对 API 的调用和操作的技术。这种方式主要应用于那些已经拥有成熟 API 接口的系统,如各种云服务、在线服务平台等。用户可以通过自然语言描述他们想要进行的操作,系统则将这些描述转换为相应的 API 调用,以实现用户的需求。对于数据分析来说,我们可以把实际需要用到的各种指标,报告和模型封装成 API 的形式,提供给一个核心的大语言模型让它来调用再进一步进行数据分析。
自然语言转 API 的实现方式主要有以下几种:
- 自然语言处理(NLP):通过 NLP 技术对用户的自然语言输入进行理解和解析,提取出其中的关键信息,然后根据这些信息生成对应的 API 调用。
- 语义分析:通过对用户输入的语义进行分析,理解用户的意图,然后根据这些意图生成相应的 API 调用。
- 机器学习:利用机器学习技术,特别是深度学习技术,对大量的用户输入和 API 调用进行学习,从而实现从用户输入到 API 调用的映射。
- 对话管理:通过对话管理技术,对用户的输入进行理解和回应,实现与用户的交互,并根据用户的意图生成相应的 API 调用。
这些方式可以单独使用,也可以结合使用,以提高自然语言转 API 的准确性和效率。就比如自然语言转 API 方面典型的例子——Toollama。这个项目就先使用 BERT 筛选需要使用的 API,再通过一个微调后的模型从用户的输入提取参数来调用 API。
Toollama 结构示意图
三、应用
既然已经有了数据分析智能体的大体思路,我们便可以探索新的智能 BI 来取代传统 BI 工具,以下是一些可能落地的场景:
- 自助式数据分析:用户可以通过自然语言查询或简单的拖放操作,自主进行数据分析,无需专业的技术背景,加速从数据中获取洞见、生成结论,并解释数据背后的相关性。
- 预测分析:利用历史数据,结合机器学习算法,对未来的趋势和模式进行预测,为决策提供前瞻性信息。
- 数据看板:处理好的数据可进行进行可视化,最理想的情况下由大模型自主选择适用的图表来生成最终看板,来简化整个报表流程,实现一句话生成报表。但现阶段还不太稳定,建议加入一些人工介入以增强灵活性。
- 智能报告:自动生成定期报告,包括关键性能指标 (KPIs)、趋势分析、异常检测等,并通过电子邮件或其他通信工具自动发送给相关利益相关者。
- 数据挖掘与探索:提供探索性数据分析工具,帮助用户发现数据中的模式、关联和异常。
- 多数据源集成:LLM 可以处理多数据源(如数据库、云存储、第三方 API 等)收集和整合数据,提供一个统一的视图。
- 嵌入式 BI:将 BI 功能嵌入到其他业务应用程序中,为用户提供无缝的数据分析体验。(CRM)
在这些场景中已经有不少产品推出可供我们参考:
-
用友——薪酬分析助手:用友是企业软件和云服务提供商。在人工智能时代前其本身就推出过不少企业级数据化转型软件,具有一定的技术积累。他们的传统产品具有多组织权限、多端接入、数据分析等充分打磨的产品特性,并且具备 API 接口对接能力。不难想象这些都会是智能体开发的先天优势。而薪酬分析助手是一款新型的基于自然语言处理技术的数据分析工具。用户可以通过自然语言输入查询薪酬相关的数据,系统则将用户的输入转换为对数据库的查询请求,并返回相应的薪酬分析结果。在其官网的客户案例中数据显示通过用友智能薪酬系统,算薪效率可以提升 70%。

-
九章云极——TableAgent:九章云极是一家人工智能基础软件供应商。而 TableAgent 是一款在九章元识大模型基础上开发的,基于自然语言处理技术的数据分析工具。TableAgent 可以通过上传的数据通过自然语言理解,将用户的自然语言输入转换为数据分析代码,从而实现数据的快速分析,并自主的利用统计科学、机器学习、因果推断等高级建模技术从数据中挖掘价值,进而提供分析观点和指导行动的深刻见解。此外 TableAgent 的一大亮点是可以为企业提供私有化部署,系统部署在企业内部,数据不外流,从根本上解决了安全合规的问题,同时 TableAgent 也可以满足企业级数据的大规模、高性能分析的要求,这也是目前很多项目的短板。

-
数势科技——SwiftAgent:数势科技一家新的行业数据智能产品提供商,其推出的 SwiftAgent 智能数据分析解决方案,是相较于上述两种产品更加完整和综合的数据分析解决方案。该系统可以通过用户的自然语言查询指标数据,并自动生成包含图表、计算和文字结论的分析报告。此外,它还可以可自动拆解和归因异常指标,并通过低代码方式组装派生和衍生指标,提高决策效率。整个系统实现了指标的定义、计算、查询和应用全流程管理,并实现了指标口径的统一。可以说数势科技的 SwiftAgent 是一个比较完善的智能数据分析解决方案,其通过交互式查询、智能归因、自动报告生成和指标全生命周期管理等功能,可以有效提升了数据分析和决策的效率。

四、DataAgent 的设计思路
说了这么多业务场景和产品,我们再回到智能体本身,这样的数据分析智能体具体的设计思路又是如何的呢?
1. 直接与通用大模型交互
最为简单和直接的方案,就是模型直接和数据库/上传的数据进行交互。我们可以尝试可以插入一些工具来帮助大模型提高完成任务的准确率。此外,这些工具可以用小模型来代理,来进一步压缩成本。但需要注意的是这种侵入式的交互可能会产生数据隐私和安全问题。

2. 引入领域模型层
另一种思路是将领域模型与通用模型在私有数据资产上做解耦。对内核心业务的交互全部放在领域模型层做处理,交互层还是通过通用模型去下发,在通用模型层与领域模型之间做安全与隐私防护。

简而言之就是整体的任务规划,语义理解和人机交互还是大模型来做,但是对于特定的与 SQL 的交互交给一个本地部署的领域/微调模型来做。之后再加一些工具来增强外部信息和行动能力。这里的工具模型可以比领域模型规模更小,我们不太需要模型掌握太多的泛化或者推理的能力。恰恰相反,我们需要的是最低成本确定性完成某一任务的能力。
3. 与指标平台/API 交互
还是保留通用大模型作为核心语义理解和任务规划的核心,但数据调用可以通过指标平台/API 进行提前封装。相当于大模型不是和数据库直接进行交互而是和从数据生成的指标或者统计模型进行交互。可以采取的策略是提前针对特定行业封装好一些开箱即用的模型/指标的方法/API,用户可选择在客制化的 Agent 增加如何指标/模型,当然这里还可以进一步降低门槛,比如有对 xx 行业推荐的 Agent 数据包。但一定需要的是客制化这些指标的能力,可以是低代码式的。这样做有几种好处:
- 因为不直接连接数据库一定程度上保护数据隐私。
- 分担大模型的能力,减少大模型出错的概率。
- 也许可以选择参数相对较少的模型来减少成本。
4. 与可视化看板的封装对接
与可视化看板的结合式是与指标平台交互相似的设计思路,它允许用户通过自然语言查询或命令来获取数据可视化结果,而不需要直接与数据库或复杂的分析工具交互。这种设计思路的实现可以分为以下几个步骤:
- 可视化工具:首先,需要选择合适的可视化工具,如 Tableau、Power BI、Looker 等,同时也可选用一些开源的可视化组件或自己进行可视化工具组件的封装,通过可视化看板的工具组件可以提供丰富的图表和仪表板功能。
- 建数据接口:接下来,构建一个数据接口,用于将 DataAgent 的数据分析结果转换为可视化工具能够识别的格式。
- 装自然语言接口:设计一个自然语言接口,允许用户通过简单的句子或问题来请求特定的可视化。这个接口将用户的输入转换为对数据接口的调用。
- 反馈机制:建立一个反馈机制,允许用户对可视化结果进行评价和注释,这些反馈可以用于改进 DataAgent 的查询理解和结果呈现。
通过这种方式,DataAgent 不仅能够提供数据分析的能力,还能够提供直观的数据可视化结果,使得非技术用户也能够轻松地从数据中获取洞察。同时,这种方式也能够保护数据隐私,因为用户不直接与数据库交互,而是通过 DataAgent 和封装的可视化工具来获取信息。
五、可用的开源智能体项目参考
Open Interpreter
Open Interpreter 是一种采用直接与通用大模型交互的简易智能体项目。作为最基本和直接的实现数据分析的方式,其本质上是个高效的 python 代码 Interpreter。在所有我们测试过的项目中,Open Interpreter 是当前最强大的开源代码解释器之一,其完美复刻了 OpenAI 代码解释器的实现,并额外支持读取本地各种文件的功能。其核心设计理念是讲大模型生成的代码在本地执行并将结果与历史对话(上下文)一起再交给 LLM 来不断交互,改进。此外 Open Interpreter 也是我们看到能支持模型选择最多的项目之一,包括 GPT 系列,Mistral 等等并同时支持使用本地大模型。更让人惊喜的是 Open Interpreter 最近在探索 OS mode——尝试让大模型来控制系统硬件(键盘,鼠标)来完成任务。包括 Openao 和微软在内一些团队也在做这方面的尝试,需要注意的 OS mode 的性能还不是很理想,但这种技术探索无疑给了我们更多大模型落地具体场景的畅想。

开源项目地址:GitHub - Open Interpreter
DB-GPT
DB-GPT 是一个国内团队以重新定义数据交互为使命的开源项目,包括了完整前后台功能的实现,实现了多场景下的交互数据分析:
- RAG(Retrieval Augmented Generation):可以基于 DB-GPT 的 RAG 能力构建 QA 应用
- GBI(智能 BI):生成式 BI 是 DB-GPT 项目的核心能力之一,为构建企业报表分析、业务洞察提供基础的数智化技术保障
- 微调框架:提供直接可用的微调框架
- 数据驱动的 Multi-Agents 框架:支持自定义插件执行任务,原生支持 Auto-GPT 插件模型。
- 支持多种模型
- 隐私安全:通过私有化大模型、代理脱敏等技术保障数据的隐私安全。
- 数据源:可对接各类数据源,包括 SQL,CSV,Excel

具体架构示意图:整体结构比较简单。左侧是知识 (RAG),右侧是工具 (Agents),中间是多模型管理,同时增加了向量存储这样的大模型记忆体,以及各类数据源,在往上是一层通用的交互层面。
开源项目地址:GitHub - DB-GPT
DeepBI
DeepBI 是基于 GPT4 的 Muti-Agent 数据分析软件,现已在 GitHub 上开源,这是一款多智能体数据分析 Agent,有一个核心 LLM 来进行任务分解,让分发任务到具体角色 Agent 上执行。
特点:
- 对话式数据分析:用户可以通过对话,得到任意的数据结果和分析结果。
- 对话式报表生成:通过对话生成持久化的报表和可视化图形。
- 仪表板大屏:将持久化的可视化图组装为仪表板。
- 自动化数据分析报告(待开发):根据用户指令自动完成完整的数据分析报告。
- 多数据源支持,支持 MySQL、PostgreSQL、Doris,Starrocks, CSV/Excel 等。
- 多平台支持,支持 Windows-WSL、Windows、Linux、Mac。
- 多语言支持,支持中文、英文。
开源项目地址:GitHub - DeepBI
六、实施建议与未来展望
在实际落地 DataAgent 时,除了技术选型,还需要综合考虑以下因素以确保系统的稳定性和可用性。
1. 安全与隐私最佳实践
To B 场景下数据安全是重中之重。建议采取以下措施:
- 数据脱敏:在将数据送入 LLM 之前,必须对敏感字段(如手机号、身份证、薪资等)进行掩码或加密处理。
- 权限控制:确保 Agent 只能访问授权范围内的数据表或 API,避免越权查询。
- 审计日志:记录所有 Agent 的查询和操作行为,便于事后追溯和问题排查。
- 私有化部署:对于高敏感数据,建议采用私有化部署的大模型方案,确保数据不出域。
2. 成本优化策略
大模型调用成本较高,可通过以下方式优化:
- 模型分层:简单查询使用小模型,复杂推理使用大模型。例如,先用小模型判断意图,再路由到大模型生成 SQL。
- 缓存机制:对相同的查询结果进行缓存,避免重复调用模型。
- Token 压缩:优化 Prompt 工程,减少不必要的 Token 消耗,例如只传递必要的 Schema 信息。
3. 开源项目对比与选型
| 项目名称 | 核心优势 | 适用场景 | 部署难度 |
|---|
| Open Interpreter | 代码执行能力强,支持 OS 控制 | 个人开发者、本地数据分析 | 低 |
| DB-GPT | 生态完善,支持 RAG 和 GBI | 企业级 BI 替代、知识库问答 | 中 |
| DeepBI | 多 Agent 协作,可视化强 | 复杂报表生成、交互式分析 | 中 |
4. 未来趋势
- Agentic Workflow:未来的 Agent 将不仅仅是单点问答,而是能够自主规划任务链条,例如先清洗数据,再分析,最后生成报告并发送邮件。
- 多模态融合:随着多模态模型的进步,Agent 将能直接理解图表、截图甚至视频内容,提供更丰富的交互体验。
- 低代码/无代码化:企业用户将能够通过拖拽配置自己的 DataAgent,无需编写代码即可定制专属的数据分析助手。
结语
DataAgent 的能力本质上比较依赖大模型的自然语言转 API/SQL/代码的能力,除了对模型进行专门优化及加入提示工程等方式,在 2B 场景下,也有一些可以通过基于字段和 API 的优化方案(具体参考与指标平台/API 的交互),在实际实施过程中,还需要根据实际场景、复杂度和可靠性做出更综合的评估。