来源：https://vibhorkumar.wordpress.com/2026/08/19/every-ai-agent-may-need-postgresql-not-every-agent-should-own-the-truth/

每个AI智能体可能需要PostgreSQL，但不是每个智能体都应掌握“真理”

发布者：企业AI · 数据平台 · 技术领导力

发布于：2026年8月19日

Databricks收购Electric一事之所以值得关注，原因有几点。Electric开发了PGlite，这是一个PostgreSQL的WebAssembly构建版本，可以在浏览器、应用程序、无服务器环境或AI智能体沙箱中运行。它还开发了旨在将这些分布式环境与中央PostgreSQL系统连接起来的同步技术。

其采用速度之快令人瞩目。PGlite的周下载量在大约12个月内从100万增长到了1300万。该项目始于Neon联合创始人Stas Kelvich在PostgreSQL到WASM方面的基础性工作，Electric随后将其转变为一种可嵌入的数据库，应用于开发工具、测试框架、浏览器沙箱和AI应用程序。（Neon公告）

这是令人印象深刻的执行力。但更重要的故事并非这次收购。

而是PostgreSQL正在浮现的新架构角色。

在其历史的大部分时间里，PostgreSQL一直被部署为服务器。应用程序通过网络连接到它，执行事务，并将其作为一个持久的记录系统（system of record）来依赖。PGlite引入了另一种可能性：PostgreSQL可以运行在应用程序内部——甚至可以直接运行在智能体本身内部。

这使得数据库更接近智能体的执行循环，并从涉及本地上下文的操作中移除了网络往返。但这也引发了一个更为棘手的问题：

如果每个智能体都有一个数据库，那么哪个数据库拥有“真理”？

为什么智能体会造成不同的状态问题

传统应用程序通常具有已知的执行路径。它们的查询是预先设计的，数据访问模式是可测试的，其基础设施也相对稳定。

智能体的行为则不同。

一个智能体可能会在运行时决定它需要哪些信息、调用哪些工具以及保留哪些中间结果。它可能检索文档、生成嵌入向量、制定计划、调用外部系统、修正其假设并与其他智能体协调。

所有这些活动都会产生状态。

有些状态是临时的。有些必须在智能体会话期间持久化。有些需要与其他智能体共享。有些最终可能成为企业记录系统的一部分。

将每一个中间操作都发送到远程数据库可能会引入延迟和不必要的耦合。然而，将所有内容都保留在智能体沙箱内部会创建难以治理、协调或审计的孤立状态孤岛。

PGlite为智能体提供了一个靠近其执行位置的本地PostgreSQL数据库。Electric的同步技术旨在将分布式本地状态与集中的PostgreSQL基础设施连接起来。Databricks将这种组合描述为将PostgreSQL从湖仓（lakehouse）扩展到边缘：PGlite在沙箱中运行，而中央Lakebase PostgreSQL环境则提供共享状态和控制。（Databricks公告）

这种模式很有吸引力，但不应将其解读为所有类型的数据都适合放在智能体本地数据库中的证据。

本地自治与企业权威并非同一回事。

同一个PostgreSQL标准，不同的职责

PGlite并非仅仅模仿PostgreSQL语法的JavaScript数据库。它是被编译为WebAssembly并打包用于JavaScript环境的PostgreSQL。它可以在内存中运行或使用本地持久化存储，并且支持包括pgvector在内的PostgreSQL扩展。这使得智能体能够在其本地环境中结合关系数据、元数据、全文搜索和向量检索。（PGlite文档）

PGlite目前运行在PostgreSQL的单用户模式下：一个进程和一个连接。多连接支持仍在计划中，因为WebAssembly不提供PostgreSQL通常用于并发后端的fork模型。这是将PGlite视为智能体本地执行存储（而非共享记录系统）的另一个原因。（Electric的PGlite架构概览）

这是一种重要的PostgreSQL利用形式。开发人员可以在运行传统数据库服务器不切实际的地方，使用熟悉的SQL、模式、数据类型、事务以及部分扩展生态系统。

但在两端都使用PostgreSQL并不意味着这两个数据库是可互换的。本地实例和中央实例承担着不同的职责。

我发现将智能体状态分为三类很有用。

