打造下一代 AI Agent 的统一多模智能数据底座——PostgreSQL 与 AI 的融合演进

分享人：魏波，北京晟数科技技术顾问，PG 分会副秘书长。

前言

过去两年，AI Agent 从"模型调用+工作流"的应用形态，逐步走向具备记忆、工具使用、任务规划、多智能体协作和持续运行能力的系统。与此同时，企业落地 AI Agent 时遇到的问题也正在发生变化：真正制约系统规模化的，往往不再只是模型能力，而是数据、记忆、检索、权限、运行状态与治理能力是否能够形成一个可靠的数据底座。

对于企业而言，AI Agent 的数据既包括传统业务数据，也包括文档、JSON、Embedding、会话记录、用户偏好、任务状态、工具调用记录以及实体关系等。因此，一个值得长期讨论的问题是：

能否以 PostgreSQL 为核心，把尽可能多的数据与 AI 数据能力统一到同一套事务与治理体系中，同时又保留对专业 AI 服务和专用基础设施的开放性？

本文从"数据底座"而不是"数据库包打一切"的角度，重新审视 PostgreSQL 与 AI 的融合路径，并结合 pgvector、pgvectorscale、pgai、PostgresML、Apache AGE，以及 PostgreSQL 17/18/19 的演进，讨论一个更适合企业实践的架构原则：

数据下沉，智能上移；统一优先，专业系统补位；数据库负责可靠的数据与记忆，Agent 平台负责编排与协作。

一、现状与挑战：AI Agent 为什么越来越需要"数据底座"

AI Agent 的核心循环可以抽象为：

text 复制代码

用户任务
   ↓
理解与规划
   ↓
检索记忆 / 知识 / 业务数据
   ↓
调用工具与外部系统
   ↓
产生观察结果
   ↓
更新状态、短期记忆、长期记忆
   ↓
继续循环或完成任务

这意味着 Agent 所依赖的并不是单一的"向量数据库"，而是一组彼此关联的数据：

业务事实：客户、订单、资产、组织、账号、工单等结构化数据。
非结构化知识：文档、网页、FAQ、规章制度、技术资料等。
语义数据：文本、图像等内容生成的 Embedding。
Agent 状态：会话、任务、执行步骤、工具调用、事件与结果。
记忆数据：用户偏好、历史事实、长期经验、总结信息。
关系数据：实体、组织、上下游关系和复杂业务关联。

因此，Agent 的"记忆问题"本质上不是单纯的向量检索问题，而是一个多模数据管理与一致性问题。

1.1 常见数据底座方案

当前企业常见的路线大致可以分为四类。

（1）专用向量数据库 / 向量检索引擎

代表产品包括 Pinecone、Milvus、Qdrant 等；FAISS 更准确地说是一个向量相似度检索库，而不是完整意义上的独立数据库产品。

其优势是围绕 ANN 检索进行专项优化，在超大规模向量场景下可以获得很好的性能与扩展能力。但如果业务事实仍存储在关系数据库中，就需要考虑数据同步、ID 关联、权限过滤、删除更新和一致性维护等问题。

（2）缓存 / KV 存储方案

代表产品包括 Redis 等。

其优势是低延迟、数据结构灵活，适合热点上下文、短期状态、会话缓存和任务协同。但如果把大量长期记忆、Embedding 和复杂过滤条件全部放入缓存体系，成本、持久化和查询能力会逐渐成为约束。

（3）对象存储 + 检索计算层

代表产品包括 S3、MinIO 等。对象存储非常适合原始文档、图片、音视频等非结构化数据，但它本身并不是完整的向量检索数据库；通常仍需要额外的索引、Embedding、检索或计算服务。

（4）关系数据库 + 向量 / JSON / 图等扩展

典型路线是 PostgreSQL + pgvector，并根据业务需要叠加 JSON、全文检索、PostGIS、时序扩展或图能力。

其核心价值并不是"所有场景性能都第一"，而是把业务事实、语义数据与 Agent 状态尽可能放在同一个数据治理边界内。

1.2 真正的企业痛点：不是数据库数量，而是数据边界

当企业同时维护业务数据库、向量数据库、图数据库、缓存和对象存储时，真正复杂的不是"系统多"本身，而是下面这些跨系统问题：

