上一篇文章讨论了 Harness Engineering 的本质——它依赖外部记忆让任务执行可接力。本文继续深入：外部记忆有没有标准的文件格式？它除了用在 Harness Engineering 里，还有哪些更广泛的用途？

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

先说结论：目前没有一个被所有主流 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/ 目录下的执行计划文件。这类文件记录的是动态的任务状态：

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

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

功能清单文件（Feature Manifests）

Anthropic 推荐使用 JSON 格式的功能清单，而不是 Markdown。原因前文已提到：模型更不容易"不恰当地修改" JSON 文件。

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

结构化知识库（Structured Knowledge Bases）

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

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 目前还处于提案阶段，但已经有越来越多的开源项目和文档网站开始支持它。

标准化的方向

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

维度一：按稳定性分层

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

维度二：按读者分层

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

外部记忆的更广泛用途

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 团队将他们称为"黄金原则"的内容直接编码到代码仓库中：

我们更倾向于使用共享的实用程序包，而不是手工编写的辅助工具

我们不会使用"YOLO 式"探测数据——我们会验证边界，或依赖类型化的 SDK

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

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

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

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

外部记忆可以记录：

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

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

外部记忆的四层架构

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

┌─────────────────────────────────────────────────────┐
│  第四层：长期外部记忆（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 吗？	不，它还用于多智能体协作、跨会话个性化、知识库管理、行为约束与治理、长期项目知识积累
外部记忆的发展趋势是什么？	"记忆即代码"：外部记忆正在从临时性的进度日志，演进为版本化、可验证、自动维护的知识基础设施