Sluke的夹生饭

欲生还熟

https://mindmux.ai/ & https://projectbrain.md/

我的 typecho 老友们，https://segmentfault.com/ 团队的又一次产品试验

过去两年，AI Coding Agent 的能力提升速度远远超过了很多人的预期。

Claude Code、Codex、Cursor、Gemini CLI 等工具已经能够理解大型代码库，自动修改代码、执行命令、完成复杂任务。

能力越来越强，却始终存在一个共同的问题：每次开启新的 Session，Agent 都像第一次加入项目。它需要重新理解架构，重新阅读 README，重新询问设计背景，重新学习团队约定。那些真正花费大量时间积累下来的经验、讨论过程和设计决策，随着聊天窗口的关闭一起消失。

越来越多的开发者开始意识到，项目缺少的不是更大的上下文窗口，而是一套能够长期沉淀项目知识的机制。MindMux 正是在这个背景下诞生的。

一、MindMux：项目的大脑，而不是聊天工具

MindMux 将自己的定位定义为 Project Brain。

聊天只是入口，项目知识才是真正需要长期保存的资产。

在传统的 AI 工具中，知识主要存在于三个地方：

位置保存内容持久性
Chat History对话过程较弱
README使用说明较强
AGENTS.mdAgent 工作规范较强

这三者之间存在明显的空白。

README 更关注项目如何使用；AGENTS.md 更关注 Agent 如何修改代码。而真正决定项目演进方向的内容——比如设计原因、架构取舍、技术决策、历史经验、已经验证失败的方案——并没有合适的位置保存。

MindMux 将这些知识统一放入一个新的对象：Project Brain。

整个项目围绕 Brain 建立统一的认知中心。

Discussion
      │
      ▼
Project Brain
      │
      ▼
Execution

讨论产生知识。知识指导执行。执行又不断更新知识。Brain 成为整个项目持续演化的核心。

二、BRAIN.md：从产品抽象出的开放协议

MindMux 并没有把 Brain 封装成私有格式。相反，团队将底层协议完全开放，并命名为 BRAIN.md。

BRAIN.md 可以理解为 Project Brain 的文件系统，推荐目录结构如下：

project/
├── README.md
├── AGENTS.md
├── BRAIN.md
└── brain/
    ├── background.md
    ├── architecture.md
    ├── roadmap.md
    ├── stack.md
    ├── flow.md
    ├── mindmap.md
    └── pages/
        ├── auth.md
        ├── db-choice.md
        ├── cache.md
        └── api-version.md

整个协议仍然采用 Markdown。所有内容都可以纳入 Git，无需数据库、无需云服务、无需专用 Runtime。任何 Agent 都能够直接读取。因此，BRAIN.md 更像是一种开放标准，而不是一种产品。

三、Project Brain 保存什么？

Brain 保存的不是代码，也不是聊天记录。它保存的是项目已经形成的共识。

例如：

  • 为什么选择 PostgreSQL
  • 为什么放弃 Redis
  • 为什么接口采用 Event Sourcing
  • 权限模型如何演化
  • 哪些方案已经验证失败
  • 当前架构有哪些技术债务

这些信息通常散落在会议记录、Issue、聊天工具、PR Review 中，随着时间推移很难再次完整恢复。Project Brain 将这些知识持续整理成为稳定的项目认知。

四、Compiled Truth：把讨论编译成知识

BRAIN.md 最有特点的设计，是每一个知识页面都包含两个部分。

第一部分是 Compiled Truth：它保存当前已经确认的事实。

例如：

Current Truth

使用 PostgreSQL。

主要原因：

……

参考：

……

Agent 以后读取这个页面，只需要关注当前有效结论，不用重新阅读数百条历史聊天。这相当于把讨论过程编译成为可以直接消费的知识。

五、Timeline：保存知识如何形成

