我要投稿

腾讯的这款AI数据智能体工具Lumos，颠覆了传统的数据分析

发布日期：2025-08-18 17:52:12 浏览次数： 1530

作者：腾讯技术工程

微信搜一搜，关注“腾讯技术工程”

作者：steveweng

AI 如何跟数据分析结合，同时保持高效与专业性，一直是业界关注的焦点。Tomoro 是一款基于大数据分析引擎能力，结合表格式UI与 AI 于一体的数据工具，旨在通过熟悉的表格操作与无边界的数据引入，结合 AI 驱动的数据分析工作台，实现零门槛的大数据自助分析。Lumos 作为 Tomoro 中的数据智能体，采用多智能体架构，旨在解决复杂场景下的专业问题，并通过一系列技术优化提升用户体验。当前Lumos 的能力和效果是如何实现的？本文将深入探讨数据智能体 Lumos 的技术思路与实践。如果你对 Data Agent 的应用前景充满好奇，欢迎阅读，一同探索AI 分析的更多可能。

0. 内容摘要「万字长文的浓缩」

0.1 产品及技术思路

1）产品定位：大数据 + 表格 + AI，协作完成更全领域的一线数据分析任务。

2）产品思考：表格分析这种大家熟悉且久经验证的分析交互形态结合AI实现的数据分析工作台，最有可能实现零门槛大数据自助分析。

3）产品能力：以简单、熟悉的表格操作 + 无边界的数据引入 + AI驱动，实现从分析到报告的全流程能力，并尝试化繁为简。

4）技术思路：从分析环境、Data Agent和分析情景三个角度出发，思考技术要素。当前模型能力的限制下，人可以通过环境操作来验证Agent结果是必要能力。

5）实用性驱动的技术方案设计：优先考虑AI能增强的场景，基于场景考虑Agent 主体设计和对公共能力需求，再基于Agent需求驱动环境产品的建设，实现全流程考虑AI应用需求。

0.2 Lumos落地实践

1）为什么Lumos选型做成多智能体？

数据分析任务中的高价值问题，往往是一个简单问题对应着多任务，多步骤才能回答好。为了适应复杂场景下，更好的解决专业领域问题，同时避免主体Agent负担过重，设计成多智能体，保证灵活且专业。

2）如何解决多智能体存在的一致性问题？

设计共享工作记忆机制，实现多个Agent之间可以观察到各自的目标、计划、结果及状态。任务顺序执行，确保下游任务可以有效利用上游的结果。并行执行效率损失，可以通过解决更关键的查询和计算工具效率来提升体验。

3）如何实现极致查询&计算工具响应？

结合引擎能力实现分层计算框架，并且细分场景持续优化。提升Agent执行效率的同时，也可以让用户手动验证Agent结果效率提升，有助于构建信任，并提升体验。

4）如何做AI Coding和工具调用之间的选择？

优先使用工具调用，工具存在局限性时候使用AI Coding。并构建监控机制，分析AI Coding输出的内容，驱动工具迭代。从机制上实现大部分场景工具提供稳定效果，AI Coding提供足够的灵活性，实现通过率提升。

5）如何通过 MCP共建专家Agent，满足业务复杂分析需求？

结合Planner能力和MCP、插件服务，实现整个系统足够的开放性，让业务知识、工具、算法可以有效融入整个产品，实现适配度提升。

6）如何提高用户提问的有效性？

通过基于表的问题推荐能力和多轮问题推荐能力，帮助用户在使用过程中快速提问。结合澄清能力，通过多轮澄清，帮助用户有效提问，避免无效回答干扰上下文。

7）如何对 Agent 的分析能力进行有效测评？

构建有效、持续的产品能力测评和Agent 能力测评机制，持续验证通过率、质量、效果并进行调优。通过分析认知驱动，基于数据表、数据域、分析方法、分析方式4大领域8个类型的打标、完善，持续构建有效、完善的内部Benchmark，并探索不同任务的测评方法。