1. 临时工作状态
这包括中间计划、临时工具结果、检索到的文档片段、一次性嵌入向量、测试数据和短期上下文。将此状态保持在智能体附近可以减少延迟，并允许沙箱更独立地运行。
其中大部分根本不需要成为企业数据。

2. 持久化智能体状态
这可能包括检查点、已批准的记忆、已完成的工作产品，以及另一个智能体完成任务所需的信息。它必须在一个执行会话之后仍然存在，但它不会自动成为权威的业务记录。
此类别需要明确的同步、保留、所有权和重用规则。

3. 权威企业状态
客户记录、财务交易、权限、身份、策略、受监管信息以及最终业务成果属于受治理的记录系统。
智能体可以消费或提议更改此状态，但其本地数据库不应悄无声息地成为替代数据源。

这种区分很重要，因为PostgreSQL可以保证单个本地沙箱内的事务完整性，却不能自动保证在成千上万个独立运行的智能体之间保持正确性。

它也决定了该架构的哪些部分实际上需要随之而来的审查。从未离开沙箱的临时工作状态大多不受此影响。持久化和权威状态才是真正的问题开始的地方。

同步才是真正的系统性问题

在WebAssembly中运行PostgreSQL在技术上令人着迷。同步一组分布式PostgreSQL环境则是更深层次的架构挑战。

• 当两个智能体更新同一个实体时会发生什么？
• 如果智能体在中央权限被撤销后继续工作怎么办？
• 本地生成的事务在网络中断后能否安全地重放？
• 哪些操作可以容忍最终一致性，哪些操作在执行前需要中央批准？
• 模式和策略更改如何传播到活动的沙箱？
• 我们如何证明数据、策略、模型和提示的哪个版本影响了智能体的决策？

这些问题决定了该模式能否从优雅的开发者体验转变为可信赖的企业架构。

它们也说明了为什么同步必须携带的不只是行（rows）。智能体需要适当的数据，但它还需要授权和策略上下文来管理如何使用这些数据。如果数据脱离了其控制而移动，同步可能会在复制信息的同时削弱其意义。

其中一些工作仍处于早期阶段。当前文档中描述的PGlite同步插件被标记为alpha版本，其限制包括出站本地写入同步和冲突解决。更广泛的Electric同步引擎具有额外的能力，但文档是一个有用的提醒，表明架构愿景领先于某些实现细节。（PGlite同步文档）

这并不削弱其方向性。它只是阐明了困难工程从何处开始。

应用 C.A.L.M. 平台测试

我一直在使用 C.A.L.M. 平台测试来评估一个PostgreSQL架构在增长时是变得更值得信赖，还是仅仅积累运营方面的担忧。该测试考察了可变更性（Changeability）、保障（Assurance）、杠杆作用（Leverage）和可测量性（Measurability）。

C.A.L.M. 对纯粹的、从不离开沙箱的临时工作状态没有评判——一个草稿缓冲区不需要平台信任测试。当智能体本地状态进入持久化或共享领域时，它就变得相关了：那些必须跨会话存活、同步回中央实例或影响另一个智能体下一步决策的检查点、记忆和工作产品。

这正是智能体本地PostgreSQL正在走向的方向，也是C.A.L.M.的每个维度都变得更加重要的地方。

可变更性
智能体架构可能会创建数千个——甚至最终数百万个——短暂的PostgreSQL数据库。我们需要了解模式、扩展、数据合约、同步规则和安全策略如何在这个分布式资产中演进。
数据库可能是短暂的。但模式不兼容却异常持久。

可变更性还意味着要避免这样一种设计：本地应用程序变得与某一个同步服务或中央平台密不可分。PostgreSQL兼容性应保留架构选择，而不仅仅是重新定位依赖。

保障
保障从一个简单的问题开始：对于每一类状态，哪个PostgreSQL实例是权威的？
由此引出更难的问题。冲突如何处理？授权变更多快能到达活跃的沙箱？当智能体完成工作时，敏感数据会怎样？哪些操作需要中央验证？如何防止被入侵的本地状态污染记录系统？
我们赋予智能体的自主权越多，就必须越精确地定义其边界。

