我将 Git 变成了工程团队和多个 Claude Code 会话的共享上下文层

你好！我最近一直在研究编码代理的共享记忆。这是一个开源项目，仓库链接在回复中。 显而易见的构建方式是每个代理都与之通信的共享后端。数据库、同步服务、账户、权限，所有这些。但当我思考团队记忆真正需要什么时，我越来越觉得它听起来像 Git 已经做过的事情。你想要历史记录。你想要差异对比。你想要变更随仓库一起移动。你想要分支携带自己的状态。你想要冲突可见，而不是静默地相互覆盖。所以我尝试围绕 Git 构建共享记忆层。基本设置很简单。规范的项目记忆作为普通文件存在于仓库中。架构、决策、规格、工作流、交接、活动等，像代码一样提交。每个检出都维护自己的本地索引，用于搜索和代码智能。这些不会被共享。如果另一个工程师拉取仓库，他们需要针对自己的检出重建索引。所以大致模型是： 我觉得最有趣的部分是记忆现在与其描述的代码拥有相同的历史。如果有人更改了项目决策，你可以审查差异。如果两个人更改了同一部分共享上下文，Git 会暴露冲突。如果代理学到了一些有用的东西，它不会在一个聊天会话中消失。我还开始将相同的想法用于交接。代理可以在会话结束时准备一个结构化的交接，而不是用一个庞大的聊天摘要。交接包括已完成的工作、阻塞项、决策、更改的文件、下一步操作，以及它写入时的仓库状态。发送者提交它，下一个人拉取它，它就成为项目历史的一部分。我不希望的是代理静默地将它们写的内容变成共享真相。所以一些共享更改使用提案流程。代理可以准备本地草稿，但发布和接受规范是需要明确批准的单独操作。我一直称这个为 Git 原生团队记忆。它是我正在构建的开源项目 MEX 的一部分。目前还处于早期阶段，有明显的权衡。Git 不是实时消息总线，MEX 不会自动推送或拉取任何内容，两个断开连接的克隆仍然可以创建正常的 Git 冲突。但我开始认为项目记忆的行为应该更像源代码，而不是另一个 SaaS 数据库。我真诚地想听听其他人对编码代理之间共享记忆的思考方式，特别是如果你尝试过用 Git、数据库、MCP 或其他方式解决这个问题。