失败经验层怎么选：MisakaNet 与四类替代方案的取舍边界
选型时最常见的错误，是把 MisakaNet 拿去和"给文档做问答的 RAG"比，比完之后得出结论说召回不够准。这两者根本不在同一层：一个是把踩过的坑记下来给人查，一个是把你的资料变成可检索的上下文。定位错了，后面的技术比较全是白费。
这篇做的是横向选型：先分清要解决哪一类问题，再把 MisakaNet 与个人记忆框架、自建 RAG、团队文档三种替代路线摆在一起，最后给出不适用的场景。
先分清你要解决哪一类问题
把"记忆"这个词拆开，至少能拆出四层互不替代的需求：
- 执行能力层：让 Agent 会做某件事。这层要的是 Skill，不是知识库；
- 失败经验层：让 Agent 和你都不重复踩同一个坑。MisakaNet 在这一层；
- 个人偏好层：让 Agent 记住上一个会话里你的习惯、称呼、约束；
- 资料检索层：把你自己的文档变成可问答的上下文。
项目说明里那句区分比任何架构图都省事：Skill 解决"怎么做",Lesson 记录"以前怎么失败的"。 先确定痛点在第二层，才有必要往下看。
与个人记忆框架的横向对比
同样叫"给 AI 加记忆"，个人记忆框架解决的是第三层。对比维度如下（数据取自项目页面）：
| 维度 | MisakaNet | Letta | MemMachine | LangMem | Evolver |
|---|---|---|---|---|---|
| 记忆类型 | 集体（Swarm） | 个人（OS） | 个人（三层） | 个人（图） | 个人（向量） |
| 基础设施 | git + python3（零依赖） | Docker + PostgreSQL | Docker + Neo4j | Python + SQLite | Docker + Qdrant |
| 网络效应 | ✅ 节点越多越强 | ❌ 各实例隔离 | ❌ | ❌ | ❌ |
| 离线优先 | ✅ 完整离线搜索 | ❌ 需服务器 | ❌ | ⚠️ 部分 | ❌ |
| 入门成本 | git clone（5 秒） | Docker（约 15 分钟） | Docker（约 15 分钟） | pip install | Docker（约 20 分钟） |
表格里最值得盯的一列不是"记忆类型"，而是"网络效应"。个人记忆方案的设计前提是每个实例自成世界：我的 Agent 记住我，你的 Agent 记住你，两者之间没有通路。这在偏好记忆上完全正确，但放到失败经验上就失效了——pip install 超时这件事不会因为我是我、你是你而变成两件事。
MisakaNet 反过来的代价也清楚：集体记忆要求大家往同一个池子里写，于是必须有一套格式与质量约定，没有个人方案那种"随手记"的自由度。目前池子的规模是 393 条去重后的 canonical 条目、333 个节点，方向覆盖 RAG / DevOps / Feishu / Fanuc / Network / Claude / MCP；页面上把它定位为 failure-memory protocol 的参考实现，许可 Apache 2.0，493 star、综合评分 70.7。这些数字说明网络已经起步，但离"什么坑都查得到"还很远。
与自建 RAG 的差别：不是精度差，而是目标不同
把团队的历史文档灌进向量库，也能实现"问一句、答一段"。这条路线和 MisakaNet 的差别集中在三点上。
数据形态不同。 RAG 吃的是原始文档，长、杂、含有大量与答案无关的内容；MisakaNet 的一条 lesson 是压缩过的四段结构（问题 → 根因 → 修复 → 验证），本身就是为检索与执行设计的。
检索机制不同。 它的检索是 BM25 关键词匹配，纯 Python 标准库实现，官方明说"不保证语义准确"。RAG 天然带语义相似度。所以如果你要查的是"意思差不多"的东西，RAG 有优势；如果你要查的是某个具体报错码或命令名，关键词匹配反而更准——报错原文里的独特 token 恰好是 BM25 最擅长命中的东西。
维护成本不同。 RAG 要维护向量库、嵌入模型、切片策略和一套服务；MisakaNet 的存储层就是一条 Git 仓库，代价是召回能力被刻意压低了。这是一个明确的能力交换，不是谁做得更好。
与团队文档的差别：贡献成本决定内容质量
很多团队其实已经有答案：一份 Wiki、一个"常见问题"页面、一堆排错记录。它们和 MisakaNet 的差别不在载体，而在写进去的成本结构。
文档站的路径是"专门抽时间写一篇"，于是内容倾向于总结经验、写得漂亮、但更新慢；MisakaNet 的路径是"刚踩完就记一条"，格式被固定成四段，提交走 queue_lesson.py，之后由 CI 检查质量分数、DCO 与格式。写起来更像填表，不像写文章。要求低了，愿意写的人就多了，但内容颗粒度也更细——这是它选择的方向。
值得单独提的是 Git 带来的附带效果：每条 lesson 的增删改都留在提交历史里，谁在什么时候改了什么一目了然。要在一套数据库驱动的知识库里实现同等审计能力，得额外做一套审计表。
什么时候不该选它
选型的价值一半在"不选"。以下四种情况建议直接放弃：
需要语义召回。 你的查询词和语料用词对不上、同义词与中英混写很多时，关键词匹配会明显漏召。这不是配置问题，是设计边界。
语料是私有资料而非公共失败经验。 内部制度、产品手册、客户资料这类内容，集体记忆机制帮不上忙，反而有合规风险。
需要高并发写入。 Git 不以并发写见长，多节点同时提交要靠 PR 队列串行化，写入吞吐靠流程而不是靠系统。
需要可执行的能力封装。 你要的是"Agent 自己动手把这件事做完"，那属于 Skill 的范畴，装多少 lesson 都不会让它长出执行能力。
一个可用的决策顺序
按下面四步问自己，基本能定位：
1. 我的问题是"Agent 不会做"还是"总在同一个地方摔"？前者找 Skill，后者继续往下；
2. 这些经验是通用的还是只属于我的？通用的才有共享价值，只属于我的用个人记忆方案更省事；
3. 我能不能接受关键词匹配？接受就继续，不能接受就回到 RAG 或混合方案；
4. 团队有没有人愿意按格式贡献？没有的话，先解决这个，工具换哪个都一样。
四步都过得去，MisakaNet 就是合适的候选；它甚至不要求你放弃别的方案——Remote MCP 那种接法是一次配置的事，和现有的个人记忆层、向量库并不冲突。真正冲突的是期待值：把它当"万能知识库"会失望，把它当"失败经验层"会好用。
想看清同类插件各自的定位与接入方式，可以顺着这份清单横向比 https://dpharness.com/top