如何构建企业级数据智能体：Data Agent 开发实践

“What I cannot create, I do not understand.”  --  Richard Feynman

2025年3月，笔者曾撰文探讨LLM驱动的AI Agent如何重塑人机协同模式，彼时更多聚焦于技术实验与理论推演，尚未在实际业务场景中落地。如今，随着Agentic AI技术的成熟，Data Agent for Analytics 正式从实验室走向企业生产一线——它不仅是对AI Agent潜力的验证，更是企业级数据分析范式的革新。 

本篇将介绍DMS的一款数据分析智能体（Data Agent for Analytics ）产品的技术思考和实践。Data Agent for Analytics 定位为一款企业级数据分析智能体， 基于Agentic AI 技术，帮助用户查数据、做分析、生成报告、深入洞察。由于不同产品的演进路径，背景都不一样，所以只介绍最核心的部分，来深入剖析如何构建企业级数据分析助手：能力边界定义，技术内核，企业级能力。希望既能作为Data Agent for Analytics产品的技术核心介绍，也能作为读者的开发实践的参考。

很多客户会问Data Agent是不是ChatBI，是不是另一个NL2SQL产品。我一般都会明确回答不是，并补充Data Agent 使用了ChatBI和NL2SQL相关的技术。但为了更好的让用户理解本质的区别，需要先做一些概念的抽象， 聚焦在数据与分析技术领域上，以及对Agentic AI的介绍，  抽象能够更好的理解。

数据与分析主题在大语言模型起来之前已经比较热门。我们可以借助Gartner对数据与分析的定义，尝试把Data Agent的分析能力边界定义清楚。 Gartner把数据和分析定义为：管理数据以发挥数据作用，分析数据以优化决策、业务流程和成果的方法。并将核心分析技术按照目标分为四种：

• 描述性分析（Descriptive analytics）：使用BI工具、数据可视化和展示面板来回答：发生了什么？
  

• 诊断性分析（Diagnostic analytics）：需要更深入的分析和数据挖掘能力来回答：为什么会发生？
  

• 预测性分析（Predictive analytics）：通过概率预测或模拟一段时间内一系列结果 来回答：可能发生什么？
  

• 规范性分析（Prescriptive analytics ）：以结构化方式整合已有的知识和优化技术，在约束范围内寻找最佳结果并生成可执行的行动计划，以此来回答：应该做什么？

  
  

 ChatBI或NL2SQL类的产品分析技术本质上在传统的BI分析基础上结合了LLM能力。 传统的BI分析侧重描述性分析和诊断性分析，也就是回答发生了什么，为什么会发生问题，为决策提供事实依据， 典型流程是：业务系统，ETL工具，数据仓库，预定义指标最后到报表和仪表盘。

传统的BI分析技术，优势在于直观可控， 业务人员可以自主地生成报表， 工具链完整，技术成熟。 劣势主要在分析能力上，比如深度上存在局限，依赖预定义指标，需提前定义分析维度和提出假设，比较难以发现隐藏洞察。

传统的BI分析对于预测性或者规范性的分析洞察是比较困难的，所以这里提出了高级分析技术， 涵盖了预测性，规范性和人工智能技术。偏向于使用数据科学和机器学习技术，主要流程包含数据处理与特征工程，模型构建，模型推理最后到行动建议。

高级分析技术的优势是可以利用不同的数据输入类型和来源，为分析者提供更多的角度洞察，推动企业作出更明智的商业决策。通过ML模型预判趋势/风险，优化算法生成行动方案，以及从非结构化数据中挖掘关联规则，比如自然语言处理，挖掘隐藏模式等。 劣势主要是门槛较高，落地周期长。 数据类型支持上，除了结构化数据， 相比传统BI分析，多了非结构化，实时数据流以及图关系数据，所以对数据治理要求也比较高。 另外涉及到机器学习，尤其是用到了深度学习模型，可解释性存在挑战。 

我们现在可以更明确地定义DMS Data Agent for Analytics了。 我们希望把 Data Agent 定位为一款能够同时覆盖传统BI分析（描述性、诊断性）和高级分析（预测性、规范性）能力的智能体。也就是既可以作为自然语言到SQL查询的转换工具（NL2SQL），也可以生成预定义报表的聊天式BI（包括ChatBI），更重要的是一个具备理解分析意图、规划分析路径、执行复杂任务、并生成深度洞察的自主智能系统。

