brain0：AI 代码的黑盒记录仪 — 谁写的、为什么写、能信吗

如果你的 AI 编程 Agent 写了一半代码，你如何知道：哪段代码是 AI 写的、用的是哪条 prompt、它读了哪些文件、它实际改了什么和声明的有什么不同？

现在，所有 AI Agent 用户都面临同一个困境：git blame 只会告诉你「谁提交的」，但不会告诉你「谁写的」。当多个 Agent 并行作业（Claude Code 改后端、Codex 写前端、人工 review 穿插其中），代码成了一个黑盒。bug 进来了，但「哪次对话、哪个 prompt 引入的」——没人知道。

brain0 就是为这个困境而生的。它被动地在你的仓库上构建一张「决策图谱」，把每一次 commit 和它们背后的 Agent 意图关联起来，告诉你每一行变更背后的 是谁、为什么、可信吗。

一、它是什么

brain0 是一个开源的 AI 代码溯源系统，由全新的组织 Brain0-ai 在 2026 年 7 月 2 日发布，采用 Apache-2.0 许可证。

它的核心理念可以用一句话概括：git blame 告诉你「谁提交的」，brain0 告诉你「谁写的、为什么写、能信吗」。

git blame → 人与提交时间
brain0 view → Agent + prompt + 读取的文件 + 声明 vs 实际 + 风险评分

brain0 是一个纯粹的被动观察者（passive observer）——它从不修改你的仓库，从不 commit，从不 checkout，从不干扰 git。它只读：

git 历史（事实层）
AI Agent 的会话记录（意图层，自动发现 Codex 的 ~/.codex 和 Claude Code 的 ~/.claude/projects）

技术栈方面，brain0 的核心用 Rust 编写（14 个 crate），GUI 用 TypeScript + PixiJS，存储后端默认为 SQLite + sqlite-vec（向量数据库），使用体验非常轻量。

二、它能回答什么

brain0 专治以下五个 AI 代码管理中最棘手的问题：

① 哪条 prompt 引入了这个 bug？

重构了一天代码，回归测试挂了。git log 显示的是「Refactor user auth module」，但你真正想知道的是：哪次与 Agent 的对话、哪条 prompt 导致了这次改动？

brain0 把 commit 和意图（prompt）的关系显式建模，点击 commit 即可看到背后的原始对话摘要。

② 到底改了哪些、没改哪些？（Drift 检测）

Agent 说「我只是重构了用户模块」——但 git diff 显示它还改了数据库连接池的配置。这种「声明 vs 实际」的差距，brain0 用一个 drift 分数量化：

1
2
3

drift — declared vs done (41)
  · [1.00] claude-code — changed but not declared:
    crates/brain0-cli/src/main.rs, packages/gui/src/main.ts … +12 more

Drift 分数越接近 1.0，说明 Agent 实际改动和它「自述」的差距越大。

③ Agent 读取了哪些敏感文件？（DLP 审计）

Agent 在写代码过程中读了哪些文件？它是不是读到了 .env 里的密钥？brain0 会记录每一个读取事件，识别出密钥类型（绝不保留值本身），并生成一份敏感读取报告：

1
2
3

sensitive reads — DLP (7)
  · claude-code read crates/brain0-agentsrc/src/driver.rs [env_secret]
  · 8 read(s) outside the repo reached the model's context

④ 这次改动后来证明有问题吗？（风险学习）

brain0 构建了一个两阶段风险模型：先验风险（影响范围 + 膨胀系数 + 差异大小 + drift 分数）和后验风险（回滚记录、紧急修复记录）。如果一个改动「看起来安全、后来证明危险」，它被标记为 gold signal——值得学习的高价值案例。

⑤ 能直接让新 Agent 查询代码历史吗？（MCP 集成）

brain0 把自己暴露为一组 MCP 工具：

MCP 工具	Agent 能学到什么
`brain0_context`	文件/符号的风险、近期历史、背后的意图
`brain0_blame`	这一行是哪个意图写的：`file:line` → 符号
`brain0_debug`	根因分析候选，按时效和风险排序
`brain0_audit`	全仓风险分布、gold signals、最危险节点

在 Claude Code 中注册：

1	claude mcp add brain0 -- brain0 mcp

从此，你的 Agent 在改代码之前可以先问 brain0：「这个函数上次是谁改的？风险高不高？」——它再也不会重复破坏自己记不住的东西。

三、核心架构

brain0 的架构可以拆解为三个层次：

观察层（Rust Core）

这是 brain0 的大脑，负责：

git 读取器：解析 commit 历史，提取每一个 diff 和 commit message
文件监控器：实时感知文件变化（也支持无 git 环境的 checkpoint 模式）
会话摄入器：被动读取 Agent 留下的日志文件，提取每个 Decision Turn
Tree-sitter 解析器：AST 级的符号提取和跨机器身份识别（识别出同一个符号被重命名/移动）
声明 vs 实际协调器：对比 Agent 说了什么和实际改了啥
风险评分引擎：两阶段风险模型（先验 + 后验）

所有操作都是只读的，从不写回仓库。

存储层（可插拔后端）

brain0 用 Storage trait 抽象存储层：

组件	功能
轻型索引	SQLite + sqlite-vec（默认），存储图谱拓扑 + 向量嵌入
重型负载	加密后的 payload（diff、摘要、原始数据）
企业版	PostgreSQL + pgvector（商业版本）

默认是本地 SQLite，完全离线运行，零配置。

展示层（PixiJS GUI）

GUI 是一个二部图（bipartite graph），左边是文件/符号节点，右边是意图/Agent 节点，用边关联它们。支持：

