Palinode - 把 AI agent 记忆放回可读、可 diff 的 Markdown 文件
AI agent 的“记忆”正在变成真实工程问题。一个 agent 今天记住了什么、下周会不会把旧判断当成事实、团队能不能审计某条经验从哪里来，这些问题都不适合只交给黑盒向量库处理。对长期项目来说，记忆不是越多越好，而是要能读、能删、能合并、能追溯。
今天推荐的 phasespace-labs/palinode 正是在处理这件事。它把 agent 记忆的源头放在普通 Markdown 文件和 YAML frontmatter 里，用 Git 做版本历史，再把 SQLite-vec、SQLite FTS5、MCP server、REST API 和 CLI 作为派生层。GitHub 页面当前显示项目约有 24 stars、6 forks，主要实现语言是 Python，许可为 MIT。当前可见提交历史从 2026 年 3 月 31 日开始，最近提交在 2026 年 5 月 26 日；最新 release 为 v0.8.12，发布时间是 2026 年 5 月 26 日。
项目概览
| 属性 | 详情 |
|---|---|
| 仓库 | phasespace-labs/palinode |
| Stars | 约 24 |
| Forks | 6 |
| 主要语言 | Python |
| 许可 | MIT |
| 可见提交历史起点 | 2026 年 3 月 31 日 |
| 最近提交 | 2026 年 5 月 26 日 |
| 最新 release | v0.8.12 |
文件是记忆的源头
Palinode 的核心判断很朴素：agent memory 不应该只存在于数据库里。它把 people、projects、decisions、insights、daily 等记忆类型保存成 Markdown 文件，每个文件带有 YAML frontmatter。人可以直接在 Obsidian、VS Code、vim 或任何文本编辑器里查看和修改，机器再从这些文件生成索引。
这种设计的好处是，最坏情况下系统也不会完全失明。向量索引坏了，还可以 grep。API 挂了，还可以 cat。嵌入模型不可用，文件仍然存在。对长期助手来说，这比“所有记忆都在一个不可读服务里”要稳得多。
它也让审计变得自然。某条事实是什么时候加入的、后来被谁改过、某次合并是否把旧信息覆盖掉，都可以通过 Git diff、blame 和 history 回看。Palinode 还把这些 Git 操作做成一等工具，让 agent 可以通过 MCP、CLI 或 REST API 调用。
混合搜索，而不是只靠向量召回
Palinode 同时使用 SQLite-vec 和 SQLite FTS5。前者负责语义相似，后者负责关键词和 BM25。搜索结果再通过融合排序合并。这个选择很适合记忆系统，因为人查历史时经常有两类问题：一种是“我记得关键词”，另一种是“我记得大概意思”。
只用向量检索，精确术语、错误码、项目代号可能不够稳。只用关键词，又很难找回语义相近的旧经验。Palinode 把两者都放进本地 SQLite 文件里，避免引入 Postgres、Redis 或云端检索服务。对个人开发者和小团队来说，部署成本会低很多。
README 里还提到 content-hash dedup，用来跳过未变化文件的重复 embedding。这类细节说明它不是只做一个 demo，而是在处理长期运行后会遇到的维护成本。
MCP、REST API 和 CLI 共用同一套后端
Palinode 不假设你只使用一种 IDE 或一个 agent。它提供 MCP server、REST API、CLI 和 OpenClaw plugin。MCP 适合 Claude Code、Claude Desktop、Cursor、Windsurf、Zed、VS Code 的 Continue 或 Cline 等工具；REST API 适合脚本、webhook 和自定义集成；CLI 则适合 cron、SSH 和低 token 成本的自动化。
这一点对跨工具工作流很关键。很多开发者现在并不是只用一个 agent：可能白天在 Cursor，晚上在 Claude Code，偶尔用 Zed 或终端工具。如果记忆被绑定在某个单一客户端里，换工具就会丢上下文。Palinode 的思路是把记忆服务放在中间，各种客户端只连接同一个后端。
它也明确支持把 MCP server 作为 HTTP 服务暴露给多台机器。这样一来，记忆不需要在每个工作目录里复制一份，也不需要靠聊天记录迁移。
记忆压缩是可审查的操作
长期记忆最容易失败的地方不是“存不进去”，而是越存越乱。Palinode 的 consolidation 机制把压缩做成结构化操作：LLM 只提出 KEEP、UPDATE、MERGE、SUPERSEDE、ARCHIVE 这类操作，由确定性的执行器真正修改文件，并把结果提交到 Git。
这个边界很重要。让 LLM 直接改记忆库，容易产生漂移，也很难知道哪条信息为什么被删或被重写。Palinode 把“建议”和“执行”拆开，每次压缩都能变成可 review、可 blame、可 rollback 的提交。
对于团队知识库，这种方式比简单总结更可靠。记忆压缩不是把一堆旧文本压短，而是把可继续使用的事实、决策和项目状态整理成更少、更准的文件。
和 Obsidian 的关系很自然
因为记忆本身就是 Markdown 文件，Palinode 可以把记忆目录当作 Obsidian vault 使用。palinode init --obsidian 会生成 vault 结构、索引页、日记线索和一些图谱视图默认配置。README 还提到它会维护 entities: frontmatter 和正文里的 wikilinks，让图谱关系能随着记忆变化而更新。
这对人类参与很有帮助。完全自动维护的记忆系统很容易失去可解释性，而完全手写的知识库又会增加负担。Palinode 试图让 agent 负责保存、检索和提出整理建议，人类仍然能用熟悉的 Markdown 和 Obsidian 介入。
如果团队已经有 Obsidian 或文件化知识库习惯，这个迁移成本会比引入一个专用 SaaS 低。
v0.8.12 关注写入路径和监控
最新 release v0.8.12 的重点不是大功能，而是保存路径和健康检查。发布说明提到，auto_summary 不再同步阻塞 /save，而是从写入热路径移出去；同时新增了 /health/auto-summary 和 /status.auto_summary，用于让监控 agent 发现异步摘要管线是否卡住。
这类变化看起来不花哨，但对记忆系统很实际。如果保存一条记忆会被本地 LLM 的首 token 延迟拖住，调用方就可能以为写入超时；如果摘要后台任务卡住，又没有健康信号，问题会很晚才暴露。Palinode 近期 release 关注这些运行细节，说明项目作者在按真实使用反馈打磨。
适合什么场景
Palinode 适合已经认真使用 AI agent，并且开始遇到“上下文无法长期复用”的开发者或团队。
典型场景包括：
- 想把 agent 记忆保存成可读、可提交、可备份的文件；
- 希望 Claude Code、Cursor、Windsurf、Zed 等工具共用同一套长期记忆；
- 想用 MCP 给 agent 提供 search、save、diff、blame、rollback 等能力；
- 需要把项目决策、运维经验、人物和任务状态分类型保存；
- 希望定期压缩旧记忆，但不愿意让 LLM 不可追踪地直接重写知识库；
- 已经使用 Obsidian，想让 agent 记忆和人工知识库互相靠近。
如果你只是偶尔让 agent 修一个小 bug，Palinode 可能太重。它需要 Python、Git、Ollama 的 BGE-M3，以及一个持续运行的 API/watcher/MCP 组合。它更适合长期助手、团队记忆、跨 IDE agent 工作流和可审计知识管理。
需要注意的边界
记忆系统天然会处理敏感信息。Palinode 的 README 明确提醒：记忆目录是私有数据，不要公开。它把数据放回文件系统和 Git，这带来了可审计性，也要求用户认真设计仓库权限、远端同步和 .gitignore 边界。
另外，Palinode 不会自动保证记忆正确。它能保存、检索、压缩和追溯，但过期事实仍然需要人或流程发现。混合搜索也不等于真相判断，召回出来的内容仍然需要 agent 和用户结合当前上下文评估。
最后，项目仍然很早期，stars 很少，版本迭代也快。把它放进关键流程前，最好先在个人记忆库或非生产知识库里试运行，观察写入、检索、压缩和回滚是否符合自己的工作方式。
总结
phasespace-labs/palinode 的价值不在于又做了一个 agent 笔记本，而是把 agent 长期记忆重新变成普通工程资产：Markdown 文件、Git 历史、本地索引、MCP 工具、可审查压缩和明确的运行健康信号。
如果你已经在维护长期助手、AI coding 流程或团队知识库，并且不想把记忆完全交给黑盒数据库，Palinode 是一个值得观察的小众项目。它的方向很清楚：让 agent 记得住，也让人类看得懂、改得动、追得回。