身份一致性：同一客户、用户、设备或文档，在多个系统中如何保持统一 ID。
状态一致性：业务数据更新之后，Embedding、检索索引和缓存何时同步。
权限一致性：用户在业务系统中的权限，能否正确传递到 Agent 检索结果。
删除一致性：数据被删除或撤销权限后，旧向量和旧缓存如何及时失效。
事务边界：业务写入、记忆更新、审计记录是否需要处在同一个事务边界。
运维复杂度：多个系统的备份、监控、扩缩容和故障排查如何统一。

所以，企业选择 AI 数据底座时，不应该简单比较"谁的向量 QPS 更高"，而应该同时比较：数据一致性、过滤能力、事务能力、权限模型、运维成本、扩展性和生态成熟度。

二、融合新思路：从"多系统拼装"到"统一数据平面"

PostgreSQL 的价值，不在于替代所有专业数据库，而在于提供一个成熟的关系数据库核心，再通过扩展机制，把更多 AI 所需要的数据类型与查询能力纳入同一治理体系。

2.1 传统 AI Agent 数据架构

典型架构往往类似：

这条路线并没有"错"。当向量规模、图查询规模、对象数据规模或实时性要求达到某个程度时，专业系统反而是更合理的选择。

问题在于：如果所有数据都过早拆开，系统会把大量工程复杂度消耗在同步、权限与数据治理上，而不是 AI 能力本身。

2.2 PostgreSQL 融合架构

更适合多数中型企业和大量 AI 应用的路线，可以抽象为：

这里最关键的变化是：

不是"全部统一"，而是"统一优先"。

2.3 PG 融合架构真正解决什么问题

第一，减少数据副本。

业务数据和 Embedding 可以在同一个数据库体系内管理，减少为了检索而创建不必要的跨系统复制链路。

第二，提升一致性能力。

关系数据、JSON、Embedding 等数据在同一个 PostgreSQL 事务体系中管理时，可以更自然地实现原子更新和权限控制。

第三，支持组合查询。

企业 AI 检索往往不是"只按向量相似度找 Top-K"，而是：

sql 复制代码

WHERE tenant_id = ?
  AND department_id = ?
  AND status = 'active'
  AND created_at > ?
ORDER BY embedding <=> ?
LIMIT 20;

也就是：权限过滤 + 业务过滤 + 时间过滤 + 语义相似度共同参与查询。

第四，减少运维系统数量。

尤其对于规模尚未达到必须采用多个专业数据库的团队，统一数据平面可以明显降低部署、监控、备份和故障处理复杂度。

2.4 需要避免的一个误区：数据库不是 Agent 大脑

"把 AI 计算推向数据端"容易被理解为：

PostgreSQL 最终应该成为完整的 LLM、Agent、Workflow 和多智能体平台。

这并不是企业级架构的合理目标。

更合理的职责边界是科学分工协作：

这也是本文后续讨论 pgai 等案例时的核心判断。

三、社区生态：PostgreSQL AI 能力全景

PostgreSQL 的 AI 生态并不是单一产品，而是"数据库内核 + 扩展 + 外部 Agent/AI 服务"的组合体系。

3.1 向量核心生态

核心组件可关注：

pgvector：PostgreSQL 最成熟、最广泛采用的向量扩展之一。
pgvectorscale：在 pgvector 之上进一步提供基于 DiskANN 思路的高性能向量检索能力。
其他向量扩展：可根据发行版和具体场景选型，但应重点验证活跃度、兼容版本和社区支持。

对于企业选型，不宜用一个"向量扩展排行榜"直接得出结论，更应该以真实数据规模、过滤条件、召回率、延迟和成本做基准测试。

3.2 库内 AI / ML 生态

PostgreSQL 生态中存在多种"数据库内 AI"尝试，例如 PostgresML、MADlib 以及面向 LLM/AI 的第三方扩展。

这类项目的共同思路是：

尽量减少数据搬运，让模型或推理能力更靠近业务数据。

但"库内推理"并不意味着一定比独立模型服务更好。企业仍然需要根据模型规模、GPU 利用率、弹性伸缩、推理隔离、模型生命周期和安全策略进行判断。

3.3 图与 GraphRAG 生态

值得关注的代表项目是 Apache AGE。AGE 通过 PostgreSQL 扩展提供图数据能力，可在关系数据库之上引入图模型与 openCypher 查询能力。