杠杆作用
这可能是该架构最大的优势。
PostgreSQL可以在开发、测试、本地执行和集中化生产之间提供通用语义。团队可以重用SQL知识、数据模型、迁移、事务概念和已建立的工具。诸如pgvector之类的扩展还允许本地AI检索，而无需引入完全不同的数据库模型。
环境之间的转换越少，意味着集成错误越少。但杠杆作用不应与同质化混淆：相同的PostgreSQL基础可以支持不同的操作职责。

可测量性
没有可观测性的分布式自治会变成分布式模糊性。
企业将需要测量同步延迟、陈旧上下文、复制失败、冲突写入、策略传播、资源使用情况以及每个本地数据库的生命周期。他们还需要将智能体本地观察到的内容与其最终在中央更改的内容关联起来的血缘关系（lineage）。
应该能够回答的不仅是“智能体做了什么？”，还有“它在决定这样做的时候，依据的是什么策略，知道了什么？”

C.A.L.M. 将讨论从PostgreSQL能否在智能体内部运行，提升到了由此产生的平台能否在智能体、数据库和同步路径数量增长时仍保持可信赖。

当智能体采取行动时，ORBIT变得重要

平台准备就绪只是问题的一部分。一旦智能体开始更改持久化数据或调用外部系统，执行路径也必须是可靠的。仅限本地且可丢弃的工作状态不需要这种纪律；一旦它写入某个持久化位置或触发沙箱外部的操作，它就变得需要了。

这正是ORBIT原则适用的地方：

• Outbox First（先出箱）：在同步更改或调用外部系统之前，以事务方式记录持久意图。
• Rate State Is Shared State（速率状态即共享状态）：一组智能体无法在隔离的沙箱内部独立地强制执行全局资源或API限制。
• Background Is the Unit of Execution（后台是执行单元）：同步和外部调用应作为可恢复的后台工作运行，而不是在长时间运行的数据库事务内部。
• Idempotency Before Day One（从一开始就幂等）：重试、重连和重放事件不得重复底层的业务操作。
• Trace Everything（追踪一切）：本地上下文、数据库更改、同步事件、工具调用和中央结果必须形成一条可追踪的执行路径。

考虑一个智能体在本地提交一个事务，调用一个外部服务，然后在其状态被中央同步之前失去连接。当任务恢复时，智能体可能不知道外部操作是否已完成。重复执行它可能会向客户重复收费、再次提交同一订单或执行第二次基础设施变更。

PostgreSQL可以保护本地事务。ORBIT则是关于保护端到端的结果。

PostgreSQL社区接下来应该审视什么

PGlite证明PostgreSQL可以到达以前数据库服务器难以进入的环境。它的采用表明，对一个小的、可嵌入的、对扩展友好的PostgreSQL运行时存在真实需求。

接下来的问题比PGlite或任何单次收购都更大：

• 在受限和临时的运行时中，应该保留哪些PostgreSQL功能？
• 逻辑复制能否发展以更自然地支持这些拓扑结构？
• 扩展、模式更改和安全策略应如何分发？
• 对于大规模嵌入式数据库集群，需要哪些生命周期和可观测性标准？
• 本地PostgreSQL能否在中央平台和同步提供者之间保持可移植性？
• 社区应该在哪里划清有用兼容性与行为与基于服务器的PostgreSQL存在实质性差异之间的界限？

这些都是值得提出的问题，因为PostgreSQL正同时朝着两个方向发展。

一方面，它正变得更加分布式、弹性化，并与大型数据和AI平台深度集成。另一方面，它正变得足够小巧，可以运行在浏览器标签页、应用程序进程或智能体沙箱中。

一个方向是将PostgreSQL集中化，以提供持久性、治理和共享事实。另一个方向则是将其分布化，以实现局部性、自治性和速度。

未来可能需要两者兼得。

因此，Databricks收购Electric不仅仅是AI基础设施市场的又一起交易。它证明了PostgreSQL不仅被视为智能体应用程序背后的数据库，也被视为智能体本身内部的数据库。

这是一次重要的演进。但持久的架构问题不在于我们可以创建多少个PostgreSQL数据库。

而在于我们能否在智能体可以使用（use）的状态、它可以更改（change）的状态以及企业准备信任（trust）的事实之间，保持一个清晰的边界。