这里先尝试定义Data Agent的价值主张，技术实现也是围绕以下的价值主张：

• 打破分析能力边界： 用户无需预先知道该用描述性统计还是构建预测模型。Data Agent 能根据用户模糊或复杂的自然语言提问（比如“为什么上季度华东区销售额下滑？预测下季度趋势并给出改善建议”），自动判断所需的分析技术组合，无缝衔接查询、诊断、预测和规划。
  

• 降低高级分析门槛： 将复杂的机器学习、优化算法等高级分析能力封装在Data Agent内部，用户通过自然语言即可调用，无需具备数据科学专业知识，缩短从问题到洞察的行动路径。
  

• 摆脱预定义的限制： 不再局限于预定义的指标、维度和仪表盘。Data Agent 能动态探索数据，发现预定义框架之外的隐藏模式、关联关系和异常点，提供更全面、更深入的洞察。
  

• 实现端到端分析闭环： 从数据查询、可视化、根因诊断、趋势预测到行动方案建议，能够在一个连贯的交互过程中完成，过程可解释，分析过程可复用，提供闭环的分析体验。
  

• 具备企业级更大规模数据的分析能力：不限于分析数据库或者表格文件，借助于云原生计算能力，能够无缝对接大数据生态，使用分布式计算（Spark/Ray）实现海量，多模的数据实时分析。

  
  

Data Agent与ChatBI等市面上其他的问数的产品区别是什么呢？毕竟都在强调具备Agentic AI的能力。 Agentic AI（智能体驱动的人工智能）的概念在LLM出现之前就存在（例如在强化学习、传统AI中）， 但随着LLM能力的突破性进展，Agentic AI作为新一代AI范式被广泛认可。其核心可定义为：以大型语言模型为认知引擎，具备自主决策、目标导向和环境交互能力的智能体系统

我们可以从利用模型推理的程度来进行分别，也就是Test-Time Scalling。 是模型推理阶段的Scaling Law。 

随着OpenAI o1和DeepSeek R1等模型展示了强大的CoT推理能力，业界认识到增加推理计算量能显著提升复杂任务的准确性。这催生了TTS（Test-Time Scaling）这一新兴的研究领域。TTS模仿了人类在处理困难问题时的倾向，也就是投入更长的时间和更多的思考资源来提高决策的可靠性， 对于AI Agent来说， 通过增加LLM的测试时间， 可以增强其自我改进，减少人工监督。 接下来我们结合TTS从架构差异，性能和适用场景进行简单对比。

• 架构的差异：

• ChatBI（问数）优势：架构简洁，基于NL2SQL技术，易于集成现有BI平台，支持快速意图识别和可视化输出，适合对话式交互。局限：TTS应用有限（简单的CoT），被动响应模式，缺乏上下文记忆和多步推理，难以处理复杂查询和根因分析。前期配置工作较多，比如需要对接入的数据源进行清洗，质量优化。同时为了提高自然语言查询的准确度，需要预定义好数据模型（维度，独立，层次关系等）
  

• Data Agent 优势：多代理架构，集成知识库和长期记忆，深度应用TTS（多路径探索、迭代采样），支持主动监控和个性化洞察。局限：架构复杂，实施门槛高，对于简单的问题容易陷入复杂的逻辑陷阱中，导致取数效率不高。

• 性能：

• ChatBI（问数）响应速度快，低延迟（单轮100-5000 Token），适合即时洞察（如销售汇总、图表生成），推理深度有限，缺乏主动性。
  

• Data Agent：深度分析（异常检测、预测建模、行动建议），支持多源数据处理，延迟较高，Token消耗大，但可以基于问题的难易程度实现推理时间的最优分配。

  
  

• 适用场景：

• ChatBI（问数）：适合标准化、高频的简单查询场景，但对数据质量要求极高，需要提前做数据建模。

• Data Agent：适合复杂、个性化的分析场景，对数据质量要求不高，提供主动式、智能化的数据洞察体验。

  
  

最后，我们可以用表格对传统BI/ChatBI，高级分析和Data Agent差异化进行总结：