需要特别强调：

openCypher 兼容不等于与 Neo4j 全面兼容。

在复杂图查询、深度遍历和高并发场景中，是否采用 AGE，应该通过真实业务基准验证，而不是简单将其视为传统图数据库的完全替代品。

3.4 工程化与多模能力

PostgreSQL 本身还可以通过生态组件增强企业 AI 所需的数据基础设施能力：

PostGIS：空间数据。
TimescaleDB / 时序扩展：时间序列与监控类数据。
pg_cron：数据库内调度。
pg_partman：分区管理自动化。
全文检索能力：用于关键词/全文召回，并可与向量召回形成混合检索。

这意味着一个 AI 应用可以逐步建立：

text 复制代码

+ 结构化数据
+ JSON / 文档元数据
+ 全文检索
+ 向量检索
+ 时序数据
+ 空间数据
+ 图关系
+ Agent 状态与记忆

而不是一开始就搭建六七套数据库。

3.5 pgvector------PostgreSQL 向量能力的核心基础

pgvector 为 PostgreSQL 增加向量数据类型、相似度计算和近似最近邻索引能力，是今天 PG+AI 架构中最值得优先掌握的基础组件之一。

当前 pgvector 支持多种向量类型，其中 vector 类型存储最高支持 16,000 维，但使用 HNSW 或 IVFFlat 索引时上限为 2,000 维；此外还提供 halfvec、bit、sparsevec 等类型，不同类型对应不同的维度/非零元素上限。它支持 HNSW 与 IVFFlat 两类近似最近邻索引。

需要特别注意：

近似索引不是"免费加速"。它本质上是在召回率、查询延迟、内存与构建成本之间做权衡。

例如，HNSW 通常在速度/召回率权衡上表现更好，但构建更慢、内存占用也更高；IVFFlat 构建更快、内存相对友好，但需要合理设置 lists/probes，并注意建索引时的数据规模。

使用示例：统一管理业务数据与向量

sql 复制代码

CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE agent_memories (
    id BIGSERIAL PRIMARY KEY,
    tenant_id BIGINT NOT NULL,
    memory_type TEXT NOT NULL,
    content TEXT NOT NULL,
    embedding vector(1536),
    metadata JSONB,
    created_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
);

CREATE INDEX idx_agent_memories_embedding
ON agent_memories
USING hnsw (embedding vector_cosine_ops);

-- 语义检索
SELECT id,
       content,
       1 - (embedding <=> $1) AS similarity
FROM agent_memories
WHERE tenant_id = $2
ORDER BY embedding <=> $1
LIMIT 10;

-- 业务过滤 + 语义检索
SELECT id,
       content,
       1 - (embedding <=> $1) AS similarity
FROM agent_memories
WHERE tenant_id = $2
  AND memory_type = 'preference'
  AND created_at > NOW() - INTERVAL '90 days'
ORDER BY embedding <=> $1
LIMIT 10;

这里真正重要的并不是 SQL 本身，而是：Agent 的记忆、租户边界、业务过滤和向量检索可以在同一个数据模型中协同工作。

3.6 pgvectorscale------把 PG 向量检索推向更大规模

pgvectorscale 是 Timescale 围绕 PostgreSQL 向量检索推出的扩展，核心能力包括 StreamingDiskANN、量化以及过滤优化，并与 pgvector 配合使用。官方项目公开的代表性基准是在 5,000 万条、768 维 Cohere Embedding 数据集上，以 99% recall 为目标，对比了 Pinecone 的某一索引方案。该基准显示了较低的 P95 延迟、更高吞吐以及更低成本，但这些数字应理解为特定测试条件下的结果，而不是所有场景的通用结论。

因此，建议把 pgvectorscale 的价值理解为：

text 复制代码

pgvector
   ↓
基础向量类型 + HNSW / IVFFlat
   ↓
pgvectorscale
   ↓
更大规模向量检索 + DiskANN思路 + 量化 + 过滤优化

企业选型建议

如果数据规模仍处于百万级或较低的千万级，应优先把精力放在：

Embedding 质量
Chunking 策略
权限过滤
Hybrid Search
Rerank
Query 改写
召回率与端到端延迟

而不是过早为"百亿级向量"做架构设计。

当规模、成本或延迟真正成为瓶颈，再通过 pgvectorscale 或专用向量平台做第二阶段优化。