8）工程结构优化，保证Data Agent稳定性

通过合理的应用层划分、公共层引入和模型层设计原则，实现Data Agent开发迭代的有序和聚焦。

0.3 下一步计划

重点优化Tomoro Lumos智能体效果，推进业务知识、工具引入及场景验证，深化业务协作持续提升能力；欢迎访问官网，体验大数据分析新方式。

1. AI小蓝表Tomoro的产品及技术思路

1.1 Tomoro产品定位- AI表格式大数据分析工具

Tomoro希望可以结合AI的能力，让一线消费数据的同学可以在这里解决全领域的数据分析问题，涵盖整个数据分析过程，实现真正的数据平权和提效，消除生产者和消费者之间的技术鸿沟。为了做到这一点，就需要产品上能把大数据 + 表格 + AI组合应用，如下

1）中台BI多年沉淀的分析引擎核心能力（大数据分析能力提炼）

● DataTalk沉淀的百亿大数据秒级查询链路能力

● DataTalk沉淀的出图、业务分析函数等分析领域原子工具能力

● DataTalk沉淀的业务数据模型、用户分析case、真实场景的复杂分析路径

2）重塑UI为产运用户更熟悉的表格式形态（升级表格交互）

● 低学习门槛，每一步操作数据所见所得，激发探索灵感

● 预装挂载的数据资产和丰富的数据源连接

● 可扩展函数公式和功能插件，提升通用性亿级数据，秒级响应，适应真实业务分析的数据规模

3）探索AI分析师：感知和陪伴用户分析全流（AI嵌入）

● AI拆解复杂分析任务，规划分析路径，为用户提供分析灵感与引导

● AI对于复杂分析问题，进行SQL + Python编码处理

● AI吸收业务个性化知识，更懂业务上下文，给出更好的分析思路发散和洞察总结

1.2 Why Tomoro-目标：实现零门槛大数据自助分析

过往我们设计并实现很多的大数据分析工具产品形态，希望实现零门槛的大数据自助分析，帮助一线同学解决数据分析上的困难和效率问题。但是在进入业务一线组深入调研和访谈后，我们发现非技术同学在进行大数据分析过程，依然面临显著障碍，主要在以下两方面

1. BI数据理解困难：他们希望数据能实现“找得到、能理解、看得懂”，但是想要实现这一目标，需要一个非常完备且治理清晰的语义层。而真实的业务往往是在不停的随着市场变化和迭代的，很难实现数据的完备性。而当数据不完备时候，就需要自助分析过程中掌握BI平台规则、数据仓库等大量数据分析概念知识，实现底层的数据提取和调整。非技术同学很难理解这些概念和操作，最终只能转换为需求，由数据工程老师或者内部专门负责取数的同学解决。

2. 分析工具使用习惯和门槛问题：Excel作为从1982年就出现的产品，其表格分析形态已经占领了大家的操作心智和使用习惯。在过往数据分析工具建设中，很多用户提出了能不能像”Excel一样的需求“。例如，直观的明细操作、透视表、分列功能和公式计算等特性。

如果想要更普遍地让非技术同学自助分析不求人，需要回到一线需求本身，以［分析任务解决率］为目标，思考突破性的、并贴合用户习惯的AI分析产品解决方案。

1.3 Tomoro产品设计框架

1.3.1 以简单、熟悉的方式导入数据并进行基础分析

基于上面产品的洞察，我们希望Tomoro能以简单、熟悉的方式开启分析。我们希望所有数据分析相关的数据源都是“无边界”的，也就是可以被简单引入的，总结为以下三类

1）数据库/大数据引擎等传统数据仓库数据分析：Mysql、StarRocks、Clickhouse、Thive等等

2）数据分析相关的平台类数据：DataTalk报表系统、腾讯文档、腾讯问卷等多个和数据分析流程强相关，或者可以成为数据源的平台数据

