当 AI 智能体需要跨越多个上下文窗口工作时，外部记忆是让任务可接力的核心机制。但外部记忆远不止于此——它有没有标准的文件格式？除了用在 Harness Engineering 里，还有哪些更广泛的用途？本文系统梳理外部记忆的文件标准现状、腐烂与治理挑战，以及超越 Harness 的更广泛应用场景。

外部记忆的文件标准：现状与混沌

先说结论：目前没有一个被所有主流 AI 工具统一采纳的外部记忆文件标准，但已经出现了若干事实标准（de facto standards），并且正在快速收敛。

为什么标准化很难

外部记忆文件的标准化面临一个根本性的困难：不同的 AI 工具、不同的任务类型、不同的团队规模，对"需要记住什么"的答案是不同的。

一个用于代码生成的智能体需要记住架构约束、代码规范、依赖关系；一个用于客户服务的智能体需要记住用户偏好、历史交互、业务规则；一个用于科学研究的智能体需要记住实验假设、已验证的结论、待验证的方向。

这种多样性使得"一个文件格式统治所有场景"几乎不可能。

当前的事实标准

尽管如此，业界已经形成了几个被广泛认可的文件约定：

AGENTS.md / CLAUDE.md / CURSOR_RULES

这是目前最接近"标准"的外部记忆文件形式。

  • AGENTS.md：OpenAI Codex 和多个 AI 编码工具采用的约定，放在代码仓库根目录，描述"如何在这个仓库中工作"
  • CLAUDE.md：Anthropic Claude Code 的约定，功能类似，但支持 @import 语法引入其他文件，以及 /init 工作流
  • .cursorrules：Cursor IDE 的约定，作用相同

这三者的内容高度重叠，都是回答同一个问题："一个刚进入这个项目的 AI 智能体，需要知道什么才能有效工作？"

典型内容包括：

  • 项目概述和技术栈
  • 代码规范和命名约定
  • 架构原则和禁止事项
  • 如何运行、测试、部署
  • 关键文件的位置说明

这类文件的特征是稳定的背景知识——它们描述的是项目的"不变量"，而不是任务的进度状态。

进度日志文件（Progress Logs）

Anthropic 在其 Harness 方案中使用 claude-progress.txt，Codex 团队使用 docs/exec-plans/ 目录下的执行计划文件。这类文件记录的是动态的任务状态：

1
2
3
4
5
## 2025-11-15 会话记录
- 完成了用户认证模块（JWT + refresh token）
- 发现了一个 CORS 配置问题，已修复
- 下一步：实现消息列表的分页功能
- 已知问题：WebSocket 连接在移动端偶发断开，待排查

这类文件没有统一格式，但有一个共同原则：写给下一个智能体实例读，而不是写给人读。 因此它需要足够结构化，让智能体能快速定位关键信息。

功能清单文件（Feature Manifests）

Anthropic 推荐使用 JSON 格式的功能清单，而不是 Markdown。他们的工程师发现，模型更不容易"不恰当地修改或覆盖" JSON 文件——这是一个微妙但重要的工程细节。

这类文件的本质是可机器验证的任务状态：每个功能项都有明确的 passes: true/false 字段，智能体可以通过读取这个文件知道"还有什么没做"，而不需要依赖模糊的自然语言描述。

一个典型的功能清单条目如下：

1
2
3
4
5
6
7
8
9
10
{
  "category": "functional",
  "description": "新建对话按钮能创建一个新的会话",
  "steps": [
    "导航到主界面",
    "点击「新建对话」按钮",
    "验证新会话已创建"
  ],
  "passes": false
}

初始化智能体在第一次运行时生成完整的功能清单，所有功能初始标记为 passes: false。后续的编码智能体每次选择优先级最高的未完成功能进行实现，完成后将其标记为 passes: true。这种机制让任务进度变得可量化、可追踪、可验证。

版本控制历史（Git History）

Git 本身就是一种外部记忆。每次提交都是一个检查点，记录了"在这个时间点，代码处于什么状态"。Anthropic 明确要求编码智能体在每次会话结束时提交代码，并写清楚提交信息。

