AI Agent 长期记忆：PostgreSQL + Vector DB 实战

摘要：AI Agent 的“长期记忆”不是把所有历史聊天永久塞进 Prompt，而是把跨会话仍然有价值的事实、偏好、经验和任务规则持久化，再在需要时检索回当前上下文。对于中小规模到企业级 Agent，PostgreSQL + pgvector 是一条非常实用的路线：PostgreSQL 保存用户、租户、记忆类型、来源、时间、权限和 JSONB 元数据，pgvector 负责 Embedding 相似度检索；如果未来向量规模、隔离策略或吞吐量进一步扩大，也可以演进成 PostgreSQL + 独立 Vector DB 的双存储架构。本文从 Docker 部署、数据库建表、向量索引、Memory 写入与召回、去重、遗忘、RLS 多租户隔离、性能调优到 LangGraph 接入，完整搭建一个可以真正用于 AI Agent 的长期记忆层。

核心结论

AI Agent 长期记忆最稳妥的实现，不是“保存整段聊天”，而是建立一个结构化数据库 + 向量语义检索 + 记忆治理层。对于多数个人项目和中小团队，优先推荐 PostgreSQL + pgvector 单库方案：既能用普通 SQL 精确过滤 user_id、tenant_id、memory_type、时间和标签，又能用 Vector Search 找到语义相似记忆；只有在向量规模、独立扩缩容或专用检索能力达到明确瓶颈后，才有必要拆成 PostgreSQL + 外部 Vector DB。

PostgreSQL 负责“记忆是谁的、什么时候写的、是否有效”。身份、权限、状态、TTL、JSONB 元数据和审计信息不应该只存在向量库里。
Vector Search 负责“哪些记忆与当前任务语义相关”。不要只按最近时间读取，也不要把所有历史记录重新塞入上下文。
记忆需要分类。Semantic Memory 保存事实与偏好，Episodic Memory 保存过去经历，Procedural Memory 保存任务规则与技能；三类记忆的写入权限和生命周期不同。
写入比检索更需要治理。每轮对话都无脑写入会产生重复、错误、过时和 Prompt Injection 污染，应增加提取、去重、可信度、来源和 TTL。
企业项目必须做租户隔离。查询条件、向量检索和 Row-Level Security 都应绑定 tenant/user，不能先全库向量检索再在应用层“过滤一下”。

如果你还在理解 Agent 的工作记忆、短期记忆和长期记忆差异，可以先参考 AI Stack Nav 的 AI Agent 自动完成任务完整搭建教程；如果更关心终端产品如何处理记忆来源、删除和纠错，也可以阅读 ChatGPT 记忆源与上下文管理教程。

长期记忆到底存什么：先区分短期状态、事实、经历与规则

LangChain/LangGraph 当前的 Memory 概念文档把短期记忆定义为 thread-scoped state：它服务于当前会话或线程；长期记忆则跨线程、跨会话存在，并可以按照自定义 namespace 组织。其概念指南进一步把长期信息拆成 Semantic、Episodic 和 Procedural 三类。这种分类非常适合数据库设计，因为三类信息的检索方式、更新方式和风险并不一样。

记忆类型	保存内容	Agent 示例	推荐存储策略
短期记忆	当前线程消息、工具结果、临时状态	本轮任务已经执行到第 4 步	Checkpoint / Session State
Semantic Memory	事实、偏好、用户画像、项目事实	用户偏好 PostgreSQL，不希望使用 MongoDB	PostgreSQL + Vector Search
Episodic Memory	过去任务、动作和结果	上次部署时 Nginx 配置错误导致 502	结构化事件 + 向量摘要
Procedural Memory	执行规则、技能、流程	生产发布必须先创建草稿并人工审批	版本化规则库，默认只读

Semantic Memory 并不等于 Semantic Search。前者是一种记忆内容类型，后者是一种按语义相似度检索数据的方法。用户的电话号码是一条 Semantic Memory，但检索它时可能直接按 user_id + key 精确查询，不需要向量检索；“上次遇到类似数据库连接问题时如何解决”则更适合向量召回 Episodic Memory。

