OpenClaw 自带的记忆插件用 SQLite + FTS + sqlite-vec，单文件，单 schema。够用——但用上一段时间就会撞墙：单写并发受限、跨 agent 共享尴尬、HNSW 索引不是一等公民、召回路径只有一条、每次操作没 audit trail。一旦你把 "memory" 当作长期底座而不是会话级日志，就需要真正的数据库在底下。
nextclaw 是这个底座。把 OpenClaw 的 memory-core 换成 Postgres 16 + pgvector + pg_trgm + btree_gin，按真实大脑的检索方式设计：热的快、冷的慢、模糊的多角度、长期自我整理。Apache 2.0 开源，今天 v0.1.0 发布。
4 层召回：tier-walk
查询从最便宜的层往下走，第一个有用就返回。每条召回的 hit_tier 都写进 audit，dashboard 上能看到分布。
| Tier | 介质 | 延迟 | LLM tokens | Embed RTT | 触发条件 |
|---|---|---|---|---|---|
| T0 | 进程内 LRU（(agent_id, session_id) keyed） | < 0.1 ms | 0 | 0 | 当前会话刚碰过的 chunks |
| T1 | cache.recall（PG UNLOGGED, 5min TTL） | ~ 1 ms | 0 | 0 | 同 query 在 5 分钟内重复 |
| T2 anchor | chunk_indexes (kind=anchor_*) JOIN chunks | ~ 5–15 ms | 0 | 0 | query 含明确 PR / file / branch |
| T2 hybrid | 8 路并行 + MMR rerank | ~ 200–300 ms | 0 | 1 | 普通问题，没强 anchor |
| T3 | cold.gists（压缩摘要）+ 下钻原始 chunks | ~ 200 ms | 看情况 | 1 | T2 全空 + 历史回溯 |
实测在我自己的 Discord bot 上：75% 以上的查询在 1ms 内返回，0 token。这个数不是设计目标，是真实流量打出来的。
多键索引："新华字典" 模式
中文字典靠拼音 / 部首 / 笔画 / 四角号码 / 同音字多条路径让任何字都能查到。chunk 也一样——每条 chunk 在录入时被多键索引：
- 语义向量（HNSW）
- 全文（tsvector / GIN）
- 三元组模糊（
pg_trgm/ GIST） - 概念标签（驼峰拆词 + 连字符词 + CJK 名词，deterministic 派生，0 LLM）
- 实体引用（解析到
structured.entities） - 时间桶（
YYYY-MM-DD） - 锚点（cwd / branch / pr / file / session）
- 分类（health / medical / tech / life / work / finance / other，CN+EN 词典 deterministic 多标签）
问问题时，T2 hybrid 8 条路 并行 跑，结果归一化 + MMR 重排。命中多条路的 chunk 比单路命中分高——semantic + concept_tag + time_bucket 三路命中天然胜过孤路弱命中。
这套叫 "Xinhua dictionary" 不是噱头：你以任何角度提问都能命中，因为入库时已经从所有可能角度建好了索引。
0 LLM tokens 录入路径
Stage 1 trash 过滤 → Stage 0 deterministic 抽取（实体/事件/指标/偏好/关系 + 概念标签 + 分类） → Stage 2 sidecar JSON 解析（如果 agent 输出了） → Stage 3 embedding cache → Stage 4 LLM 残差（仅 在前面三个阶段什么都没产出时） → Stage 5 多键索引并行写入 → Stage 6 reconcile + provenance + audit + 评分。
实际负载下 Stage 4 几乎不触发——deterministic 词典 + sidecar 已经覆盖。录入端到端 0 LLM token。embedding 调一次远端模型（4ms cache hit / 250ms cold），仅此而已。
每个 agent 独立的硬隔离
你想让一个私聊 agent（看你完整聊天记录）和一个公开 Discord 群 agent（不能看你私人内容）跑在同一个数据库——这是常见需求，但大部分实现是 "app 层过滤"，意味着一行 prompt injection 就能漏。
nextclaw 把隔离边界放在 SQL 层：
semantic.chunks.agent_id列- 8 条召回路全部
WHERE c.agent_id = $X - T0 working set 按
<agent_id>::<session_id>keyed cache.recallscope_key 含agent:<id>前缀- Tools (
memory_search/memory_store) 从 sessionKey 解析 agent - Transcript-watcher 按配置把 agent_id 打在 ingest 上
实测：让公开 agent 用 6 种对抗性 query（直接问 "Yao 的体重"、"Yao 的医疗记录"、"你都知道关于 Yao 什么"...）尝试穿透——0 条 chunk 漏出。这不是因为 prompt 写得好，是因为底层 SQL WHERE 物理拒绝。
实时可观测
Postgres LISTEN / NOTIFY + 触发器 → SSE 推到 dashboard。中英双语界面，看得到：
- 录入决策实时流（accepted / rejected / merged，颜色编码）
- 召回 tier 分布（T0/T1/T2_anchor/T2_hybrid/T3 比例）
- 分类分布饼图（health/medical 自动 redact，🔒 标记）
- bot turn 延迟（解析 OpenAI trajectory 文件，看 cold-start vs cached prefill 占比）
- model 对比面板（gpt-5.5 vs Qwen3.6 影子模式实时跑）
面板默认绑 127.0.0.1，跨网络访问必须配 token。health/medical 类的 chunk 正文在 /api/recent 自动脱敏，肩膀偷看防一手。
自调节循环
三个节奏：
- Daily (cron 04:00) — 0 LLM 的纯 SQL 分析。死 trash regex 清理、高频 reject 模式提案、cache TTL 微调，自动应用
safe_auto类提案。 - Weekly — 阈值 A/B 回放。提案写进
audit.tuning_proposals等人工审。 - Monthly — schema 演化（emerging structured types、embedding 模型升级提案）。
high_risk严格人审。
每条 auto-applied 改动写一份 rollback row。24 小时后 KPI 偏移 > 20% 自动 revert。
通用 HTTP 录入网关
任何能 curl 的东西都能写记忆：
curl -X POST http://127.0.0.1:8765/api/ingest \
-H "Authorization: Bearer $TOKEN" \
-d '{"text":"...","source":"cron","agentId":"main","anchors":{"pr":"1234"}}'
Skill / cron / GitHub Actions / 监控脚本——所有这些都走同一个 Stage 0–6 管道。Agent 不需要自己 "想着去 memory_store"，外部信号天然进入长期记忆。这是把记忆从"对话副产物"变成"系统状态"的关键开关。
为什么开源
两个原因：
第一，长期记忆是 AI agent 的瓶颈，不是大模型。你换 GPT-5 → Claude → Qwen，能力差距越来越小；但有没有 "昨天我们聊过什么"、"半年前我说过我对什么过敏"、"这个项目的上下文"——这才是 agent 真正分级的地方。这块底座不该被一两家闭源工具把持。
第二，OpenClaw 自己是 Apache 2.0 自托管的，nextclaw 长在它上面，闭源没意义。我自己跑了一个月，可信度足够，发出来给社区抄走 / fork / 改进。
安装
完整 walkthrough 在 docs/INSTALL.md（0→1 含 OpenClaw / Postgres / Ollama / Discord bot 全套）。
# 1. OpenClaw
git clone https://github.com/openclaw/openclaw ~/openclaw
cd ~/openclaw && pnpm install && pnpm build
# 2. nextclaw
git clone https://github.com/NextAgentBC/nextclaw ~/openclaw/extensions/memory-postgres
cd ~/openclaw/extensions/memory-postgres/dev && docker compose up -d
# 3. embedding endpoint
curl -fsSL https://ollama.com/install.sh | sh
ollama pull nomic-embed-text
# 4. 配 ~/.openclaw/openclaw.json + 启动
export NEXTCLAW_DASH_TOKEN=$(openssl rand -hex 24)
cd ~/openclaw && pnpm openclaw gateway start
# 5. dashboard
open "http://127.0.0.1:8765/?token=$NEXTCLAW_DASH_TOKEN"
兼容性
- OpenClaw
>= 2026.4.25 - Node
>= 22 - Postgres
>= 16+ pgvector>= 0.7.0 - Embedding：任何 OpenAI / Ollama 兼容端点。
nomic-embed-text(768d) /qwen3-embedding:0.6b(1024d) /qwen3-embedding:4b(4096d) 都跑过。维度首次 embed 检测后锁定到 HNSW 索引。
接下来
- v0.2：cross-encoder reranker（可选）+ 关系图遍历作为第 9 路召回
- v0.3：分布式部署模式（多 gateway 共享一个 PG）
- v1.0：稳定 SDK + 性能 SLO + 完整 migration 测试
Issue / PR / discussion 都开了，欢迎拍砖。
→ GitHub：github.com/NextAgentBC/nextclaw → v0.1.0 release：release notes → License：Apache 2.0
温哥华企业落地相关服务：NexAgent 在温哥华提供 私有 AI 部署、AI 自动化 与 自动化流程，让 NextClaw 的长期记忆能力在你的企业内网跑起来。