这样，下一个智能体实例可以通过 git log --oneline -20 快速了解最近发生了什么，而不需要阅读所有代码。Git 历史作为外部记忆的独特价值在于：它不仅记录了"当前状态是什么"，还记录了"如何一步步走到这里"——这种时间维度的信息对于理解设计决策和排查问题至关重要。

结构化知识库（Structured Knowledge Bases）

Codex 团队走得更远，他们建立了一个完整的 docs/ 目录结构：

1
2
3
4
5
6
7
8
9
10
11
12
13
docs/
├── design-docs/          # 设计文档，含验证状态
├── exec-plans/
│   ├── active/           # 活跃的执行计划
│   ├── completed/        # 已完成的计划
│   └── tech-debt-tracker.md
├── generated/
│   └── db-schema.md      # 自动生成的数据库模式文档
├── product-specs/        # 产品规格
├── references/           # 外部库的 llms.txt 格式文档
├── DESIGN.md
├── FRONTEND.md
└── QUALITY_SCORE.md      # 各模块的质量评分

这不是一个文件，而是一套文件系统。AGENTS.md 作为目录，指向这套知识库的各个部分。

llms.txt：一个新兴的网络标准

值得单独提出的是 llms.txt 这个新兴约定。它的设计思路是：为网站提供一个专门给 LLM 读取的简化版文档入口，类似于 robots.txt 之于搜索引擎爬虫。

Codex 团队在 docs/references/ 目录下存放了 nixpacks-llms.txt、uv-llms.txt 等文件，这些是他们使用的外部库的 LLM 友好版文档。这样，智能体在需要了解某个库的用法时，可以直接读取这些文件，而不需要去爬取官方文档网站。

llms.txt 目前还处于提案阶段，但已经有越来越多的开源项目和文档网站开始支持它。

外部记忆的腐烂与治理

外部记忆不是写好就万事大吉的——它本身也会腐烂。

OpenAI 的 Codex 团队在实践中总结了一个深刻的教训：他们最初尝试用一个大型的 AGENTS.md 文件来存储所有知识。结果发现了四个严重问题：

  • 上下文是稀缺资源：一个巨大的指令文件会挤占任务、代码和相关文档的空间
  • 过多的指导反而失效：当一切都"重要"时，一切都不重要了
  • 它会立即腐烂：随着代码库演进，文档跟不上，智能体开始基于过时信息做决策
  • 难以验证：单一的大文件无法进行机械化的覆盖率检查和新鲜度验证

他们的解决方案是：将 AGENTS.md 从百科全书变成目录。一份约 100 行的 AGENTS.md 作为地图，指向 docs/ 目录下结构化的知识库。专门的 linter 和 CI 作业验证知识库的更新状况，定期运行的"文档园丁"智能体扫描过时文档并发起修复 PR。

这个教训揭示了外部记忆工程化的核心挑战：外部记忆本身需要被设计、维护和治理。 它不是一次性的配置，而是一个需要持续投入的基础设施。就像代码需要测试来保证质量一样，外部记忆也需要自动化的验证机制来保证新鲜度和准确性。

标准化的方向

综合来看，外部记忆文件的标准化正在沿着两个维度演进：

维度一：按稳定性分层

层次 文件类型 更新频率 示例
静态背景知识 AGENTS.md, CLAUDE.md 很少变化 架构原则、代码规范
半静态知识 docs/design-docs/ 按需更新 设计决策、产品规格
动态任务状态 claude-progress.txt, exec-plans/active/ 每次会话更新 进度日志、当前任务
机器生成 docs/generated/, feature_list.json 自动维护 数据库模式、功能状态

维度二：按读者分层

  • 给智能体读的：结构化、精确、可机器验证（JSON、结构化 Markdown）
  • 给人读的：可读性强、有上下文（普通 Markdown、注释丰富的文档）
  • 两者兼顾的：AGENTS.md 这类文件，既要让智能体能快速定位信息，也要让人能维护它

语义时代的索引难题：从 B-tree 到语义钩子