3）数据分析过程可能涉及到的多模态数据：带数据的截图、数据分析报告相关的PDF等等

有了数据之后，我们希望所有的分析都可以是类Excel形式的，用户可以直面表格分析数据。同时，实现亿级数据秒开，结合AI优化，支持用户快速通过清晰的表格数据理解元数据信息。另外，分析操作上也需要都是用户熟悉的表格操作，比如以下特性：

● 「枚举值筛选」即席获取数据，像本地操作一样“快”

● 「分组聚合」分级加速，分析体验不受数据量级影响

● 「函数计算完成列操作」无需牢记函数公式，AI 生成函数轻松完成列操作

● 「vlookup关联多表」多元数据轻松关联

1.3.2 以简单、熟悉的方式进行专业分析&可视化生成

为了实现产品目标，除了基础的分析能力之外，相对高阶的数据分析功能也是必须的。比如：

1）交叉透视表：让大家用习惯的分析进行数据洞察和下钻分析

2）数据可视化：实现多种可视化图形能力，同时要求可以风格和样式上可以比肩Tableau

3）分析结果交付：分析报告、仪表盘的配置生成&更新能力

同时在这些能力的不同场景中，支持一定程度的AI能力嵌入，实现使用体验和效率上的提升。

1.3.3 AI 驱动，分析全流程化繁为简

有了基础和高阶的分析能力，Tomoro还仅仅处于一款数据分析产品的状态。在AI时代，我们希望能够给Tomoro赋予AI灵魂，以AI驱动，实现分析全流程的化繁为简。

传统的分析工具，往往需要用户基于分析目的，自行推导下一步分析步骤，手动完成操作。整个过程需要反复在页面多个位置进行不同程度的操作，非常的繁琐和复杂。

我们希望在Tomoro中能结合AI的能力，学习用户的历史分析习惯，实时获取前序分析操作，启发、推荐下一步分析，贯穿用户 GUI/Chat 完整分析流程，这样就可以实现流程上的简化。用户仅仅需要不断的点击下一步推荐，就能轻松实现复杂分析。另外，针对探索之后的分析工作流也能记录，实现后续例行分析时候的Workflow可以全自动执行。

当然，这块能力是需要持续探索和优化的，我们目前实现了分析指南、列表操作推荐、分析推荐等能力来探索和验证。期待未来能结合业务使用验证，实现更加贴心有效的算法&产品形态。

1.4 Tomoro技术设计框架

1.4.1 技术思路的关键点：环境 + Agent + 分析情景

在产品核心理念的引导下，我们思考技术方案实现时候，总结起来有三个关键内容：

1）Tomoro环境：将Tomoro当一个类似工作台一样的运行环境来设计，同时支持能被人使用，也支持被DataAgent使用，整体上要求这个环境是简单、高效的。那么就需要这个环境具备以下要素：

● 可交互：给人交互的GUI + 给Agent使用的简单OpenAPI

● 能计算：分析引擎 + 分析工具集，实现按需的计算和分析能力

● 有素材：元数据 + 数据资产，支持对无边界引入的数据管理

● 要安全：权限管控 + 环境隔离，实现各个场景数据安全上的保障

2）Lumos数据智能体：长期来看我们希望Lumos可以像一个数据伙伴一样，协同用户解决数据分析情景中的各类问题，所以需要具有足够的灵活性和专业性。所以Lumos需要具有以下能力：

● 有思路：通过Planning能力来实现结合用户的问题和场景独立思考和规划。

● 用工具：通过Function Call + Coding能力，实现会使用已有的工具，并能通过AI Coding创造更多的工具来解决问题。

● 会对齐：通过多轮对话 + 业务知识&环境信息注入等方式对齐，来现实数据分析中复杂的分析需求、业务背景知识、环境信息的理解，充分了解用户的本质诉求。

