brain
codejunkie99/brain加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
微信扫码咨询客服
POMOAI — 让开源 AI 即刻运行
加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
凌晨两点，你正在调试一个困扰了团队三天的并发 bug。Claude Code 突然发来一条消息："我找到了根因！"你兴奋地追问，它却愣了一下："等等，上次我们在哪讨论过这个模式来着？"
这不是 Claude Code 的错——大多数 AI 编码工具根本没有长期记忆。它们每次对话都是"白纸一张"，关掉窗口就清空记录。第二天早上回头看，连自己昨晚写了什么代码都记不清楚。
独立开发者 Avid（GitHub @codejunkie99）也遇到了同样的问题。他在多个 AI 编码代理之间切换（Claude Code、Cursor、Codex、OpenClaw），每次都要重新解释项目上下文。更要命的是：这些代理各自为政，你在 Claude Code 里记下的技术决策，Cursor 完全不知道。
2026 年 4 月底，他决定自己解决这个问题。他用 Rust 写了一个叫 brain 的工具——一个 Git 背书的、AI 编码代理专用的长期记忆系统。
图：brain 核心架构。memory notes 通过
brain note命令写入，以 git commit 形式存储在本地~/.brain/目录，经 SQLite FTS5 全文索引后对外提供检索。
大多数记忆工具会选择云端存储——数据安全、跨设备同步、看起来很美。但 brain 走了一条完全不同的路：所有记忆都存储在本地的 .git 仓库中。
为什么这样做？
首先是隐私。AI 编码代理常常处理敏感代码（内部 API 密钥、专有算法、商业逻辑）。把这些东西发到云端？Avid 说不。他要确保你的记忆永远在你自己手里。
其次是可审计性。Git 是最好的变更历史记录工具。你可以用 git log 看到某条记忆是什么时候写的、谁写的、修改过几次。用 git diff 对比两个时间点的记忆状态——这是传统数据库做不到的。
第三是与现有工具链无缝集成。brain 不需要任何云服务，不需要注册账号，不需要配置 API Key。它就是一个本地 Git 仓库，加一个 Rust 写的命令行工具。
存储结构长这样：
~/.brain/
├── .git/ # Git 仓库（所有记忆的"真相之源"）
├── index.db # SQLite FTS5 索引（加速搜索）
└── events/ # 事件日志
每次 brain note "remember that..." 执行时，工具会：
.md 文件brain 不是一个单体应用，而是一个精心拆分的 Rust workspace，包含 7 个独立 crate，每个各司其职：
| Crate | 职责 | 关键依赖 |
|---|---|---|
brain-types | 共享数据类型、UUID v7、blake3 哈希 | serde, chrono |
brain-store | Git 仓库读写（git2）、事件追加 | git2, chrono, uuid |
brain-index | SQLite FTS5 全文索引构建与查询 | rusqlite, regex |
brain-app | 业务逻辑层，编排 store + index | tokio, anyhow |
brain-mcp | MCP 服务器（rmcp），暴露给 Claude Code 等 | rmcp, tokio |
brain-tui | 全屏终端界面（ratatui + crossterm） | ratatui, crossterm |
brain-cli | 命令行入口（clap） | clap, brain-app |
这是一个架构设计上的亮点：存储层（git）与索引层（sqlite）完全分离，且两者都可以独立重建。brain doctor --deep 命令会清空 SQLite 索引，从 git 历史重新构建——这意味着即索引损坏，你的数据丝毫无损。
技术选型也很有意思：
brain 的野心不只是做个笔记工具，而是成为 AI 编码代理的统一记忆层。它通过 adapters/ 目录下的适配器，与五款主流代理深度集成：
~/.claude/mcp_servers.json + ~/.claude/CLAUDE.md（MCP 协议）~/.cursor/mcp.json + .cursor/rules/brain.mdc（MCP 协议）~/.codex/config.toml + ~/.codex/AGENTS.md（MCP 协议）~/.openclaw/workspace/BRAIN.md（CLI 文件注入）AGENTS.md（本项目的工作目录文件注入）你可能会问：这些代理自己的记忆系统不够用吗？
答案是：够用，但不够通用。Claude Code 的记忆存在它的内部状态里，换一台机器就没了。Cursor 的规则存在项目目录下，别人协作时看不见。而 brain 把记忆存在 ~/.brain/——一个独立的、可以用 GitHub 同步的仓库里。
也就是说，你的团队可以共享同一个 brain 仓库：
# 克隆团队的共享记忆仓库
git clone git@github.com:your-team/brain-memory.git ~/.brain
# 或者通过 brain 内置的 remote 功能
brain remote add origin git@github.com:your-team/brain-memory.git
brain push # 推送到远程
brain pull # 从远程拉取
这样，团队成员在各自项目中学到的技术决策，就能被其他成员在别处复用。
brain 的上手流程被设计得非常顺滑：
# 首次安装，自动引导配置
brain onboard
# 记录一条记忆
brain note "auth 使用 PKCE，不是简单 token"
# 检索记忆（模糊搜索）
brain ask "auth"
# 查看最近记忆
brain log
# 打开全屏 TUI 界面
brain tui
# 健康检查（重建索引）
brain doctor --deep
# 开启 MCP 服务器（供 Claude Code 等连接）
brain serve --mcp
# 同步到远程仓库
brain remote add origin git@github.com:your-team/shared-brain.git
brain push
brain onboard 是整个工具最聪明的设计。它不强制你做任何选择，而是：
BRAIN:START / BRAIN:END 标记块防止重复注入整个过程透明、安全、可回滚。
brain 不是什么银弹，它有几个明显的局限：
1. 本地存储 ≠ 跨设备无缝同步
虽然支持 brain push/pull，但这不是真正的实时同步。团队协作时需要手动 push/pull，或者依赖 CI/CD 定时同步。没有冲突解决机制，多人同时 push 可能产生 git 冲突。
2. Rust 编译门槛 目前只提供 Homebrew（macOS）和源码编译两种安装方式。没有预编译的 Linux 二进制包，Windows 用户需要从源码构建（需要 Rust 工具链）。这一点对非 Rust 开发者来说增加了使用门槛。
3. MCP 协议依赖 Claude Code、Cursor、Codex 都通过 MCP 协议连接 brain。如果某个代理未来不再支持 MCP，或者 MCP 协议发生 Breaking Change，brain 的这部分集成可能失效。
4. 记忆质量依赖使用者的"纪律性"
brain 本质上是一个"记忆容器"，不是"记忆管家"。你不会自动获得有用的记忆——你必须主动 brain note 有价值的信息。对于懒得记录的人，这个工具的价值大打折扣。
2025-2026 年，AI 编码代理呈爆发式增长。Claude Code、Cursor、GitHub Copilot、Codex……每一款都在解决"代码生成"的问题，但很少有工具认真对待跨会话、跨项目的知识积累。
brain 的出现填补了一个空白：它证明了"用 Git 做记忆存储"这条路径完全可行，而且比云端存储更透明、更隐私、更符合开发者习惯。
更重要的是，brain 展示了模块化架构的力量。七个子 crate 的设计让每个组件都可以独立测试、独立替换。如果未来有人想用不同的存储后端（不一定是 git），他们只需要实现 brain-store trait。如果想换搜索后端，只需实现 brain-index。
从增长曲线看，brain 2026 年 4 月底才发布，到 8 月已有 75 stars、13 forks，虽然数字不大，但考虑到它是一个非常垂直的工具（只面向 AI 编码代理用户），以及它目前已经支持五款主流代理，这个增长是健康的。
brain 解决的不是"记忆什么"的问题，而是**"记忆怎么存、怎么用、怎么共享"**的问题。它用 Git 作为存储后端，用 SQLite 作为索引，用 MCP 作为接入协议——三个开发者最熟悉的技术栈，拼出了一个实用的 AI 代理记忆系统。
如果你同时使用多个 AI 编码代理，或者在团队中协作开发，brain 值得一试。它的上手成本很低（brew install + brain onboard），数据完全在自己手里，而且支持 GitHub 同步。
唯一需要习惯的是：养成主动记录的习惯。没有人的记忆是自动变好的，工具也不例外。