导读 在 AI 浪潮席卷而来之际，数据工程领域正在经历一场深刻变革。本次圆桌讨论邀请了三位深耕数据领域的技术专家，围绕"数据工程+Agent+落地挑战"展开了一场精彩对话。 主要内容包括以下几个部分： 1. 嘉宾介绍 2. 开场：为什么选择数据工程这个赛道？ 3. AI Agent 给数据工程带来的最大价值 4. 海内外市场的差异化实践 5. 数据上下文：Agent 落地的基石 6. 沉浸式分析：交互范式的革新 7. 架构设计哲学的殊途同归 8. 准确性：数据 Agent 的生命线 9. 记忆与学习：让 AI 越用越智能 10. 技术理想与工程现实的权衡 11. 数据库生态的 AI 原生改造 12. 展望未来：从辅助到主导 13. 结语 分享嘉宾｜汤庆 崔京 赵恒 内容校对｜郭慧敏 出品社区｜DataFun 01嘉宾介绍主持人 汤庆 OceanBase 开源社区技术专家，专注于数据库及 AI 方向探索 崔京 察言观数 AskTable 创始人，前阿里技术专家（花名已修），从数据库 DBA 到云计算再到 AI 产品的跨界实践者 赵恒 大兔子 AI（Datus：http://datus.ai/）创始人，前阿里数据库开发工程师、StarRocks 核心成员，专注于开源 Data Engineering Agent 02开场：为什么选择数据工程这个赛道？汤庆首先介绍了本次直播的背景：“大家好，感谢 DataFun 技术社区提供这次机会。今天的三位嘉宾都将参加 1 月 16-17 日在北京举办的 Agentic AI Summit 超级智能体系统架构大会，今天的直播也是为大会做个预热。” 崔京分享了创业初衷：“我叫崔京，之前在阿里花名已修，从数据库 DBA 做到云计算，现在在做 AI 产品。察言观数（AskTable）是我们 2024 年启动的项目。当时大模型来的时候，很多人在做非结构化数据检索，但我们看到结构化数据这块有非常强的需求，却没有特别好的方案。所以我们专注于在数据库和大数据基础之上，利用 AI 能力帮助大家更快从数据中发现洞察，推进决策效率。目前在国内有一些客户落地，未来也希望走向全球市场。” 赵恒则从技术演进的角度切入：“我也是数据库和大数据领域的老兵了。毕业第一份工作在阿里做数据库开发，后来在 StarRocks 工作了四年多，从 0 到 1 参与了这个国内优秀的开源数据仓库项目，主要精力在海外市场。今年年初出来做了大兔子 AI 这个开源的 Data Engineering Agent，可以简单理解为’Cloud Code for Data Engineers’。我们专注帮助数据工程师构建更好的 Data Context，包括指标、参考 SQL、语义层等，都能通过 AI 做得更好。开源两个月已经有 LinkedIn、PDR、Coinbase 等北美大客户在做 POC，国内也在推进一些落地。” 03AI Agent 给数据工程带来的最大价值汤庆开启了第一个核心话题：“从各位的实践来看，当前数据工程领域引入 AI Agent 的最大价值是什么？是效率提升、体验革新，还是解决了过去无法解决的问题？” 崔京率先回应：“我觉得核心是能把繁琐的工作简化掉。举个例子，大模型刚出来的时候，很多做数据治理的厂商发现，原本需要大量人工的数据治理工作，比如从数据中提炼关键信息，恰好是大模型擅长的方向。这是早期比较好的切入点。现在更多的是想让 AI 帮我们完全接管某部分工作，而不是只打下手。但这种场景目前接触得还不是特别多，这块赵恒可能更有发言权。” 赵恒从更宏观的视角展开分析：“我觉得首先要聊聊数据工程的定义。传统数据工程就是用软件工程思维做数据——从一张表加工到另一张表，数仓分层（ODS、DWD、DWS、ADS），最后交付 Dashboard。但这一波 AI 带来的最大改变，是数据工程的需求变了。原来只要交付表和 Dashboard，现在消费端不仅有 BI，还有 AI Chatbot、数据分析 Agent 等。这给数据工程师的交付要求变得越来越高——因为如果底层的数据治理、元数据、语义层建得不够完备，后面就很难谈准确率。” 他继续补充道：“第二个变化是生产端。我年初用 Claude Code 的时候，真正体验到了 Coding Agent 带来的体验变革。数据工程也值得有为它定制的开发工具，不仅仅是 SQL 自动补全，而是像 Cloud Code 那样能自主做多轮 function 调用的产品。更大的主题是，数据治理不应该是事后工作。等 SQL 代码变成屎山再治理往往已经晚了。如果数据工程做得好，应该配合AI在事中做更多的数据管理和体系搭建，这需要更多长程 Planning Agent 的配合。” 汤庆总结道：“两位老师都提到了关键点——效率提升和技术平权。原来数据工程靠堆人，现在不懂 SQL 的人也能通过自然语言对话拿到想要的结果。这不光是数据工程，包括 Web Coding 等全都在范式上做改变。” 04海内外市场的差异化实践对于海外和国内市场的落地差异，赵恒有着深刻的观察：“首先，不管海外还是国内，数据这件事都挺难的，并没有想象中那么容易。海外市场的云原生生态比较成熟，Snowflake和 Databricks 两大生态都有原生 Data Agent 产品，比如 Databricks 的 Copilot、Analyst。而且有 DBT 这样的专业 Data Transformation 工具，虽然不那么 AI native，但有很多生态长在上面。海外还有标准的 Catalog Service 等三方接口，做开放生态更容易。由于劳动力成本高，提升数据工程效率的价值更明显，所以他们倾向于选择更小的切入点，用开源生态方式整合，不需要自己做BI、指标层。” 谈到国内市场，赵恒指出：“国内最火的词还是’ChatBI’，业务导向更强。执行力非常强，针对某些场景的 AI 落地，堆人力也能做上去。往往从上到下做完整的链路。DBT 这类工具在国内从来没火过，也火不起来。” 崔京对此表示认同：“确实，我们也能看到国内现在开始有意识地分工、切分、分层，不再什么都自己抓。但相比之下这个意识还是会差一些。我最近接了一个电话，是国内一个行业前辈，做了很多年系统，现在也逐渐能看到很多人已经不再想一把抓，什么都自己干了，开始分工、开始切分、开始分层。” 05数据上下文：Agent 落地的基石汤庆引出了一个关键议题：“下周我的演讲会提到'上下文工程是 Agent 决策的基石'。两位在各自产品中如何构建或利用'数据上下文'？它是否是 Agent 在数据领域落地的前提？” 崔京分享了务实的选择：“在我们的场景中，我们并不是所有场景都用 Agent，反而在很多地方用自定义 Workflow 来实现。对于简单的多轮对话问答，我们用自己设计的 Workflow，而不是 Agent。对于稍微复杂的开放性场景，比如在有限数据集上生成报告，我们才会用到 Agent。为什么这样选择？因为要回到实际用户场景。比如有 20 张表的 OceanBase 数据库，如果让 Agent 完全自主去找数据、找表、找指标、生成 SQL、查数据，这个过程会非常漫长，容易走偏且不可控。我们一直在平衡能力范围和响应时间——很多用户希望几秒钟内就看到答案。” 他进一步阐述产品定位：“所以针对 Agent 这件事，要看适合自己的场景，选择合适的方案。我们一直没有提太多 Agent，更多是说我们是一个数据库/数据表的快速问答助手。在生态集成上，我们可以跟市面上的智能平台（Dify、FastGPT、Coze 等）直接对接，作为专门查数的小 Agent 融入，让企业各岗位的人无缝使用我们的能力——他们甚至可能不知道背后用的是我们，但本质上我们在提供这个能力。” 赵恒则详细介绍了大兔子 AI 的技术架构：“我们的产品是比较 Agent Native 的，整个聊天链路都是 Agents Loop 方式。但像崔老师说的，场景确实有差异。一个 Agent 核心要提供两件事：Context（上下文）和 Tools（工具）。数据的上下文比其他上下文更复杂，因为 Database 有更大的 Search Space。我们把整个 Database 组织成两棵树：一棵是 Catalog Tree（物理结构树），即 Database → Schema → Table 的层次结构，做表、列信息的召回和检索；另一棵是 Subject Tree（业务逻辑树），按业务域、一级主题、二级主题分层，叶子节点是 Metrics（指标）、Reference SQL（参考业务逻辑片段）和 Knowledge（知识召回）。” 他补充道：“这两棵树都会动态更新，我们提供了一组 Native Tools，大语言模型可以调用 list、search、database 工具做多轮探索，最终交付答案。真实场景下，用户可以定义 Sub-agent——在两棵树里选一些叶子节点或子树，比如 5 个 SQL、10 个指标、20 个 Reference SQL，配上动态更新的 Knowledge，就能达到比较好的效果。如何定义这些 Sub-agent？本质上还是数据工程师或数据分析师的工作——他们先定义一个 Scope，框出一个业务域，然后Agent可以在里面不停更新 Context。人和 AI 可以独立更新或协同编辑这个结构。” 06沉浸式分析：交互范式的革新谈到交互体验的变革，崔京分享了 AskTable 的创新实践：“我们在思考，初级数据分析师做的很多事情手工负担很重——写 SQL 拿数据，接收别人微信发的 Excel 或从系统下载 CSV，格式还不对，要用 Python 脚本处理。有了 Agent，哪些事情可以让 Agent 做？如何验收 Agent 的交付物是符合预期的？第一个问题可以通过工程手段解决，第二个问题我们做不了——必须交给最终用户去确认。如果不符合预期，怎么调整？怎么让 AI 记住这次提示？这就涉及 Memory（记忆）技术。” 他详细介绍了"AI 画卷"产品：“基于这两个出发点，我们发现线性的对话方式很难满足实际工作需求。所以我们做了’AI 画卷’——一个二维的沉浸式画布空间。用户可以把 Excel、CSV、数仓查询拖进来，AI 自动帮你写 Python 或 SQL 处理数据，自动生成可视化看板，支持灵活布局和调整。这个交互范式的变化，让用户能在探索过程中不断深入，而不是在单一对话框里迷失。” 赵恒从"氛围编程"的角度补充：“交互方式确实从单一框变成了协同。我们提出’氛围编程’（Vibe Programming）的概念——你不需要精确指定每一步，只需要给出整体意图，AI 能帮你完成。在 SQL 场景下，我们有 Plan Mode（计划模式）：AI 先生成执行计划，人工确认关键步骤（比如要不要修改某个生产表），然后 AI 负责长程执行。这样既保证了可控性，又发挥了 AI 的自动化能力。核心是在合适的地方让人介入，而不是全自动或全手动。” 07架构设计哲学的殊途同归三位嘉宾在架构设计上展现了不同的思路，但都指向了"数据层智能化"这个共同方向。 汤庆介绍了 OceanBase 的实践：“我们做了一个一体化的数据库，把向量、结构化数据、全文检索放在一起。这样做的好处是：让数据库自己说话，数据本身能提供最准确的 Context；降低使用门槛，用户不需要理解复杂的 Agent 架构，数据库内置智能；一体化存储与检索，避免多个系统之间的数据同步和一致性问题。这个思路是把智能下沉到数据层，而不是在数据层之上再加一个 Agent 层。” 赵恒阐述了大兔子 AI 的三大设计哲学：“第一是 Context not Control（提供上下文，而非死控），不要试图完全控制 Agent 的每一步，而是给它足够好的 Context 让它自己决策。第二是 Simple and Reliable（简单可依赖），平衡 Agent 和 Workflow，在需要可靠性的地方用 Workflow，在需要灵活性的地方用 Agent。第三是 Embrace Changes（拥抱变化），利用后训练（Post-training）提升小模型能力，快速适应新的数据库方言和场景。我们认为数据层智能化是趋势，但不是把所有智能都塞进数据库，而是在合适的层次提供合适的智能。” 崔京总结了 AskTable 的务实路线：“我们的选择是在确定场景用 Workflow 优化体验，在探索场景用 Agent 扩大能力边界。为什么？因为 Workflow 的优势是快速、可控、成本低，而 Agent 的优势是灵活、能处理开放性问题。两者不是对立的，而是互补的。我们在产品中会根据场景动态选择。比如简单的查询用 Workflow 几秒钟响应，复杂的报告生成用 Agent 可以等待更长时间。” 汤庆对此表示认同：“看来三位都在追求’合适的问题用合适的工具’，而不是盲目追求 All-in Agent。这个务实的态度很重要。” 08准确性：数据 Agent 的生命线准确性是数据领域绕不开的话题。赵恒分享了大兔子 AI 的应对策略：“准确性是最难的问题。我们的策略包括：选择容错度高的场景切入，比如数据开发（改错了可以重跑），而不是直接做生产决策；建立 Feedback Loop（反馈环），让 AI 记住用户的修正，通过不断迭代提升准确率；进行语义层转换，把 SQL 生成转化为参数填充，预定义好模板，只让 AI 填参数，大幅降低出错率；以及最根本的，数据治理是根基，准确性问题往往源于数据本身的混乱，要在事中就做好数据治理，而不是事后补救。” 崔京提出了不同的思路：“我们的理念是不追求 AI 一次性百分百准确，而是追求十倍的效率提升。具体做法是提供便捷的纠错机制，用户能快速调整 AI 的交付物；让 AI 记住修正，通过 Memory 技术避免重复犯错；以及保证业务口径的一致性，这个不是技术问题，要让业务专家参与定义。我们发现很多时候不是 AI 不准，而是业务口径本身就不清楚。AI 反而能倒逼业务把口径理清楚。” 汤庆介绍了 Power Memory 在准确性提升上的作用：“我们也在做 AI 记忆产品 Power Memory，解决三个问题：信息淹没，从海量对话中提取关键信息；记忆冲突，当新旧信息矛盾时如何处理；以及个性化画像，理解用户的真实意图和偏好。通过这些机制，AI 能’越用越懂你’，准确率自然就上去了。” 原文，开启你的记忆系统工程。 09记忆与学习：让 AI 越用越智能在记忆机制的设计上，三位嘉宾都有深入的探索。 汤庆详细介绍了 Power Memory 的分层架构：“Power Memory 的核心是分层记忆机制。第一层是短期记忆（对话内存），存储当前会话的上下文，快速访问用于连贯对话。第二层是长期记忆（知识库），存储用户的偏好、习惯、业务规则，定期整理和压缩。第三层是情景记忆（案例库），存储历史问题和解决方案，用于类似场景的快速召回。关键是记忆的组织和召回策略——不是所有信息都存，而是存最有价值的信息，并且能在合适的时候召回。” 赵恒分享了大兔子 AI 的 Feedback Loop 机制：“我们的 Feedback Loop 分几个层次。即时反馈层面，用户修改 SQL 后，AI 记住这个 Pattern，下次遇到类似情况直接使用。语义层积累层面，每次正确的查询都会沉淀到 Reference SQL，逐步构建业务知识库。Sub-agent 优化层面，根据使用频率自动调整 Sub-agent 的范围，高频场景的 Context 会更精准。关键是要有’写回’机制——不仅是读 Context，还要能更新 Context。这样才能真正做到越用越智能。” 崔京强调了业务特定记忆的价值：“我们在 Memory 上的实践主要是业务口径的记忆。用户说’GMV 要这么算’，我们记下来，下次再问 GMV 直接用这个口径。如果有冲突，会提醒用户确认。这种 Memory 不是通用的，而是业务特定的，才更有价值。” 10技术理想与工程现实的权衡落地过程中，权衡是永恒的主题。崔京坦言：“最难的权衡是能力范围 vs 响应速度。用户既想要’什么都能问’（需要强大的 Agent），又想要’几秒钟就出结果’（需要简单的 Workflow）。这两个诉求本质上是矛盾的。我们的做法是明确产品定位，我们主打’快速问答’而不是’无所不能’；分场景处理，简单问题快速响应，复杂问题提示用户需要等待；以及渐进式能力扩展，先把核心场景做到极致，再逐步扩展。” 赵恒分享了另一个维度的挑战：“我们遇到的最大权衡是开放性 vs 可控性。数据工程师需要开放性，能处理各种意想不到的需求，同时也需要可控性，知道 AI 在做什么，能随时介入。我们的解决方案是 Plan Mode：AI先生成完整计划，用户 review 并确认，然后 AI 自动执行。这样既保证了灵活性，又保证了可控性，但代价是多了一次交互，牺牲了一些流畅度。” 他继续补充：“另一个权衡是通用性 vs 专业性。做通用 Coding Agent 能覆盖更多场景，但数据场景不够深；做数据专用 Agent 能做得更深，但用户群更窄。我们选择了后者，因为数据工程有太多隐性知识，通用 Agent 很难做好。” 汤庆总结道：“这些权衡确实都很难。我觉得关键是不要试图一次解决所有问题，而是找到最核心的价值点，先把它做到极致。” 11数据库生态的 AI 原生改造谈到数据库与 Agent 的结合，汤庆介绍了 OceanBase 的探索：“我们在 OceanBase 的实践主要是数据库层面的智能化。首先是一体化存储，将向量、结构化数据、全文检索放在一个数据库，避免多系统同步的复杂性。其次是内置智能接口，数据库直接提供 Context API，Agent 可以直接查询’这个表是干什么的’。再次是查询优化，理解自然语言意图，自动选择最优执行计划。我们认为数据库应该对 Agent 更友好，而不是让 Agent 去适配数据库。” 赵恒从在 StarRocks 的经验出发：“数据库与 Agent 的结合有几个层次。第一层是接口适配层，提供标准的 Catalog API，支持 Metadata 查询，这是最基础的。第二层是优化层，针对 AI 生成的 SQL 做优化（因为 AI 生成的 SQL 往往不是最优的），提供更友好的错误信息帮助 AI 自我纠正，这能提升体验。第三层是 AI 原生层，这是未来方向，包括数据库理解语义查询，自动推荐索引和优化策略。目前大多数数据库还在第一层，少数在做第二层，第三层还在探索。” 崔京从产品对接的角度补充：“从产品角度，我们需要对接各种数据库。最大的痛点是 Metadata 的标准化，每个数据库的 Catalog 结构不一样，有的有 Schema 层有的没有，字段类型的定义也不统一。我们的做法是抽象出一个统一的 Metadata 层，然后适配不同数据库。这个工作量很大但必须做。另一个点是权限控制，Agent 不能越权访问数据，要和数据库的权限体系打通，这个现在很多数据库还没有很好的支持。” 12展望未来：从辅助到主导在讨论的最后，三位嘉宾对未来两年的趋势做出了各自的判断。 崔京给出了富有哲理的预测：“技术会变得平实普通，像手机一样融入日常。短期我们可能高估技术，但长期不应低估它对组织效率的深层变革。就像当年智能手机出来时，我们也觉得不过如此，但现在已经离不开了。AI Agent 也会是这样的路径。” 赵恒描绘了一个角色转换的未来：“从’AI 辅助人’转向’人辅助 Agent’。Agent 将承担更长程的主动规划，人只需提供架构品味和关键决策。这不是说人变得不重要，而是人的价值从执行层上升到决策层。就像现在的建筑师不需要亲自搬砖，但建筑设计的价值反而更高了。” 汤庆则给出了具体的时间预测：“我预测 2026 年下半年将迎来产业应用的 V 型反转。随着治理和记忆技术的成熟，AI 将从 Demo 真正落地实处。前半年可能还在技术积累期，下半年会看到大规模商业应用的爆发。” 13结语整场对话持续了一个多小时，三位深耕数据领域的技术专家从各自的实践出发，深入探讨了 AI Agent 在数据工程领域的现状、挑战与未来。从上下文工程到交互范式革新，从准确性保障到记忆机制设计，从架构哲学到工程权衡，他们的分享既有技术深度，又有实战经验，为数据工程的 AI 化转型提供了宝贵的思路。 三位嘉宾也将在 Agentic AI Summit 2026 上做更深入的技术分享，届时将有更多关于数据工程与 AI Agent 结合的实践案例和前沿探索。 以上就是本次分享的内容，谢谢大家。