Databricks 收购 Electric，值得关注的地方不只是交易本身，更在于它提示了一种正在成形的架构：PostgreSQL 不再只能作为远程服务器运行，也可以进入浏览器、应用进程、无服务器环境，甚至 AI Agent 的沙箱。
Electric 的 PGlite 是编译为 WebAssembly 的 PostgreSQL，可以嵌入 JavaScript 环境，并支持本地持久化、事务、SQL 以及包括 pgvector 在内的一部分扩展。配合同步技术，本地数据库可以与中心 PostgreSQL 系统连接起来。
这会让 Agent 的执行循环更快、更独立。但它也带来一个必须正面回答的问题：如果每个 Agent 都有自己的数据库，究竟哪个数据库拥有真相？
Agent 带来的新状态问题
传统应用通常拥有相对稳定的执行路径。查询由开发者预先设计，数据访问模式可以测试，基础设施也较容易统一管理。
Agent 的执行路径则可能在运行时决定。它可能检索文档、生成向量、调用工具、制定计划、修改假设、协调其他 Agent，并把中间结果保留到下一次执行。于是，系统会产生大量不同性质的状态：
- 临时计划、检索片段和一次性工具结果；
- 需要跨会话保留的检查点、批准记忆和工作成果；
- 客户、财务、权限、身份和最终业务结果等企业权威数据。
把所有中间操作都写入远程数据库，会增加网络延迟和系统耦合。把所有内容留在 Agent 沙箱中，又会产生难以治理、审计和对账的孤岛。
一个更清晰的做法，是把状态分成三层：
1. 临时工作状态
包括中间计划、短期上下文、检索文档片段、临时 embedding、测试数据和一次性工具响应。这类数据通常适合放在 Agent 本地，任务结束后可以清理，也不必进入企业系统。
2. 持久 Agent 状态
包括任务检查点、经过批准的记忆、已完成的工作成果，以及其他 Agent 需要继续处理的信息。它必须跨执行会话存活，但不代表它自动成为企业事实。
这类状态需要明确同步方向、保留期限、冲突处理、访问权限和复用规则。
3. 企业权威状态
客户记录、金融交易、订阅权益、身份、策略、受监管信息和最终业务结果，应当存放在受治理的系统记录中。Agent 可以读取这些数据，也可以提出变更，但本地数据库不应悄悄变成另一个事实来源。
PostgreSQL 在单个本地沙箱中可以保证事务完整性，却不能自动保证成千上万个独立 Agent 之间的数据一致性和业务正确性。
PGlite 的价值：熟悉的数据库进入执行现场
PGlite 的意义不只是“在浏览器里放一个 SQL 数据库”。它把 PostgreSQL 本身编译为 WebAssembly，让开发者能够在受限环境中继续使用熟悉的数据类型、Schema、事务和部分扩展生态。
这带来几个实际收益：
- Agent 可以在本地完成低延迟的上下文查询；
- 关系数据、全文检索、元数据和向量检索可以放在同一套模型中；
- 开发、测试、浏览器沙箱和生产 Agent 可以共享更多 SQL 与迁移知识；
- 对短期任务而言，不必为每个本地执行环境启动完整数据库服务器。
但兼容 PostgreSQL 并不等于本地实例和中心实例可以互相替代。PGlite 当前运行在 PostgreSQL 的单用户模式中，通常对应一个进程和一个连接。由于 WebAssembly 不具备 PostgreSQL 服务器常用的 fork 后端模型，多连接支持仍然是另一个工程问题。
因此，PGlite 更适合被视为 Agent 的本地执行存储，而不是共享系统的权威数据库。
一个可实践的本地状态模式
下面是一个简化示例。它演示如何在 Agent 本地使用 PGlite 保存临时上下文，并通过 outbox 记录准备同步到中心系统的持久意图。
这是一个可改造的实践示例，不代表所有 PGlite 版本都具有完全相同的同步插件接口。运行前可以先创建一个空的 Node.js 项目，并安装当前版本的 PGlite：
mkdir agent-local-db
cd agent-local-db
npm init -y
npm install @electric-sql/pglite
创建 agent.mjs：
import { PGlite } from '@electric-sql/pglite';
const db = new PGlite('./data/agent');
await db.exec(`
CREATE TABLE IF NOT EXISTS working_context (
key TEXT PRIMARY KEY,
value JSONB NOT NULL,
expires_at TIMESTAMPTZ
);
CREATE TABLE IF NOT EXISTS outbox (
event_id UUID PRIMARY KEY,
event_type TEXT NOT NULL,
aggregate_id TEXT NOT NULL,
payload JSONB NOT NULL,
created_at TIMESTAMPTZ NOT NULL DEFAULT now(),
sent_at TIMESTAMPTZ
);
`);
await db.transaction(async (tx) => {
await tx.query(
`INSERT INTO working_context (key, value, expires_at)
VALUES ($1, $2::jsonb, now() + interval '30 minutes')
ON CONFLICT (key) DO UPDATE
SET value = EXCLUDED.value, expires_at = EXCLUDED.expires_at`,
['customer_context', JSON.stringify({ customerId: 'cust_123', intent: 'renewal' })]
);
// 只记录可重试的持久意图，不在数据库事务中调用外部服务。
await tx.query(
`INSERT INTO outbox (event_id, event_type, aggregate_id, payload)
VALUES (gen_random_uuid(), $1, $2, $3::jsonb)`,
[
'renewal.proposed',
'cust_123',
JSON.stringify({ source: 'agent-local', requestedBy: 'agent_42' })
]
);
});
const result = await db.query(
`SELECT event_id, event_type, aggregate_id, payload
FROM outbox
WHERE sent_at IS NULL
ORDER BY created_at
LIMIT 100`
);
console.log(JSON.stringify(result.rows, null, 2));
await db.close();
这个模式有几个关键边界：临时上下文可以留在本地；需要跨会话传递的动作先写入 outbox；真正的外部调用由可恢复的后台工作执行；中心系统在接收事件后，仍然负责校验权限、业务规则和最终状态。
在真实系统中，还需要为 outbox 增加事件去重键、重试次数、错误原因、租约和死信处理。对于金融交易、订单提交或基础设施变更，不能仅凭本地事务判断外部动作是否成功。
同步比运行 PostgreSQL 更难
在单个 Agent 中运行 PostgreSQL 是工程实现问题；同步一批分布式 PostgreSQL 实例，才是系统架构问题。
至少需要回答以下问题：
- 两个 Agent 同时修改同一个实体时，谁能胜出？
- Agent 失去权限后，本地沙箱还能运行多久？
- 断网期间产生的事务是否可以安全重放？
- 哪些数据允许最终一致，哪些操作必须先获得中心批准？
- Schema、扩展和安全策略如何传播到正在运行的沙箱？
- 如何证明某次决策使用了哪个版本的数据、策略、模型和提示词？
同步的不应只有数据行，还应包括数据的控制上下文。授权范围、租户边界、数据分类和策略版本如果没有一起传播，系统可能复制了数据，却削弱了数据原本的治理含义。
当前文档中提到的 PGlite 同步能力仍有早期阶段的限制，例如本地写入向外同步和冲突解决。更完整的同步引擎可以提供更广泛的能力，但这也说明架构愿景与成熟的企业级实现之间仍有距离。
用 C.A.L.M. 检查平台是否值得信任
当本地状态开始跨越 Agent 边界时，可以用四个维度检查整体平台：Changeability、Assurance、Leverage 和 Measurability。
Changeability：能否持续改变
Agent 的数量可能从几百增长到数百万。平台需要管理本地 Schema、扩展、数据契约、同步规则和安全策略的演进。
数据库本身可以是短命的，但 Schema 不兼容往往会长期存在。迁移策略必须能够处理版本差异、暂停同步、回滚和逐步升级。使用 PostgreSQL 的兼容性，应该帮助团队保留架构选择，而不是把所有本地应用锁定在某个同步服务上。
Assurance：谁对结果负责
第一问永远是：每种状态由哪个 PostgreSQL 实例负责？
接下来还要确认冲突规则、权限传播延迟、敏感数据清理、中心审批和本地状态隔离。Agent 越自主，边界就越需要精确。一个本地事务成功，并不代表企业已经接受了这个结果。
Leverage：是否真正减少了复杂度
统一使用 PostgreSQL 可以复用 SQL、数据模型、迁移、事务概念和成熟工具。pgvector 这类扩展也让本地检索不必完全切换到另一种数据库模型。
但统一基础设施不等于所有实例承担相同职责。PGlite 负责本地低延迟执行，中心 PostgreSQL 负责共享、治理和权威记录，这种职责差异应当写进架构与代码中。
Measurability：是否能解释发生了什么
没有观测能力的分布式自主性，最终会变成分布式不确定性。至少需要监控：
- 同步延迟和失败率；
- 本地上下文的新鲜度；
- 冲突写入和重放次数；
- 权限与策略传播状态；
- 每个本地数据库的资源使用和生命周期；
- Agent 观察到的上下文与中心最终变更之间的关联。
理想的审计记录不只回答“Agent 做了什么”，还应回答“它在什么时间、基于哪一版数据和策略、在什么权限下做出了决定”。
Agent 一旦产生外部副作用，就要遵守 ORBIT
临时状态如果永远留在沙箱内，风险相对有限。一旦 Agent 开始修改持久数据或调用外部系统，就需要更严格的执行纪律：
- Outbox First：在同步或调用外部系统前，先事务性记录持久意图；
- Rate State Is Shared State：全局配额和 API 限流不能依赖每个沙箱的本地判断；
- Background Is the Unit of Execution：同步和外部调用应由可恢复的后台任务完成，不应绑在长事务中；
- Idempotency Before Day One：从第一天就设计幂等键，确保重试和重放不会重复业务动作；
- Trace Everything：本地上下文、数据库变更、同步事件、工具调用和中心结果必须串成一条追踪链。
例如，Agent 先在本地提交订单意图，再调用支付服务；调用完成后网络断开，本地状态却还没有同步。任务恢复时，如果系统无法确认支付是否完成，盲目重试就可能造成重复扣款。PostgreSQL 可以保护本地事务，不能单独保护跨系统的最终结果。
采用前的检查清单
可以把以下问题作为落地前的最低检查标准：
- 临时、持久和权威状态是否有明确分类？
- 每类数据的唯一事实来源是否已经写明？
- 本地写入、中心审批和冲突解决的边界是否明确？
- 权限、策略和数据版本是否可审计？
- 同步失败、断网、撤权和 Schema 升级是否有恢复方案？
- 外部动作是否使用 outbox、幂等键和可恢复后台任务？
- 是否能从 Agent 决策追溯到本地上下文和中心结果？
PGlite 说明 PostgreSQL 已经足够灵活，可以进入浏览器、应用进程和 Agent 沙箱。未来的重点不是创建多少个 PostgreSQL 数据库，而是为每个数据库划定清楚的权限、生命周期和责任边界。
本地 PostgreSQL 负责靠近执行现场，中心 PostgreSQL 负责持久性、治理和企业真相。两者可以使用同一种数据库语言和技术基础，但不应因此被误认为拥有同一种权威。真正成熟的 Agent 架构，必须同时保留本地自主性和企业对最终事实的控制。