“人”退场，“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原生重构。可以说，这场“换岗”，给整个社会带来的影响，不亚于从算盘到计算机的跃迁。