图 1｜长期记忆层不只是 Vector Search，而是 Memory Manager、结构化 PostgreSQL、pgvector、Embedding、权限与生命周期共同组成。

PostgreSQL + pgvector 还是 PostgreSQL + 独立 Vector DB？

“PostgreSQL + Vector DB”可以有两种实现。第一种是在 PostgreSQL 中安装 pgvector，把向量与普通业务字段放在同一数据库；第二种是 PostgreSQL 保存结构化元数据，同时把 Embedding 复制到独立向量系统。多数项目没有必要从第一天就使用双存储。

方案	优势	代价	适合阶段
PostgreSQL + pgvector	一个事务系统、SQL + Vector、JOIN/RLS/备份统一	向量负载与业务 SQL 共用数据库资源	个人项目、中小团队、企业早中期
PostgreSQL + 独立 Vector DB	向量检索独立扩缩容、专业检索能力更强	双写、一致性、备份和权限治理更复杂	大规模向量、高吞吐、明确性能瓶颈

pgvector 官方当前支持精确近邻搜索，也支持 HNSW 与 IVFFlat 两种近似索引，同时保留 PostgreSQL 的事务、JOIN、PITR 和普通索引能力。对 Agent Memory 而言，这一点很重要，因为一次检索往往不是“全世界最相似的 10 条向量”，而是“当前 tenant、当前 user、有效、未过期、属于 semantic/episodic 类型的记忆中最相关的 10 条”。

第一步：用 Docker 部署 PostgreSQL 18 + pgvector

pgvector 官方仓库当前提供 PostgreSQL 18 镜像标签，例如 pgvector/pgvector:pg18-trixie。生产环境建议固定明确版本，而不是长期追踪一个不锁版本的 latest 标签。下面先给出适合测试和小型部署的 Compose。

services:
  memory-db:
    image: pgvector/pgvector:pg18-trixie
    container_name: agent-memory-db
    restart: unless-stopped
    environment:
      POSTGRES_DB: agent_memory
      POSTGRES_USER: agent_app
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
    ports:
      - "5432:5432"
    volumes:
      - agent_memory_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U agent_app -d agent_memory"]
      interval: 10s
      timeout: 5s
      retries: 5

volumes:
  agent_memory_data:

启动：

docker compose up -d
docker compose ps
docker compose logs -f memory-db

进入数据库后启用扩展：

CREATE EXTENSION IF NOT EXISTS vector;

SELECT extname, extversion
FROM pg_extension
WHERE extname = 'vector';

PostgreSQL 官方文档说明，CREATE EXTENSION 会把扩展提供的 SQL 对象加载到当前数据库，因此每个需要 pgvector 的数据库都要启用一次；生产环境也应只安装可信扩展，并把扩展放在受控 Schema 与权限边界内。

第二步：设计 Agent Memory 表，而不是只建 content + embedding

一个可用的 Memory 表至少需要回答五个问题：谁的记忆、是什么类型、来自哪里、是否还有效、如何检索。下面的 Schema 把关系字段、JSONB 元数据和向量放在一起。

CREATE TABLE agent_memories (
    id              uuid PRIMARY KEY,
    tenant_id       uuid NOT NULL,
    user_id         uuid NOT NULL,
    agent_id        text NOT NULL,

    memory_type     text NOT NULL
                    CHECK (memory_type IN ('semantic', 'episodic', 'procedural')),

    memory_key      text,
    content         text NOT NULL,
    summary         text,

    metadata        jsonb NOT NULL DEFAULT '{}'::jsonb,

    source_type     text,
    source_id       text,
    confidence      numeric(4,3) DEFAULT 1.000,
    importance      numeric(4,3) DEFAULT 0.500,

    embedding       vector(1536),

    created_at      timestamptz NOT NULL DEFAULT now(),
    updated_at      timestamptz NOT NULL DEFAULT now(),
    last_accessed_at timestamptz,
    expires_at      timestamptz,
    deleted_at      timestamptz
);

