“人”退场，“Agent”登场，数据库与AI正在发生“化学反应”。这套运行了50年的“老基建”正在经历一场前所未有的剧变。
回望过去，从上世纪70年代至今，数据库的演进逻辑始终围绕着一个中心：如何让人更高效地使用数据、挖掘数据价值。最早人们有了数据，很自然会想到用工具、语言或脚本把价值提取出来，这大概就是ETL的雏形——数据从各个业务系统抽取、清洗、整合，再进入数据库，供人分析与使用。
准确说，是共性需求催生了新的抽象理念：为了让人们稳定地挖掘价值，行业最终确立了标准化的结构化查询语言——SQL。从“数据接入”转向“系统供数”，SQL作为人与数据之间的“通用接口”，连接了数据操作层、数据灌注层与最终使用者，将工程师关心的“实现层细节”——选什么语言、数据存在哪、表结构怎么设计——都封装在这套为人服务的标准化体系之下。
但现在，这套运行了50年的数据工程范式正在失效。
▲酷克数据研发副总裁杨瑜
“特别是今年，编程范式发生了根本性变化。”酷克数据研发副总裁杨瑜，在IT168&ITPUB最新推出的《Agent Infra变革进行时，企业级智能体规模化落地的“基础设施之战”》选题采访中，谈到行业变化时的真实体感。
以前，操纵代码和软件的主体是人，人需要处理许多细致的工作，路径明确。但现在，主体变了。当Agent开始接管代码，成为数据的主要消费者和生产者时，传统的SQL接口显得笨重且低效。AI无需像人那样关心底层表结构设计，它需要的是更上层的语义理解和自主交互能力。
用杨瑜的话说，Agent进入生产场景，不仅是交互方式的改变，更是数据库发展史上最剧烈的一次“换岗”。在这场变革中，我们需要重新思考：满足AI原生需求的“数据底座”该如何重构。
从人到Agent，到底变了什么？
“以前DBA写出高效的SQL查询语句，很考验功底；现在，Agent自己生成查询语句，你只需要告诉它你要做什么。”杨瑜一句话点破Agentic AI时代的核心变化。
过去的ETL数据链路很慢。数据工程师需要按天同步、清洗数据，写SQL跑报表，最后把结果交到决策层手中，整个周期以天为单位。即便是实时数仓，最终使用者还是人，人不会一秒发起十几次查询，也不会在无人干预的情况下，自动改完数据立刻执行下一步动作。
但Agent完全不同。它拿到用户的一个目标，会自动拆成十几步操作。像“人”一样，Agent会先读历史会话记录，写完执行日志立刻存进去，查完用户画像马上更新，调用完工具链立刻回到“写”状态，单次任务里几十次读写是常态，全程无需人介入，而且以远高于人的频率连续完成从读到写再到执行——数据库侧的单次读写通常在毫秒级。
对底层数据库而言，Agent的入场带来了三个明显变化：
第一，操作主体变了。 过去学数据库技术，第一课就要学SQL，所有接口设计围绕“人能看懂、人能写对”展开。但现在Agent根本不需要你教它写SQL，它要的是“语义层”：需要弄清表里存的是什么、字段代表什么含义、怎么关联能最快拿到结果。数据库得把这些语义信息直接喂给Agent，而不是让它对着一堆陌生的“表名”猜半天。
第二，数据类型变了。 数据从纯结构化变成全模态通吃。过去数据库只存人能处理的结构化数据，音频、图片都得单独丢到别的系统。但Agent天生就习惯处理非结构化信息，你把数据拆在十几个不同系统里，它跨系统调用时不仅慢，连最基本的数据一致性都保证不了。
第三，AI催生出“新器官”，“记忆”成为数据库的刚需能力。 过去我们根本不需要考虑“记忆”，所有数据都是静态的、预先定义好的。但Agent跑起来之后，会话状态、交互历史、用户偏好、行动经验，这些动态生成的“记忆”成了支撑它不“降智”的核心。
数据库的分工边界在哪里？
需要强调的一点是，在与Agent的交互中，“记忆”是一个核心痛点。这就像人的记忆分为短期和长期一样，Agent的记忆也面临同样的挑战。
你是否遇到过这种情况？与Agent进行多轮对话时，聊着聊着它就变得逻辑混乱。这本质上是“上下文”问题：交互越长，上下文不断膨胀、关键信息被稀释（context rot），注意力退化，导致Agent“降智”。数据库的价值不在于“写得快就不降智”，而在于承担上下文的卸载与精准召回——把不必进入上下文窗口的状态外置存储，需要时按相关性精准取回。
短期记忆的特点是： 1）高频读写，每一次交互都在更新状态；2）生命周期短，通常以分钟或小时计；3）局部性强，不同会话间的记忆无需共享；4）一致性要求低，允许存在短暂矛盾，过期即焚。
当然，短期记忆中也会沉淀出有价值的信息，比如代码规范、业务规则等，这些构成了Agent的长期记忆。
长期记忆的特点是： 1）写少读多，一旦沉淀便被频繁引用；2）内容一致、无矛盾，需要冲突消解与版本治理，否则模型取到过期或矛盾的知识会输出错误、逻辑混乱；3）数据形态多样，不仅是结构化数据，更多是文本、音视频等非结构化数据及其向量表示（embedding）。
那么，长短记忆和数据库是什么关系？Agent的长短记忆到底该存在哪里？关系型数据库、向量数据库、图数据库，到底谁来扛这个活？
“你照着人类大脑的记忆逻辑去想，立刻就通了。”杨瑜给出了一个非常直白的答案。他认为，人类的记忆天生就分两类：一类是你当下正在做的事，比如正在敲代码、正在和人聊天，这些短期记忆更新极快，用完之后大部分会被忘掉；另一类是你沉淀了几年的知识体系、长期养成的习惯，这些长期记忆很少改动，但需要时能立刻精准回忆起来。
Agent的记忆完全遵循同样的逻辑，天然分成两个完全不同的工作负载。短期记忆，对应Agent的会话状态，就像人脑的“临时缓存”，核心需求是“快”，不能卡；长期记忆，从海量短期记忆里提炼出的经验、偏好、知识，需要支持语义检索、关联推理，就像人脑的“长期知识库”，核心需求是“准”，能找到关联信息。
过去，我们把这两类负载拆给不同的数据库去扛：短期记忆丢给关系型数据库（或内存/KV缓存）处理高频读写；长期记忆里的语义检索丢给向量数据库，关联推理丢给图数据库。但现在Agent的调用密度上来了，跨多个数据库来回跳转，链路长、延迟高，并发稍微上来一点就直接堵死。
这也是现在行业里逐渐形成的共识：未来的数据库，不再是单一的关系型、向量型或图数据库，而是一个能同时扛TP（事务处理）级高频写入、向量语义检索、图多跳关联查询的一体化引擎。你不需要再把数据拆成好几份分别存储，Agent一次调用就能同时拿到结构化状态、语义相似的历史经验、关联的知识链路——这才是能支撑Agent跑通全流程的真正底座。
更进一步的理解是，为了解决Agent“记忆”问题，绕过“短期健忘”与“长期错乱”的各种泥潭，数据库需要从内核层面进行重新升级，才能满足AI原生需求。放眼市场，满足新时代需要的数据库不仅要支持高效的向量检索，还要保证数据的强一致性，并提供类似“审计”的功能，追踪知识的更新与遗忘等。而PostgreSQL生态正是应对这一场景的典型思路：向量检索靠pgvector，强一致来自内核，审计、知识的更新与遗忘追踪则由pgaudit、时序表/软删除等机制配合完成。
Agent-Ready数据平台长什么样？
从 AI-Ready 到 Agent-Ready，在这场范式变革中，不只数据库在变化，湖仓一体也在向2.0时代演进，为AI装上了“语义缓存”层。
“在AI时代，数据是燃料，AI是发动机。但传统的‘数据湖’作为燃料库，其查询延迟往往在秒级甚至分钟级，这对于需要实时交互的Agent来说是无法忍受的。”杨瑜认为，构建一个智能的“服务层”，是填平这道鸿沟的关键。
传统的ETL链路和Spark批处理，在Agent的交互式查询面前显得力不从心。解决方案并非简单地让数据湖变快，而是引入语义缓存（Semantic Cache）。它以问题的语义（向量）作为检索键，而非传统的精确SQL文本匹配；当Agent提出一个语义相似的问题时，系统可复用已算好的结果或洞察，而无需再次扫描海量数据，同时需要配合基于数据新鲜度的失效策略与相似度阈值，避免陈旧命中或误命中。同时，通过计算下推、元数据优化、热冷数据分离等手段，可以最大限度地减少不必要的数据扫描。
最终，湖与仓不再是两个割裂的系统，而是通过统一的元数据和管理层，形成一个对Agent透明的、统一的数据视图。
综合来看，不管是数据库，还是湖仓一体、湖库一体，一个面向未来的、真正的“Agent-Ready”数据平台，必须具备以下四大核心特征：
1. 拥有多模态原生存储能力。 地基必须牢固，平台需要原生支持表格、文本、图像、音频、向量等多种数据格式，并对其进行统一的元数据、权限和血缘管理，而不是让它们散落在不同的系统中。
2. “混合检索”与“执行引擎”是重要“抓手”。 引擎必须强大，查询优化器和执行器需要能够统一规划涉及向量检索、全文检索和结构化查询的混合负载，而不是将任务拆分给三个独立的系统，避免大量数据在系统间搬运。
3. 构建面向Agent的语义层。 交互必须友好，在SQL之上，构建一个Agent可理解的语义层，将数据的业务含义“翻译”给AI，让它知道如何正确地使用数据。
4. 建立可观测与可审计链路。 要安全、可控，由于Agent拥有自主读写能力，平台必须提供比传统数据库更强的权限管理、数据脱敏、访问审计、路径重放，以及面向Agent自主写入的幂等、回滚/补偿、并发隔离与破坏性操作的人工审批（HITL）。同时，还需要一个反馈闭环，让Agent能根据数据操作的结果进行自我优化，实现协同进化。
在这场由Agent引发的结构性变革中，酷克数据选择了一条基于PostgreSQL生态的“湖库一体”路径。
杨瑜介绍，他们的产品从下至上进行了全面布局：
存储层： 通过Directory Table能力（以库内元数据直接寻址库外对象存储中的音视频等文件），将非结构化数据的元数据与数据库统一纳管，并支持Iceberg等开放湖格式，实现热数据在库内、冷数据入湖的分层存储。从内核元数据层支持数据Branching的能力。
计算层： 在兼容PG接口的同时，构建了云原生无状态计算层，内置分布式向量引擎和全文检索能力，支持计算下推，确保混合查询的高效执行。
服务层： 向上提供MCP Server以及语义层等工具接口，将数据能力以Agent易于调用的方式暴露出去，并构建了语义层和数据可观测性能力。
在与Snowflake、Databricks等厂商的竞争中，酷克数据强调PostgreSQL生态的高度兼容，以及其“一套系统”的统一性，而非通过CDC等方式同步数据的双拷贝方案，从根源上保证了一致性、简化了架构。
写在最后
从整个ETL链路来看，数据还是那个数据，但使用数据的方式，再也回不去了。
采访快结束时，笔者问了最后一个问题：你们的差异化优势是什么？杨瑜的回答是：“大方向大家确实相近，但我们的差异化在于选择并高度兼容PostgreSQL生态——能直接借力PG成熟、庞大的工具、扩展与开发者生态（如pgvector等），用户上手和迁移成本低，也不必被单一厂商锁定。这不是投入多少资源的问题，而是技术路线的选择。”
从70年代的SQL到2026年的Agent Ready，数据库走过了50年。前40年，数据库围着人转；最近10年，数据库开始围着数据转；而从今年开始，数据库要围着Agent转。工具和人（或者Agent）的关系变了，整个底座都得重构。这不是加个插件的事，而是要AI原生重构。可以说，这场“换岗”，给整个社会带来的影响，不亚于从算盘到计算机的跃迁。
发表于 昨天 23:18
|
查看: 7|
回复: 0