通过前面的介绍，Data Agent将LLM作为认知引擎。 LLM基于语言模式的统计学习，缺乏对事实世界的真实理解。生成的内容是对训练数据中模式的重组，而非基于逻辑推理的事实表述，这就会导致数据分析过程中，有可能出现幻觉。  其次是上下文学习能力（ICL）的局限性，比如差的Few-shot会误导后续推理，泛化能力问题，难以理解复杂场景下的深度语义和意图等。 另外是工具使用上，一方面LLM对于太多工具难以适应，一方面工具调用也存在安全的风险。 

接下来重点介绍 Data Agent 针对以上的问题是如何优化的，以及如何让LLM像分析师一样思考与行动，包含以下几个方面：

• 深度语义理解
  

• 上下文管理
  

• 幻觉抑制
  

• 工具的使用

  
  

首先需要理解用户想要什么，当用户说"分析一下销售表现"时，作为数据分析的智能助手， Data Agent需要考虑提问者的角色背景、所处的业务场景、以及历史对话记录中学习的用户偏好，计算口径等，需要记忆沉淀能力。

其次是语义理解，语义理解的复杂性体现在同一个词在不同行业、不同公司甚至不同部门都有不同含义。"活跃用户"在电商场景下可能指30天内有购买行为的用户，在社交产品中可能指7天内有登录行为的用户，在SaaS产品中可能指当月有核心功能使用的付费用户。Data Agent必须维护这些领域特定的语义映射，并在对话中动态选择正确的解释。

数据的元数据（Catalog）决定Data Agent的数据理解， 比如多表关联查询，或者某个字段的分布特征，如果一开始 Data Agent不理解或者未完全理解，直接导致后续分析逻辑错误，我们把数据理解作为独立模块，便于在用户录入和分析过程中可以复用。

计算口径的澄清是语义理解的另一个关键维度。企业数据分析中最常见的问题之一就是：同样的指标名称，不同团队计算出的结果不一样，这往往源于对计算口径的理解差异。是否包含退货、是否剔除测试订单、是用下单时间还是支付时间、汇率是用实时还是月末等等。

我们把以上的内容抽象为知识和记忆。

知识与记忆形成了人对事物的认知，AI Agent中的知识和记忆是什么呢？在AI  Agent 系统中，“知识”通常指Agent可获取的领域事实、规则或静态信息，如预先收集的文档、知识库或训练数据中的隐式知识；而“记忆”指Agent在交互过程中动态记录的上下文信息和经验，如用户历史对话、偏好或之前决策。知识和记忆如同光谱的两端，二者在某种程度上可以相互转化。 

• 左侧是具体，个性化的记忆，偏向具体的事实记录，有情景性和特殊性。
  

• 右侧是抽象，通用的知识，原理和规则，具有逻辑性强，通常是经过整理和归纳的通用信息。
  

• 中间存在过渡状态，如同光谱的颜色渐变一样，当记忆被多次验证、结构化、抽象化后，它可以上升为知识；反之，当知识被个性化使用时，也会沉淀为新的记忆。

  
  

哲学家对知识的定义始终未达成一致，不过我们可以尝试定义 Data Agent的知识，可以按照不同的抽象层次进行划分：

• 底层是基础数据知识，关于数据本身的详细信息，包括数据的Catalog（通常包含库表列，名称含义、数据类型，存储方式，采集来源，数据血缘等），是 Data Agent理解和获取原始数据的基础。
  

• 中间为分析方法知识，包含各种用于处理和分析数据的算法，模型，统计方法或口径，以及自定义的分析流程， 决定 Data Agent如何从原始数据中提取有价值的信息和规律。
  

• 最高层为行业通用知识，包含通用的业务逻辑，行业术语（黑话），概念以及行业的一般性规则和理念等，用于指导 Data Agent的分析方向，如何解读分析结果，并使得 Data Agent以符合行业或公司习惯的方法进行交流和应用分析结果。

  
  

知识和记忆的难点在于如何召回，二者的召回目的，流程和策略都有较大的差别，知识的目的是保证分析的正确性与通用性，提供确定性，逻辑规则，而记忆是为了连续性和情景化。 策略上，知识可以使用RAG，层级（上文的三个抽象层级）分类召回。 而记忆需要根据时间和热度召回，记忆需要具备遗忘机制。

最后，人与人之间沟通需求时，也不是一次问答就能够清晰明了的，所以多轮对话也是必要的， 这就要求 Data Agent 需求分析模块具备“反向提问”的能力，当模型检测到语义置信度不足，通过Human-in-the-Loop 意图澄清机制，使得Data Agent能够在前期确保问题被正确定义。