● 能交付：不论是在问答、报告、洞察等不同场景中，都可以输出一个有效的交付物，来实现真正的分析提效果。

3）用户分析情景：需要涵盖用户在数据分析中的全领域分析内容，比如：

● 【思路分解】分析目标、分析思路确认

● 【预处理】过滤、清洗和预处理的整理计算

● 【探索洞察】数据探索和分析洞察

● 【高级分析】机器学习、算法任务

● 【结果呈现】数据可视化、总结效果、报告生成

长期上看，用户在不同分析情景的任务应该主要由Data Agent来接受指令，直接交付成果，用户主要应用数据价值，以此实现低门槛、高价值的数据分析。但是，目前Data Agent由于模型幻觉、Agent在模型场景能力上还有不足，导致无法实现全场景的高效应用，可能引发的用户AI信任的问题。基于这个考虑，人可以结合Excel操作心智快速操作环境获取数据这一步骤非常关键，我们也在重点建设。通过页面操作校验和快速验证AI结果，是一个构建长期AI应用信任的关键能力，同时也是AI观察和学习用户操作的关键入口。

1.4.2 实用性驱动的技术方案设计，实现大数据与AI融合

基于以上AI与Tomoro结合的整体思考内容，我们本着一种实用性驱动的逻辑来驱动我们大数据与AI产品的技术落地。主要分以下几个步骤：

STEP 1: AI 场景分析&设计

在整体设计开发之前，先思考，AI在整个流程中到底有哪些实用的场景是可以帮助用户，并提升效率的，比如以下几点：

1）分析引导

● 智能菜单推荐（步骤中引导

● 分析指南（整体说明和分析思路建议

● 仪表盘一键生成（通过可视化的方式提供全局建议

2）页面操作提效

● 对话生成操作指令，加速页面筛选

● 对话分析实现可视化出图

● 实现对话报告生成&调整

3）分析数据准备

● 文本内容智能提取

● 推荐分析函数等等

STEP 2: 按AI 场景需求设计 Lumos

结合AI分析场景的需求，来设计我们的数据智能体Lumos，并抽取关键公共能力，以便对环境提出准确的需求。

1）Agent核心能力【DS Agent建设核心】

1.1）Agent主体原子能力

比如：表格理解、问题推荐、图表生成、数据洞察、表格操作、 Planner规划能力、 Summary总结能力等

1.2）数据源+记忆的上下文应用能力

比如：数据源元数据&数据本身的有效读取；长、短记忆整合：高频查询+各类离线数据源、缓存的加载等

1.3）输出能力

比如：步骤式结构化返回、结果流式输出等

2）需要依赖的公共能力【转化为需求，要求环境或者外部工具提供】

2.1）应用层环境态信息

比如：环境采样的示例数据、环境分析表的元数据信息、环境用户交互行为、环境支持的通用指令集合

2.2）工具&指令服务

比如：【引擎】时间、数据、Excel函数等常规公式函数、【引擎】SQL/Python等高阶查询&计算工具支持、系统各类OpenAI&MCP 延伸服务（查询接口、元数据接口、挖掘机数据挖掘接口、事件信息库等其他第三方开放接口等）

STEP 3: 按 Lumos 需求设计并实现分析环境

分析环境本质上是一个数据产品，和过往我们实现的数据分产品没有本质的区别。唯一的差异是，本次实现过程中全流程考虑了AI辅助，在能力的组织和建设中都考虑并且为AI做了针对性的定制和优化，保证流程和接口上是对AI简单、易用的。

2. Tomoro中智能体Lumos的落地实践

2.1 Lumos用户分析情景中的角色分析

Tomoro的一个核心场景是希望可以结合AI的能力，通过人机协同的方式，消除一线非技术同学在分析过程遇到的数据分析技术和分析经验问题。所以我们会从一线产运的分析视角来看，以下以非技术的电商业务运营同学，进行用户画像和场景角色举例。

1）用户画像

● 角色：电商业务运营；