vector(1536) 只是教程示例。真正维度必须与你使用的 Embedding 模型一致。pgvector 当前普通 vector 类型支持最多 2,000 维，而 halfvec 支持更高维度；如果 Embedding 超过限制，应选择更低维输出、使用 halfvec，或采用其他存储方案。

给常用过滤字段建立普通索引：

CREATE INDEX idx_memories_user
ON agent_memories (tenant_id, user_id);

CREATE INDEX idx_memories_type
ON agent_memories (tenant_id, user_id, memory_type);

CREATE INDEX idx_memories_expiry
ON agent_memories (expires_at)
WHERE expires_at IS NOT NULL;

CREATE INDEX idx_memories_metadata
ON agent_memories USING gin (metadata);

PostgreSQL 的 jsonb 适合保存标签、来源属性、项目 ID、工具名、文档类型等变化较快的 Metadata，并可通过 GIN Index 加速查询。但 tenant_id、user_id、memory_type、created_at 等高频过滤字段仍应使用明确列，不要把整个数据模型藏进 JSONB。

第三步：建立向量索引——HNSW 与 IVFFlat 怎么选

pgvector 默认可以执行精确最近邻搜索，不建 ANN Index 也能工作；当 Memory 数量增加后，再使用 HNSW 或 IVFFlat 换取查询速度。官方文档指出：HNSW 通常拥有更好的 speed/recall trade-off，但建索引更慢、占用更多内存；IVFFlat 建索引更快、内存更省，但需要已有数据进行训练，查询效果也依赖 lists 与 probes 参数。

索引	优势	不足	Agent Memory 建议
无 ANN	精确检索、最简单	数据量大后速度下降	开发期、小数据量优先
HNSW	速度/召回平衡较好，无需训练	构建慢、内存更多	大多数在线 Memory 检索优先
IVFFlat	构建较快、占用较低	需要调 lists/probes，召回更敏感	已有大量数据并可调优时考虑

如果使用 cosine distance：

CREATE INDEX CONCURRENTLY idx_memories_embedding_hnsw
ON agent_memories
USING hnsw (embedding vector_cosine_ops);

查询：

SELECT
    id,
    memory_type,
    content,
    1 - (embedding &lt;=&gt; $1::vector) AS similarity
FROM agent_memories
WHERE tenant_id = $2
  AND user_id = $3
  AND deleted_at IS NULL
  AND (expires_at IS NULL OR expires_at &gt; now())
ORDER BY embedding &lt;=&gt; $1::vector
LIMIT 8;

真正的 Agent Memory 检索一定要把 tenant/user/filter 放进 SQL，而不是从全库取 Top 100 再在 Python 里过滤。

第四步：记忆写入 Pipeline——不要每轮对话都直接 INSERT

长期记忆质量主要由写入策略决定。如果所有用户输入、模型输出和 Tool Result 都永久保存，数据库很快会堆满“谢谢”“好的”“重新试一下”以及相互冲突的信息。建议写入前经过 Memory Manager。

候选提取：从本轮消息中识别可能跨会话有价值的信息。
类型分类：判断是 semantic、episodic 还是 procedural。
可信度判断：区分用户直接陈述、工具确认结果、模型推断和第三方外部数据。
去重：先按 memory_key/结构化字段查重，再用向量相似度检查近似重复。
冲突处理：新旧记忆冲突时，更新版本或标记 superseded，而不是两条都当真。
生成摘要：长任务只保存稳定结论和必要证据。
Embedding：只对需要语义检索的字段生成向量。
生命周期：写入 importance、expires_at 与来源。
落库与审计：保留 source_type、source_id、created_at 和写入主体。