在语义结构明确后，Data Agent 会自动生成意图执行计划，以结构化方式给用户展示分析思路，用户也可以根据需要进行调整。 

如何处理开放式探索性类型的问题， 很多时候用户可能也不知道怎么提问，就像老板给你分配一个模糊的任务一样，老板内心里面可能希望你发现一些洞察，但是不知道具体是什么。 这类问题对人来说简直是天灾，没有目的地分析，对于认真工作的你来说，往往需要耗费更多的精力。 但是对于Data Agent来说，这反而是其最擅长的点。 Data Agent可以结合业务语义，数据语义从不同的角度进行分析。在这个过程中，可能会给你更多的启发，帮助你进一步下钻分析。

Data Agent一轮分析完后给出问题建议，帮助用户进一步洞察

Context Engineering 是当下比较流行的AI Agent开发的工程实践， 针对每一次给到LLM的上下文进行动态的设计，构建，和优化，上下文内容除了系统提示词、角色和目标描述、用户需求外，还有对话历史，外部知识，工具调用等。 简单来说，上下文工程决定了模型知道什么，何时知道以及何种方式知道， 最终目的是LLM在约束的搜索空间下， 可以更好的理解、推理和决策。

如下图，Data Agent 的上下文管理实际上是一个完整的智能认知系统的构建，核心流程如下：从规划，分析，反思到学习，构建一个完整的智能认知系统。 

 Agent Core Loop

进一步展开，如下图， 从右往左看：

Data Agent上下文管理

• Data Agent通过Multi-Agents协作，每个Agent具备独立的上下文管理能力，有助于进一步缩小模型的搜索空间， 通过协作完成复杂的任务。

  
  

• Context Windows内容是动态的，也就是大家常看到的上下文管理能力， 比如长度控制，KVCache优化， 按需从长期记忆层寻找相关规则和知识内容。 

  
  

• 我们称为Cognition，有点拟人化意思。 包含前文描述的三层知识（基础数据知识，分析方法支持和行业通用知识），同时包含Agent的长期记忆，  作为 Data Agent的认知基座，为每次分析提供认知支撑。 

  
  

• 最左边是外部输入层，具备多源知识融合能力， 主要负责将文档、数据库、实时搜索等异构数据源统一处理，通过知识图谱和向量化技术实现语义级的知识存储和检索。

  
  

用户经常会问使用Data Agent做数据分析，模型有上下文窗口限制，是怎么放得下的， 我们通常回答放不下，因为Data Agent并不会把用户的原始数据给到模型上下文， 根本原因不是上下文窗口问题，而是模型推理的本质， 虽然今天像Qwen，DeepSeek这类模型具备Thinking模式，模型进行依然是语义空间的模式匹配和概率推理，对于精确的数值计算，逻辑推导，模型本质是在模拟计算过程，而非真正执行计算。 比如下面的例子， 模型会根据问题进行下一个Token预测， 如果使用Greedy Decoding方式，每次取概率最大的Logis或token，很有可能计算错误，设置不同的tok_k或者temperature会产生不一样的结论。

来自：Chain-of-Thought Reasoning without Prompting

 如果结合LLM的预训练机制，我们可以进一步分析LLM数字幻觉的原理，尽管今天的LLM在数学能力上显著提升，在一些竞赛上已经超过了大部分人，  但在处理需要精确数值理解的任务时，仍易产生数字幻觉。具体体现在以下几个方面。

• 分词问题，LLM在推理之前，会把输入进行分词，也就是我们常说的Token化，然后再进行Embedding向量化。 有时LLM对数字的分词是非原子化的，比如“489,012” 可能被分解为：489、 ， 、012 三个独立的Token，这不仅割裂了数字的整体性，使模型难以将其作为一个单一数值实体处理，分隔符Token（如逗号）还可能引入干扰或歧义。
  

• 位置编码干扰，主流的序列位置编码方法（比如RoPE）主要解决文本的相对位置依赖性，但对数值的绝对精度需求支持不足。位置编码的量化特性也可能对邻近小数字的表征造成不利影响。
  

• 预训练知识中数据分布的长尾效应， 数据中某些模式的普遍性会导致模型产生系统性偏差。例如我们之前遇到的一个真实案例：训练语料中“第X个”的表达常以“第0个”或“第一个”对应索引0开始，导致模型在明确要求“从1开始计数”时，仍顽固地输出从0开始的索引（BadCase）。相反，要求“从100开始计数”则可能正确，因为该模式在数据中相对少见。
  

