MEX：把团队记忆放进 Git 仓库的 TypeScript 工具

MEX 要接住的是没人写下来的那部分

README 开头描述了三种典型丢失：一个工程师知道某个约束为什么存在，另一个工程师手上有调试历史，某个编码 agent 在没人会读的会话里发现了边界情况。这三种东西的共同点是都没有进入代码库，下一任接手者只能重新推导。MEX 的做法是给它们一个持久位置：可读的 Markdown、与代码关联的解释、经过审核的知识贡献、结构化的交接记录。目标读者是团队里的工程师和他们的编码 agent，README 明确写了「Working solo? The next person using that memory can be you in a new session」，所以单人开发者也在射程内。它不解决代码本身的问题，解决的是代码旁边那层解释的归属问题。

仓库即数据库，Git 即同步层

README 的关键句是「Canonical memory travels with ordinary Git commit, push, and pull」。也就是说，权威记忆就是仓库里的文件，同步靠 commit、push、pull 这三个已有动作，没有单独的同步协议。每个成员保留自己的本地索引、草稿、身份选择和 Hub。README 明确列出不需要的东西：no hosted MEX service, Docker, proxy, MEX account, or MEX-owned model key。这个设计直接决定了协作的粒度。Alex 发布 Relay 时，写文件只发生在他自己的 checkout 里，README 说得很直白：「Publishing writes files to Alex's checkout; it does not notify Sam or deliver anything until they share through Git.」通知和送达是 Git 的职责，不是 MEX 的职责。凡是期待「发出去对方就收到」的用法，都会在这里撞墙。

Relay 传递的是解释，不是未提交的代码

README 里的交接例子是 Alex 改 webhook 重试逻辑，Sam 接着做。Alex 让 agent 先读现有架构、相关决策和代码证据，再改动、再跑测试；然后让 agent 更新 Wiki 解释和代码引用；对于需要团队审核的结论，准备一条 Inbox 知识提案等待明确批准。交接本身通过 `$mex-relay` 起草，包含改了什么、跑了哪些测试、还剩什么、下一步看哪里。Alex 在 Hub 里审阅草稿和发布预览，显式发布，再通过 Git 提交推送。Sam 拉分支、按需更新本地索引、打开 Hub、领取 Relay，然后让 agent 读取其中的上下文继续。有一处边界必须说清楚：Relay 携带的是解释和观察到的仓库状态，不是未提交的代码。把它当成代码传递机制会失望，它传的是「为什么」和「到哪了」。

Hub 是给人看的，CLI 和 MCP 是给 agent 用的

分工在 README 里写得很清楚：人在本地 Hub 里探索和审核，agent 通过项目指令和 CLI 检索并协助维护。Hub 的四个区域各有职责：Home、Search、Context、Code 把解释和实现证据放在一起，Context 图展示知识实体和它们之间的关系，选中一个实体能看到它直接关联的代码 grounding；Inbox 用来提出项目知识的增补和修正；Relays 保存下一个人需要的东西；Team/Members 负责归属和本地身份选择，Activity 显示已接受的 MEX 工作流事件。README 还提到既有的 Spec 提案和 Workstream 记录保持可读，这是兼容性说明，不是新功能。MCP 服务器那一栏的徽章写的是「MCP: source only」，README 的章节锚点也是 `#mcp-server`，意味着它不从发布包直接提供，要从源码跑。这一点在配置客户端之前必须先确认，否则会卡在第一步。

装上并跑起来需要哪些命令和配置

包名是 `mex-agent`，从 npm 安装。运行环境有硬要求：Node.js >= 22.5，TypeScript 5.9，这两个数字来自 package.json 徽章，低于这个版本不要尝试。README 里出现的可执行入口是 `$mex-relay`，用于起草交接记录。配置层面能确认的键不多，README 提到 0.8.1 带来 configurable agent logging，也就是说 agent 日志是可配置的，但材料里没有给出具体键名，这里不编造。README 还提到 0.8.1 的 Hub 可以在 Graph 构建期间继续响应请求，这是可用性上的改进，不是配置项。工作流本身没有隐藏步骤：装包、在仓库里初始化、让 agent 读上下文、在 Hub 里审阅、用 Git 提交推送。真正需要设置的往往是团队约定，比如谁有权批准 Inbox 提案。

它不会替团队做决定，也不会自动收集

最大的限制不是技术性的。MEX 的价值全部建立在「有人愿意写下来并且有人愿意审」之上。Inbox 的设计是提案加明确批准，Relay 的设计是草稿加发布预览，两处都要求人工介入。如果团队现在的习惯是决策只存在于 PR 评论和聊天记录里，装上 MEX 不会改变这一点，只会多出一层没人填的目录。第二个限制来自同步模型：因为共享依赖 Git，交接的及时性等于分支合并的及时性。长期不合并的分支上，Relay 对别人不可见。第三个限制是 MCP 只从源码运行，对只想装个包就接入现有客户端的用法不友好。第四个是版本节奏，从 0.7.3 到 0.8.1 大约两周一个版本，0.x 阶段的接口和文件格式仍可能调整，跨版本升级前值得先读 RELEASE_NOTES.md。

和 CLAUDE.md 或 .cursorrules 这类单文件约定的区别

常见的替代做法是在仓库根目录放一个给 agent 读的约定文件，比如 CLAUDE.md 或 .cursorrules，把项目规则写进去。两者的差别在结构而不在位置。单文件约定是一份扁平文本，所有内容平权，没有实体关系，没有代码 grounding，也没有审核流程，改它就是改它，谁改的、为什么改、对应哪段代码都留不下来。MEX 把知识拆成带关系的实体，Context 图能显示某个知识关联到哪些代码，Inbox 让修改变成需要批准的提案，Relay 让交接变成有生命周期的记录。代价是 MEX 需要安装、需要 CLI、需要一个本地 Hub 进程，而单文件约定只要一个文件。如果团队只有两三个人、规则不到一屏，单文件更划算；如果已经出现「这个约束是谁定的」这类问题反复被问，结构化才有回报。

许可证与升级成本

许可证是 MIT，仓库根目录有 LICENSE 文件，徽章链接指向 v0.8.1 的 LICENSE。MIT 允许商用和修改，附带常见的免责条款，具体条款以仓库里的 LICENSE 原文为准，这里不做法律解读。升级成本主要来自两方面。一是 Node.js 版本门槛，>=22.5 不是所有 CI 镜像的默认值，升级 MEX 之前先确认构建环境。二是 0.x 阶段的文件格式变动，因为权威记忆是仓库里的 Markdown，格式调整会直接落到你的提交历史里，产生需要人工处理的 diff。README 提到 0.7.3 的主题是 Graph performance and recovery，0.8.0 是 Project memory for the whole team，0.8.1 是 Explore context, share knowledge, keep work moving，从标题看 0.8.0 引入了面向团队记忆的较大变化。跨这种版本升级时，先读 RELEASE_NOTES.md 再动，比升级后修 diff 便宜。

编辑结论

MEX 适合已经用 Git 协作、并且愿意把「解释为什么」当作交付物一部分的工程团队：它的价值来自 Relay 和 Inbox 这类需要人工审核的产物，而不是自动抓取。不适合想找一个后台服务自动收集聊天记录、或者团队里没人愿意写决策说明的情况。上手前先确认三件事：Node.js 版本是否达到 package.json 里的 >=22.5，团队能否接受在每次交接时多一次 Hub 审核和一次 Git 提交，以及 MCP 服务器只从源码运行这一限制是否会挡住你现有的客户端配置。

官方来源

1. License: MIT
2. mex-memory/mex on GitHub
3. Project website
4. README
5. Releases