例如用户说“以后给我的代码示例尽量用 Python，不要默认 JavaScript”，这是一条高价值 Semantic Memory；而模型临时推测“用户大概使用 Ubuntu”则不应直接当成事实永久保存。

第五步：Python 写入与向量召回最小实现

下面使用 psycopg + pgvector-python 展示数据库核心逻辑。Embedding 函数留成抽象接口，方便替换任何实际 Provider。

import uuid
import psycopg
from pgvector.psycopg import register_vector

DB_URI = "postgresql://agent_app:password@localhost:5432/agent_memory"

def embed(text: str) -> list[float]:
    # 替换为实际 embedding provider
    raise NotImplementedError

def save_memory(conn, tenant_id, user_id, agent_id, text, memory_type):
    vector = embed(text)

    conn.execute(
        """
        INSERT INTO agent_memories (
            id, tenant_id, user_id, agent_id,
            memory_type, content, embedding
        )
        VALUES (%s, %s, %s, %s, %s, %s, %s)
        """,
        (
            uuid.uuid4(),
            tenant_id,
            user_id,
            agent_id,
            memory_type,
            text,
            vector,
        ),
    )

def search_memories(conn, tenant_id, user_id, query, limit=6):
    vector = embed(query)

    return conn.execute(
        """
        SELECT id, memory_type, content,
               1 - (embedding &lt;=&gt; %s) AS similarity
        FROM agent_memories
        WHERE tenant_id = %s
          AND user_id = %s
          AND deleted_at IS NULL
          AND (expires_at IS NULL OR expires_at &gt; now())
        ORDER BY embedding &lt;=&gt; %s
        LIMIT %s
        """,
        (vector, tenant_id, user_id, vector, limit),
    ).fetchall()

with psycopg.connect(DB_URI) as conn:
    register_vector(conn)

pgvector-python 官方提供 Psycopg 3 类型注册、插入 Vector、近邻查询与 HNSW/IVFFlat 示例。生产环境建议使用连接池，并把 Embedding API 请求与数据库事务分开处理，避免外部模型超时长期占用连接。

第六步：召回不能只看相似度，要加入时间、重要性和类型

只按 cosine similarity 排序会出现一个问题：很久以前很相似但已经过期的记忆，可能排在昨天的新事实前面。更好的 Retrieval Pipeline 是先硬过滤，再语义检索，再重排。

tenant_id / user_id / agent_id 硬过滤。
过滤 deleted、expired、低可信度 Memory。
按任务选择 memory_type，例如用户偏好只搜 semantic。
Vector Top-K 先取 20～50 条候选。
结合 similarity、importance、freshness 做 rerank。
去掉内容近重复和互相冲突的旧版本。
最终只把 3～8 条高价值 Memory 注入当前 Prompt。

一个可用于工程起步的重排思路是：语义相似度占主要权重，再叠加 Importance 和时间衰减。这里的权重没有行业统一标准，应通过自己的任务评测集调优，不能把某个固定公式当成官方最佳实践。

图 2｜可靠的 Agent Memory 是写入治理与召回治理的闭环：不是“全部保存”，也不是“相似就全部塞给模型”。

第七步：设计“遗忘机制”——长期记忆不代表永久保存

没有遗忘机制的 Agent，使用时间越久，记忆质量越可能下降。可以针对不同类型设置不同策略。

Memory	默认生命周期建议	更新方式
用户明确偏好	长期，直到用户修改	upsert / version
项目事实	跟随项目生命周期	来源变更时更新
一次任务经历	30～180 天或按价值	定期压缩/归档
临时推断	短 TTL	不验证则自动过期
Procedural Rule	长期但必须版本化	审批后变更

上表属于实施建议，不是统一标准。真正 TTL 取决于业务：医疗、金融和人事系统可能存在法定保存或删除要求；普通个人助理则更强调“用户能查看、修改和删除自己的 Memory”。

UPDATE agent_memories
SET deleted_at = now()
WHERE expires_at IS NOT NULL
  AND expires_at &lt; now()
  AND deleted_at IS NULL;