• 数字模式的过拟合，比如LLM学到了“销售增长通常在20-30%” 这样的模式， 当实际需要计算时，如果PE没有做好，模型很可能会输出这个“经验值”
  

• 语义空间和数值空间是不对等的， 我们知道LLM基于自然语言模式匹配，其数值推理缺乏数学严谨性，在Embedding空间中，两组数字语义距离可能离得很近，但实际上对数值分析来说，毫无意义，甚至产生误导。

  
  

那如何解决这个问题呢，一种方式是通过提示词工程（PE）手段进行优化，比如COT，Step by Step等，这些PE优化手段的主要作用是：提升推理过程的透明度、引导LLM结构化思考、暴露潜在错误，它们本身不能直接大幅降低前面描述的LLM固有幻觉。在Agent应用场景中，这些方法的作用是让错误更容易被发现，并为后续的验证或工具调用创造条件。另外也可以使用Self-Consistency 方式，采样多个推理路径并投票，能在一定程度上减少随机错误的发生。Self-Consistency 假设正确的答案往往对应多条合理的推理路径，从统计上是优于单一路径上的结果。

另外就是借助工具，比如计算器。 2023年6月GPT-4首次引入Function Calling，而Calculator是最早的示例之一。 

观察今天的大语言模型，主要在内容创作，Math和Coding能力方面，这很大原因是这些知识都是人类对世界的抽象语言，并且已经数字化，这正是LLM的学习来源。 对于Agent来说，使用LLM 来Coding，实际在创造工具，感知真实世界，解决更复杂的问题，可能是通往AGI的必经之路。各大厂商都在不断增强LLM的Codding能力。

Data Agent 综合了以上的优化思路，尤其是以 Code-based Reasoning 为核心策略， LLM负责理解问题并生成可执行代码，比如SQL，Python 以及其他的DSL，作为中间的逻辑表示， 将最终答案生成的责任转移给代码执行引擎，使输出可执行、可解释、可复现。将产生幻觉的风险从“自然语言层面的直接幻觉”转化为“逻辑层面的代码正确性风险”，后者可通过工程化手段（代码检查、测试、验证）进行更有效的系统性管理，从而从大幅减少LLM 在最终数值和事实断言上的编造问题。

其次Data Agent使得LLM像一个数据分析师那样思考：理解问题，数据获取，数据验证，逻辑建模，可视化，结论生成等。除了通过编写SQL或者借助Pandas，Numpy这类数据分析常用的库以外，Data Agent也会和数据分析一样，通过数据可视化进行直觉验证，毕竟一图胜千言，借助VL模型可以比较容易地洞察数据趋势和异常点。 Verify机制也是Data Agent最重要的部分，不仅可以对可视化效果进行审查，最重要的是对最终的分析结果进行上下文验证，进一步降低幻觉。另外在数据分析层次上，比如DIKW模型的内化，有助于 Data Agent更加的专业化的分析。

LLM因为有了工具，不再局限于文本生成。 MCP掀起一波AI Ready 热潮，可能MCP的构建者比MCP用户还要多。 实际上模型能够准确地用好几个工具已经是非常大的进步了。实际经验来看，超过10个以上，主流的LLM很难得心应手。总结下来有几个方面。

• 当系统中工具数量增多时，系统注册了大量工具（例如：查询数据库、绘图、报表生成、外部 API 调用等）， 模型需要根据自然语言描述在这些工具之间进行匹配，面临工具选择的语义模糊性，导致工具误选，漏选。

  
  

• 其次是工具多，增加了组合复杂性，尤其是参数复杂或中间状态不透明时，很容易导致调用链断裂，结果不一致和死循环。

  
  

• 上下文容量与记忆碎片化问题， 工具说明会占用大量上下文，工具调用之间的状态和结果难以长期保留，导致记忆碎片化，信息丢失。

  
  

• 工具接口不统一，往往由不同团队或系统提供，接口规范、输入输出格式、错误机制各不相同，无形地增加了LLM推理时的搜索空间。 

  
  

• 最后是安全问题，工具调用往往意味着执行外部代码或访问敏感数据，外部工具恶意 Prompt 注入可能诱导模型越权执行。

  
  