3.7 pgai------一个很有价值的架构演进案例

pgai 曾经是一套帮助开发者在 PostgreSQL 体系内构建 RAG、语义搜索和 Agentic 应用的工具，能够围绕 PostgreSQL 数据自动生成和同步 Embedding，并提供语义目录、语义搜索等能力。

截至本文修订时，pgai GitHub 仓库 README 明确写明：自 2026 年 2 月起不再维护或支持 ；GitHub 仓库则显示其在 2026 年 5 月 27 日被 owner 正式 Archive，进入只读状态。

更值得关注的技术启示

pgai 这个案例并不应该被解读为：

"数据库不应该碰 AI。"

更合理的解读是：

第一，数据与语义检索天然适合贴近数据库。

Embedding、向量检索、元数据过滤、数据同步等工作，与 PostgreSQL 的数据管理能力具有天然结合点。

第二，复杂的模型调用和 Agent 编排应保持服务化边界。

LLM 调用通常具有高延迟、外部依赖、限流、成本、Provider 切换和弹性需求。因此在企业架构中，更适合通过应用服务或 AI Gateway 实现隔离，而不是把复杂的 Agent Loop 全部塞进数据库。

第三，数据库与 AI 服务应该形成分工，而不是二选一。

可以抽象成：

核心结论

PostgreSQL 与 AI 的融合，不应该追求"数据库成为完整 AI 平台"，而应该让数据库成为可靠的数据、记忆与检索底座，让应用层承担模型编排、Agent Loop 和复杂智能行为。

3.8 PostgresML------数据库内 AI 的另一条路线

PostgresML 代表的是另一种思路：把机器学习、NLP、Embedding 或部分推理能力进一步靠近 PostgreSQL 数据。

其项目仓库目前仍提供开源的 pgml 扩展和自托管方式，也同时提供云服务。其定位是让 PostgreSQL 更方便地承载 ML/AI 工作负载。

这里需要特别修正一个常见误区：

"库内推理 = 零延迟"或者"必然比 HTTP 模型服务快几十倍"都不应该作为普遍结论。

把模型放入数据库附近，可以减少数据搬运和额外网络跳转；但端到端性能仍然取决于模型大小、GPU、并发方式、Batch、数据准备、模型加载、线程/进程模型以及数据库资源竞争。

更适合库内 AI 的场景

结构化数据上的实时预测
特征计算与模型推理高度耦合的场景
需要减少数据出域的业务
小模型、Embedding 或轻量文本处理
需要在 SQL 查询链路中完成部分 AI 变换的场景

不适合强行库内化的场景

超大模型在线推理
GPU 资源需要独立弹性伸缩
高并发多租户模型服务
模型发布与回滚频繁变化
需要跨模型、跨 Provider 路由的企业 AI Gateway

因此，PostgresML 更应该被理解为：扩大"数据与 AI 可以靠近"的边界，而不是消灭模型服务层。

3.9 Apache AGE------知识图谱与 GraphRAG 的补充能力

Apache AGE 是 PostgreSQL 的图扩展，可以在 PostgreSQL 中使用图模型，并支持 openCypher 风格的图查询。其目标之一就是在关系数据之上增加图能力，从而减少额外图存储系统带来的数据复制。

但企业应避免把 GraphRAG 变成"所有 Agent 的默认检索方案"。

很多知识库场景仅依靠：

text 复制代码

+ 关键词检索
+ 向量召回
+ Rerank

就已经能够取得很好的效果。只有当"实体关系本身决定答案"时，图检索才真正体现价值，例如：

组织与权限关系
设备与依赖关系
产品与供应链关系
人员与技能关系
复杂故障传播关系

一个更合理的混合检索模型

这样，GraphRAG 成为检索能力的一部分，而不是取代传统 RAG。

四、PostgreSQL 内核演进：哪些能力真正有利于 AI 负载

需要首先纠正一个表述：

PostgreSQL 17、18、19 并不是"专为 AI 设计"的版本。

更准确的说法是：这些版本的通用数据库能力持续增强，其中一些特性恰好对 AI 数据处理、检索和高吞吐工作负载很有价值。

4.1 PostgreSQL 17：更好的数据处理与维护基础