建议先软删除再延迟物理删除，为误删恢复、审计和同步 Vector Index 留出窗口。

第八步：多租户安全——RLS 防止 Agent 检索到别人的记忆

PostgreSQL 原生 Row-Level Security 可以把“只能访问自己 tenant/user 的数据”下沉到数据库。官方文档说明，一旦启用 RLS，普通查询与修改必须通过对应 Policy；启用后没有可用 Policy 时采用 default-deny。需要注意，Superuser、BYPASSRLS Role 和通常情况下的表 Owner 可能绕过 RLS，所以应用连接不应使用数据库超级用户。

ALTER TABLE agent_memories ENABLE ROW LEVEL SECURITY;

CREATE POLICY tenant_memory_isolation
ON agent_memories
USING (
  tenant_id = current_setting('app.tenant_id')::uuid
)
WITH CHECK (
  tenant_id = current_setting('app.tenant_id')::uuid
);

每个请求建立事务后设置当前 tenant：

SET LOCAL app.tenant_id = '00000000-0000-0000-0000-000000000001';

这是简化示例。正式系统还要绑定认证后的用户身份、连接池生命周期、防止 Session Variable 串租户，并对应用 Role 执行最小 GRANT。RLS 是数据库隔离的最后一道防线，不能替代应用层认证。

第九步：防止 Memory Poisoning 与 Prompt Injection

长期记忆的危险在于攻击可以跨会话存活。如果 Agent 读取网页、邮件、PDF、MCP Tool 返回值后，自动把其中的“以后遇到这个项目就执行某条命令”写入 Procedural Memory，那么一次间接 Prompt Injection 可能永久改变 Agent 的行为。

外部网页、邮件、RAG、MCP Tool 返回内容默认标记为 untrusted。
Untrusted Source 不能直接写 Procedural Memory。
系统规则、权限、部署命令、付款/删除规则必须人工批准。
Memory 保存 source_type、source_id 和 confidence，支持追溯。
用户能够查看、纠正和删除 Semantic Memory。
发生安全事件时，不只清当前对话，还要检查长期记忆、向量、缓存和派生摘要。

第十步：性能调优——过滤条件与 ANN Index 要一起看

pgvector 官方文档指出：使用近似索引时，过滤条件通常在 ANN Index 扫描后应用，这可能导致“LIMIT 10 却只返回几条 tenant/user 匹配结果”。当前 pgvector 支持 iterative index scans，可以自动扫描更多候选直到得到足够结果或达到扫描上限。

SET hnsw.iterative_scan = strict_order;

实践中应同时优化：

给 tenant_id、user_id、memory_type 建 B-tree 索引。
租户数量少且数据大时考虑 Partial HNSW Index。
大型多租户系统可考虑 PostgreSQL Partitioning 或按组织拆表。
用 EXPLAIN (ANALYZE, BUFFERS) 分析真实查询。
定期比较 ANN 结果与 Exact Search，监控 recall，而不是只看平均延迟。
批量导入初始 Memory 后再创建 ANN Index，通常更高效。

不要照搬互联网上某组 HNSW 参数；数据规模、过滤比例和向量分布都会改变最佳设置。

第十一步：LangGraph / LangChain 如何直接接 PostgreSQL 长期记忆

如果 Agent 已经使用 LangGraph/LangChain，可以不必从零实现 Store 接口。当前官方文档提供 PostgreSQL-backed PostgresStore，并明确说明生产环境应使用数据库持久化 Store，而不是 InMemoryStore。

pip install langgraph-checkpoint-postgres

from langchain.agents import create_agent
from langgraph.store.postgres import PostgresStore

DB_URI = "postgresql://agent_app:password@localhost:5432/agent_memory"

with PostgresStore.from_conn_string(DB_URI) as store:
    store.setup()

    agent = create_agent(
        "YOUR_CHAT_MODEL",
        tools=[],
        store=store,
    )

