顶尖大学的校园哲学：主权AI时代谁才真正拥有智能体数据记录？

顶尖大学为何将图书馆与实验室建在同一校园？原因很简单：数据、智能、学习与应用集中在一处，形成飞轮效应。牛津、斯坦福和麻省理工学院之所以举足轻重，靠的不是某项单一能力，而是所有能力高度集中、协同设计的结果。这些校园培育出诺贝尔奖得主和公司创始人，正是因为它们从一开始就围绕核心要素构建，而非事后拼凑。

AI与数据平台同样遵循这一逻辑：邻近性与主权决定胜负。大多数企业都希望运行自己的AI与数据平台，但真正成功的寥寥无几。成功者有一个共同特征：拥有一个主权控制平面，统一数据、运行时、治理与访问控制各层紧密协作。他们弥合了"立志成为数据与AI平台"和"真正成为自己的AI操作系统"之间的差距。

请记住这个核心理念：邻近性加上居中控制。智能体时代即将对这一理念发起前所未有的考验。

Databricks近期收购了Electric团队，该团队开发了一款可在智能体沙箱内运行的WASM版Postgres，体量极为轻量。此次收购将其并入Lakebase，并配套实时同步引擎，实现边缘端轻量Postgres与中央平台之间的数据同步，以保障持久性与可控性。这是一笔聪明的收购，但也透露了一个信号：当最大的平台竞相在"面向智能体的Postgres"领域插旗，问题已不是Postgres是否胜出，而是这笔收购解决了哪一半问题，以及真正重要的那一半最终归谁所有。

Postgres的胜出并非某家厂商的一面之词，业内架构师的评估可以作证。ORBIS Austria数据与AI首席企业架构师Florian Zeba直言：在概念验证和最小可行产品阶段，Postgres是默认选择，尤其是在AI相关项目中。但他同时指出了瓶颈所在：标准pgvector在向量数量约500万至1000万以内可维持p99延迟低于20毫秒；一旦超过这一阈值，HNSW索引将超出内存容量，延迟急剧劣化。这恰恰是一个基础原语力不从心、需要平台接棒的临界点。

智能体打破了传统基础设施的固有假设。它们在运行时动态决定所需数据，在沙箱中运行且只有一条网络路径通向外部，同时以集群方式部署，每个智能体都需要实时获知其他智能体的最新操作状态。这实际上是两个问题，但业界常常将其混为一谈。

第一个问题是快速本地上下文，即在智能体运行所在位置部署一个轻量级数据库。这正是Electric所解决的问题，确实有其价值，但这只是较易解决的那一半。

第二个问题是数据记录：一个持久、受治理的状态版本，供数百个非确定性智能体并发读写，且不产生冲突或数据损坏。这才是真正的难题——谁拥有这份记录、写入如何协调、向量数量超过阈值后检索性能如何保持。边缘原语加同步引擎能搬运数据，但无法治理数据，也无法解决中心端的性能问题。这正是校园原则的技术表达：智能与权威记录必须从设计之初就共处一地，而不是把沙箱里的数据通过网络路径同步回一个由他人掌控的记录系统。

性能数据值得关注。今年7月，McKnight咨询集团的独立基准测试显示：在标准化企业硬件上处理5000万向量时，EDB Postgres(R) AI的查询中位延迟为50毫秒，而Databricks的延迟超过4000毫秒，且召回率更低、每次查询成本更高。检索性能与治理能力虽是不同维度，但对于一个将自身定位为"面向智能体的Postgres"中心平台的产品而言，中心恰恰是这些数据最为关键的地方。

"将数据同步回中央平台以实现管控"——细则就藏在这句话里。管控是在谁的条件下实现的？治理数据记录意味着数据库本身必须强制执行每个智能体的权限，按角色划定范围，仅授予当前任务所需的最小权限，并在执行层面而非应用代码层或提示词层落实。写入操作在触及记录之前须经过审批，每条语句均须被捕获以供审计。做到这一点，一个智能体集群才真正可信。若跳过这一步，构建的不过是一套快速、分布式地破坏数据源真实性的机制。收购模式的隐患在于：你同步回去的那个中心，是一个专有控制平面，其持久性与管控权是在平台条款下提供的，运行在你并不完全拥有的基础设施之上。

以下是当前值得重点权衡的几点建议：

在选择工具之前，先将两个问题分开。快速本地上下文与受治理的数据记录是两项不同的工作，询问任何供应商他们所解决的究竟是哪一半。

了解自身的规模临界点。pgvector在特定规模内表现优异，超出后性能下降。明确自身工作负载所处位置，以及平台在超过该临界点后如何应对。

找到真正执行权限的边界层。应用代码和提示词终究会失效，持久的解决方案是数据库在执行层面、针对每个智能体强制执行权限，并对每次写入设置门控。

要求完整的可审计性。如果无法逐条语句地还原每个智能体的行为，就无法信任它，也无法向监管机构证明其合规性。

确认谁掌控中心。如果数据记录存储在某个供应商的专有控制平面内，你实际上是在租用AI战略的地基。务必确认能否在开放的Postgres上、在自己掌控的基础设施上独立运行。

Postgres赢得智能体数据库之争，在于它本身就具备事务保障和运营成熟度，能够为不可预测的工作负载提供受治理的记录支撑，且以开放方式实现。这才是值得守护的核心价值。

顶尖大学几个世纪前就悟透了这个道理：将所有重要的事物集中在一处，统一设计，置于同一屋檐下。Databricks刚刚花钱买下了边缘端。而中心——那个每个智能体都要写回的、可信、受治理、可移植且高性能的数据记录——仍然由你自己掌握。问题在于：你是真正掌控它，还是在租用它？

Q&A

Q1：为什么说Postgres赢得了智能体数据库之争？

A：Postgres赢得智能体数据库市场的核心原因在于，它本身具备成熟的事务保障能力和丰富的运营经验，能够为不可预测的智能体工作负载提供受治理的持久记录支撑，并以开放方式实现。业内架构师普遍将Postgres作为AI相关项目概念验证和最小可行产品阶段的默认选择。但需注意，标准pgvector在向量数量超过500万至1000万后性能会显著下降，超出这一阈值后需要更完整的平台能力来接棒。

Q2：Databricks收购Electric团队解决了哪些问题，又遗留了哪些问题？

A：此次收购解决了"快速本地上下文"问题，即在智能体沙箱内提供轻量级Postgres运行环境，并通过实时同步引擎将数据传回中央平台。但遗留的关键问题是"数据记录治理"：谁拥有权威数据记录、写入冲突如何协调、超过向量规模阈值后检索性能如何保障，以及数据被同步回的中央控制平面是否真正由企业自己掌控。这是该收购模式难以回避的隐患。

Q3：企业在构建面向智能体的数据平台时应如何评估供应商？

A：企业应重点从以下维度评估：一是区分快速本地上下文与受治理数据记录这两个不同问题，确认供应商解决的是哪一半；二是明确自身工作负载的规模临界点，了解平台超出阈值后的表现；三是确认权限是否在数据库执行层面强制落实，而非依赖应用代码或提示词；四是要求完整的逐语句可审计性；五是确认数据记录是否运行在开放Postgres和企业自控基础设施上，避免将AI战略的地基"租"给单一供应商。