PostgreSQL 17 于 2024 年 9 月 26 日发布。官方重点能力包括新的 VACUUM 内存管理机制、SQL/JSON 增强以及多项查询与 I/O 性能改进。

JSON_TABLE

JSON_TABLE() 可以把 JSON 数据映射为关系型结果，对于处理 LLM 工具调用结果、事件数据和半结构化输入很有价值。

VACUUM 内存改进

PostgreSQL 17 引入了新的 VACUUM 内部内存结构，官方表述为可消耗最多低至原来的二十分之一内存，同时改善 VACUUM 性能。这里应使用"最多 20 倍内存节省"的严谨表述，而不是把它理解为所有表、所有场景都固定下降到 1/20。

这对于高频更新的 Agent 状态、会话、事件和记忆表尤其值得关注，但不能据此得出"彻底解决膨胀问题"的结论。

4.2 PostgreSQL 18：AIO 是更值得关注的基础设施升级

PostgreSQL 18 于 2025 年 9 月 25 日发布。其显著变化之一是新的异步 I/O（AIO）子系统，用于提高顺序扫描、位图堆扫描、VACUUM 等场景的 I/O 并行度。官方说明称某些读取场景最高可获得约 3 倍的性能提升，但这依赖具体工作负载。

PG 18 提供 io_method、io_workers 等参数来控制 AIO 执行方式，并支持 worker、io_uring 和 sync 等选项。

这对 AI 有什么意义？

大规模向量表、知识库、日志与事件表，本质上都可能产生大量扫描与 I/O 请求。

因此，AIO 对 AI 的意义是：

改善 PostgreSQL 处理大型数据集时的通用 I/O 能力，而这些改进可以使 AI 数据工作负载间接受益。

4.3 PostgreSQL 18：JSON 性能与 AI 数据处理

PostgreSQL 18 对长 JSON 字符串的处理进行了 SIMD 优化，这对于 AI 场景中的 JSON 工具调用、结构化输出、事件数据处理具有一定帮助。

4.4 PostgreSQL 18：Table AM / Index 真正值得关注的是扩展边界

PostgreSQL 的访问方法体系使社区能够以扩展方式探索不同的数据访问与存储结构。PG 18 对 Index Access Method API 增加了 amgettreeheight 等函数，同时还进一步完善了相关接口。

对于 AI 架构而言，它的战略价值在于：

PostgreSQL 内核提供稳定的数据库执行、事务和扩展边界，而向量、列存以及其他特殊访问方法可以由生态组件继续创新。

4.5 PostgreSQL 19：AI 之外，图能力成为值得关注的新方向

截至本文修订时，PostgreSQL 19 仍处于开发/测试阶段，官方文档将其标记为 Development Version；2026 年 8 月已经发布 Beta 3，正式 GA 时间仍以 PostgreSQL 官方公告为准。

对于"PostgreSQL + AI"这一主题，PG 19 有一个非常值得关注的方向：

SQL/PGQ（Property Graph Queries）进入 PostgreSQL 19。

这意味着未来 PostgreSQL 在关系数据与图查询融合方面的能力边界可能进一步扩大。

除此之外，PG 19 还包含逻辑复制、Autovacuum、I/O、查询规划等方面的改进。这些虽然并非 AI 专属，但对大规模 Agent 数据平台具有基础设施价值。

五、从技术可行到企业落地：PG + AI 的四步行动指南

企业不应该从"迁移数据库"开始，而应该从"验证数据边界"开始。

5.1 第一步：从一个可衡量的 Agent 场景开始

建议优先选择：

企业知识库问答
IT 运维知识助手
工单智能助手
数据查询与分析助手
账号 / 资产 / 配置查询

不要一上来就设计完整的"AI 数据湖"。

5.2 第二步：建立统一的数据模型

建议至少统一以下对象：

text 复制代码

Tenant
User
Document
Chunk
Embedding
Conversation
Memory
Task
Tool Call
Agent Event
Audit Event

这一步的核心不是数据库选型，而是建立稳定的数据实体模型与生命周期规则。

5.3 第三步：明确 Agent、数据库、模型服务的边界

推荐的企业级边界是：

这样可以避免把数据库、Agent 编排与模型服务做成一个巨大单体。

5.4 第四步：再做规模化性能优化

按照下面的顺序通常更合理：

text 复制代码

RAG质量
  ↓
混合检索
  ↓
权限过滤
  ↓
