当前的 AI 基础设施讨论几乎被模型、GPU、推理速度和向量数据库占据。这些组件确实重要,但它们掩盖了一个更深的架构问题——随着企业从 AI 实验走向运营系统,这个问题正在快速浮现:记忆。
不是简单存储聊天记录或 embedding 的那种记忆,而是跨长时间交互中维持持久上下文、操作连续性、历史理解、工作流状态、推理可追溯性和业务感知的能力。大多数 AI 系统在单次交互中表现聪明,但在时间维度上异常脆弱。模型本身并不缺乏智能,缺乏的是一套连贯的记忆架构。
向量搜索为什么不够
向量搜索能找到语义相似的信息,这很有价值。但企业 AI 系统需要回答的问题远不止"哪些内容和查询相似":
- 哪条信息是最新的?哪些事实覆盖了旧事实?
- 哪条记录属于当前工作流?用户有权访问哪些信息?
- 哪个决策导致了下游操作变更?哪些未解决任务仍然活跃?
- 哪些事件在时间或因果上相连?
这些不是纯粹的向量问题——它们是关系型、事务性、时间性和治理性问题。一个 embedding 能告诉你两段文本语义相近,但企业系统还需要上下文过滤、一致性保证、可审计性、权限控制、工作流感知和业务推理。
很多团队目前的做法是把能力拼凑起来:向量数据库做语义搜索,Redis 管短期状态,对象存储存文档,图数据库建模关系,工作流引擎追踪执行状态,独立审计系统管合规。这种方案能跑,但上下文散布在多个系统中,一致性模型、检索语义、安全边界各不相同,碎片化很快成为运维噩梦。
PostgreSQL 的独特定位
PostgreSQL 之所以在这个场景中值得关注,是因为它在单一平台内已经组合了企业 AI 记忆架构所需的多数基础能力:
- 关系一致性 + JSON 文档灵活性
- 全文搜索 + pgvector 向量相似度
- 事务保证 + 事件/时序存储
- 行级安全(RLS)+ 治理控制
- 成熟索引 + 复制和高可用
- 高表达力的 SQL 引擎
关键在于这些能力可以在同一操作系统中共存。企业记忆不是单一数据类型——它需要同时支撑结构化运营数据、语义 embedding、历史事件、工作流状态、实体关系、审计轨迹、上下文检索和策略执行。PostgreSQL 可以将许多这样的关注点统一到一个连贯的操作架构中。
用 PostgreSQL 实现分层记忆模型
人类记忆不是单一层——我们有短期记忆、情景记忆、语义记忆、程序记忆和长期记忆,同时运作、优先级不同。企业 AI 系统也需要类似结构:
| 记忆类型 | AI 系统中的对应 | PostgreSQL 存储方式 |
|---|---|---|
| 短期记忆 | 当前交互的活跃上下文 | 会话表 + JSONB |
| 情景记忆 | 历史对话和操作事件 | 事件表 + 时序索引 |
| 语义记忆 | embedding、概念、通用知识 | pgvector + 全文搜索 |
| 程序记忆 | 工作流、业务策略、操作序列 | 状态机表 + 策略规则 JSONB |
| 长期记忆 | 组织知识、审计历史 | 审计日志 + 归档分区 |
下面是一个可以直接运行的 PostgreSQL 方案,展示如何在同一个数据库中构建混合记忆层:
-- 1. 启用 pgvector 扩展
CREATE EXTENSION IF NOT EXISTS vector;
-- 2. 短期记忆:当前交互上下文
CREATE TABLE active_sessions (
session_id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
user_id UUID NOT NULL,
agent_id UUID NOT NULL,
context JSONB NOT NULL, -- 当前对话状态、意图、参数
created_at TIMESTAMPTZ DEFAULT now(),
updated_at TIMESTAMPTZ DEFAULT now()
);
-- 3. 情景记忆:历史事件与对话
CREATE TABLE episodic_events (
event_id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
session_id UUID REFERENCES active_sessions(session_id),
user_id UUID NOT NULL,
agent_id UUID NOT NULL,
event_type TEXT NOT NULL, -- 'conversation', 'decision', 'tool_call', 'escalation'
content JSONB NOT NULL, -- 事件详情
sentiment TEXT, -- 'positive', 'neutral', 'negative', 'frustrated'
importance SMALLINT DEFAULT 3, -- 1-5, 越高越重要
occurred_at TIMESTAMPTZ DEFAULT now()
);
CREATE INDEX idx_episodic_user_time ON episodic_events (user_id, occurred_at DESC);
CREATE INDEX idx_episodic_type_importance ON episodic_events (event_type, importance DESC);
-- 4. 语义记忆:知识条目 + embedding
CREATE TABLE semantic_knowledge (
knowledge_id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
domain TEXT NOT NULL, -- 'product', 'policy', 'finance', 'support'
title TEXT NOT NULL,
body TEXT NOT NULL,
embedding vector(1536), -- OpenAI ada-002 维度,按实际模型调整
metadata JSONB NOT NULL DEFAULT '{}', -- 来源、可信度、版本等
effective_from TIMESTAMPTZ DEFAULT now(),
effective_to TIMESTAMPTZ, -- NULL 表示当前有效
superseded_by UUID REFERENCES semantic_knowledge(knowledge_id),
created_at TIMESTAMPTZ DEFAULT now()
);
-- 向量索引(IVFFlat,生产环境数据量大时换 HNSW)
CREATE INDEX idx_semantic_embedding ON semantic_knowledge
USING ivfflat (embedding vector_cosine_ops) WITH (lists = 100);
-- 全文搜索索引
CREATE INDEX idx_semantic_fts ON semantic_knowledge
USING gin (to_tsvector('simple', coalesce(title, '') || ' ' || coalesce(body, '')));
-- 5. 程序记忆:工作流状态与业务策略
CREATE TABLE workflow_state (
workflow_id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
workflow_type TEXT NOT NULL, -- 'loan_approval', 'claim_processing', 'order_fulfillment'
status TEXT NOT NULL DEFAULT 'active', -- 'active', 'suspended', 'completed', 'failed'
current_step TEXT NOT NULL,
context JSONB NOT NULL, -- 工作流变量、审批链、条件分支状态
user_id UUID NOT NULL,
agent_id UUID NOT NULL,
created_at TIMESTAMPTZ DEFAULT now(),
updated_at TIMESTAMPTZ DEFAULT now()
);
-- 6. 长期记忆:审计与决策追溯
CREATE TABLE audit_trail (
audit_id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
decision_type TEXT NOT NULL,
context_snapshot JSONB NOT NULL, -- 决策时的完整上下文快照
tools_invoked JSONB NOT NULL DEFAULT '[]',
outcome TEXT NOT NULL,
reasoning_trace JSONB NOT NULL DEFAULT '{}', -- 推理步骤记录
user_id UUID NOT NULL,
agent_id UUID NOT NULL,
created_at TIMESTAMPTZ DEFAULT now()
);
CREATE INDEX idx_audit_decision_time ON audit_trail (decision_type, created_at DESC);
-- 7. 行级安全:确保用户只能访问自己的记忆
ALTER TABLE episodic_events ENABLE ROW LEVEL SECURITY;
ALTER TABLE semantic_knowledge ENABLE ROW LEVEL SECURITY;
ALTER TABLE workflow_state ENABLE ROW LEVEL SECURITY;
ALTER TABLE audit_trail ENABLE ROW LEVEL SECURITY;
CREATE POLICY user_episodic_access ON episodic_events
FOR ALL USING (user_id = current_setting('app.current_user_id')::UUID);
CREATE POLICY user_workflow_access ON workflow_state
FOR ALL USING (user_id = current_setting('app.current_user_id')::UUID);
CREATE POLICY user_audit_access ON audit_trail
FOR ALL USING (user_id = current_setting('app.current_user_id')::UUID);
上面的 schema 把五种记忆类型放在同一个数据库中,用 RLS 保证权限边界。接下来看一个混合检索查询——这正是向量数据库单独做不到的:
-- 场景:查找最近 30 天与"交易失败"相关的高价值客户未解决升级事件
-- 同时检索语义知识中的相关政策,排除已被新版本取代的旧条目
-- 设置当前用户(应用层在连接时设置)
SET app.current_user_id = 'a1b2c3d4-5678-90ab-cdef-123456789012';
WITH relevant_events AS (
-- 情景记忆:结构化过滤 + 时间窗口 + 重要性排序
SELECT
e.event_id,
e.content,
e.sentiment,
e.importance,
e.occurred_at,
e.event_type
FROM episodic_events e
WHERE e.user_id = current_setting('app.current_user_id')::UUID
AND e.event_type = 'escalation'
AND e.occurred_at > now() - INTERVAL '30 days'
AND e.content->>'resolution_status' = 'unresolved'
AND e.content->>'account_tier' IN ('premium', 'enterprise')
ORDER BY e.importance DESC, e.occurred_at DESC
LIMIT 20
),
relevant_knowledge AS (
-- 语义记忆:向量相似度 + 时效性过滤 + 排除已取代条目
SELECT
k.knowledge_id,
k.title,
k.body,
k.domain,
k.effective_from,
1 - (k.embedding <=> '[0.02, -0.01, ...]'::vector) AS similarity -- 替换为实际查询 embedding
FROM semantic_knowledge k
WHERE k.domain = 'policy'
AND k.superseded_by IS NULL -- 排除已被取代的旧版本
AND k.effective_to IS NULL -- 当前仍然有效
AND k.effective_from <= now() -- 已生效
ORDER BY k.embedding <=> '[0.02, -0.01, ...]'::vector
LIMIT 10
),
active_workflows AS (
-- 程序记忆:当前用户相关的工作流状态
SELECT
w.workflow_id,
w.workflow_type,
w.current_step,
w.context
FROM workflow_state w
WHERE w.user_id = current_setting('app.current_user_id')::UUID
AND w.status = 'active'
LIMIT 5
)
-- 组装上下文:为 LLM 提供结构化的多维度记忆
SELECT json_build_object(
'events', (SELECT json_agg(relevant_events) FROM relevant_events),
'knowledge', (SELECT json_agg(relevant_knowledge) FROM relevant_knowledge),
'active_flows', (SELECT json_agg(active_workflows) FROM active_workflows)
) AS assembled_context;
这个查询在一条 SQL 中同时完成了语义检索、结构化过滤、时间排序、权限校验和工作流状态关联——这正是"上下文工程"的核心操作。
从提示工程到上下文工程
文章作者 Vibhor Kumar 提出了一个重要观点:行业将从强调提示工程转向强调上下文工程。提示工程优化指令怎么写;上下文工程优化推理前如何组装操作记忆——包括语义检索、结构化过滤、时间排序、权限执行、工作流感知、时效加权、信任评估和上下文摘要。
一个企业系统可能需要回答:"查找最近 30 天与失败交易相关的未解决客户升级,优先高价值账户,排除已取代的工单,并检索关联的情绪历史。"这不是纯向量查询,而是混合推理问题——语义、结构、业务逻辑、时间感知和治理的组合。PostgreSQL 的 SQL + JSONB + 事务 + pgvector 组合恰好是处理这类问题的强力工具。
还缺什么
PostgreSQL 的基础能力已经就位,但完整的 AI 记忆平台还需要更高层的编排能力:
- 智能上下文组装框架——决定每次推理需要哪些记忆层、多少上下文窗口
- 记忆生命周期管理——不是所有记忆都应该永远同等可访问;需要摘要、归档、优先级调整和受控遗忘
- 时序推理引擎——理解"事实 A 在时间 t1 取代了事实 B"
- 混合检索编排——自动决定何时用向量、何时用结构化查询、何时两者结合
- 治理感知评估框架——解释为什么做出某个决策、哪些上下文影响了结果
其中记忆生命周期管理尤其关键。AI 系统会积累海量历史状态,需要机制来做摘要、压缩、优先级衰减和受控遗忘——这和人类记忆的"遗忘曲线"是同一个问题。PostgreSQL 的事务一致性、可审计性和运维可靠性天然契合这些需求。
落地建议与风险
可以开始做的事:
- 不要为 AI 记忆单独引入新数据库——先评估 PostgreSQL 是否已经能覆盖 80% 的需求
- 用上面的分层 schema 作为起点,根据业务域调整表结构
- 把 RLS 作为权限的第一道防线,在连接池层面设置
app.current_user_id - embedding 维度按实际使用的模型调整(OpenAI ada-002 是 1536,其他模型不同)
- 数据量超过 10 万条向量时,把 IVFFlat 索引换成 HNSW(
USING hnsw),检索性能更好
需要注意的边界:
- pgvector 的向量检索是近似搜索,不是精确匹配——对"必须找到所有相关结果"的场景需要配合结构化过滤兜底
- PostgreSQL 单机能处理百万级向量,但千万级以上需要考虑分区或 Citus 扩展
- RLS 增加了查询计划复杂度,高并发场景下务必验证性能
- 记忆摘要和受控遗忘目前没有现成框架,需要自己写定时任务或事件触发逻辑
- 不要把 LLM 当记忆引擎——数据库负责记住,LLM 负责推理
一个实用的检查清单:
- [ ] 每次推理前,上下文是否从数据库动态组装而非硬编码在 prompt 中?
- [ ] 事实是否有时效标记(
effective_from/effective_to)和版本取代链? - [ ] 用户是否只能访问自己权限范围内的记忆(RLS 或等效机制)?
- [ ] 决策是否有完整审计轨迹——包括上下文快照、推理步骤和工具调用记录?
- [ ] 是否有记忆衰减/归档策略,避免历史数据无限膨胀?
智能没有持久记忆,最终只是不可靠的自动化。不可靠的自动化在企业系统中很难存活。AI 行业当前聚焦于模型和推理基准,但长期来看最重要的架构问题可能更简单:系统如何可靠地记住? 不是检索语义相似的文本,不是持久化对话日志,而是跨工作流、用户、系统和决策维持连贯的操作记忆。
机会不只是"PostgreSQL 做向量搜索",而是 PostgreSQL 作为企业 AI 系统的持久记忆和操作状态基底。