本文最后更新于 2026年8月14日。
有，而且你描述的其实已经形成了一个比较明确的方向：AI Coding Agent 的长期记忆（Persistent Memory / Agent Memory）。
而且到了 2026 年，已经不只是简单的“把聊天记录存进向量数据库”，而是开始出现你说的这种：
遇到问题 → 尝试方案 → 失败 → 找到解决方案 → 记录原因 → 下次遇到类似问题自动提醒 → 多次经验后形成更稳定的规则
这和“人的记忆”已经比较接近了。
我比较推荐你先看这几个
1. Memorix —— 我认为最符合你现在的需求
它非常贴合你的场景，而且明确支持 Trae。
它可以让 Claude Code、Codex、Cursor、Windsurf、Copilot、Gemini CLI、OpenCode、Trae 等 Coding Agent 共用一套项目记忆。底层以 SQLite 为核心存储，支持 MCP。(GitHub)
它记录的不只是：
用户说了什么
而是类似：
Issue
↓
Attempt
↓
Failed
↓
Fix
↓
Why
↓
Decision
↓
Future Gotcha
尤其有几个功能很符合你说的“不断优化”：
-
Session Summary
-
Fix / Gotcha
-
Reasoning Memory
-
Git Memory
-
Project Memory
-
Memory Autopilot
-
跨 Agent 共享
-
MCP
-
SQLite
-
可以把 Git commit 转换成工程知识
也就是说，你今天用 Trae，明天用 Claude Code，后天用 Codex，项目记忆仍然存在。(GitHub)
2. Agent-Memory —— 更像一个通用“人脑”
这个项目的定位就是：
Persistent memory for AI coding agents
支持 Claude Code、Cursor、Gemini CLI、Codex CLI、OpenCode 等 MCP 客户端。它不只是向量搜索，还加入了：
-
confidence
-
lifecycle
-
knowledge graph
-
hybrid search
-
memory hooks
-
自动捕获 session
-
memory viewer
也就是：
观察
↓
记忆
↓
建立关系
↓
评估可信度
↓
随着时间更新
↓
检索
这种设计已经比传统的：
embedding → vector DB → similarity search
高级不少。(GitHub)
3. A-MEM —— 很接近你说的“像人的记忆一样不断组织”
它的思路非常有意思。
不是简单：
问题 → 一条 memory
而是让 Memory 自动形成 Zettelkasten 知识网络。
例如你解决过：
Simulink Bus hierarchy error
可能产生：
Simulink
├── Bus Object
│ ├── hierarchy mismatch
│ ├── element order
│ └── DataType
│
├── Model Reference
│
└── Mask Parameter
以后又遇到类似错误，它可以通过关联记忆找到以前的解决经验。
项目作者明确把它定义为 self-evolving memory for coding agents。(GitHub)
4. projectmem —— 我觉得特别适合“代码问题 → 解决方案”这个场景
这个项目甚至直接针对你说的问题：
issue → attempt → fix → decision
它把开发过程记录成事件：
Issue
Attempt
Fix
Decision
Note
然后重新投影成 AI 能读取的项目知识。
更有意思的是，它不是单纯“记住”。
它有一个 pre-action gate：
AI 准备再次执行某个操作之前，如果发现过去已经尝试过并失败，可以提前警告。
例如：
AI:
我要修改 xxx.m 文件……
Memory:
⚠️ 注意：
这个方案在 2026-08-10 已经尝试过。
失败原因：
Bus object hierarchy mismatch。
之前有效方案：
使用 ParaBus_PPS.Value 传递结构体。
建议：
不要重复使用旧方案。
这就已经非常接近你说的：
“人的经验记忆”
了。(projectmem)
其实你真正想做的东西，可以抽象成这个架构
我反而觉得，你这个想法非常值得自己搭一个轻量版本。
┌────────────────────┐
│ Trae / CodeBuddy │
│ Claude Code │
│ Cursor / Codex │
└─────────┬──────────┘
│ MCP / Hook
▼
┌──────────────────────┐
│ Memory Engine │
│ │
│ ① Observe │
│ ② Extract │
│ ③ Evaluate │
│ ④ Store │
│ ⑤ Retrieve │
│ ⑥ Evolve │
└──────────┬───────────┘
│
┌─────────────┼─────────────┐
▼ ▼ ▼
SQLite Vector Knowledge
FTS5 Search Graph
│ │ │
└─────────────┼─────────────┘
▼
┌──────────────┐
│ Long Memory │
└──────────────┘
Memory 不应该只有一种
我建议至少分成 5 类：
| 类型 | 例子 |
|---|---|
| Episodic | “昨天我们解决了这个 Bug” |
| Semantic | “这个项目使用 SQLite + Go” |
| Procedural | “遇到 Bus hierarchy 错误先检查 Bus Object” |
| Failure | “方案 A 已经验证失败” |
| Decision | “最终决定使用 Mask 参数传递 Bus” |
这比简单的 RAG 强很多。
更关键的是：不要让 AI 什么都记
这是目前很多 Memory 项目的核心问题。
如果把：
每一次聊天
每一次 tool call
每一次代码修改
每一次 terminal 输出
全部存进去，最后会变成：
垃圾记忆库
正确方式应该是：
Agent 工作
↓
产生大量 Observation
↓
Memory Extractor
↓
判断“这东西以后有没有价值？”
↓
┌───────────┐
│ │
NO YES
│ │
丢弃 提炼
↓
Memory
↓
去重 / 合并 / 冲突
↓
Confidence
↓
长期记忆
例如：
User:
npm install 报错
Agent:
删除 node_modules
重新 npm install
成功。
不应该记。
但是：
这个项目必须使用 pnpm，
npm 会导致 lockfile 冲突。
应该记。
我甚至建议你做一个“经验记忆”层
如果结合你前面想做的 Trae / CodeBuddy → NAS 部署工具，我会建议你把它设计成：
Coding Agent
│
┌──────────┴──────────┐
│ │
MCP Hook
│ │
└──────────┬──────────┘
▼
┌──────────────┐
│ Memory Core │
└──────┬───────┘
│
┌────────────────┼────────────────┐
▼ ▼ ▼
Project Memory Failure Memory Personal Memory
│ │ │
▼ ▼ ▼
架构知识 Bug经验 编码习惯
技术决策 失败方案 偏好
项目规则 解决方案 工作方式
然后最重要的是增加一个：
memory_score
例如：
Memory:
“这个项目使用 SQLite”
confidence = 0.98
usage_count = 31
last_verified = 2026-08-12
source = project
再比如：
Memory:
“把 timeout 设置成 30 秒可以解决这个 API 问题”
confidence = 0.42
usage_count = 1
last_verified = 2026-07-20
随着 Agent 使用：
成功一次
↓
confidence + 0.1
再次成功
↓
confidence + 0.1
发现失效
↓
confidence - 0.3
被新方案取代
↓
superseded
这样才真正有“记忆随经验成长”的感觉。
如果是你，我会怎么选
你之前一直偏向 个人项目、轻量、SQLite、Go、自部署，所以我不会建议你一上来搞：
PostgreSQL + pgvector + Neo4j + Redis + Kafka + Qdrant
完全没必要。
我会优先：
第一选择：直接部署 Memorix
因为它已经：
SQLite + MCP + Trae + 多 Coding Agent + 项目记忆
基本和你的需求高度吻合。(GitHub)
第二选择：projectmem
如果你特别关注：
“我以前怎么解决 Bug 的？”
那么 projectmem 的 issue → attempt → fix → decision 模型非常值得研究。(projectmem)
第三选择：自己做
如果你的最终目标不是“使用”，而是做一个自己的 AI Coding Memory 工具，我反而建议你直接参考这几个项目，然后做一个：
CodeMemory
│
├── MCP Server
├── SQLite
├── FTS5
├── Embedding
├── Project Memory
├── Failure Memory
├── Solution Memory
├── Decision Memory
├── Memory Evolution
└── Web UI
甚至第一版完全不需要向量数据库。
SQLite：
memories
memory_relations
sessions
issues
attempts
solutions
decisions
- FTS5
就可以跑起来。
等数据量大了再增加 embedding/vector search。
还有一个很重要的点：Trae / CodeBuddy 是否能做到“自动捕获 → 自动形成记忆”，取决于它们开放的 MCP / Hook / Agent 接口。 如果接口足够开放，那么就可以做到几乎全自动，而不是要求你每次都说“请记住这个”。
如果你愿意，我可以下一步直接帮你把 “Trae/CodeBuddy + SQLite + MCP + 本地 Embedding + 自动提取 Bug/解决方案 + Web 记忆管理界面” 这个系统的架构和数据库 Schema 设计出来。这个其实很适合你前面那种个人开发者、小型工具、NAS 自部署的路线。
有没有基于go或者其他很轻量，数据库用sqlite可以docker部署的
有，而且我刚查了一下，现在已经有一个非常符合你要求的项目：Go + SQLite + FTS5 + MCP + 单二进制。
首推：Engram
它基本就是你要的：
AI Coding Agent 长期记忆 + Go + SQLite + Docker/本地部署 + MCP
架构非常简单：
Trae / CodeBuddy / Claude Code / Cursor / Codex
│
MCP
│
▼
┌───────────┐
│ Engram │ ← Go
└─────┬─────┘
│
▼
SQLite + FTS5
│
▼
engram.db
官方目前的定位就是 Persistent memory for AI coding agents，而且是 agent-agnostic，可以给支持 MCP 的 Coding Agent 使用。它使用 SQLite + FTS5，不需要 ChromaDB、Redis、PostgreSQL 等额外服务。(GitHub)
它为什么特别适合你
Engram 是：
-
Go
-
SQLite
-
FTS5
-
单二进制
-
MCP Server
-
HTTP API
-
CLI
-
TUI
-
Windows / Linux / macOS
-
ARM64 / AMD64
-
MIT License
-
不依赖 Node.js / Python / Bun
-
不需要独立 Vector DB
官方甚至明确把它和 claude-mem 做了对比：Engram 使用 SQLite FTS5，而不是 ChromaDB；单个 SQLite 文件即可保存记忆。(GitHub)
还有一个更接近“问题 → 尝试 → 解决”的
projectmem
这个项目的理念其实非常符合你上一条说的：
“把代码过程中遇到的问题及解决方案形成记忆，并不断优化。”
它不是简单保存聊天记录，而是把开发过程拆成：
Issue
↓
Attempt
↓
Attempt
↓
Fix
↓
Decision
例如你今天遇到：
Simulink Bus hierarchy mismatch
然后：
Attempt #1
修改 Bus Object
❌ 失败
Attempt #2
修改 Model Reference
❌ 失败
Attempt #3
修改 Mask Parameter
✅ 成功
最终 Memory 变成：
Issue:
Bus hierarchy mismatch
Failed approaches:
1. 修改 Model Reference
2. 修改 Bus 元素顺序
Successful solution:
通过 Mask 传递 ParaBus_PPS.Value
Reason:
Block 使用 Bus Object，
Value 必须与 Bus hierarchy 完全匹配。
Confidence:
High
而且它还有一个很有意思的机制：
Pre-action Gate
AI 下一次准备做类似操作时：
Agent:
我要修改 Model Reference...
Memory:
⚠️ 这个方案以前失败过。
Previous attempt:
2026-08-10
Failure:
Bus hierarchy mismatch
Recommended:
检查 Bus Object hierarchy
这已经不是传统 RAG 了，而是让 Memory 影响 Agent 下一步行为。论文也把它定义为 Memory-as-Governance。(arXiv)
不过它目前是 Python，不是 Go。
如果你要求“极致轻量”，我会这样排序
| 项目 | 语言 | DB | MCP | Docker | 轻量程度 | 我对你的推荐 |
|---|---|---|---|---|---|---|
| Engram | Go | SQLite | ✅ | 可容器化 | ⭐⭐⭐⭐⭐ | 🥇 |
| projectmem | Python | 本地事件日志 | ✅ | ✅ | ⭐⭐⭐⭐ | 🥈 |
| memory-graph | Python | SQLite | ✅ | ✅ | ⭐⭐⭐ | 🥉 |
| agent-memory-mcp | Go | SQLite | ✅ | ✅ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ |
其中 agent-memory-mcp 也是值得看的 Go 项目，它提供 MCP + semantic search，并且官方提供 Docker/Compose 部署方式。(GitHub)
但是我觉得你真正应该选 Engram
尤其结合你前面说的：
个人项目
SQLite
Go
Docker
NAS 部署
Trae / CodeBuddy
希望长期积累 Coding 经验
我会直接选：
Trae
│
CodeBuddy
│
│ MCP
▼
┌───────────────┐
│ Engram │
│ Go │
└───────┬───────┘
│
▼
┌───────────────┐
│ SQLite │
│ FTS5 │
└───────────────┘
│
▼
/data/engram.db
NAS 上甚至可以：
docker-compose.yml
data/
└── engram.db
就够了。
不过有一个非常重要的区别：
Engram 更偏“记忆”
而你真正想要的可能是：
“Coding Experience Engine”
也就是：
代码
↓
Agent 操作
↓
错误
↓
尝试
↓
解决
↓
自动提取经验
↓
Memory
↓
下次遇到类似问题
↓
自动注入经验
↓
验证是否有效
↓
更新 Memory confidence
这个东西比单纯的 Engram 更进一步。
我反而建议你不要急着部署
因为你前面问的是：
“有没有开源项目可以自动把 Trae / CodeBuddy 写代码过程中遇到的问题及解决方案形成记忆？”
现在答案是：
有，Engram 是目前最符合“Go + SQLite + 极简”的。
但是如果你的目标是：
“我希望在 NAS 上部署一个自己的 Coding Memory Server，然后 Trae、CodeBuddy、Claude Code、Codex 都接进去，共享所有项目经验。”
那我建议我们直接设计一个：
CodeMemory
├── MCP Server ← Go
├── SQLite ← 主数据库
├── FTS5 ← 全文检索
├── Embedding ← 可选
├── Memory Extractor ← LLM
├── Deduplication
├── Confidence
├── Failure Memory
├── Solution Memory
├── Decision Memory
├── Project Memory
└── Web UI
第一版甚至可以控制在一个 Go Docker 容器 + 一个 SQLite 文件。
这样比上 PostgreSQL、Qdrant、Neo4j 之类的方案轻很多，也特别适合你前面说的 NAS 场景。