实例讲解什么是上下文治理

Tue, 19 May 2026 00:00:00 +0000

上下文治理（Context Governance）是上下文工程（Context Engineering）中的一个部分。但我觉得，上下文治理是上下文工程里最有意思的部分。

光这么说，你肯定会像我一开始一样，觉得这个概念很抽象。但是，如果你跟我一样，了解了几种主流智能体（Agent）的上下文治理之后，你一定会对"上下文治理"有一个非常直观的理解。

接下来，我会通过比较 4 种智能体的上下文治理方式，让你直观地理解什么是上下文治理。以下四种工具的上下文治理，从简单到复杂、从低级到高级。

Codex

首先是 OpenAI 的 Codex。虽然 OpenAI 是第一个做出 LLM 的公司，但是它们的智能体产品反而最年轻。

虽然它最年轻，但它的上下文治理也是最简单的。在 .codex/ 目录下，有一个叫 AGENTS.md 的文件。这是一个简单的 AGENTS.md 文件示例：

# 仓库规范

## 项目结构
- `src/` 存放应用代码
- `tests/` 存放测试代码

## 常用命令
- 运行测试：`npm test`
- 运行代码检查：`npm run lint`

## 编码规范
- 优先使用 TypeScript
- 避免使用 default export（默认导出）
- 使用 async/await，而不是直接使用原始 Promise

Codex 在开始工作之前，会先读取这个文件的内容。这个文件需要你手动维护，不断往里面添加规则。

除了这个文件以外，还有一个文件夹：~/.codex/memories/ 顾名思义，就是"记忆"。Codex 会自动往里面写文件。

大概的结构如下：

类型	可能内容
summaries	session 摘要
durable	长期稳定记忆
recent	最近上下文
evidence	来源证据

可以看到，Codex 的上下文治理其实非常轻量。

它本质上还是：

一个规则文件
一个自动记忆目录

仅此而已。

Claude Code

Claude Code 的上下文治理很特别。

官方支持的其实跟 Codex 差不多：

CLAUDE.md
~/.claude/projects/<project>/memory/

就这两个东西。你一看名字基本就懂了。但是，Claude Code 的社区自己增强了它的上下文治理，逐渐演化成了这样：

名字	类型	作用	人工/自动
`CLAUDE.md`	文件	项目规则、Agent 行为规则	人工
`MEMORY.md`	文件	长期记忆、长期偏好、长期经验	半自动
`NOTES.md`	文件	临时工作笔记、scratchpad	人工
`DECISIONS.md`	文件	关键架构/技术决策历史	人工
`ARCHITECTURE.md`	文件	系统结构、模块关系、数据流	人工
`LEARNINGS.md`	文件	踩坑经验、经验总结	半自动
`TASKS.md`	文件	当前任务列表、待办事项	人工
`SESSION.md`	文件	当前 session 工作记录	半自动
`docs/`	文件夹	长文档上下文来源	人工
`memory/`	文件夹	memory 分类存储	半自动
`prompts/`	文件夹	prompt 模板、workflow prompt	人工
`.cursorrules`	文件	Cursor 兼容规则	人工

这下就比 Codex 复杂很多了。但是你会发现，这里面有大量文件都需要人工维护。而且整个结构特别像我们以前做项目时写的 Wiki 文档结构。

其实，为了让 Agent 更好地工作，它也应该像我们一样，先看看项目 Wiki。人们现在只是把 Wiki 文档，变成了上下文 Markdown 文件而已。这样理解就很容易了。Claude Code 在这些上下文文档的基础上，工作的方式越来越像一个真正的程序员。

Open Claw

Open Claw 的定位跟 Claude Code 不太一样。它更偏向生活助手。而且 Claude Code 社区版的上下文治理，需要管理的文件太多了。不同于 Claude Code，Open Claw 的用户更多是普通人。很多用户其实并不会直接编辑 Open Claw 的上下文文件，甚至都不知道这些文件需要人工维护。

但是，Open Claw 的上下文设计其实比 Claude Code 社区版更"Agent 化"。因为 Claude Code 社区版的上下文结构，还是带有很强的人类项目管理思维。但在 Agent 面前，其实并不一定需要拆成那么多文档。

Open Claw 的上下文治理更偏向"角色"和"人格"。它有这些上下文文件：

核心指令层（静态，你手动维护）