● 业务理解深度：熟悉用户行为、市场策略、库存周转等业务逻辑；

● 技术短板：非技术，SQL语法不熟，无法自主编写JOIN/子查询；

● 决策场景：日常监控、需快速定位问题（如促销效果差）、制定运营策略等；

2）环境系统

● 数据来源：通过DT报表系统引入的动销商品下钻分析看板，对应的底层明细表

● 数据规模：3.5亿行，18个字段

● 加载背景：DataTalk进行报表消费时候，发现动销情况异常

3）Lumos多智能体系统

● Master Agent：职责为目标对齐、指令理解、环境信息获取、总体结果总结，并通过记忆管理和应用长短记忆，通过模型进行任务规划。

● Executor Agents：主要为基础分析Agent、归因分析Agent、实用分析Agent等专家Agent,负责处理特定领域的分析问题。同时每个智能体能根据自己的任务进行步骤规划和反思。

2.2 为什么Lumos是多智能体？

将Lumos设计成多智能体，主要是从专业分析任务复杂度的角度出发，做框架的选择。因为数据分析场景的特点是一个简单的问题，可能对应多个任务。

举例1：如何提高高单价商品的销量？这个问题看起来很简单，但是分解出来看，就会发现它需要从多个角度分析才能解答。并且这种策略型问题属于分析的高价值问题。

当然，分析场景同样具有很多简单问题，指定查询类型的（这个往往是现在Chat BI/BI报表筛选直接能涵盖的问题）。

举例2：帮我查询订单 2025053108532414786 的销售数据？这个问题虽然很简单，但是也是日常分析的高频问题，也不可或缺。这类问题主要是分配给基础分析Agent，找到正确的字段，即可回答正确。

为了尽量适配各种分析任务，同时降低Master Agent的负担（避免需要了解各种不同类型任务的特殊规则）我们将Lumos的原子能力组合设计成了多智能体。以下图的方式进行工作

2.3 如何解决多个Agent之间的行为一致问题？

1）问题现象：

多智能体版本Lumos上线后，我们发现多智能体协作会有一致性问题，这个现象在任务并行后会加剧。

比如，如何提高高单价商品的销量？

这个问题，其实4个子任务中，有3个任务是可以用到相同的中间结果，但是智能体系统在不同子任务执行时候会表现出不一致行为：

● 重复计算，明明可以用中间结果不用，导致效率低

● 反复总结一样的内容，显得啰嗦且愚蠢

● 由于以上两点引起的上下文过多，导致整体效果变差

2）解决方案：

● 建立共享工作记忆，我们设计一套独立的工作记忆机制，实现Agent之间的共享信息区域，互相了解对方的目标、计划、产出物、执行状态等，确保Agent之间的信息对齐。

● 将整个任务设置为顺序执行，保证下游任务是可以充分理解和应用上游的结果。

方案缺点：失去多智能体系统，并行效率的加成，导致整个执行速度变低。但并行这个方案对当前的模型来说复杂度太高，需要在分解任务并标识出依赖关系，形成执行的DAG图。目前还需要较多的深度研究。

如何解决串行导致的Agent执行慢，带来的用户体验不足的问题呢？经过数据分析，我们发现模型性能的问题并不是关键，因为模型输出过程都是流式输出，对用户体感影响并不大（受到各种模型应用的训练）。真正对用户影响最大的是查询和计算的过程，大数据计算和传输的过程耗时非常高，并且这个过程对页面是阻塞的，导致体感非常差。因此，如何实现极致的查询和计算工具响应，才是提升用户体验的关键。

2.4 如何实现极致查询&计算工具响应，提升用户体验

由于Lumos是支持无边界的数据导入，也就意味着查询的数据是多源、异构的，且数据规模可能是从几十条到几十亿条。为了解决查询和计算速度的问题，我们和Mixquery引擎同学协作推动了分级查询计算框架的设计。