Data Agent 对于工具的选择始终保持克制，前文提到 Data Agent 使用 “Code-based Reasoning” 的策略，专注于数据分析， 除了给到LLM的上下文是连贯的， 我们希望代码逻辑也是连贯的，也就是LLM的输出是可执行、可解释、可复现的。 结合DMS的DataOps的能力积累，我们为客户提供一个安全的，云原生的沙箱环境，Agent通过统一的交互协议与之通信。 这种模式有以下几个关键优势，也是 Data Agent服务于企业客户数据分析场景的关键。

• 模型只需要知道一个工具，可以执行SQL，Python代码，画图，编写文档，并且是交互式的，可验证计算，有助于LLM自动修正与逐步推理。
  

• 具备持久执行上下文，代码执行器可以在多轮推理中保留变量、函数、数据表和中间结果，变量与函数在多轮推理间复用。这种模式与模型上下文的目的是一致的，能让 LLM 以更自然、更一致的方式进行多步推理与探索。同时可以固化为分析文档，使得分析流程可追踪和可解释。
  

• 与数据分析生态融合， 兼容主流 Python 数据分析与机器学习库，在分析过程中动态构建、训练模型，利用算法结果辅助推理，传统的算法提供确定性，LLM 提供语义解释。
  

• 大小模型协同，尤其是自然语言处理领域除了LLM，还有许多专有的语言模型，在情感分析，文本聚类等场景下，尤其是数据规模比较大的情况下，性能效率更出色。
  

• 支持部署在用户VPC网络环境，计算沙箱环境与VPC内存储与计算资源打通，构建私有网络分析环境，数据不出域。
  

• 支持更大规模数据的分析，计算沙箱环境可以作为数据库，分布式计算引擎或框架（比如Spark，Ray， Dask等）的Driver端，进而连接更大规模的数据。对海量的数据进行探索性分析。

  
  

举一个例子，

 用Data Agent分析《2017年Kaggle 机器学习和数据科学调查》 公开数据集，Data Agent 可以利用BERTopic，将基于 Transformer 的嵌入模型，聚类以及自定义 TF-IDF 策略相结合，创建可解释且语义上有意义的主题，再结合LLM的语言理解能力，可以给出人能看得懂的分析报告。

Data  Agent 经过小半年的建设，其分析能力已经得到客户的认可，并在云栖大会上，备受关注。 三天的云栖大会，团队的同学在展台边上与来自各行各业的300+客户交流，深刻认识到，成为企业生产链路的一环是多么的重要，技术先进性需与企业价值对齐，缺乏业务增长支撑的能力将难以落地。那我们常说的企业级能力是什么呢， 或者说用云企业客户关注企业级能力什么特征？我理解核心有三点：

• 首先是可靠性，系统持续在线；

  
  

• 其次是可控性，数据，安全，责任边界等可控；
  

• 最后是可复用性， 知识，流程，洞察能被沉淀和扩展。

  
  

从这三个特征出发，结合客户交流反馈， 可以定义出Data Agent应当有哪些企业级核心能力。

Data Agent 知识，记忆与协作

空间内部成员， 一个企业或者组织中， 围绕数据可以分为四层结构，通常每一层对数据的认知需求也不太一样， 可以面前的与DIKW模型对应起来，但这也不是绝对的。  但我们可以明确的是， 对数据洞察的需求以及数据分析技能的掌握是不匹配的， 大多数最有能力的人距离真实业务场景相对而言更远。所以Data Agent需要考虑他们之间的协作关系，帮助有数据专业分析技能的人更加高效，使得他们的价值通过Data Agent 放大数倍，实现对企业数据更加深刻的洞察，同时可以减少数据消费者洞察数据价值的等待时间，另外借助Data Agent赋予数据消费者更多的自主能力。

企业数据分析需求分布

以上是我们这半年做Data Agent 一些想法和实践经验，希望使得您对Data Agent有更全面的认识， 同时在构建类似的产品功能时有些参考价值，  LLM能力的快速发展，使人有一种AGI很快就会到来的错觉， 但实践下来其实还有很长的路要走， 或许不久将来会出现比基于Transformer或者RL更先进的训练方法，不管怎么样，人工智能始终是一门应用学科，只有不断地实践，才能突破认知瓶颈，更好的拥抱时代的变化。

云栖大会 Data Agent 架构介绍