PostgreSQL 已经成为 Agentic AI 的默认数据库，但真正的挑战才刚开始。智能体不再只是读取几张表、生成一段回答，而是在数据库中持续写入记忆、检查点、中间结果、工具调用记录和共享状态。把 PostgreSQL 当成一个“停车场”，只负责把数据放进去，系统很快就会被并发写入、失败恢复和数据膨胀拖垮。
更可靠的做法，是把 PostgreSQL 当成计算层：让它负责事务、检索、任务领取、事件通知、并发控制、恢复和审计，并让这些能力与业务数据处于同一个一致性边界内。
Agent Memory 与 Agent State 不是一回事
Agentic AI 的数据通常可以分成两类。
Agent memory 是智能体跨会话保留的知识，例如用户偏好、历史事实、产品文档和向量化内容。它主要服务于检索，关注语义匹配、关键词命中和数据更新期间的可见性。
Agent state 则是工作流运行所需的状态，包括检查点、scratchpad、中间计算结果、任务领取记录和多智能体协调信息。它决定一个工作流失败后能否继续，以及多个智能体同时操作时是否会互相覆盖。
这一区分很重要。只做 RAG 的聊天应用大多是读密集型系统；生产中的自主智能体则会反复写回数据库。它们可能同时更新共享表、读取其他智能体尚未完成的结果，或者在同一个工作流中运行多个并发步骤。
例如，一个数据清洗智能体正在更新知识库，RAG 查询同时读取这批内容；一个预测智能体把半成品写入临时表，其他流程又开始读取这些结果。如果没有事务边界和明确的状态模型，问题不会只表现为查询变慢，而会表现为错误上下文、重复执行和无法解释的决策链。
检查点让失败变成可恢复事件
多步智能体工作流的端到端成功率会快速下降。假设每一步成功率为 85%，一个十步流程全部成功的概率约为：
0.85^10 ≈ 0.20
因此，生产系统不能只在工作流结束时保存结果。更实用的方式是在每个重要步骤之后，将完整工作流状态保存为检查点。第七步失败时，系统从最近一次已知良好状态恢复，而不是从第一步重新执行。
LangGraph 等生产架构把 PostgreSQL 用作检查点后端，原因并不只是它能存 JSON，而是它同时提供事务、持久化、并发控制和可查询的历史记录。数据库在这里承担的是恢复机制，而不是普通日志文件。
可以这样实践一个基于 PostgreSQL 的任务领取与检查点表。下面的示例假设使用 PostgreSQL 14 或更高版本：
CREATE TABLE agent_jobs (
id BIGSERIAL PRIMARY KEY,
workflow_id TEXT NOT NULL,
status TEXT NOT NULL DEFAULT 'ready',
payload JSONB NOT NULL,
checkpoint JSONB,
locked_at TIMESTAMPTZ,
updated_at TIMESTAMPTZ NOT NULL DEFAULT now()
);
CREATE INDEX agent_jobs_ready_idx
ON agent_jobs (updated_at, id)
WHERE status = 'ready';
-- 一个工作进程原子地领取任务，不等待其他进程已锁定的行
WITH next_job AS (
SELECT id
FROM agent_jobs
WHERE status = 'ready'
ORDER BY updated_at, id
FOR UPDATE SKIP LOCKED
LIMIT 1
)
UPDATE agent_jobs AS j
SET status = 'running',
locked_at = now(),
updated_at = now()
FROM next_job
WHERE j.id = next_job.id
RETURNING j.id, j.workflow_id, j.payload, j.checkpoint;
-- 每一步完成后保存检查点
UPDATE agent_jobs
SET checkpoint = jsonb_build_object(
'step', 'review',
'result', jsonb_build_object('approved', true)
),
updated_at = now()
WHERE id = $1;
FOR UPDATE SKIP LOCKED 适合将普通表变成并发任务队列：多个智能体可以领取不同任务，不必等待已经被其他进程锁定的行。实际部署时，还需要增加超时回收逻辑，例如把长期处于 running 状态的任务重新标记为 ready，并记录重试次数与错误信息。
把检索、协调和审计放在同一层
Agentic AI 的检索通常不能只依赖向量相似度。向量搜索擅长理解“概念相近”，但可能漏掉产品 SKU、错误码或合同编号；关键词搜索能命中精确字符串，却可能错过语义相关的内容。生产 RAG 更适合组合两者，再使用 Reciprocal Rank Fusion 等方法合并排名。
PostgreSQL 可以在同一个系统中承载关系数据、向量、全文搜索和时间序列数据。pgvector 可用于余弦相似度检索，BM25 类搜索可用于关键词排名。这样，查询可以同时利用语义、字段过滤、租户权限和时间范围，而不必在多个系统之间复制和同步数据。
写入路径也需要事务化。文档摄取流程可以先写入文档版本和分块记录，完成向量生成后再以一个明确的版本号发布。RAG 查询只读取已发布版本，避免在批量写入过程中看到半成品内容。
协调状态同样适合放在数据库中。任务队列、事务、MVCC、advisory lock 和 LISTEN/NOTIFY 已经覆盖了许多多智能体场景：
- 任务领取可以用行锁和
SKIP LOCKED。 - 共享资源可以用 advisory lock 协调，而不必锁住整张业务表。
- 事件通知可以用
LISTEN/NOTIFY减少轮询。 - MVCC 让并发事务读取一致的快照，并隔离未提交修改。
这不意味着 PostgreSQL 必须替代所有编排框架。更准确的边界是：编排框架负责执行逻辑，数据库负责持久化协调状态、业务结果和恢复依据。把这些状态放到同一个事务存储中，回滚、恢复和审计可以共享一致性边界；放在多个自建状态机和缓存里，则需要额外实现一致性。
审计数据要从一开始设计生命周期
一个由多个智能体组成的工作流，至少会产生以下记录：调用了哪个模型、使用了什么提示词、模型返回了什么、消耗了多少 token、调用了哪些工具、工具参数是什么，以及每个步骤何时开始和结束。
这些记录不是可有可无的调试日志。对于贷款审批、合规审核和交易授权等场景，团队需要回答：哪个智能体做出了决定、它依据了什么、执行顺序是什么、是否发生了重试，以及最终输出能否追溯到原始输入。
这类数据通常是追加写入、关系结构明显，并且有两种查询模式：监控智能体实时检查预算和超时，人类在故障发生后沿着工作流、步骤和工具调用反向追踪。对应的数据库设计应包含稳定的外键、面向实时监控的索引、按时间分区，以及明确的保留策略。
不要让所有历史 trace 永久占用热存储。最近 48 小时的执行记录可以留在 PostgreSQL 热分区中，供 watchdog 快速查询；数月的历史记录可以迁移到对象存储上的 Apache Iceberg 等冷层，同时保留 SQL 查询能力。数据分层的目标不是放弃 PostgreSQL，而是让不同访问频率的数据使用不同成本的存储。
一份可执行的落地清单
评估 Agentic AI 数据库时，可以围绕以下问题做决定：
- 智能体是否通过受控接口访问数据库，而不是共享一个权限过大的连接字符串？MCP Server 这类接口可以提供 schema 发现、默认只读事务、查询诊断和审计记录，写权限则按数据库或操作范围显式开放。
- RAG 是否同时处理语义检索、关键词检索、结构化过滤和数据版本？只使用向量相似度通常不足以支撑精确业务检索。
- 工作流是否在每个关键步骤保存检查点？没有检查点的十步流程，失败时往往只能从头重跑。
- 多智能体是否使用数据库原生的事务、行锁、advisory lock 和事件通知，而不是在应用代码中重复实现一致性？
- trace、工具调用和审计记录是否拥有分区、索引、归档与保留策略？数据量增长速度可能超过传统业务表。
- 数据是否需要运行在云端、本地或隔离网络中？受监管系统应提前验证数据库、向量化组件和模型服务的部署边界。
PostgreSQL 的价值不只是“已经能存这些数据”。它能把检索、协调、检查点、并发控制、审计和业务事务放进一个可恢复的计算层。对于读多写少的聊天应用，读副本和横向扩展可能已经够用；但当智能体开始持续写回、相互协作并自主触发动作时，数据库层就决定了系统是可控的工作流，还是难以追踪的并发实验。