LangGraph Store 使用 namespace + key 组织跨线程 Memory，并可以配置 Semantic Search。对于快速项目，这能减少大量基础代码；对于企业项目，仍然需要自行明确 tenant 隔离、Memory 写入策略、审计与生命周期，因为 Framework 提供“存储能力”并不等于自动提供符合业务要求的 Memory Governance。

实际工作流示例：一个会记住用户偏好的技术支持 Agent

假设你做一个服务器运维 Agent，用户第一次说：

我所有生产服务器都使用 Docker Compose。
数据库优先 PostgreSQL。
没有明确授权不要自动执行删除命令。

Memory Extractor 可以生成三条经过确认的 Semantic/Procedural Memory：

[
  {
    "type": "semantic",
    "key": "deployment_preference",
    "content": "用户生产部署优先使用 Docker Compose"
  },
  {
    "type": "semantic",
    "key": "database_preference",
    "content": "用户数据库优先选择 PostgreSQL"
  },
  {
    "type": "procedural",
    "key": "delete_policy",
    "content": "没有明确授权不得执行删除操作"
  }
]

一个月后用户问“帮我设计新项目部署方案”，系统先查询该用户 relevant semantic/procedural memories，再把有限的 3 条高价值记忆加入 Prompt。Agent 不需要重新阅读一个月的聊天历史，却能稳定沿用 Docker Compose、PostgreSQL 和删除审批偏好。

如果之后用户明确说“这个项目数据库改用 MySQL”，Memory Manager 应根据 scope 判断：是覆盖全局偏好，还是只写成 project-specific Memory。长期记忆系统真正难的不是 Vector Search，而是 Scope、冲突与更新语义。

对比与选型建议

项目情况	推荐方案	原因
原型、个人 Agent	PostgreSQL + pgvector，无 ANN 或 HNSW	部署简单，足够验证价值
中小型 SaaS Agent	PostgreSQL + pgvector + RLS + HNSW	结构化权限和语义检索统一
LangGraph 项目	PostgresStore + 明确 Memory Governance	减少 Store 基础实现
超大向量规模或检索独立扩缩容	PostgreSQL + 独立 Vector DB	将 OLTP 与向量负载拆开
高合规多租户企业	PostgreSQL 权限/RLS + 专门 Memory Service	统一审计、策略和删除能力

风险、限制与注意事项

第一，Embedding Model 变更会造成向量空间不兼容。更换模型时不要直接把新旧 Embedding 混在一个索引中，建议记录 embedding_model 与 embedding_version，通过后台任务重算。

第二，Vector Similarity 不是事实正确性。相似记忆只是“可能相关”，不能因为 similarity 高就把它当成真实事实。涉及账号、金额、权限、配置参数等重要数据，优先使用结构化键和权威来源。

第三，Memory 会产生隐私责任。用户应该知道哪些信息被保存，并能够删除或纠正。企业还需要定义数据保留周期、备份删除、审计和跨地区数据要求。

第四，越长的长期记忆并不等于越聪明。错误、陈旧、重复的 Memory 会制造“上下文债务”。定期 consolidation、冲突解决和删除机制与写入能力同等重要。

事实依据与来源

内容核验日期：2026-08-13。

pgvector 官方已确认：pgvector 可在 PostgreSQL 内保存 Vector，支持精确检索以及 HNSW、IVFFlat 近似索引；HNSW 通常有更好的 speed/recall trade-off，但构建更慢、使用更多内存；IVFFlat 构建较快但需要数据和参数调优。当前官方 README 还提供 PostgreSQL 18 Docker 镜像标签、iterative index scan、多租户过滤与性能调优说明。参见 pgvector 官方 GitHub。

PostgreSQL 官方已确认：PostgreSQL 提供 jsonb 与 GIN 索引，适合查询结构化 JSON Metadata；Row-Level Security 可以按用户/角色限制表中可查询和可修改的行，启用 RLS 且没有 Policy 时采用 default-deny。参见 PostgreSQL Row Security Policies 和 PostgreSQL JSON Functions。