前面讨论的所有标准化努力——无论是 AGENTS.md 的层级覆盖、docs/ 的结构化知识库，还是按稳定性和读者分层——本质上都在回答同一个问题：如何让智能体在正确的时间找到正确的知识？

这个问题，其实极其像我们当初设计数据库时面对的核心挑战。

一个深刻的类比：外部记忆 ≈ 数据库索引

数据库索引的设计哲学是：构建一个足够小、可以长期驻留在内存中的数据结构（如 B-tree），使得查询只需要对数复杂度就能定位到真正的、完整的数据页。 索引不存储全部数据，它只存储"钩子"——足够让查询引擎判断"下一步该往哪走"的最小信息。

Codex 团队将 AGENTS.md 从百科全书变成目录的做法，正是这个思路的直觉应用：AGENTS.md 是索引，docs/ 目录下的知识库是数据页。智能体先读索引，再按需加载具体知识。

学术界已经开始系统性地验证这个类比。2024 年的 MemTree 算法直接使用动态树状结构来组织 LLM 的记忆，优化检索和集成。2025 年的 H-MEM（Hierarchical Memory）架构通过多层记忆存储和位置索引实现高效长期推理。同年的 SHIMI（Semantic Hierarchical Memory Index）更进一步，将知识建模为动态结构化层次——这几乎就是语义版的 B-tree。

Anthropic 在其 Context Engineering 博客中也明确提出了类似的设计原则：

“Context engineering refers to the set of strategies for curating and maintaining the optimal set of tokens during LLM inference.”

他们推荐的 Just-in-Time Retrieval 策略——使用轻量级标识符（文件路径、存储查询、Web 链接）在运行时动态加载数据——本质上就是"先查索引，再加载数据页"的数据库思维。

工业实践中，3 层记忆架构已经被验证可以将 token 使用减少 35-45%，同时保持 87% 的语义召回准确率。这个数字背后的逻辑与数据库缓存层级（L1/L2/L3 cache）的设计哲学如出一辙：越热的数据离处理器越近，越冷的数据可以容忍更高的访问延迟。

但语义钩子 ≠ theta 连接

类比到此为止就遇到了根本性的困难。

在传统数据库中，索引的工作原理是 theta 连接（θ-join）：查询表达式 WHERE age > 25 与索引中的值之间存在精确的、可计算的匹配关系。B-tree 的每个内部节点都知道"大于这个值往右走，小于往左走"——这个判断是确定性的、无歧义的。

但在语义时代，智能体的"查询"不是 WHERE column = value，而是**“我现在正在实现一个分布式锁，需要了解这个项目中关于并发控制的约定”。这个查询与外部记忆中的知识之间，不存在精确的 theta 连接。它们之间的关系是语义相似性**——模糊的、概率性的、依赖上下文的。

这带来了两个被学术界和工业界越来越清晰地识别出来的核心难题：

难题一：我们不知道怎么设计知识的结构

在数据库中，数据的结构（schema）是预先定义好的。你知道有哪些表、哪些列、什么类型。索引的设计可以基于查询模式来优化——如果大部分查询按时间范围过滤，就在时间列上建索引。

但对于外部记忆中的工程知识，我们不知道最优的组织结构是什么。目前的主流做法是"总分总"式的层次化拆解——一个顶层目录文件指向若干子文档，每个子文档再细分。这种做法简单直觉，但它隐含了一个强假设：知识的语义关系是树状的。

现实中，知识的关系往往是图状的。一条关于"数据库连接池配置"的知识，可能同时与"性能优化"、“资源管理”、“部署配置”、"故障排查"四个主题相关。把它放在哪个分类下？无论放在哪里，从其他三个入口来的查询都可能找不到它。

2025 年发表在 NeurIPS 的 A-MEM 论文提出了一个突破性的思路：受 Zettelkasten（卡片盒笔记法）启发，不再用静态的层次结构组织记忆，而是用动态链接的原子化知识网络。每条记忆是一个独立的节点，通过语义关联动态链接到其他节点。更关键的是，A-MEM 支持记忆演化——当新记忆被整合时，它可以触发对历史记忆的上下文表征和属性的更新。这意味着知识结构不是一次性设计好的，而是随着使用不断自我重组的。

