在大模型技术蓬勃发展的背景下，企业数据消费正从传统的 BI 报表和自助式分析，迈向 AI 原生的 Agent 时代。然而，将学术界看似成熟的 Text-to-SQL 技术落地到复杂的 OLAP 场景中，其准确率可能从纸面上的 90% 骤降至 10%。
以下是演讲实录（经 InfoQ 进行不改变原意的编辑整理）。
数据消费的发展通常被划分为四个阶段。1.0 时代是传统 BI 时代，以 SAP 等系统为代表，报表交付高度依赖 IT 团队通过编写 SQL 来实现。2.0 时代迈入了自助式 BI，Dashboard 成为主流。以我所在公司的数据平台为例，Dashboard 的月活大约有两万多，但在这两万多用户中，只有不到百分之十是数据的生产者，也就是报表的编辑者。这说明绝大部分人的数据消费，依然要指望着少数的 BI 同学进行手工操作。到了 3.0 的增强分析时代，开始引入 AI 作为辅助，但主要的分析流程依然由人驱动。而现在，我们正大踏步跨入 4.0 ——AI 原生 Agent 时代。在这个阶段，数据消费者终于可以直接通过自然语言提交需求，Agent 则能够自主完成从取数到智能分析的全过程。
我们团队对 AI 取数的探索始于 2024 年。起初，我们对 Text-to-SQL 这条路信心满满，因为学术界当时的 Benchmark 数据非常亮眼。在 Spider 这类榜单上，一些 State-of-the-art 的解决方案准确率可以达到 85% 到 91%，这甚至已经接近了人类标注员的水平。基于这份信息，我们设计了一个初代 Text-to-SQL 的 Demo 架构，不到一周就完成了搭建。当时的技术方案采用了典型的 RAG 链路：我们把平台上近三十天内有访问记录的大约一百万张表做了 Embedding 索引，用户提问后，系统通过向量近似检索召回相关的表，然后利用这些表的元数据构造 Prompt，交给大模型一步生成 SQL。
然而，这套方案上线后的效果非常差。我们构造了一个内部评测集来摸底，甚至还是简化版本的评测集。但就在这个评测集上，找表的平均倒数排名仅能达到 56% 左右，而 Text-to-SQL 的执行准确率更是不到 40%。更令人沮丧的是，就连最基本的语法准确率也徘徊在百分之五六十。差不多同一时间，Spider 发布了 2.0 版本的 Benchmark，这个新版本号称是基于企业真实 OLAP 场景构造的评测集。当时比较先进的商业化模型 GPT-4o，其裸模型在 Spider 2.0 上能达到的准确率只有百分之十左右。结合 Spider 2.0 的这个数据和我们的初版实践，我们得出了一个残酷的结论：企业级 OLAP 场景下的 Text-to-SQL，是一件极其困难的事情。
面对前期的技术难点，我们对初代 Demo 和种子用户的负反馈进行了深入分析，归纳出了五大核心问题。第一是找表不准。数仓有着严格的分层，每一层之间和内部都存在大量结构相似、只有细微区别的表。对于 Embedding 模型来说，通过语义相似性检索去区分这种微弱的差异是非常困难的，结果往往会召回看起来相关但实际上完全错误的表。第二是 SQL 语义错误。第一版架构仅仅使用了表元数据，严重缺失了业务规则和数据口径，导致生成的 SQL 虽然能跑出结果，但计算逻辑和数据结论完全不对。第三是 SQL 语法错误。大模型经常会混用 MySQL、PostgreSQL 等专有语法，而我们的底层引擎是 Presto 或 StarRocks，这些不兼容的语法会导致 SQL 直接报错。同时，模型幻觉也频繁出现，比如编造出表中根本不存在的数据列，甚至引用其他表的列。第四是交互体验差。系统里的找数、取数等功能入口各自独立，用户需要在不同模块间来回切换，体验感很差，系统响应时间也慢。第五是评测缺失。我们当初只构造了一个仅包含五十多条数据的极简评测集，完全脱离了生产环境，即便把 Agent 调校到很高的分数，也不敢放心交给业务使用。
带着这五大核心问题，我们开启了 Text-to-SQL 的技术演进之路。这段路可以总结为五次关键的跃迁，每一次都由真实的生产痛点所驱动。第一次跃迁是从单链路 RAG 转变为 Multi-Agent 加元数据渐进式披露的解决方案，主要解决找数和体验割裂的问题。第二次跃迁引入了用户画像和持久化记忆，实现了从“千人一面”到个性化响应的跨越。第三次跃迁引入了语义建模，利用语义模型和辅助建模 Agent 来突破纯大模型生成 SQL 的准确率天花板。第四次跃迁则是设计了一套包含文件系统上下文和 Sandbox 等工具的复杂 Agent 工程底座，用以支撑复杂分析和长时间稳定运行。第五次跃迁我们引入了 Skill 机制，使用户能够自定义多步骤的流程化分析主题，最终实现了从取数到场景化分析的转变。
先来看第一次跃迁，其核心设计在于 Multi-Agent 架构。系统被分为两层。上层是 Supervisor Agent，负责背景知识加载、意图识别以及任务的拆解与编排，然后把具体任务交接给下层的专业子 Agent。下层是专业 Agent 层，包含了三个关键角色：Data Scope Clarity Agent 负责确认用户问题归属的数据域；Data Discovery Agent 负责在已确认的数据域内精准找到相关的表；而生成 SQL 的 Agent 则基于已确认的表元数据和业务知识，完成最终的 SQL 生成。在这个过程中，我们加入了两层 Human-in-loop 机制。在 Data Scope Clarity Agent 找到业务域后，会引入用户确认环节；在 Data Discovery Agent 找到相似表后，同样会引入用户确认。只有用户确认通过，Agent 才会进入下一步。这种两层确认体系能够确保 Agent 的推理过程不走偏。
另一个重点设计是元数据的渐进式披露。传统的 RAG 系统习惯于一次性通过相似性检索召回所有候选信息，但假设召回了十几张表，每张表又有上百个字段，如果把这些表描述、Schema 和列描述全部塞进上下文，真正有价值的信息可能只占其中一到三张表，这会造成极大的上下文浪费和严重的上下文腐化问题。
针对这点，我们引入了三层元数据披露逻辑。第一层是业务域定位，基于意图识别和公司已有的业务域基础元数据，直接在百万级表中定位出用户问题所命中的数据域，将范围从百万级缩小到域内的数百张表。第二层是域内表发现，基于语义检索、热度排名，结合表的语义规则，从数百张表中进一步挑选出候选表并交由用户确认。只有当用户确认后，我们才会来到第三层：深度知识展开，即加载这些候选表的完整 Schema、字段和关联业务规则。比如，当用户提问“东南亚地区昨天的 GMV 是多少”，系统会在 L1 阶段定位到“Marketplace Order”业务域，接着在表发现阶段锁定订单明细表和每日 GMV 增量表等一到三张表，用户确认后，这些表的完整信息才被加载。这一机制让上下文窗口既可控又精准。
找到了正确的表之后，流程进入 SQL 生成阶段。整个生成 Workflow 被我们拆分为四个步骤。当系统拿到用户问题和候选表上下文后，第一步会引入歧义和缺失检测。例如，如果候选表中包含多个与 GMV 相关的指标，系统会通过 Human-in-loop 方式让用户确认具体的计算口径，消除歧义后再进入下一步。第二步是多路并行生成候选 SQL。我们会同时启动三条生成路径：第一条是自校正模式，模型生成后会进行反思并自我修正，然后交出候选 SQL；第二条是任务分治模式，将问题拆解成子任务，分别生成结果后再合成为候选 SQL；第三条是简单直接生成模式。这三条路径产生的候选 SQL 会进入第三步选优环节，由 Agent 从中挑选出最优的一个，然后进入第四步验证和修复。在这一步，我们会先用 SQL 编译器验证语法错误，如果发现错误，则开启一个修复与再验证的闭环，由大模型结合我们植入的专用语法知识来提升修复效果，最终交出可执行的 SQL。
为了支撑高质量生成，我们将相关的上下文信息分为四层。第一层是最基础的 Hive 表元数据，包括表名、表描述、字段名、字段描述等信息。第二层是业务域知识文档，我们内部称之为 Mart，这里包含了仓库建模介绍、数据使用帮助文档及 FAQ 等，我们对其做了语义压缩和结构化提取。第三层是 Topic 运营知识，这允许 BI 同学补充业务口径、业务术语，并将其与少量的专有表或语义模型绑定，从而在根源上规避找表阶段的不确定性。第四层是技术类元数据，包含三类信息：一是高质量 SQL 硬样例，这是我们从线上日志中基于打分机制筛选出来的；二是表的一些 Sample Data；三是表的统计数据，这部分主要来源于 Metastore 中的 Hive Statistics 数据，比如行数和列分布情况，以及我们通过枚举值挖掘链路识别出的离散列可能取值，这些知识在生成 SQL 时能有效帮助大模型写对查询条件。
引入 Multi-Agent 后，效果和体验的割裂问题有了很大改观，但我们很快遇到了新的痛点：AI 的回答千篇一律。比如，同样是问“GMV 为什么下跌”，新加坡运营的同学关心的是他负责的特定市场订单表，而全球财务的同学则关注全局财务汇总的 GMV 数据。为了解决这个问题，我们进入了第二次跃迁，引入了双层个性化体系。
第一层是用户画像，我们从权限平台等系统拉取用户的组织架构、角色、所属区域、数据权限等静态数据，在对话开始前就将其加载到上下文中，这样 Agent 在开口前就已经“认识”了用户。如果线上询问的是新加坡的运营同学，Agent 就会倾向于推荐新加坡市场相关的数据表，并在生成 SQL 的查询条件里自动加上 region = ‘SG’。第二层是用户记忆，我们实现了跨 Session 的持久化偏好记忆。用户在平台上的交互行为，比如点赞、点踩、经常搜索的表、曾经做过的口径确认、配置的数据映射等，都会被持久化存储。在用户发起新一轮对话时，系统会基于相似性规则，将相关的历史记忆加载到上下文中，实现 Agent“越用越懂你”的效果。
有了个性化能力和多路生成的 SQL 框架，我们依然发现，纯靠大模型生成 SQL 的准确率很难突破预期的天花板。我们分析总结了三重挑战。第一重是业务语义理解，比如要生成正确的 SQL，系统需要推断出 GMV 的口径、活跃用户的定义，但在缺失业务规则的文本上下文里，这种多步加工过程中的幻觉会不断累加，导致语义类错误频发。第二重是表关联推理，OLAP 场景下的数据加工往往需要复杂的多表 Join，其关联链路又因数仓层级的复杂性而极难推导。第三重是 SQL 的物理实现，比如分区的选择、数据表查询分区范围的确定，以及各种函数语法的混用，这些直接导致了很高的语法错误率。这三层复杂度的叠加，是纯大模型方案难以提升的核心原因。
对此，我们的第三次跃迁是引入语义模型，作为一个数据抽象层，它充当大模型与底层物理数据之间的桥梁。我们做了三件事：一是将业务数据映射到物理表字段和计算逻辑上；二是预定义好标准指标、维度和过滤条件，使得大模型不再需要从零开始推理业务逻辑；三是让语义模型封装技术的复杂性，对外呈现得像一张统一的宽表或 Cube，封装了底层的 Join 关系和过滤条件。大模型看到的将是业务概念而非原始的物理表，这显著降低了其生成任务的难度，直接带动了整体准确率的提升。例如，计算“昨天新加坡区域的 GMV”，在纯 Text-to-SQL 模式下，系统需要推断统计口径、定位物理表和字段、绑定过滤条件、确定聚合维度，任何一步出错结果就不对。而基于语义模型，系统只需要生成一个极其简单的 DSL，描述清楚统计指标、时间范围和区域，剩下的 DSL 到 SQL 映射就不再依赖大模型生成，而是由语义引擎以工程化的、确定性的方式翻译为可执行的 SQL。
有了语义模型之后，我们就面临了一个工程决策：后续所有查询生成是否都要交给 Text-to-DSL 来处理？我们最终选择了混合 Workflow 的方式。用户问题提交后，会先经过一个意图识别与复杂度评估环节。这个环节分为两个维度：我们可以让大模型自主评估，用户也可以配置策略进行自路由，例如将个人的 Topic 数据域设置为一直走语义模型或一直走 Text-to-SQL。如果交给 Agent 评估，Agent 会基于问题的复杂度来做路由选择。如果问题简单且偏探索性，就走传统的 Text-to-SQL 链路；如果问题涉及复杂的计算逻辑且有可用的语义模型，就走 Text-to-DSL 链路。两条链路最终都会生成物理可执行 SQL，交付给后续的取数、可视化和分析。
语义模型虽然能提升准确率，但其构建过程本身非常复杂。传统方式是由数据专家人工构建，周期长且费力。为了缩短这个工作量，我们设计了辅助语义建模 Agent，目前还处于 Beta 阶段。它的输入包含三类元数据：第一类是表结构、字段描述和数仓层级等基础元数据；第二类是已经在线上运行的 SQL，以供 Agent 学习查询模式、字段常见的计算逻辑、指标与过滤条件的绑定关系等；第三类是公司现有报表平台上已配置的数据集和看板，从这些定义中学习维度与指标配置，从数据集中学习指标的计算口径。拿到这些信息后，语义建模 Agent 基于用户的建模意图执行四项操作：指标推荐、维度识别、关键路径发现、数据关系识别与映射填充。它生成的结果是一份语义模型的草案，这份草案并不会直接上线，而是需要交由启动建模的数据专家进行审核、修改和确认，确保没有质量问题后才会上线，用以支撑 Text-to-DSL 链路。这个思路的核心是，通过辅助工具降低复杂度，但最终的数据质量交由专家把关。
语义模型上线也并不意味着终点。我们在生产环境中认识到，打造一个完美的 Agent 或语义模型从来不是一蹴而就的，它更像一个需要不断带教、辅助优化的实习员工。为此，我们建立了一个“四步循环”来持续优化语义模型。第一步是 AI 辅助建模，快速产出草稿。第二步是语义驱动查询，模型上线，执行 Text-to-DSL 查询，但会打上 Beta 版本的标签。第三步，线上用户对 Agent 输出结果的反馈信息，会被回流给数据专家，由专家进行 Review 和审核，从中发现语义模型的缺陷并进行优化。第四步，优化后的语义模型重新上线。这样就形成了一个“建模、查询、验证、优化”的反馈闭环，保证语义模型在线上能够持续正向迭代。
AI 取数的准确性问题得到阶段性解决后，另外一个核心挑战浮现了出来：如何保证 Agent 在线上能够 24 小时稳定运行，并拥有完整的评测和运营闭环？我们的工程体系全貌可以被划分为技术体系、评测体系和运营体系三大部分。技术体系内部又细分为六大块：知识管理、文件系统上下文、隔离环境、Agent 工具箱、Agent Skill 以及个性化能力。我挑选其中两个最关键的技术点展开。
第一个是文件系统上下文。在 Data Agent 场景下，模型上下文比一般的聊天 Agent 要复杂得多，它涉及表的基础元数据、Schema、语义规则、个性化数据、语义建模知识等。如果一股脑地把所有信息都塞进上下文窗口，不仅很容易撑爆窗口，还会触发严重的上下文腐化问题。我们的做法是引入一个虚拟的文件系统，其后端存储可以是 MySQL 或分布式文件系统。我们把各类知识按层级结构组织起来，这和元数据的渐进式披露相辅相成。在对话开始时，只加载最上层的元数据，如用户画像；在确定数据域时，加载 L1 层的业务域知识；只有当用户确认了具体的表之后，我们才展开最详细的信息和语义规则。而那些在当前阶段不再需要的信息，则会被择机从上下文窗口中卸载下来。此外，文件系统上下文另一个重要作用是缓存多步分析产生的中间结果。比如在一个归因分析任务中，第一步取出的数据集，后续的每一步分析都依赖于它。如果把这个庞大的数据集一直放在模型上下文里，窗口会被严重占用。我们的做法是将取到的数据以标准化 DataFrame 的方式存储到文件系统中，模型上下文中只保留一个 Reference 或数据路径。当后续步骤需要使用工具时，直接传递这个 Reference 即可，而不必在上下文里流转一个超大的数据集。
第二个重点是隔离环境，也就是 Sandbox。我们给每个 Session 中运行的 Agent 都提供了一个权限隔离和资源隔离的沙箱环境，以此保证运行的安全与可控。我们提供的一些关键工具，比如批处理执行和 Python 代码执行，全都在这个沙箱环境中完成，从而有效防止恶意 Prompt 利用工具进行破坏性操作。
接下来的评测体系同样至关重要。它包含评测集建设、评估执行、结果评分三部分。在评测集建设上，我们踩了不少坑。最早一版的评测集由 QA 团队帮忙生成，只有五六十条数据，严重脱离真实的业务场景，我们根本无法依据它得出的数据去优化一个面向生产的 Agent。后来我们转变思路，决定基于线上真实使用的 SQL 来构造评测集。我们面向特定的分析主题或重点优化领域进行表的选择，搜索线上被执行成功且执行频繁的 SQL，以及源自成熟稳定报表平台的 SQL，然后让大模型依据这些 SQL“反向生成”出对应的自然语言问题。生成的问题全部交由人工 Review，审核通过后才积攒到评测集中。最终，我们积累了一个包含数千条数据的评测集，它面向不同的分析主题和难度级别，成为我们的离线评测基准。
在结果比较方面，我们也做了很多探索。我们最先尝试了通过 AST 抽象语法树来比较两个 SQL 是否一致，但很快发现，相同的语义逻辑可以有多种多样的表达方式，它们对应着完全不同的语法树，这种比较方法效果很差。然后我们选择了基于大模型的准确性比较，这在简单场景下效果不错，但在复杂场景中，由于存在多种等价的写法，大模型评估的分数并不理想。我们通过人工比较和模型评估的交叉验证，确认了这个现象。最终，我们决定以执行准确性比较作为主要的评估手段。为了解决执行结果比较中的一些问题，比如 AI 生成的 SQL 可能带有临时别名，或者时间列的格式灵活多变，我们对时间字段做了归一化处理，并基于类似编辑距离的算法来计算列名的一致性；针对浮点数或经过类型转换的数据，我们设计了基于残差和容差的数据比较策略。我们把这一整套结果比较逻辑做成了一个工具，集成在评估 Pipeline 中。现在，平台上的知识库、Agent、模型的任何改动，都可以方便地触发离线评估链路，来对比改动前后的效果变化。
在介绍运营体系之前，我想插入一段关于元数据治理的实践，因为它对整体效果的影响非常关键。我们在开始做 Text-to-SQL 的时候就发现，平台上有大量的 Hive 表完全没有表描述和列描述。大模型在只有干巴巴的表名的情况下，几乎不可能找到符合用户需求或语义正确的表。所以我们同步启动了一个元数据治理流程。平台上有百万级别张表，靠人工去治理是不可想象的，因此我们设计了一个 AI 与人工协同的四步治理流程。
第一步，我们按照业务过程和数仓的层级，对一些表进行分组。例如，将相同业务语义的表，或是按 Region 拆分的表，都放到同一组内。这些同组的表共享相似的业务语义。第二步，以表组为基本单位，交给 AI 生成描述。它依赖的信息不仅是平台上的名字、字段，更大量地依赖了业务域建模的相关知识、用户帮助文档和 FAQ，从而生成候选的表描述和列描述。第三步，这些候选描述不能直接上线，而是必须交给业务方的负责人或表的 Owner 进行逐条的人工 Review。他们可以选择采纳、修改或补充描述，只有经过人工审核的描述，才能正式生效。第四步是血缘扩散，我们把已经治理好的核心表，通过血缘关系将其描述和计算逻辑自动扩散到它的下游表，自动为下游也生成描述。当然，扩散出来的描述同样也需要业务方 Review、修改和确认。
治理前后的效果改善非常显著：AI 生成的语义描述直接被业务方采纳、无需任何修改的比例高达 70%，这证明了方案有明显的正向收益；对于中等规模的 OLAP 表，治理时间从原来的三十分钟缩小到了十分钟左右，节省了 67% 的时间；我们通过人工方式只治理了两千张核心表，但通过血缘机制，描述的扩散与治理最终覆盖了十五万张以上的表；在找表阶段，准确度在治理前后最高提升了 15 个百分点。这充分说明，元数据的质量和丰富程度，对找表阶段的 Agent 帮助巨大。做 Data Agent 不能只盯着模型和工程架构，数据质量这块脏活、累活，也必须下苦功夫去做。
接下来就是我们的运营闭环。我们很早就发现了一个事实：线下的评测效果，绝不等于线上实际运行的效果。线下评测集即使基于线上数据构建，但随着 Agent 的迭代，分数总会越来越高，而线上用户问题千变万化，评测集的概括性会越来越跟不上。
我们的运营闭环做了三步。第一步，基于线上反馈采集和人工标注，构建线上准确率的评估系统。线上反馈采集既包含用户拷贝执行生成的 SQL、追问、纠正等隐式反馈，也包含点赞、点踩等显式反馈，还有数据团队同学在后台对结果的人工标注。这三者结合，提升了线上准确率计算的效率并收口了其准确性。第二步，是知识管理和 Topic 运营。Topic 相当于一个私域的业务域概念。BI 同学或者有数据分析需求的同学，可以把自己经常使用的表放到一个独立的 Topic 里，形成一个面向自己的私域数据组，完全绕开繁琐的找表过程。同时，通过语义建模构建的模型也可以绑定到 Topic 上，让该 Topic 下的所有数据查询都走语义模型，避免 Text-to-SQL 带来的随机性干扰。第三步，是效果验证和数据回流。我们做了后台工具和 Test Session 功能，运营同学可以快速验证他们在 Topic 中补充的业务知识或规则效果如何，效果好了就上线。所有的上线效果都有看板和监控。最后，所有的标注数据和用户记忆，都会被回流到算法平台，算法同学正在利用这些数据帮我们训练一个基于自有数据的自有模型。
前面的工作解决了“运行稳不稳”和“取数准不准”的问题，而接下来要探讨的第四部分，是如何基于 Skill 能力，让 Data Agent 支持可定制的场景化分析。这是我们将其从一个取数工具，进化为能够支持复杂分析场景的关键一步。我们最早尝试的是让 Agent 做自由归因或自由探索分析，但结果暴露了很大的问题。Agent 经常会绕过关键维度的下钻和交叉分析，直接给出一个结论。在某些情况下这个结论可能正确，但在更多情况下，它是不对的。我们去咨询了专业的 BI 同学，得到的反馈是：无论结论对错，他们都“不敢用”。因为分析过程是个黑箱，他们不知道数据是怎么一步步得来的，结论完全无法验证。这让分析的商业价值大打折扣。为了保证分析过程的可信与可靠，我们引入了 Skill 机制，在模型的自主分析和可定制的流程化分析之间寻找一个平衡点。这里的 Skill 实现，遵从的是 Anthropic 的 Agent Skill 规范。但在我们的 Data Agent 语境下，Skill 指的是由数据分析师定义的、多步骤的、复杂的数据分析流程。
以归因分析为例，一个典型的归因 Skill 可以包含一个五步流程。第一步是指标下钻，通过 SQL 拉取时间序列数据，观察指标趋势。第二步是按国家、品类、渠道等可用维度进行拆解。第三步是依据维度拆解，进行计算和分析贡献度排名，并执行一些交叉分析逻辑。第四步是找到根因，按影响因子排序定位出根本原因。第五步是生成结构化的分析报告。
看一个具体的 Skill 执行流程示例：当用户提问“帮我分析上周 GMV 下跌的原因”，Agent 首先识别意图，并将其与上下文中一个相关的 Skill 描述进行匹配。匹配成功后，该 Skill 的完整 Markdown 定义会被全部加载到上下文中，Agent 就会严格按照这个定义好的流程去一步步执行。每一步执行都会输出中间结论和结果。这种机制实现了中间步骤可追溯、异常可回归、流程不可跳过、结果可验证，从而极大地提升了分析结论的可信性。这里的 Skill 机制和我们前面提到的工程底座——Sandbox 和文件系统上下文——是相辅相成的。多步分析中产生的大量中间结果数据，并不会存放在模型上下文里，而是存放在文件系统中，模型只需要记住其 Reference 或路径即可。如果下一步需要用 Python 执行分析，就加载那个路径的数据；如果是大模型去做下一步的推理，就按需加载一小部分采样数据到上下文，防止整体数据流转导致上下文撑爆。
总结来看，这种基于 Skill 的分析方式为 Data Agent 带来了三大价值：一是可复用。一次定义，全员触发。它能把资深分析师脑中成熟的标准分析流程，变成平台级资产供所有人共享。二是可信赖。固定的流程保证了论证的严谨性，管理者或应用方可以看到一步一步的计算过程，从而验证最终结果的准确性。三是可扩展。我们提供了 Skill Builder 和 Skill Runner，用户可以自定义他们想要的任何分析 Skills，通过上传文件或在平台上直接创建，就像使用 Claude Code 的 Skill Creator 一样。
回顾我们整个 Data Agent 从 AI 取数工具到面向分析场景的全过程，我们通过 Multi-Agent、个性化与语义模型提升了准确性，通过包含 Sandbox 和文件系统上下文的工程底座来支持多步骤、长时间稳定运行，并最终引入 Skill 机制，使分析师和 BI 团队能够定制和沉淀分析流程到平台上。
放眼未来，我有几个关于趋势的判断。第一是关于 Agent Harness 的演进。Harness 就像是 Agent 的操作系统。如果 Agent 等于大模型加 Harness，那么 Agent 减去大模型，剩下的所有东西都属于 Harness。我们之前做的很多 Agent 工程工作，都属于 Harness 的范畴。但我们需要思考，这是否是“旧瓶装新酒”？答案既是，也不是。“是”的部分在于，我们做的诸如调优 Prompt、优化工具调用逻辑等工作，随着模型自身能力的进化，其带来的边际效益正在逐步降低。但“不是”的部分在于，另一些工作，比如状态管理、上下文管理，以及从个性化到通用化的转变，这些无论模型如何进化都必须去做。以前我们给大模型做工具是逐项添加，比如给它一个加法工具、一个减法工具放到上下文里，未来工具应该是通用化的场景。比如，给它“一台电脑”、一个可操作和接收反馈的环境作为通用工具，它通过标准化的接口就能自由排列组合去解决任务。这一点，从 Anthropic 从 4.5 到 4.6 的新模型中已经能明显看到这种能力的显现。
第二是 Agent First 的理念，未来的数据平台应该是为了 Agent 而设计的，而不是把 Agent 当作平台上的一个附加工具。Agent 将会成为人与数据交互的新界面。
第三是从 AI 工具到 AI 员工的转变。1.0 时代的 SQL 取数助手是一个工具；2.0 时代它变得更像一个支持分析的助手；而在 3.0 时代，就像我们看到的一些产品形态，Agent 正在向一种“数字劳动力”演进。其关键点是 Schedule Channel 和 Agent Skills 的自我生成与进化能力，最终让 Agent 能够独立地接收任务、自我演进、自我修复和自主学习。
第四是 Agent 治理。Agent 究竟聪不聪明、效果好不好，都需要伴随可追溯性、可控性和可持续的评估能力。这是让我们敢在生产环境下大规模落地 Agent 的先决条件。