Rerank
  ↓
索引与查询优化
  ↓
pgvectorscale / 分片 / 副本
  ↓
专业向量或搜索系统

即：先解决"找得对"，再解决"找得快"。

5.5 一个容易被忽略的企业指标体系

PG+AI 落地不能只看数据库 QPS，还应至少关注：

指标	关注点
Recall@K	召回质量
NDCG / MRR	排序质量
P95 / P99	端到端延迟
Token Cost	模型成本
Cache Hit Rate	缓存效率
Context Utilization	上下文利用率
Memory Hit Rate	Agent 记忆有效性
数据新鲜度	Embedding / 索引同步延迟
权限正确率	越权风险
数据删除时延	合规与生命周期

这套指标比单纯讨论"数据库能撑多少向量"更接近企业真实价值。

六、下一代 AI Agent 的统一多模智能数据底座

经过前面的讨论，一个更成熟的企业级架构可以抽象为"六层 + 两条横向协议/治理能力"。

6.1 六层逻辑架构

6.2 A2A 应该放在哪里？

应该放，而且是"横向能力"，不是数据库底座能力。

A2A（Agent2Agent）定位是让彼此独立、可能由不同框架或厂商构建的 Agent 进行发现、任务委派、状态交互与协作。当前 A2A 规范已经发展到 1.0，并提供 Agent Card、同步/流式/异步任务交互等机制。

因此，建议在企业 Agent 架构中将 A2A 画成一条横向 Agent 协作通道：

A2A 不负责存储 Agent 的长期记忆，也不取代数据库；它负责 Agent 之间"如何协作"。

6.3 MCP 与 A2A 的关系

企业架构中可以用一个非常容易理解的方式区分：

text 复制代码

MCP：Agent ↔ Tool / Data / Service
      "我如何使用能力？"

A2A：Agent ↔ Agent
      "我如何和另一个 Agent 协作？"

PostgreSQL：Data / Memory / State
      "事实、记忆和状态存在哪里？"

当前 A2A 官方资料也把 MCP 描述为更偏"垂直能力接入"，而 A2A 则更偏"水平 Agent 协作"。

这三个概念放在一起，正好构成下一代企业 Agent 平台的重要基础抽象：

MCP 连接能力，A2A 连接 Agent，PostgreSQL 连接数据。

6.4 "统一数据底座"最终应该统一什么？

不应该只统一数据库实例，而应该统一以下对象和治理边界：

text 复制代码

统一身份
   ↓
统一数据模型
   ↓
统一记忆模型
   ↓
统一检索接口
   ↓
统一权限过滤
   ↓
统一生命周期
   ↓
统一审计与可观测性

这比"所有东西都放到 PostgreSQL"更有价值。

6.5 什么时候 PostgreSQL 应该让位给专业系统？

这是本文必须补充的边界。

如果出现以下情况，就应认真评估专业系统：

超大规模向量检索

当向量规模、并发、召回率和成本要求明显超出单一 PostgreSQL 集群的经济范围时，可以引入专业向量数据库或搜索平台。

超大规模图计算

如果核心业务是复杂图遍历、图算法和超大规模关系网络，应考虑专用图数据库或图计算平台。

海量原始文件

图片、视频、音频、原始文档等仍然更适合对象存储；PostgreSQL 存储元数据、权限、索引信息和关键结构化状态。

高强度 OLAP / 数据湖分析

当数据分析已经进入 PB 级离线计算、复杂 OLAP 或数据湖场景，应采用专用分析系统，而不是强行用 OLTP 数据库承担全部任务。

最终形成：

PostgreSQL 做核心数据平面，专业系统做规模边界上的能力补位。

七、总结：PostgreSQL + AI 的真正战略价值

经过这次重新梳理，可以得到几个比"PG 是不是 AI 数据库"更重要的结论。

7.1 PostgreSQL 最重要的价值不是"向量数据库化"

pgvector 让 PostgreSQL 能够很好地承担向量存储与检索，但 PostgreSQL 真正不可替代的优势，来自：

关系数据 + 事务 + 权限 + JSON + 检索 + 向量 + 扩展生态。

7.2 "统一"应该优先，但不能绝对化

统一可以降低数据同步和运维复杂度，但专业系统仍然有存在的理由。

正确的原则不是：

"所有 AI 数据都放 PG。"