2026 年发表在 ICML 的 xMemory 论文走得更远。它明确指出了 RAG 范式在智能体记忆场景中的根本性不匹配：

“RAG targets large, heterogeneous corpora where retrieved passages are diverse, whereas agent memory is a bounded, coherent dialogue stream with highly correlated spans that are often duplicates.”

xMemory 提出了"解耦到聚合"（decoupling to aggregation）的方法论：先将记忆解耦为语义组件，组织成四层层次结构（原始消息 → Episode → Semantic → Theme），然后用"稀疏性-语义"目标函数动态指导记忆的拆分与合并。检索时采用自顶向下的策略，仅在能降低读者不确定性时才扩展到更细粒度的证据——这与数据库中"先查索引再加载数据页"的逻辑形成了精妙的呼应。

难题二：我们不知道模型需要什么知识

在数据库中，查询优化器可以通过分析查询日志来了解"用户通常怎么查"，然后据此优化索引。但对于 LLM 智能体，我们不知道模型在执行到足够深、足够复杂的场景时，它"看到"的世界是什么样的，它最需要的知识是什么，它会怎么搜索。

这不是一个工程问题，而是一个认知科学问题。模型的"意图"是在推理过程中动态涌现的，它自己可能都不知道下一步需要什么知识——直到它遇到了一个它无法解决的子问题。

Anthropic 在其 Context Engineering 文档中揭示了这个问题的一个具体表现——Context Rot（上下文腐烂）：

“As the number of tokens in the context window increases, the model’s ability to accurately recall information from that context decreases.”

这意味着，即使我们把所有可能相关的知识都塞进上下文窗口，模型也不一定能找到它需要的那条。更多的上下文不等于更好的检索——这与数据库中"全表扫描永远比索引查找慢"的道理完全一致。

xMemory 论文对这个问题给出了目前最系统的回应。它发现，传统的 top-k 相似性检索在智能体记忆场景中会"塌陷"——因为智能体的对话历史是高度相关的连贯流，相似性检索会反复返回冗余的、重复的内容，而真正需要的前置知识可能因为"不够相似"而被遗漏。它的解决方案是：检索应该超越相似性匹配，转而在潜在语义组件上操作。

2026 年的 Anatomy of Agentic Memory 综述论文则从更宏观的视角识别了这个问题的系统性根源：现有的评估基准存在饱和效应，评估指标与语义效用错位，性能高度依赖底层模型——换句话说，我们甚至还没有一个好的方法来衡量"模型是否找到了它需要的知识"。

前沿探索：超越简单索引的三条路径

面对这两个难题，学术界和工业界正在沿着三条路径探索：

路径一：从树到图——知识图谱增强的记忆

GraphRAG 的基准数据显示，在需要多跳推理的场景中，知识图谱的准确率比纯向量检索高出 3.4 倍。Mem0 和 Zep 等记忆服务已经开始将图结构与向量检索混合使用：向量检索负责"广度"（找到语义相关的内容），图遍历负责"深度"（沿着关系链找到间接相关但关键的知识）。

路径二：从被动检索到主动组装——Context Engineering

Anthropic 和 LangChain 都在推动从"被动检索"到"主动上下文工程"的范式转变。LangChain 将其总结为四大策略：Write（写入便签和跨会话记忆）、Select（向量检索 + 知识图谱 + 工具描述 RAG）、Compress（递归/分层摘要 + 上下文修剪）、Isolate（多智能体架构隔离上下文）。这不再是简单的"查索引-取数据"，而是一个完整的上下文生命周期管理系统。

路径三：从静态结构到动态演化——自组织记忆

A-MEM 和 xMemory 代表的方向是：让记忆结构本身成为一个可学习、可演化的系统。不再由人类预先设计知识的分类和层次，而是让智能体在使用过程中自主发现最优的组织方式。这类似于数据库领域中"自适应索引"（adaptive indexing）的思想——索引不是预先建好的，而是在查询过程中逐步构建和优化的。

一个未解的根本问题