只有最终结论并不足够。很多设计决策都会随着项目演进不断调整。因此，每一个知识页面还维护 Timeline。

例如：

2026-06-10
决定采用 PostgreSQL

2026-06-18
验证 Redis 不适合作为事务存储

2026-06-22
放弃 MongoDB

Timeline 采用追加模式，不会删除历史。任何人都可以理解当前结论如何形成。Brain 保存的不只是答案，也保存了决策路径。

MindMux 如何工作？

MindMux 将整个开发流程抽象成三个阶段。

Discuss
   │
   ▼
Distill
   │
   ▼
Dispatch

首先，与 AI 持续讨论。随后，将讨论内容提炼成为 Brain 中的知识页面。最后，再把已经形成共识的内容转换为 Task，交给 Claude Code、Codex 等 Agent 执行。

聊天成为知识输入，Brain 成为知识中心，Task 成为执行入口。整个过程形成完整闭环。

六、Brain 独立于 Runtime

这是 MindMux 非常重要的一点。今天项目可能使用 Claude Code，明天可能切换到 Codex，未来可能切换到新的 Agent。但 Brain 始终保持稳定。

Claude Code
        │
Codex
        │
Gemini CLI
        │
Cursor
        │
        ▼
Project Brain

知识不依赖任何模型，也不依赖任何厂商。Brain 成为整个项目真正长期存在的资产。

七、为什么采用 Markdown？

很多人第一反应会想到向量数据库、知识图谱或者 MCP。MindMux 没有选择这些方向，Brain 仍然坚持采用 Markdown。

原因很简单：Markdown 具有几个天然优势。

特性优势
Git 管理完整版本历史
可读人与 AI 都可以直接阅读
可编辑任意编辑器均可修改
可迁移不依赖厂商
可扩展易于建立知识网络

Brain 更像 Git 仓库中的源码，而 MCP、向量数据库、RAG 更像运行时能力。两者解决的是不同问题。

八、Brain 与传统文档最大的区别

传统文档记录信息，Brain 持续演化知识。传统 Wiki 更接近静态百科，Brain 更接近持续更新的认知系统。

文档Brain
静态内容持续更新
面向阅读面向推理
信息组织知识组织
人工维护AI 与人共同维护

AI 不再只是阅读文档，AI 同时参与文档演化。

九、对企业 AI 的启发

MindMux 面向软件开发，但它提出的思想却远远超出了 Coding Agent。企业同样存在类似的问题：业务知识散落在 ERP、CRM、数据库、会议纪要、聊天记录、流程系统以及大量 Agent 的执行日志中。真正有价值的并不是这些原始数据，而是经过持续提炼之后形成的业务知识。

如果将 MindMux 的思想推广到企业，可以得到一条更加完整的知识演化路径。

业务数据
   │
   ▼
业务讨论
   │
   ▼
Business Brain
   │
   ▼
Business Token
   │
   ▼
Enterprise Agent

Project Brain 可以理解为开发团队的长期认知，Business Brain 则对应企业长期积累的业务认知。两者关注的对象不同，核心思想却高度一致：持续提炼上下文，让知识能够被 Agent 长期消费，并随着业务持续演化。

写在最后

过去几年，行业一直关注模型能力、上下文长度和推理性能。MindMux 将关注点放到了另一个问题上：项目知识如何跨越 Session 持续存在。

BRAIN.md 用开放协议定义了 Project Brain，MindMux 则提供了完整的产品形态。两者共同表达了一个越来越清晰的趋势：未来 AI Agent 的竞争，不仅来自模型能力，也来自长期积累的上下文。模型负责推理，Brain 负责记忆。随着项目不断演进，真正形成壁垒的，将是持续沉淀、持续提炼、持续演化的 Project Brain。

我想:

知识的持久性不在于静态存储，而在于每次读取时被重新编译为共识的能力，长期记忆的本质是持续自我修正的解释路径，而非档案。

标签：agent

你的评论