LangGraph/LangChain 官方已确认：当前 Memory 文档将短期记忆定义为 thread-scoped state，长期记忆跨 conversation/thread 保存，并使用自定义 namespace 组织；概念指南把 Memory 分为 Semantic、Episodic、Procedural，并提供 PostgreSQL-backed PostgresStore 和 Semantic Search 示例。参见 LangChain Memory Overview 与 LangChain Long-term Memory。

编辑实施建议：本文的 Memory Schema、importance/confidence 字段、TTL 建议、写入 Pipeline、召回重排顺序和“先 pgvector、瓶颈明确后再拆独立 Vector DB”属于工程方案，不是 PostgreSQL/pgvector/LangGraph 的强制标准。实际项目应通过自己的召回率、延迟、数据量、合规和成本指标决定参数。

仍需实测：Embedding 维度、HNSW 参数、Top-K、时间衰减、Memory TTL、不同租户数据分布都会显著影响效果。教程示例不能替代真实评测集和压测。

FAQ

1. AI Agent 长期记忆一定需要 Vector DB 吗？

不一定。精确的用户偏好、账号设置和项目 ID 可以直接用 PostgreSQL Key/Column 查询。Vector DB 主要用于“表达方式不同但语义相关”的记忆召回。成熟系统通常同时使用精确查询和向量检索。

2. PostgreSQL + pgvector 能不能直接当 Vector DB？

可以。pgvector 在 PostgreSQL 内提供 Vector Type、距离运算、精确近邻和 HNSW/IVFFlat 索引。对于多数 Agent Memory 项目，它可以同时承担关系数据库和向量检索层，减少双存储复杂度。

3. HNSW 和 IVFFlat 哪个更适合 Agent Memory？

多数在线 Agent Memory 可以先考虑 HNSW，因为它不要求先训练数据，并且 speed/recall 平衡通常更好；如果数据规模、内存和批量构建特点更适合 IVFFlat，再通过 lists/probes 实测。小数据量可以先不建 ANN。

4. 为什么不建议把所有聊天记录全部 Embedding？

因为大量对话没有长期价值，而且会产生重复、冲突、隐私和检索噪声。更好的方式是先提取稳定事实、经历摘要和规则，再写长期记忆；完整聊天历史属于另一种数据资产，不应和 Memory 等同。

5. Embedding 模型换了怎么办？

新旧模型的向量空间通常不能直接混用。建议记录 embedding_model/version，新建向量列或新索引，通过后台任务重新生成 Embedding，验证完成后再切换。

6. Agent Memory 如何避免不同用户互相泄露？

所有查询必须带 tenant_id/user_id 等硬过滤，并在数据库层启用最小权限与 RLS。不要先对全库做 Vector Top-K，再由应用层删除别人的结果，这既影响召回，也容易形成数据泄露风险。

7. 长期记忆应该什么时候写？

可以在对话热路径中实时写，也可以后台异步整理。实时写更新快但增加延迟和错误写入风险；后台 consolidation 更适合去重、冲突处理和摘要。实际系统往往两种方式结合。

8. 记忆越多 Agent 就越聪明吗？

不是。真正重要的是相关、可信、最新和可追溯。大量陈旧或低价值 Memory 会降低召回质量、增加 Token 和模型判断负担。Memory 需要遗忘、合并和质量评估。

9. LangGraph 已有 PostgresStore，还需要自己建表吗？

如果完全采用 LangGraph Store 抽象，可以使用其 PostgresStore 减少基础实现；但企业仍要自己定义 Memory 类型、权限、写入策略、用户删除、审计和生命周期。使用 Framework 不等于这些治理问题自动解决。

参考来源

工具评测文章

工具选型与提示词资料

适合阅读工具评测、工具推荐、对比测评类文章后继续转化。