尽管有这些进展，一个根本性的问题仍然悬而未决：语义空间中的"排序"是否可能？

B-tree 之所以能实现对数复杂度的查找，是因为它操作的值空间存在全序关系——任意两个值都可以比较大小。但在语义空间中，"分布式锁"和"数据库连接池"之间没有"大于"或"小于"的关系，只有"相似度 0.73"这样的模糊度量。

这意味着，我们可能永远无法在语义空间中构建出像 B-tree 那样优雅的对数复杂度索引。语义检索的本质可能更接近于高维空间中的近似最近邻搜索（ANN）——它可以很快，但永远不是精确的。

这或许就是外部记忆工程化的终极挑战：我们需要在一个本质上模糊的空间中，构建出足够可靠的知识路由系统。数据库索引的类比为我们提供了宝贵的设计直觉——分层、缓存、渐进式加载——但语义钩子的设计，需要我们发明全新的工程范式。

外部记忆的更广泛用途

Harness Engineering 是外部记忆最直接的应用场景，但它远不是唯一的场景。

用途一：多智能体协作的共享状态

当多个专业化智能体需要协同工作时，外部记忆是它们之间传递状态的唯一可靠方式。

想象一个软件开发流水线：

  • 需求分析智能体：将用户需求转化为结构化的功能规格，写入 product-specs/
  • 架构设计智能体：基于功能规格设计系统架构，写入 design-docs/
  • 编码智能体：基于架构文档实现功能，更新 feature_list.json
  • 测试智能体：验证功能实现，更新测试状态
  • 文档智能体：扫描过时文档，发起修复 PR

每个智能体都是独立的，它们通过共享的文件系统进行"通信"。外部记忆在这里扮演的角色类似于微服务架构中的消息队列——解耦、异步、持久化。

Codex 团队明确实践了这一点：他们的"文档园丁"智能体定期扫描知识库，发现过时文档并发起修复 PR；"质量评分"智能体定期更新各模块的质量等级。这些都是独立运行的专业化智能体，通过共享的文件系统协作。

用途二：跨会话的个性化与用户记忆

这是外部记忆在面向用户的 AI 产品中的核心应用。

当用户与 AI 助手进行多次对话时，AI 需要记住：

  • 用户的偏好和习惯（“我喜欢简洁的代码，不喜欢过度注释”）
  • 用户的背景知识（“我是 Java 开发者，不熟悉 Rust”）
  • 历史决策（“上次我们决定用 PostgreSQL 而不是 MongoDB”）
  • 进行中的项目状态（“我们正在重构认证模块”）

这类记忆如果只存在于单次对话的上下文中，每次新对话都要重新建立，用户体验极差。通过外部记忆文件（或数据库），AI 可以在每次新对话开始时加载用户的历史上下文，实现真正的"记得你"。

目前 Mem0、Zep 等专门的 AI 记忆服务正在这个方向快速发展，它们提供的本质上是结构化的外部记忆存储和检索服务。

用途三：知识库管理与 RAG 的进化

传统的 RAG（检索增强生成）是一种被动的外部记忆：用户提问 → 检索相关文档 → 注入上下文 → 生成回答。

但随着智能体能力的增强，外部记忆正在从"被动检索"进化为"主动维护"：

  • 智能体可以写入记忆：当智能体发现新的重要信息时，它可以主动将其写入外部记忆，供未来使用
  • 智能体可以整理记忆：定期运行的"记忆整理"智能体可以合并重复信息、删除过时内容、建立索引
  • 记忆可以有结构：不再是扁平的文档列表，而是有层次、有关联的知识图谱

这种进化使得 AI 系统能够随着使用时间的增长而变得越来越"懂"用户和领域，而不是每次都从零开始。

用途四：智能体行为的约束与治理

外部记忆不只是存储"做了什么"，还可以存储"应该怎么做"和"不应该做什么"。

Codex 团队将他们称为"黄金原则"的内容直接编码到代码仓库中：

  1. 我们更倾向于使用共享的实用程序包，而不是手工编写的辅助工具
  2. 我们不会使用"YOLO 式"探测数据——我们会验证边界，或依赖类型化的 SDK