而是：

能统一就统一，达到专业系统的规模边界再拆分。

7.3 数据库应该做数据底座，Agent 平台应该做智能编排

企业级架构需要明确：

这套边界，比"把 AI 全部塞进数据库"更加长期可演进。

7.4 PostgreSQL 的下一阶段机会在"数据平面"

随着 Agent 从一次性问答走向长期运行，数据底座需要保存的不只是业务数据，而是：

text 复制代码

+ Facts
+ Knowledge
+ Embeddings
+ Memory
+ State
+ Events
+ Audit
+ Relationships

这恰恰是 PostgreSQL 具有强项的数据世界。

7.5 最终结论

下一代企业 AI Agent 不需要一个"无所不能"的超级数据库，而需要一个可靠、可治理、可扩展的数据平面。

PostgreSQL 的最佳定位肯定不是成为 AI 编排中心，而是成为 Agent 的统一数据、记忆与状态底座；Agent 平台负责智能编排，AI Gateway 负责模型服务，MCP 负责能力接入，A2A 负责 Agent 协作。

当这些边界被正确划分后，PostgreSQL + AI 才真正具备从"能用"走向"可生产、可治理、可演进"的企业级价值。

延伸阅读与资源导航

打造下一代 AI Agent 的统一多模智能数据底座——PostgreSQL 与 AI 的融合演进

前言

一、现状与挑战：AI Agent 为什么越来越需要"数据底座"

1.1 常见数据底座方案

1.2 真正的企业痛点：不是数据库数量，而是数据边界

二、融合新思路：从"多系统拼装"到"统一数据平面"

2.1 传统 AI Agent 数据架构

2.2 PostgreSQL 融合架构

2.3 PG 融合架构真正解决什么问题

2.4 需要避免的一个误区：数据库不是 Agent 大脑

三、社区生态：PostgreSQL AI 能力全景

3.1 向量核心生态

3.2 库内 AI / ML 生态

3.3 图与 GraphRAG 生态

3.4 工程化与多模能力

3.5 pgvector------PostgreSQL 向量能力的核心基础

使用示例：统一管理业务数据与向量

3.6 pgvectorscale------把 PG 向量检索推向更大规模

企业选型建议

3.7 pgai------一个很有价值的架构演进案例

更值得关注的技术启示

核心结论

3.8 PostgresML------数据库内 AI 的另一条路线

更适合库内 AI 的场景

不适合强行库内化的场景

3.9 Apache AGE------知识图谱与 GraphRAG 的补充能力

一个更合理的混合检索模型

四、PostgreSQL 内核演进：哪些能力真正有利于 AI 负载

4.1 PostgreSQL 17：更好的数据处理与维护基础

JSON_TABLE

VACUUM 内存改进

4.2 PostgreSQL 18：AIO 是更值得关注的基础设施升级

这对 AI 有什么意义？

4.3 PostgreSQL 18：JSON 性能与 AI 数据处理

4.4 PostgreSQL 18：Table AM / Index 真正值得关注的是扩展边界

4.5 PostgreSQL 19：AI 之外，图能力成为值得关注的新方向

五、从技术可行到企业落地：PG + AI 的四步行动指南

5.1 第一步：从一个可衡量的 Agent 场景开始

5.2 第二步：建立统一的数据模型

5.3 第三步：明确 Agent、数据库、模型服务的边界

5.4 第四步：再做规模化性能优化

5.5 一个容易被忽略的企业指标体系

六、下一代 AI Agent 的统一多模智能数据底座

6.1 六层逻辑架构

6.2 A2A 应该放在哪里？

6.3 MCP 与 A2A 的关系

6.4 "统一数据底座"最终应该统一什么？

6.5 什么时候 PostgreSQL 应该让位给专业系统？

超大规模向量检索

超大规模图计算

海量原始文件

高强度 OLAP / 数据湖分析

七、总结：PostgreSQL + AI 的真正战略价值

7.1 PostgreSQL 最重要的价值不是"向量数据库化"

7.2 "统一"应该优先，但不能绝对化

7.3 数据库应该做数据底座，Agent 平台应该做智能编排

7.4 PostgreSQL 的下一阶段机会在"数据平面"

7.5 最终结论

延伸阅读与资源导航

PostgreSQL 官方

PostgreSQL AI 生态

Agent 协议