2.4.1 分级计算框架思路

1）目标：让亿级数据查询，像本地一样快。

● 核心架构逻辑：通过存储、计算、多级缓存的设计和策略实现在不同数据源、不同规模数据上的计算加速、达到体验提升。同时，为了实现对Tomoro应用层和Lumos Agent应用层面的复杂度屏蔽，实现了统一、简单的查询DSL表达和分析语义模型。让前端页面和Agent可以简单的理解数据关系并查询数据。

2）主要实现手段

● 场景预计算：主要应用于优化前端交互类功能，比如，下拉选项预处理，表格秒开，字段类型和规模统计等

● 内存数据库：物化过程数据，将经过过滤筛选之后的中间结果，通过服务层的内存DB实现物化加速，帮助下游的计算任务高效执行。

● 托管式高性能引擎：支持把Spark、Thive等在首次查询无法加速的数据源查询，迁移到托管式的高性能OLAP引擎，来实现计算效率提升。

● Python计算加速：针对大模型生成的Python代码，通过Mixquery引擎实现自动改写，根据数据规模实现Pandas单核计算、Modin多核计算、Ray并行计算框架的自动切换。同时引擎层面会帮助屏蔽不同来源数据的查询语法差异，让模型只需要理解规范统一的输入文件格式即可。

3）分级计算收益

● Agent执行速度提升

● 用户页面操作检查Agent结果变得简单

● 通过以上两点实现了整体用户体验和AI信任度的提升

2.4.2 细分场景的持续深度优化

当然，整个分级计算框架还是非常复杂的，从理念到落地还需要细分场景的持续深度优化。引擎组同学通过如下思路进行更多细致的优化。（P.S. 欢迎向我们反馈更多的性能问题）

2.5 如何做AI Coding和工具调用之间的选择？

由于Lumos同时具备AI Coding和调用MCP工具的能力，这两个能力在大量的场景是有Overlap的，AI Coding是可以理解为终极工具，一切能力均可以代码实现。因此，AI Coding和工具调用之间的选择，是我们思考的一个关键问题。以下从绘图这个基础分析能力来探讨我们在这块的实践经验。

1）仅用AI Coding实现绘图：由于AI Coding是终极工具，我们最初版本的绘图就是仅仅使用AI Coding实现的。

1.1）效果：

1.2）优势：

●【高潜力】充分利用模型能力，成长性好；（基础模型越强，效果就好，能吃基础模型提升红利）

●【很灵活】可以持续对话修改代码，实现魔法图表；（任何图表组合方式都可以通过代码实现）

1.3）不足：

●【体验不佳】可视化规则很复杂，有效果一致性问题；

●【优化困难】多种方式尝试优化，效果均不佳，包括：

--【尝试Prompt规则注入解决】过多的规则注入影响模型发挥；

--【尝试RAG绘图知识库解决】很多可视化策略是结合产品需求调整的，维护成本高；

--【尝试人工干预解决】回显到页面比较困难，用户只能对话修改/代码修改；

2）仅用工具实现绘图：在AI Coding的尝试效果不佳后，我们整体切换为通过MCP工具来实现绘图，期望通过这种方式实现绘图体验和质量提升。

2.1）效果：

2.2）优势：

● 【简单】模型只要确认意图，明确绘图关键要素，成功率高；

● 【易调整】图的可视化能力和交互能力都很好，能转换成页面操作；

● 【维护成本低】新产品需求特性，前端都会支持，保证体验一致；

2.3）不足：

● 【限制多】支持的图表类型有限，复杂个性化需求无法满足；

● 【不灵活】需要模型理解特定的一些规则，才能调整图形；

3）最终方案：优先使用工具，工具局限性通过 AI-Coding 解决

● 组合应用既要效果，又能通过AI-Coding保证灵活性；

● 设计反馈机制，持续监测AI-Coding的图表类型，驱动工具持续迭代，让大部分高频图表能被MCP工具有效覆盖；

