在Agentbase 登场进入倒计时" data-itemshowtype="0" linktype="text" data-linktype="2">老夫聊发少年狂：扎克伯格豪赌华人天才少年，Meta 下注数据智能未来；数据库退场，Agentbase 登场进入倒计时一文中，我写了这么一句话：
“AI Agent 开启另一个新数据智能时代。。。具体形态是什么，我不知道。但我敢赌，它不会长在 SQL 的世界里，而会生长在 agent 理解、纠正、完成我们任务的每一次尝试之中。”
有位网名叫 Walle （瓦力）的同学在文章下面认真回复到：
感谢他花时间留言，逻辑清晰、专业扎实，说了三件事：
-
SQL 图灵完备，天下无敌，不可能被取代
-
各大厂商正忙着将 AI 功能接上数据库，不像文章说的那样：数据库要过时了
-
AI 的问题在于太贵，AI 的商业价值和互联网不能同日而语
他的观点很具代表性。Walle 也是我最喜欢的机器人 ，所以我专门花了一天时间写这篇文章，来推敲。
他的这些话乍看都没错：SQL 优雅、强大、不会死。
企业们也在向数据库加 AI 功能，比如加上 AI 函数、接入 LLM 调用接口、甚至接入 GPT 帮用户自动补 SQL、引入向量索引查 embedding、接个 RAG，搞个 Copilot 等等——
这些努力值得肯定，但说到底，更像是在老电视上装了个机顶盒，让它能播点 AI 的节目，看起来“智能”了一点。底层逻辑却从没改变。
本质上——它们是数据库时代的思维方式：怎么在旧系统上“加点智能”。
而我关心的是：这个系统本身，还适合 AI Agent 来住吗？
而成为数据主操作者的 AI Agent，会不会干脆把整个数据系统都重构了？
未来的 Agent 不只是查表，它要的是：自动理解任务目标；自动规划步骤；调用工具链；任务完成后还能“自我反思”。
如果数据系统不具备意图捕捉、状态追踪、行为反馈的能力，就算装了再多“智能插件”，也只是表面工程。
我们先来看以下几个变迁。
不是 SQL 不好，是 Agent 不写 SQL
AI Agent 的接口不再是 SQL query，而是自然语言：意图识别 → 行动计划 → 工具调用。
它可能最终会“生成”SQL 作为底层指令，但中间过程 Agent 并不需要理解 SQL 的逻辑语义。
所以不是说 SQL 不重要，而是编程范式正经历：
-
查询 query → 任务完成 action，
-
声明式→互动，
-
人工操作→ Agent 主导：
这是 Web2 → Agent Web 的本质变迁。
不是替代 SQL，而是从‘用数据’→
‘用 Agent’：这才是范式变迁的开始
过去，人 query 数据、分析数据、决策。
今天，人说目标，Agent 去调数据、调用工具、解释反馈。
人的行为在变：这正是 Meta、OpenAI、DeepSeek 等正在构建的世界。
数据智能的关键点，
不是向数据库加 AI
正如 Walle 所言，大家现在都在忙着向 DBMS 里加 AI 功能。
要我说，方向可能不太对！
Agent 已经具备主动调用工具 + 执行反思（self-evaluation）的能力，不再等待人类“命令”调用函数，而是通过任务分解（task decomposition）自行寻找路径完成目标。
特别要点出“还回来告诉你 why”，这和传统函数调用（黑盒响应）完全不同，是具备解释性/可溯源的 Agent Trace，即下一代智能系统的标准能力。
这是 AI Agent 体系中的关键转变。
在这种范式变化下，向老系统加更多的功能、函数、命令，有点南辕北辙。
AI 太贵、回报远不如互联网吗？
大家以为 AI 贵，是因为模型算力太贵、token 太贵。
但真正贵的是——如何把 AI 安进你的系统里，怎么接数据、怎么落地。
这不是算法问题，是工程问题，是数据治理问题，是系统组织问题。
而且，新的智能数据系统（比如 memory routing + context planner + semantic structure）其实是一种更高层的资源调度结构，省掉的，不只是人力，是整个旧式工程栈的维护复杂度。
而更重要的：它不是“省钱”，而是“干成原来干不成的事”。
今天，AI 如果只是“查下表”，那当然贵。 但如果它能自动完成任务（代替一个团队的活），自动复用历史 trace（让同类任务成本趋近于 0），自动生成 memory + feedback → 成为知识系统，那它就是整个系统的智能“操作层” + “创造层”。
我们已经进入以 token 成本计价 + 智能行为重用的时代。别再用“function call 便宜 / AI call 贵”来判断系统价值了。
举个例子，泉州电商丑拖鞋小哥 5个人，4 个 agent，去年做了 3000 万，今年目标 5000 万，人效 300 万，利润 30%！AI Agent 带来的价值让他成为同行业的佼佼者。
不仅中小商贩在变革，行业巨头更是 all in agent!
扎克伯格已经暗示 Meta 交互方式将不可避免地从信息流主导→ AI Agent 主导的 Chat 任务完成。
随之而来的将是每年额外千亿美金的AI Agent 收入来源，同时成为 AI 时代的数据智能的规则制定者！
这样看来，他花 140 亿美金招募 Scale 的 Alex + 10 亿美金从 OpenAI 挖一大批 AI 工程师打造超级数据智能，还贵吗？
两件事
讲到现在，你可能已经看出瓦力 Walle 和我，看问题的角度有些不一样。我们在讨论两件截然不同的事情。
从 SQL 到 Agent，是范式变迁的真实起点，不是技术，而是行为系统的重构。
而我们都是如此的幸运，即见识了互联网的前无古人、又正在目睹 AI 的雷霆万钧！
你可能会问：Agent 确实和自然语言打交道，
但 Agent 调用的也是 AI 的编程能力，
在底层，仍旧是要写函数，用 SQL 啊。
是的，在底层，Agent 最终还是会调用函数、生成 SQL、调用 API，就像今天 Copilot 写代码，它也只是调用已有的函数、类、库一样，这没问题，也没什么神秘的。
但关键点不在“有没有写 SQL”，而在：
1）谁在写？什么时候写？写给谁看？
过去是人写 SQL 给数据库看。
现在是 Agent 写 SQL，但人并不关心 SQL 本身——人在发自然语言指令，Agent 只是把它“编排”成可执行的动作链条，SQL 只是其中一环。
这叫 从 declarative 编程（声明你要什么）→ procedural 编排（AI 替你决定怎么做）。
2）“能不能写 SQL” ≠ “理解 SQL 语义”
Agent 的重点不是写 SQL，而是理解你的意图
假设我要：“查最近一周点击率最高的广告”
Agent 需要自动知道从哪个表查什么字段，再决定是否要先 join、再排序、是否分页...
这些步骤以前都要人做。
现在你只说“我想看看最近谁最火”，它就懂了。
所以重点是：AI 把“任务理解”这层做了，而不是“SQL 是不是还在底层”。
3）从行为看新范式：任务驱动 + 动态执行链条
过去是：静态函数库，谁调用谁。
现在是：Agent 动态构建执行链，做 Planning + Tool Use + Memory Routing。
例1：你说“我想知道我的广告预算最划算的投放渠道”
Agent 接管：
-
拆成多步任务（调数据、算 ROI、生成结论）
-
自动调用 SQL/API/模型LLM/搜索工具/记忆库/分析函数/可视化组件
-
最后还给你一段解释：“我发现微博 ROI 是 1.7，抖音是 1.2，所以建议重点投微博。”
这不是函数调用那么简单，这是“Agent 级工作流”。
例2：“给我看最近涨停最多的个股”
Agent 接管：
-
任务分解：这涉及调用行情数据、历史涨停数据、按时间排序、设定阈值等
-
工具选择：哪些字段、表、API、函数模型能提供这些数据？
-
反馈执行链：根据目标调整路径、缓存中间结果、生成解释、复述结论
这个过程不像传统函数调用，是静态、封闭的。 而是：动态、反馈式、路径依赖式的 Agent Chain。
它可能在执行过程中：
-
调用 SQL，也调用 LLM
-
调用搜索工具，也调用记忆库
-
调用分析函数，也调用可视化组件
-
这套机制不是“能不能写 SQL”，而是：它能不能干完这活，还告诉你它为啥这么干。
所以，不是 SQL 不重要，而是 SQL 退居幕后——未来人类和系统的交互，中心从“数据结构”变成了“任务结构”。
4）Agent - 数据系统的共建者
当你要：“看下哪类用户最近最活跃”，你本质上不是想要一张表，而是：
-
一种趋势判断
-
一种面向业务决策的支持
-
一种可解释的结论，可能还需要图表、建议、推理路径
传统 BI 工具可能查几个表做可视化。
Agent 系统会说：“你等一下，我来跑下用户行为聚类 + 热点事件相关性分析 + 社交传播路径建模”。
Agent 系统本身会主动使用数据，也会生成新的数据（比如 plan、trace、memory），不是数据系统的“使用者”，而是“共建者”。
再举一个例子，当你和一个机器人对话说：“帮我找出过去一周热销产品里库存最低的”，它不会真的“学会 SQL”，而是：
-
识别你的意图；
-
拆解为多个子任务；
-
决定其中某步是否需要访问数据库；
-
如果需要，就调一个能生成 SQL 的函数模块来获取数据；
-
获取完数据继续往下走，比如生成一张图，发封邮件，甚至反过来修改库存。
所以，SQL 还是在底层，但它的“语言地位”变了。它不再是人和系统交互的语言，而是系统和系统之间自动协作的中间语，甚至会被压进封装模块，连 Agent 都不“意识到”它的存在。
那么 MCP 协议、memory routing、
语义数据结构，是不是要取代 SQL？
我认为不是“取代”，而是“补位”。它们承担的是 SQL 无法完成的、面向 Agent 智能行为的职责。
MCP（Model Context Protocol）不是数据库协议，而是 Anthropic 提出的 上下文协调标准，用于让 Agent 在任务中调用外部工具、读取资料、跨系统协作——它像是 Agent 世界的“操作系统 API”。
Memory Routing，是智能系统里的“记忆调度器”——决定 Agent 在什么任务中调用哪段记忆、更新什么状态、丢弃什么无用历史。它让数据成为“过程”，而不仅仅是“表格”。
语义数据结构，不是新格式，而是 让 AI 懂得数据含义的表达方式。Agent 不关心“字段名”，而是需要知道：“这是什么单位？能被谁调用？它和当前任务目标的关系是什么？”
这些都不是 SQL 擅长的，它的“刚性 schema”让 AI 难以推理。所以它们和 SQL 的关系，不是“淘汰与被淘汰”，而是“主从角色的转换”：SQL 将继续存在，但它退回了后台；
新一代数据智能系统的前台语言，是意图识别、任务编排、语义推理。
就像我们今天谈 iOS、Android、visionOS，不再聊 BIOS、磁头和文件句柄。
这个转变不是一场技术比拼，而是 Agent-native 时代的范式变迁，从：
-
数据系统服务人类 → 数据系统服务 Agent；
-
人发 query → Agent 接 task；
-
靠规则写语法 → 靠意图拆解执行；
-
系统等你问 → 系统先给你答。
在这样的结构里，SQL 会继续存在，但不会定义智能的边界。
新物种
当 SQL 被“下沉”到 Agent 的 action layer，人类的工种也会变。SQL 不会死，但它的主导权在变。未来重要的不是谁写 SQL，而是谁定义 Agent 的目标和上下文。
这会诞生一批新的工种：
-
Agent 架构师：设计 Agent 的记忆模块、工具库和行为逻辑
-
意图设计师：定义人 → 任务 → Agent 的 prompt / context
-
数据智能调度员：负责 routing、token 优化、链路解释
而旧的角色，比如 BI 报表、分析师手动拉数、ETL pipeline 开发，都会逐渐自动化或融合。
写在最后
我不是数据工程师出身，我只是站在趋势的第一性原理上思考。我尊重所有深耕数据系统的人，你们铺下的地基让今天的 AI 有了用武之地。
但时代的转向，不是因为工具不好，而是因为我们有了新的问题、新的目标。
人类将不再对着数据库编程，而是让 AI 去理解任务、执行任务，并回来说：“搞定，this is how I did it. ”。
One more thing:
AI 原生的系统智能大变革
人们喜欢 native 原生这个词，我的上一次创业就是围绕云原生。
在 AI 原生环境下的任务路径长这样：
人类说话 → Agent 理解 → 生成多轮交互、工具调用链。
中间可能包含 SQL，但你看不到。
Agent 在运行中自己更新 memory、记录行动路径（agent trace），甚至形成新的数据资产。
你用的是数据系统，但你和 SQL 不再有直接关系。
SQL 不会消失，但未来最重要的，不是“查数据”，而是“干成事”。 Agent 不写 SQL，而是写 Plan；不查表，而是完成任务。
Holy Grail
这才是数据系统从“结构查询”走向“结构智能”的关键飞跃。这不是数据工程的小升级，而是系统智能的大变革。 你准备好了吗？
相关文章