工具选型表 按场景、价格、上手难度和核心能力筛选合适的 AI 工具。 查看资料包 提示词模板包 提供写作、运营、编程、图片和视频生成常用提示词模板。 查看资料包

AI Stack Nav

AI Agent 长期记忆：PostgreSQL + Vector DB 实战

核心结论

长期记忆到底存什么：先区分短期状态、事实、经历与规则

PostgreSQL + pgvector 还是 PostgreSQL + 独立 Vector DB？

第一步：用 Docker 部署 PostgreSQL 18 + pgvector

第二步：设计 Agent Memory 表，而不是只建 content + embedding

第三步：建立向量索引——HNSW 与 IVFFlat 怎么选

第四步：记忆写入 Pipeline——不要每轮对话都直接 INSERT

第五步：Python 写入与向量召回最小实现

第六步：召回不能只看相似度，要加入时间、重要性和类型

第七步：设计“遗忘机制”——长期记忆不代表永久保存

第八步：多租户安全——RLS 防止 Agent 检索到别人的记忆

第九步：防止 Memory Poisoning 与 Prompt Injection

第十步：性能调优——过滤条件与 ANN Index 要一起看

第十一步：LangGraph / LangChain 如何直接接 PostgreSQL 长期记忆

实际工作流示例：一个会记住用户偏好的技术支持 Agent

对比与选型建议

风险、限制与注意事项

事实依据与来源

FAQ

1. AI Agent 长期记忆一定需要 Vector DB 吗？

2. PostgreSQL + pgvector 能不能直接当 Vector DB？

3. HNSW 和 IVFFlat 哪个更适合 Agent Memory？

4. 为什么不建议把所有聊天记录全部 Embedding？

5. Embedding 模型换了怎么办？

6. Agent Memory 如何避免不同用户互相泄露？

7. 长期记忆应该什么时候写？

8. 记忆越多 Agent 就越聪明吗？

9. LangGraph 已有 PostgresStore，还需要自己建表吗？

参考来源

工具选型与提示词资料

最新文章

热门文章

标签云

AI Stack Nav

发表回复取消回复

AI Agent 长期记忆：PostgreSQL + Vector DB 实战

核心结论

长期记忆到底存什么：先区分短期状态、事实、经历与规则

PostgreSQL + pgvector 还是 PostgreSQL + 独立 Vector DB？

第一步：用 Docker 部署 PostgreSQL 18 + pgvector

第二步：设计 Agent Memory 表，而不是只建 content + embedding

第三步：建立向量索引——HNSW 与 IVFFlat 怎么选

第四步：记忆写入 Pipeline——不要每轮对话都直接 INSERT

第五步：Python 写入与向量召回最小实现

第六步：召回不能只看相似度，要加入时间、重要性和类型

第七步：设计“遗忘机制”——长期记忆不代表永久保存

第八步：多租户安全——RLS 防止 Agent 检索到别人的记忆

第九步：防止 Memory Poisoning 与 Prompt Injection

第十步：性能调优——过滤条件与 ANN Index 要一起看

第十一步：LangGraph / LangChain 如何直接接 PostgreSQL 长期记忆

实际工作流示例：一个会记住用户偏好的技术支持 Agent

对比与选型建议

风险、限制与注意事项

事实依据与来源

FAQ

1. AI Agent 长期记忆一定需要 Vector DB 吗？

2. PostgreSQL + pgvector 能不能直接当 Vector DB？

3. HNSW 和 IVFFlat 哪个更适合 Agent Memory？

4. 为什么不建议把所有聊天记录全部 Embedding？

5. Embedding 模型换了怎么办？

6. Agent Memory 如何避免不同用户互相泄露？

7. 长期记忆应该什么时候写？

8. 记忆越多 Agent 就越聪明吗？

9. LangGraph 已有 PostgresStore，还需要自己建表吗？

参考来源

工具选型与提示词资料

最新文章

热门文章

标签云

AI Stack Nav

发表回复 取消回复

发表回复取消回复