把 Coding Agent 当作长期协作者而非一次性脚本,这件事在 2026 年的工程社区里已经被反复证明是必要的。一个严肃的 Coding Agent 不仅要能在单次会话里完成代码改动,还要能在下一次会话里记得上一次写到一半的模块、用户对命名风格的偏好、某个已知但暂时不修复的 tech debt,以及项目里反复出现的几条工程规约。这些「需要被记住」的内容如果只活在 LLM 的上下文窗口里,会话结束就消失,Agent 永远只能「从零开始」——这种状态下 Agent 不是协作者,而是一次性工具。 在 MCP 协议出现之后,「Coding Agent 的持久内存」开始从各家框架的私有方案逐步收敛到一类标准服务:MCP Memory 服务器。Anthropic 在 2024-11-25 的官方博客《Introducing the Model Context Protocol》里给出了协议层的底座:Today, we're open-sourcing the Model Context Protocol (MCP), a new standard for connecting AI assistants to the systems where data lives, including content repositories, business tools, and development environments. Its aim is to help frontier models produce better, more relevant responses. 把 MCP 应用到 Coding Agent 持久内存这一具体场景,就意味着 Memory 服务器通过 MCP 暴露 Tools / Resources / Prompts 三类原语,Agent 客户端(Claude Code、Cursor、Continue、Cline 等)以统一协议接入。这是过去一年里整个 MCP Memory 生态得以快速繁殖的协议基础。 在所有 MCP Memory 服务器里,有一类项目特别值得关注:它们选择把 Git 作为持久化的底层基础设施,而不是传统的 SQLite + FTS5 / Postgres + tsvector / 向量数据库。Glama 在 2026-09 收录的 docmancer 自描述里直接给出这种范式的官方表述:Local-first memory for coding agents. Discovers the memory, instructions, and rules Claude Code, Codex, and Cursor already wrote on your machine, combines them into one canonical Markdown tree, and serves grounded, cited recall through tools like ask_memory and canonical_memory.——它不做数据库,而是扫本地 Git 仓库里的 Markdown 文件,合并成一个权威版本,通过 MCP 对外提供有引用出处的检索。这种「Git 原生 + Markdown 树」的选择,正是 OKF Agent Memory 这类近期项目的工程方向。 Git 作为 Coding Agent 持久内存的底层,至少有四条不可替代的工程优势。第一条是「版本化」:每一次 Agent 写入记忆,天然就是一个 git commit,作者、时间戳、diff 一应俱全,任何一次记忆污染都可以被 git revert 回滚到上一个健康状态;这与传统数据库的「写完就覆盖」是完全不同的语义。第二条是「可审计」:记忆的全部历史都在 .git 目录里,审计、合规、复盘都可以直接走 git log,而不必专门再搭一套审计系统。第三条是「分布式」:同一份 Agent 记忆可以通过 Git 远程仓库在多台机器之间同步,团队成员之间也能共享,这是任何单一 SQLite 文件或 Postgres 实例都做不到的天然分布式语义。第四条是「跨客户端兼容」:Git 是 Coding Agent 生态里事实上的「通用货币」,Claude Code 的 .claude/、Codex 的 .codex/、Cursor 的 .cursor/ 都是 Markdown 文件,天然可以走 Git 同步。 把 Git 原生方案放进 MCP 协议的坐标里看,它解决了传统记忆方案最难回答的三个问题。第一个问题是「记忆之间打架」:Claude Code 在 A 笔记本上记了一句话,Cursor 在 B 笔记本上记了同一件事的另一句话,Codex 在 C 服务器上记了同一个项目的又一条偏好——这三份记忆怎么合并?Git 原生方案走「canonical Markdown tree」抽象,docmancer 给出的官方表述是 combines them into one canonical Markdown tree and serves grounded, cited recall,本质上是把多客户端的多源记忆按 Git 树结构合并,每一条记忆都保留来源引用,Agent 检索时既能拿到合并后的视图,也能下钻到具体来源。第二个问题是「记忆污染如何回滚」:Agent 在某次会话里写错了一条记忆,后续 Agent 反复读到这条错误信息导致连锁判断错误——Git 原生方案直接 git revert 即可。第三个问题是「记忆如何审计」:任何外部审计要求看 Agent 究竟基于哪些信息做判断,Git 原生方案直接走 git log + diff,审计链条天然完整。 Anthropic 在 2024-12-19 发布的《Building effective agents》里给出的工程方法论,与 Git 原生方案高度契合:Over the past year, we've worked with dozens of teams building large language model (LLM) agents across industries. Consistently, the most successful implementations weren't using complex frameworks or specialized libraries. Instead, they were building with simple, composable patterns.——Git + Markdown + MCP 是这套方法论在持久内存场景下的天然实现:Git 提供版本化的简单原语,Markdown 提供人类可读的可组合表达,MCP 提供 Agent 可调用的协议接口。三者叠加,既不需要专用框架,也不需要专用数据库,就能给 Coding Agent 装一层稳定可靠的持久化层。 理解 Git 原生 MCP Memory 的工程新样本,关键在于它把「本地优先」「跨客户端一致」「可审计」这三件事用 Git 一个工具同时解决。本地优先:Git 仓库在本地文件系统,所有记忆读写都发生在本地,不需要云端服务、不依赖特定 SaaS、不上传任何数据;这与 docmancer 自我描述里的 Local-first memory for coding agents 完全一致,也与 Anthropic 在 MCP 协议层给出的「数据留在它原本在的地方」的设计初衷一致。跨客户端一致:同一份 Git 仓库可以被 Claude Code、Cursor、Continue 等多个 Agent 客户端并行访问,所有客户端通过 MCP 协议从同一个 Git 仓库读写记忆,从根本上避免了「每个客户端各自存一份」的碎片化问题。可审计:任何一次 Agent 决策背后引用的记忆条目,都可以从 Agent 输出回溯到具体的 Markdown 文件、具体的 commit、具体的作者。 把视线从工程方案拉到企业级落地。一个严肃的企业 Coding Agent 持久内存项目,在落地时通常会走四步流程。第一步是「仓库规划」:在企业内部建立一个中心化的 Git 仓库(可以是 GitHub Enterprise、GitLab Self-Hosted 或本地 Gitea),所有 Coding Agent 的记忆文件都提交到这个仓库;记忆按项目、按团队、按职能分目录组织,例如 memory/projects//、memory/teams//、memory/rules/。第二步是「客户端适配」:为 Claude Code、Cursor、Continue、Cline 等每种 Agent 客户端编写一个适配层,把它默认的本地记忆目录软链接或同步到中心 Git 仓库;这一层在工程上通常是 200-500 行代码的胶水。第三步是「MCP 服务暴露」:在每个开发者的本地机器上跑一个 MCP Memory 服务器,这个服务器负责从中心 Git 仓库 pull 最新记忆、向 Agent 客户端暴露 MCP Tools(ask_memory / write_memory / canonical_memory);这一层是 Git 原生方案的关键胶水。第四步是「审计与治理」:对中心 Git 仓库设置合适的权限——开发者可以读写自己项目下的记忆,但只读其他项目;敏感记忆(API Key、数据库连接字符串)由专门的安全扫描在 commit 阶段拦截。这一套走完,企业就拥有了一个「Coding Agent 持久内存」基础设施。 Git 原生方案在当下还有几个工程新样本值得展开。第一个新样本是「智能合并」:多客户端同时写同一段记忆时,Git 的文本合并算法在 Markdown 这种自然语言格式上表现很差,docmancer 这类项目需要额外提供一种「语义级合并」——把多份 Markdown 解析成结构化条目,按条目做 union / dedup / conflict 标记。第二个新样本是「分级记忆」:Git 原生方案天然适合分层——按生命周期分长期记忆(项目规约、命名风格)与短期记忆(某个未完成的改动),按可见性分公开记忆(团队共享)与个人记忆(仅本机),按内容分客观记忆(事实)与主观记忆(偏好);这些分层都可以直接用 Git 目录结构与 .gitignore 实现。第三个新样本是「记忆条目引用」:docmancer 给出的 serves grounded, cited recall 表述,意味着每次 Agent 引用记忆都应该附带来源出处,这是 Git 原生方案相对向量数据库的天然优势——向量检索只能给相似度,Git 原生方案可以给文件路径、行号、commit hash 这些工程级别的精确引用。 Git 原生方案在企业落地中也有几条工程约束必须正视。第一条是「性能上限」:Git 在小到中等规模(单仓库 < 100MB Markdown, < 10 万次 commit)表现良好,一旦超过这个规模,git clone / git pull 的延迟会显著上升;大规模场景需要拆分成多个仓库或引入 Git LFS。第二条是「冲突处理」:Git 在结构化数据上表现很好,但在自然语言 Markdown 上语义级冲突经常需要人工介入;企业需要约定一套「记忆冲突处理 SOP」(谁拥有最终决策权、是否合并到主干、如何标注冲突来源)。第三条是「敏感信息隔离」:记忆里经常会包含敏感信息(API Key、内部域名、未公开的产品名称),企业必须把中心 Git 仓库的权限模型做严密,任何记忆写入都需要过一遍敏感信息扫描——这条 Anthropic 在 containment 报告里反复强调的 defense-in-depth 思路同样适用。 把视线从工程细节拉回到 Coding Agent 工程的整体趋势。2026 年的 Coding Agent 持久内存讨论里,有一个反复出现但很少被明说的判断:Git + Markdown + MCP 三件套,是当下最具可持续性的 Coding Agent 持久化方案。它不依赖某个具体云服务、不锁定某个特定模型、不绑定某个特定框架,任何一个严肃的 Coding Agent 项目都可以基于这套组合在数小时内部署完成。这与 Anthropic 在《Building effective agents》里给出的 simple, composable patterns 思路一脉相承——越是基础的工程原语,越是能跨厂商、跨模型、跨客户端稳定复用。下一阶段的 Coding Agent 工程,大概率会沿着「Git 原生 + Markdown 树 + MCP 协议」这条路径继续收敛,把 Coding Agent 从一次性脚本变成长期协作者的工程基础也会越来越扎实。