AI Agent 上下文与持久记忆:从 Context Window 到项目状态机

📅 2026/7/24 18:02:22
AI Agent 上下文与持久记忆:从 Context Window 到项目状态机
一、Context Window 不等于持久记忆很多人第一次使用 AI Agent 时会把 Context Window 理解成「Agent 的记忆」。它确实决定了当前请求最多能看到多少内容但这个容量只服务于当前会话。对话结束、上下文被压缩或者换一个窗口后里面的信息就不再可靠。可以把它理解成函数调用时的参数而不是数据库。参数决定这次函数能处理什么数据库才负责跨调用保存状态。项目背景、操作规则和上次的执行结果如果只放在 Context Window 里Agent 每次重新进入项目时都需要重新发现。即使模型支持更大的上下文也只是把更多信息放进当前请求不能自动判断哪些内容应该长期保留更不会自动知道项目最新进度。所以解决 Agent「接不上项目」的问题重点不是继续扩大 Context Window而是把不同生命周期的信息放到不同位置临时任务留在会话中稳定规则写进规则文件项目进度写入状态文件。后面的四层模型就是为了把这几类信息拆开管理。二、四层上下文模型要让 Agent 能持续接手工作可以把信息按作用范围拆成四层。每一层解决的问题不同保存位置也不同。层级负责内容保存位置当前任务层本次要改什么、刚确认什么当前对话全局规则层跨项目长期有效的偏好和红线全局AGENTS.md、CLAUDE.md项目规则层项目目录、执行边界、验证方式和协作流程项目级AGENTS.md、CLAUDE.md项目状态层版本、进度、阻塞和下一步ROAD_MAP.md上下文压缩规则可以写在项目级CLAUDE.md中和项目目录、执行边界、验证方式等规则放在一起。四层模型里最先需要处理的是当前对话。它承载眼前任务也最先遇到上下文上限。接下来就从这里开始看哪些信息应该留在会话里以及/compact如何配合项目规则工作。三、当前对话与/compact当前对话只负责承载正在变化的工作集这次要改什么、刚确认了什么、正在查看哪个文件以及尚未完成的临时判断。任务结束后这些信息可能就失效不适合直接当项目档案。上下文接近上限时Claude Code 会自动压缩也可以手动执行/compact。为了避免重要信息被一起压掉可以在项目级CLAUDE.md中加入官方称为Compact Instructions的章节### Compact Instructions - 保留已确认的结论和操作约定 - 保留已修改文件、验证命令和未完成事项 - 未验证的信息标记为待确认 - 丢弃抓取原文、调试过程和临时讨论这些规则由项目文件统一维护平时不需要每次在终端重新输入。只有本次压缩有特殊重点时才临时补充/compact 保留当前 API 改动和测试结果这样当前对话负责记录过程Compact Instructions负责定义压缩时的取舍。两者配合才能让上下文变短后仍然保留下一步行动所需的信息。四、AGENTS.md与CLAUDE.md的分工同时使用 Codex 和 Claude Code 时最容易出现的问题是为两个 Agent 各写一份看起来完全一样的规则。这样不仅增加维护成本文件内容逐渐分叉后两个 Agent 还可能按不同约定执行。我的做法是按「共同规则」和「工具差异」拆分文件主要使用者适合写什么CLAUDE.mdClaude Code项目规则、业务流程、目录职责、验证方式AGENTS.mdCodexCodex 的执行边界、工具习惯和补充约束项目级文件放在仓库根目录。跨项目都有效的个人偏好则分别放入全局AGENTS.md和CLAUDE.md。同一条业务规则只在CLAUDE.md中维护AGENTS.md通过指针引用它再补充 Codex 特有的执行差异。例如写作项目的导出流程、草稿目录和发布边界写在CLAUDE.mdCodex 如何读取文件、何时使用补丁、哪些命令需要确认写在AGENTS.md。两个文件不是重复的记忆库而是不同 Agent 进入同一项目时各自读取的执行入口。这样规则只维护一份工具差异单独隔离。换 Agent 时不需要重新解释项目约定它们会从自己的入口找到共同规则和专属规则。五、用ROAD_MAP.md管理项目状态规则文件解决的是「应该怎么做」但 Agent 还需要知道「项目现在做到哪了」。这部分不能依赖聊天记录也不适合混进CLAUDE.md应该单独放在ROAD_MAP.md。一个可用的路线图至少要记录## 最新进展 - 当前版本 - 最近已验证的改动 ## 已完成 - 已实现并验证的功能 ## 待规划 - 尚未承诺时间的事项 ## 阻塞 - 当前无法继续的问题每次任务完成后只把已经实现并验证的内容放进「已完成」。只改了代码但还没跑验证就应该留在「最新进展」或标记为「待确认」不能提前改变状态。因此ROAD_MAP.md不是一次写完的项目介绍而是随着迭代持续更新的状态文件。Agent 进入项目时先读它就能知道当前版本、最近变化和下一步任务结束后再把验证结果写回去下一次接手看到的就是新的状态。从这个角度看路线图更像一个简单的项目状态机任务从待规划进入进行中验证通过后进入已完成遇到依赖或错误则进入阻塞。状态变化有记录Agent 才能沿着当前节点继续执行。六、一套可执行的 Agent 交接流程有了文件还不够关键是每次进入项目都执行相同的读取和回写顺序。我现在采用下面这条流程1. 读取 ROAD_MAP.md确认版本、进度和阻塞 2. 读取项目级 AGENTS.md、CLAUDE.md加载执行规则 3. 根据当前任务读取相关源码、草稿或脚本 4. 先说明准备修改的范围再开始执行 5. 运行与改动对应的验证命令 6. 将已验证的结果写回 ROAD_MAP.md 或规则文件例如在写作项目中Agent 先从ROAD_MAP.md确认当前文章和导出流程再读取CLAUDE.md了解平台规则读取AGENTS.md了解 Codex 的执行边界。修改草稿后运行对应的导出脚本确认 HTML 和图片都正常再把完成项写回路线图。这里有两个容易忽略的细节。1读取顺序本身就是交接协议。先看状态再看规则Agent 才不会拿过期流程判断当前任务。2验证结果必须回写。只在对话里说「已经完成」下一次 Agent 仍然无法确认写进状态文件项目才真正获得了可复用的记忆。这套流程没有增加模型的记忆容量却让每个新会话都能从正确的状态开始工作。我是 RestartHuaC 老兵现在用 Python 和 AI 做工具、写文章。