数据基础设施比 DataAgent 更重要

最近和几位做大数据的同行吃饭，席间聊到Data Agent，大家的话匣子一下就打开了。 "我们今年all in Agent了，团队一半人力都扑上去了。" "我们去年就发了Agent产品，但客户问得最多的还是：你们这个能查哪些表？信息安全和权限怎么控？" 聊到这儿，我突然意识到一个被严重低估的事：所有人都在卷Agent，卷模型、卷多智能体编排、卷记忆机制、卷MCP协议，但真正决定Agent能不能跑起来、跑得稳、跑得久的，不是那些花里胡哨的东西，而是地下的水管——也就是数据基础设施。 这不完全是 OneMind 的观点，是OpenAI数据平台工程主管Emma Tang在接受采访时反复强调的一件事。

一场两个月完成的迁移，揭开了行业最深的误解

先说一个让我印象深刻的细节。

OpenAI近期干了一件让同行目瞪口呆的事：在两个月内，把1.5EB数据、9万个表、600PB存储、几万个DAG，从一个云平台完整迁到了另一个云平台。

你可能不知道这个数字的份量。

OneMind的老师同学们混迹AI+大数据圈这么多年，类似规模的跨云迁移，行业里普遍的预估是——得两三年吧。

很多公司甚至直接放弃迁移，理由是数据耦合太重，根本搬不动。

那OpenAI是怎么做到的？

答案是，他们没有靠什么神奇的工具，而是靠一个非常简单的Data Agent，加上一个极其扎实的数据底座。

这个Agent本身没什么黑科技——一个LLM、一个上下文组装层、13个工具、一个Agent Loop。

但它能稳定地服务4000名内部用户，每天处理大量关键查询。

这就好比两个厨师做同一道菜。

一个在普通厨房里忙活，锅不够利、火不够稳、调料找不到，就算手艺再高也发挥不出来。

另一个用的是顶级厨房，灶台、刀工台、储物柜全是按米其林标准配的，菜刀磨得铮亮，调料伸手就够得着。

你说，做出来的菜差距大不大？

被严重低估的上下文工程

真正让我拍大腿的，是OpenAI数据团队对上下文这件事的执着。

他们给Agent喂的不是干巴巴的表结构，而是一个六层上下文体系：表的使用元数据、表所有者的手写注释、Codex每天读pipeline代码生成的增强描述、公司内部Slack和Notion里的专有知识、过去对话中积累的记忆，以及运行时实时查询的能力。

听起来很复杂对吧？

但本质上干的事就一个：让模型在回答问题之前，就已经懂了这张表是什么、谁在用、什么时候用、和别的表什么关系。

举个栗子：

同样一个user_id字段，存在于几十张表里。

光看schema，模型根本不知道哪张表里的user_id是"已登出用户"、哪张是"活跃用户"、哪张是"包含已注销账号的"。

但通过六层上下文的层层叠加，模型就有了判断的依据。

这就是为什么OpenAI的Agent看起来简单却用起来很稳——它不需要多聪明，只需要拿到的信息是准的、是对路的。

OneMine经常跟团队说一句话：Agent的能力上限，不是模型决定的，是上下文决定的。

模型再强，你喂给它一堆噪声，它也只能输出噪声。

模型一般，但你喂给它精心整理过的信息，它反而能给你惊喜。

这背后其实是一整套技术活儿：表元数据要被embedding成向量存进向量数据库，检索的时候要做语义匹配和精确文本匹配的混合召回；离线流程要每天晚上跑批，把pipeline代码的diff、表所有者的注释、查询历史聚合成每个表的画像；还要做去重、降噪、版本管理，避免上下文里出现互相矛盾的描述。

这套体系的建设成本，远比训练一个Agent高得多。

但一旦建好，Agent的准确率提升是数量级的。

真正的护城河

还有一个细节特别打脸现在的工具焦虑。

OpenAI最初给Agent接了40个工具。

结果模型开始犯傻——该用A工具的时候调用了B工具，该用元数据服务的时候跑去了数据字典。原因很简单：这些工具功能重叠，模型分不清谁是谁。

后来他们砍到13个工具，砍掉了所有功能重复的部分，问题立刻解决。

这事儿OneMine太有感触了。

去年我们对接一个外部Agent框架，对方恨不得把自己平台的所有接口都暴露成工具，结果模型在几十个相似接口之间反复横跳，回答得稀烂。

后来我们坐下来一起梳理，把工具从二十多个砍到八个，准确率立刻上来了。

工具多不是本事，能砍到刚好才是。