这些原则通过自定义 linter 和 CI 作业机械地强制执行。当智能体生成的代码违反这些原则时，CI 会失败，智能体会收到带有修复指令的错误信息。

这是外部记忆的一个重要用途：将人类的品味和判断编码为可执行的约束，使其能够持续、一致地应用于所有智能体生成的内容。

用途五：科学研究与长期项目的知识积累

在科学研究场景中，外部记忆的价值尤为突出。一个研究项目可能持续数月甚至数年，涉及大量的实验、假设、验证和推翻。

外部记忆可以记录：

  • 已验证的假设和实验结论
  • 已尝试但失败的方向（避免重复踩坑）
  • 当前的研究进展和下一步计划
  • 相关文献的摘要和关键引用

Anthropic 在其 Harness 工程博客中提到，他们相信这些经验"可以应用到科学研究或金融建模等领域所需的长期智能体任务类型"。

外部记忆的四层架构

综合以上分析，我们可以将智能体的记忆系统分为四个层次：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
┌─────────────────────────────────────────────────────┐
│  第四层：长期外部记忆（External Long-term Memory）      │
│  文件系统、数据库、向量存储                              │
│  跨会话持久化，可被所有智能体实例访问                     │
├─────────────────────────────────────────────────────┤
│  第三层：会话外部记忆（Session External Memory）        │
│  进度日志、功能清单、Git 历史                            │
│  在单次任务的多个会话之间持久化                           │
├─────────────────────────────────────────────────────┤
│  第二层：上下文内记忆（In-context Memory）              │
│  当前会话的对话历史、工具调用结果                         │
│  会话结束即消失（Compaction 可延长但不能无限延长）         │
├─────────────────────────────────────────────────────┤
│  第一层：参数化记忆（Parametric Memory）                │
│  模型训练时学到的知识                                   │
│  固定不变，无法在运行时更新                              │
└─────────────────────────────────────────────────────┘

Harness Engineering 主要解决的是第三层的问题：如何在单次长任务的多个会话之间传递状态。

但外部记忆的价值远不止于此——第四层的长期记忆是实现真正"有记忆的 AI"的关键，它使 AI 系统能够随时间积累知识、学习用户偏好、建立领域专长。

一个值得关注的趋势：记忆即代码

Codex 团队提出了一个深刻的洞察：

从智能体的角度来看，它在运行时无法在情境中访问的任何内容都是不存在的。存储在 Google Docs、聊天记录或人们头脑中的知识都无法被系统访问。代码仓库本地的、已版本化的工件就是它所能看到的全部。

这意味着，将知识写入外部记忆文件，本质上是在为智能体"立法"。你写下的每一条规则、每一个约束、每一份设计文档，都会成为智能体行为的一部分。

这与软件工程中"基础设施即代码"（Infrastructure as Code）的理念高度相似：与其依赖口头约定和隐性知识，不如将一切显式化、版本化、可审计。

随着智能体在软件开发中扮演越来越重要的角色，“记忆即代码”（Memory as Code） 可能会成为下一个重要的工程范式：

  • 外部记忆文件和代码一起被版本控制
  • 外部记忆的质量和新鲜度被 CI 自动验证
  • 外部记忆的更新由专门的"记忆维护"智能体负责
  • 人类的品味和判断通过外部记忆持续注入系统

小结

问题 答案
外部记忆有统一的文件标准吗？ 没有统一标准，但有若干事实标准：AGENTS.md/CLAUDE.md 用于背景知识，进度日志用于任务状态，JSON 功能清单用于可验证的任务追踪
外部记忆只用于 Harness Engineering 吗？ 不，它还用于多智能体协作、跨会话个性化、知识库管理、行为约束与治理、长期项目知识积累
外部记忆的发展趋势是什么？ "记忆即代码"：外部记忆正在从临时性的进度日志，演进为版本化、可验证、自动维护的知识基础设施

外部记忆是智能体从"工具"进化为"同事"的关键基础设施。它解决的不只是"任务怎么接力"的问题，而是"AI 系统如何随时间积累智慧"的根本问题。

参考资料