SOUL.md — 人格、价值观、边界。回答"你是谁"。定义语气、性格、不可违反的约束。
AGENTS.md — 操作流程和规则。回答"你做什么、怎么做"。最大也最重要的文件，放复杂工作流和步骤化指令。
USER.md — 用户信息。你的名字、时区、偏好、工作背景。相当于个性化层。
IDENTITY.md — 结构化身份档案（名称、角色、目标、语气）。用于一致性地重新应用已知身份。（其实我觉得这个有点多余。）
TOOLS.md — 工具文档。不控制权限（权限是 config 管的），而是告诉 Agent 如何使用已有工具。

自动化层

HEARTBEAT.md — 定时任务，相当于用自然语言写的 cron。比如"每 30 分钟检查一次"“每周一 8 点生成报告”。
BOOTSTRAP.md — 首次运行的初始化脚本。setup 完成后会自动删除。
BOOT.md — 每次启动时执行的 hook。

记忆层

MEMORY.md — 长期记忆。持久化的事实、偏好、决策摘要，跨周跨月生效。
memory/YYYY-MM-DD.md — 每日笔记。当天和昨天的笔记自动加载，更早的内容通过 memory_search 检索。
DREAMS.md — dreaming 系统的日记，记录从短期记忆向长期记忆的"晋升过程"，供人类审阅。这是一个实验性功能。

可以看出，Open Claw 已经比前两个系统复杂很多了。所以你在使用 Open Claw 的时候，会明显觉得它"更聪明"。

Hermes Agent

接下来就是重头戏了。如果你不理解上下文治理，你可能会觉得 Hermes Agent 跟 Open Claw 没什么区别。但不知道你有没有发现：Open Claw 里仍然有很多文件需要你手动维护。

甚至就算是我，用了这么久 Open Claw，也是最近才知道这些文件需要人工维护。这就导致 Open Claw 设计的很多上下文，其实一直都没有真正被使用起来。Hermes Agent 的上下文治理跟 Open Claw 和 Claude Code 都不太一样。它的核心设计理念是：

“自我进化”——Agent 自己写自己的记忆和技能。

整个体系住在 ~/.hermes/ 目录下。

身份层（静态）

SOUL.md — system prompt 的第一个 slot，定义人格、语气、价值观、行为边界。这是全局的，从 HERMES_HOME 加载。这个文件你仍然可以手动编辑。

项目上下文层（按优先级，只加载第一个匹配的）

.hermes.md
AGENTS.md
CLAUDE.md
.cursorrules

先找到谁就用谁。

这意味着 Hermes 同时兼容 Claude Code 和 Cursor 的项目配置文件。

记忆层（三层，Agent 自己维护）

MEMORY.md — 长期记忆。存环境信息、项目惯例、工具使用经验。
USER.md — 用户档案。存你的名字、沟通偏好、技能水平。注意，这回 USER.md 已经变成自动维护了。
state.db — SQLite 数据库，带 FTS5 全文索引，存所有历史消息。Agent 不会默认全部加载，而是在需要时通过 session_search 按需检索。

这时候，记忆已经开始进入数据库时代了。因为只有数据库，才能真正支撑长期上下文检索。

技能层（Hermes 最独特的部分）

skills/ 目录 — 每个技能都是一个文件夹，里面包含一个 SKILL.md（带 YAML frontmatter），以及可选的模板和脚本。

关键区别在于：

技能不是人类写的。Agent 在完成非平凡任务之后，会通过 skill_manage 工具自己创建技能。同样，记忆也不再主要依赖人类维护。Agent 会在对话间隙，自己编辑 MEMORY.md 和 USER.md。而且技能是按需加载的。不用的技能不会进入上下文。这其实已经开始接近真正的"上下文自动治理"了。

调度层

cron jobs — 定时任务，类似 Open Claw 的 HEARTBEAT.md。

到了这一步，上下文治理不仅变复杂了，还开始自动化了。

总结

AI 是否真的能干活、干得好不好，已经不仅仅是模型之间的区别了。很多时候，更好的上下文治理，对智能体工作效率的提升，甚至比你换一个更强的模型还明显。

电子脑

随之而来的，还有一个很有意思的问题：上下文，其实就是智能体的"电子脑"。一个 Agent 用久了，那份上下文就会逐渐变成独一无二的它。只要上下文还在，就算换了一个"壳"，你的小助手还是你的小助手。如果智能体坏了需要重装，或者你想迁移到另一个智能体平台，只要把上下文迁移走，你的助手理论上就还能继续存在。

于是，一个新的问题出现了：如何安全地迁移上下文？

但现在的问题是：各家之间的文件名、结构、格式都完全不同。这就导致上下文迁移非常麻烦。我相信，未来一定会出现更统一、更标准化的上下文协议。而"上下文治理"，也会逐渐成为 AI Agent 最核心的能力之一。

上下文工程 on Code Plato