这背后的原理也不复杂：Function calling的设计哲学，本质上是给模型一组动词，让它在合适的语境下选择最合适的那一个。

但当动词之间语义重叠的时候，模型的选择就变成了掷骰子。它擅长的是"该不该用工具"的判断，不是"在N个相似工具里挑一个"的判断。

所以好的Agent架构，一定是工具集经过精心设计的——每个工具的职责边界清晰、输入输出格式统一、错误码语义明确、调用失败的fallback策略可预期。

回到国内的AI+大数据圈。

这两年我看到一种很普遍的现象：很多老牌数据厂商，在Agent浪潮里特别焦虑。

焦虑的原因是，他们发现自己花了十几年建起来的数据底座、指标体系、权限管理、血缘追踪，在Agent时代好像突然不值钱了。

因为新冒出来的创业公司，用一个轻量级的Agent框架，套上大模型API，三五个人就能跑出一个数据助手原型，看起来也能查数、也能出图，也能回答业务问题。

老厂商会本能地反驳：我们做了二十年的元数据管理、做了十年的数据治理，这些沉淀不是几个月能追上的。

这话没错，但问题在于：你的这些沉淀，Agent能调用到吗？

OneMind见过太多这样的场景——客户找老厂商合作，想用Agent对接他们的数据平台，结果一上来就卡壳。

接口是给人用的，不是给模型用的，返回的格式模型解析不了；权限是按项目静态授权的，Agent跑过去直接被拦；指标定义埋在十年前的wiki里，模型根本不知道GMV在你们家到底怎么算。

于是客户说：算了，我直接让Agent接你们的数据源，再在外面套一层，凑合用吧。

就这么一下，老厂商十几年的积累，就被一个轻量级Agent绕过了一半。

那老厂商到底该怎么办？

OpenAI的故事其实给了一个很明确的答案：不要去卷Agent的面子，要卷Agent的里子。

什么意思呢？

就是不要试图做一个"更聪明的Agent"去和框架厂商竞争，而是要把自己做成"Agent能稳定调用的底座"。

具体来说就是几件事：

把指标、字段、权限、口径，结构化地暴露出来，Agent能读、能查、能调用。

不要再让Agent去爬十年前的wiki、问某个离职员工才能知道的事。

这背后需要做的是建设一套标准化的语义层（Semantic Layer），把业务指标的定义、维度、计算逻辑、依赖关系都抽象成机器可读的契约，类似dbt的metric flow或者Cube.js那种思路。

把接口设计成Agent友好型。

返回值要带语义、要带上下文、要告诉调用方为什么失败、失败了下一步该干什么，而不是冷冰冰地返回一个403。

另外，你的API要支持丰富的错误码体系、自描述的元数据、可机读的SLA信息。

MCP（Model Context Protocol）之所以重要，就是因为它试图把这套契约标准化，让Agent和工具之间的对话有共同语言。

把权限做成动态可审可追。

同一个字段，Agent在A场景下能查，在B场景下不能查；同一个调用，Agent代表老板查能过，代表实习生查就拦下来。

这些事情，传统的Excel权限表根本做不了。需要的是ABAC（基于属性的访问控制）加上完整的审计链路，让每一次Agent调用都有据可查、有责可追。

把流程做成可编排的。

Agent过来不是要一个查询结果，而是要完成一个任务。

你要思考的是：我在这个任务的哪一段出现、输出什么、下一步接给谁、失败了怎么回滚。

每一个数据产品都要有清晰的工作流契约——输入是什么、输出是什么、SLA是什么、上下游依赖是什么。

这其实是在做一件以前很少有人认真做的事：把数据系统当成"可被编排的工作节点"来设计，而不是当成"终点型的工具"来交付。

这些事情，没有一件是做Agent。但每一件，都是让Agent离不开你。

结语

这一年 OneMind 看过太多Agent项目了。

有的团队上来就搭多智能体框架、搞复杂的记忆系统、接MCP协议、搞AutoGPT式的自主决策，结果落地的时候发现，模型连个准确的SQL都写不出来。

问题出在哪？

出在它拿到的数据是乱的，权限是不清的，指标是各说各话的。

OpenAI的Data Agent能跑得稳，不是因为它有多前沿，而是因为它脚下踩着的是十几年积累下来的扎实基础设施。

模型是新的，但底子是老的、稳的、统一的。

所以下次再有人问我Data Agent时代，传统大数据厂商还有救吗的时候，我都会反问一句：

你家底下的水管，修好了吗？

关于OneMind

#OneMind #AI #人工智能 #Agent #DataAgent #RAG #算法 #AI中台