# AI Agent 的记忆护城河，可能不是模型，而是一堆 Markdown

> 本文整理自 The New Stack 文章《Andrej Karpathy, Google and Garry Tan agree Markdown is the answer, but they're not solving the same problem》。原文链接：https://thenewstack.io/markdown-agent-memory-moat/

过去一年，AI Agent 的讨论大多围绕模型能力：哪家模型更强、上下文窗口多大、工具调用是否稳定、代码能力是否领先。

但这篇文章提出了一个更容易被低估的变化：真正长期沉淀价值的，可能不是某一个模型，而是团队持续积累、可版本控制、可迁移的一组 Markdown 文件。

换句话说，AI Agent 的“记忆护城河”，正在从模型供应商那里，转移到使用者自己维护的知识库里。

## 三个看似不同的案例，都指向 Markdown

文章提到三个例子：Andrej Karpathy、Google 和 Garry Tan。他们解决的问题不同，但最后都落到了同一个基础设施上：Markdown。

**第一，Karpathy 的 LLM Wiki。**

Karpathy 曾提出一个设想：用 LLM 维护互相链接的 Markdown 文件，形成个人知识库。传统个人 wiki 的难点是维护成本太高，交叉引用、补充上下文、整理结构都很烦。但对 LLM 来说，这些重复性维护工作并不构成心理负担，甚至可以一次处理多个文件。

这对应的是个人知识管理问题：如何让 AI 帮人长期整理和维护知识。

**第二，Google 的 Open Knowledge Format。**

Google 推出的 OKF v0.1，则面向组织知识。它试图用纯 Markdown 打包指标、表格、运行手册、架构说明等内容，让 Agent 能够读取企业上下文。

它的关键点不是“又一个知识库产品”，而是尽量避免绑定专有账户或专有平台。只要这些知识以 Markdown 形式存在，就可以被不同的 Agent、云平台和框架读取。

这对应的是企业知识流动问题：如何让组织知识不被锁死在某个系统里。

**第三，Garry Tan 的 gstack。**

Y Combinator 总裁 Garry Tan 推出的 gstack，则更像是工程团队模拟器。它包含 23 个专门角色的 Markdown 文件，没有复杂运行时，也没有特殊代码，却可以在多个编码 Agent 中运行。

文章提到，gstack 在 GitHub 上快速获得大量关注。它的意义不只是“一个热门仓库”，而是说明一组文本角色、规范和上下文，已经足以成为 Agent 协作的核心资产。

这对应的是工程协作问题：如何让不同 Agent 共享同一套工作方式和项目知识。

## 为什么偏偏是 Markdown？

Markdown 并不高级。它没有数据库事务，没有复杂权限模型，也没有知识图谱那样的关系结构。

但它有几个非常现实的优势：

- 人能直接读，Agent 也能直接读；
- 可以用 Git 做版本控制、审查、回滚；
- 可以被任何编辑器、脚本、CLI 工具处理；
- 不依赖特定云服务或账号体系；
- 迁移成本低，换模型、换工具、换平台时仍然可用。

这也是文章最值得注意的判断：Markdown 的胜出不一定来自技术先进性，而来自足够低的摩擦。

对 Agent 来说，能被稳定读取、稳定更新、稳定携带的上下文，比格式本身是否“高级”更重要。

## 模型会换，但上下文资产会留下

今天用 Claude Code，明天可能换 Codex、Gemini、GLM 或其他本地模型。如果一个工作流的关键能力全都藏在模型自身的记忆或一次性提示词里，那么换模型时很容易归零。

但如果项目规则、工程约定、架构决策、运行手册、评审标准都沉淀在 Markdown 文件中，模型只是消费这些上下文的执行层，那么底层模型就更容易替换。

这也是“护城河”这个说法成立的地方：

真正有价值的不是某次对话里的聪明回答，而是长期积累下来的上下文资产。

这些资产包括：

- 项目级 `CLAUDE.md` / `AGENTS.md`；
- 架构决策记录；
- 运行手册和故障处理流程；
- 团队编码规范；
- 业务术语解释；
- 常见任务的检查清单；
- 对过去错误和经验的复盘。

当这些内容被持续维护，Agent 才不只是“临时聊天助手”，而更像能继承团队经验的工作系统。

## 但不要把 Markdown 神化

需要注意的是，文章并不是证明“Markdown 能解决所有记忆问题”。

Markdown 适合沉淀稳定知识：规则、结构、背景、手册、决策、流程。它不一定适合处理所有高频变化的数据，也不擅长复杂查询、权限控制、实时状态和大规模关系推理。

所以更合理的理解是：Markdown 是 Agent 记忆系统的基础层，而不是全部。

在真实系统里，可能还需要搭配：

- 数据库保存结构化状态；
- 全文检索或向量检索做召回；
- 知识图谱表达实体关系；
- 权限系统控制敏感信息；
- 自动校验防止过期知识污染上下文。

但即便如此，Markdown 仍然适合作为第一层，因为它简单、透明、容易被人审查。

## 对 AI 工作流的提醒

这篇文章对个人开发者和团队最大的提醒是：不要只追逐模型更新，也要建设自己的上下文资产。

如果每次换工具都要重新解释项目背景、重新说明偏好、重新描述流程，那说明知识还没有从对话里沉淀出来。

一个更稳的做法是：

- 把稳定规则写进项目文档；
- 把重复流程写成 checklist；
- 把关键决策写成 ADR；
- 把常见错误写进 runbook；
- 把 Agent 需要遵守的边界写成可版本控制的 Markdown；
- 定期清理过期上下文，避免旧信息误导 Agent。

这样做的价值，不是让文档变多，而是让 AI 每次进入项目时都能站在已有上下文上继续工作。

## 结语

AI Agent 的竞争表面上是模型竞争，深一层是上下文竞争。

模型负责推理和生成，但它能不能稳定完成任务，很大程度取决于它拿到的上下文是否准确、完整、可维护。

Markdown 的意义就在这里：它不是最复杂的知识系统，却可能是最容易开始、最容易迁移、最容易被人和 Agent 同时维护的共同语言。

未来真正有壁垒的，可能不是“我用了哪个模型”，而是“我积累了多少可迁移、可审查、可复用的上下文资产”。