● 流程示例：

2.6 如何通过 MCP共建专家Agent，满足业务复杂分析需求？

针对指标异动归因、实验效果分析等专业性比较强，比较多的业务定制规则的复杂分析场景，我们主要通过与业务共建的专家agent实现。通过业务特定workflow和业务知识融合进对应的专家Agent，实现避免Master Agent过多的业务知识和规则负担（只需要完成意图识别和定向路由即可）。以下从指标异动归因场景举例

2.6.1 指标异动归因场景举例说明复杂Agent实现

指标异动归因场景的分析问题，明显具有延续性。比如，下图中（左）用户发现实际下单金额在持续下降时，会发起Query1:实际下单金额相比上个月的变化原因是什么？当这种问题被拆解分析后输出报告显示北京市这个维度项影响最大时，用户很大概率会问出Query2:针对北京市的数据进一步分析不同折扣类型的影响？

针对这种情况，结合lumos的Planner能力和原DT中的指标异动归因工具的联动，是可以实现生成式归因能力。见下图（右）

场景验证过程中的关键点：各个业务针对异动归因选用的算法、公式拆解方法、关联事件规则，存在一定的差异，需要结合算法市场，支持业务方自定义MCP，有效实现业务适配。

2.6.2 更全面的提高适配度，需要让系统足够开放，支持业务自定义高级工具

除了指标异动归因场景之外，还存在如实验结果生成分析报告、业务舆情评论分析、IP运营分析等等许多复杂分析场景。为了让Tomoro具有足够的业务适配度，我们将系统设计的非常开放，支持业务自定义各种高级工具，实现业务定制分析。针对Lumos智能体场景，我们支持Workflow共建，通过MCP对接灵活的介入各种业务算法、知识等实现丰富的智能分析体验。针对数据GUI场景，我们也支持通过插件形式引入业务功能。未来也会进一步支持页面插件和智能体操作联动分析。

2.7 如何提高用户提问有效性，问题推荐和澄清能力

在Lumos建设过程中，我们发现问题推荐和澄清能力也是必不可少的模块，这部分能力对提高用户问题有效性有非常大的帮助。

1）问题推荐

1.1）基于表的推荐

主要是表高频query，有效帮助用户提升使用效率。以及表信息结合大模型生成丰富的问题集合，可以给用户提供分析创意。

● 方案：

● 效果：

1.2）多轮问题推荐

结合上下文信息&表信息，组合生成的下一步推荐，有助于提高分析问题质量和流畅度。

● 方案：

● 效果：

1.3）澄清能力：

避免用户过于宽泛的问题（如：最近数据怎么样），导致Lumos生成过于复杂且对用户无效的回答污染上下文。

● 方案：

● 效果：

2.8 如何对 Agent 的分析能力进行有效测评？

Lumos实践中发现，如何有效测评是最关键的问题之一，并且只有持续的进行有效测评，才能有效引导DataAgent持续有效迭代，避免整个研发迷失在LLM爆发引起的海量实现方案和不同实施框架中。

2.8.1 基础测评能力构建

Tomoro通过产品能力测评和Agent能力测评双体系持续优化分析效果与保障服务稳定性。

2.8.2 持续完善和扩充Benchmark，难而正确的事要坚持

由于测评任务多，任务存在多步骤任务的错误传播、结果验证的主观性、复杂任务分解难度等问题，数据分析领域的测评集合标注成本非常高。但是，这块任务的价值也同样高，是促进Agent能力提升和模型选择的关键。持续完善和扩充Benchmark是一件难而正确的事，所以要坚持。如何有效坚持下去，我们想到的是通过重新理解数据分析，从“分析认知”驱动测评集合完善，测评方法探索。

我们将数据分析按如下方式分解为4大类8个小部分，并持续按8个领域涵盖情况打标签整理Benchmark数据集合，保证对数据领域的问题全面覆盖。