LOD（Level of Detail）：缩放时从 repo → module → file → symbol 逐层深入
热力图：风险从绿到红着色
时间轴：拖动时间滑块查看历史状态
搜索栏：全文 + 语义搜索

四、快速上手

brain0 最令人印象深刻的是它的上手极简——只需一条命令：

1	npx brain0 up

在任何一个 git 仓库里执行后，它会：

自动从 git remote 推断 repo 身份
索引 git 历史（事实层）
被动摄入 Agent 的会话文件（如果找到了 Codex 或 Claude Code 的本地数据）
在 http://localhost:8787 打开交互式 GUI

日常使用命令：

命令	作用
`brain0 today`	今早巡检：Agent 做了什么，按风险排序
`brain0 report --md`	问责报告：drift、敏感读取、Top 风险
`brain0 query "为什么解析器崩了"`	基于图谱的根因分析
`brain0 mcp`	启动 MCP 查询通道供 Agent 调用
`brain0 rewind`	从 checkpoint 恢复工作树
`brain0 guard`	DLP 防护：标记已到达远程模型的密钥读取
`brain0 verify`	完整性校验（内容寻址）

硬件要求只有一个：Node.js >= 20。一切离线优先，本地 LLM（Ollama）是可选的增强，不是必需的。

五、技术深度解剖

5.1 秘密扫描（Secret Scanning）

brain0 最独特的设计之一是增量式秘密扫描。AI Agent 在写代码的过程中可能会读取到 .env、API 密钥、私钥等敏感信息。brain0 在写入阶段之前就执行扫描和脱敏：

扫描阶段：用 SecretScanner 识别出密钥类型（AWS key、GitHub token、private key 等）
脱敏阶段：把真实值替换为 [REDACTED:<kind>] 占位符
审计阶段：记录哪些文件被读取、哪些密钥类型被发现（但绝不记录值本身）
可选：BRAIN0_EXCLUDE 白名单、BRAIN0_REDACT 自定义规则

原始 prompt 文本不会被持久化——只有模型生成的摘要被保留。嵌入向量只基于已脱敏的文本计算。

5.2 本地优先，零出站

brain0 的默认配置是完全离线的：

没有 API Key → 用本地的确定性摘要 + 本地嵌入（qwen3:4b via Ollama）
没有网络请求 → 所有计算在本地完成
远程 LLM 需要在环境变量中显式 opt-in

即使你用上了远程 LLM：

发送出去的 prompt 已被脱敏（命名密钥被替换、高熵自由文本被清洗、绝对路径被剥离）
嵌入向量默认仍留在本地（除非显式设置 BRAIN0_EMBED_PROVIDER=openai）

5.3 数据安全架构

brain0 把数据分为四个层级：

层级	内容	保护措施
T0	检测到的密钥（key、token、私钥、`.env`）	绝不持久化明文，摄入时即脱敏
T1	Payload（决策摘要、commit 消息、diff）	可选的 ChaCha20-Poly1305 信封加密、可清除
T2	嵌入向量（可逆！）	和 payload 同等级保护，只对脱敏文本计算
T3	索引（元数据、引用、风险）	受保护、非公开、无原始内容

5.4 符号身份（Symbol Identity）

这是一个容易被忽略但工程含量很高的设计：如果代码中的一个函数被重命名或移动到另一个文件，传统的 git blame 或代码分析工具会把它当作「新的」实体。brain0 通过 Tree-sitter 解析 + 确定性指纹（基于内容而不是名字），能够追踪符号的跨文件、跨提交身份。

这意味着：即使你重构时把 getUserData 从 user.ts 移到 auth.ts 并改名为 fetchProfile，brain0 依然能认出这是同一个函数——它的风险历史、修改记录都跟着走。

5.5 open-core 模式

brain0 采用 open-core 商业模式：

开源免费（Apache-2.0）：单用户本地模式完全可用，没有任何「阉割」
商业付费（brain0-enterprise，AGPLv3）：PostgreSQL/pgvector 后端、多用户协作、SSO、跨 repo 审计、合规输出

存储层通过 Storage trait 抽象，开源版只实现 SQLite 后端，任何 PostgreSQL 后端都在商业版本中。brain0 从不依赖 brain0-enterprise——开源版是完整产品，商业版是增值扩展。

六、局限性与思考

客观地说，brain0 仍是非常早期的项目（发布仅 7 天），存在一些限制：

Agent 支持范围有限：目前只支持 Codex 和 Claude Code 的自动发现。Cursor、Windsurf、OpenHands 等工具还不支持，需要手动配置。不过项目的架构设计是开放的，未来可以扩展。
仅限 git 仓库：没有 git 的项目虽然可以用 checkpoint 模式（brain0 watch），但功能和流畅度不如 git 原生。
摘要质量依赖模型：如果用本地 Ollama（默认 qwen3:4b），摘要质量受限于小模型能力。切换到更强的远程模型（Anthropic/OpenAI）会显著提升，但也意味着数据需要出站。
C++ 符号分析暂缺：目前 Tree-sitter 支持 Rust、TypeScript、Python 等语言，C++ 的支持还不完善。对于全 C++ 项目，符号追踪功能受限。
GUI 只有本地访问：GUI 默认只监听 127.0.0.1:8787，没有提供远程访问或分享功能。团队协作需要等待企业版。
编辑器内 inline blame 暂缺：目前没有 VSCode 插件或 JetBrains 插件来直接在代码行内显示 brain0 的 blame 信息。需求是明确的，但 roadmap 上还是「planned」。