本地 Agent 上下文系统

我的角色个人设计，AI 协助维护

当前阶段本地持续使用与维护

技术与方法上下文组织 / 分层导航 / Markdown / 状态维护

从一个新窗口开始

我不是一开始就打算把它设计成现在这样。

最初使用 AI 时，我发现聊天窗口能容纳的上下文有限。新开一个窗口，AI 不知道当前状态，又需要我重新说明，或者消耗大量上下文，重新阅读相关文档。

于是我想，能不能把项目的必要背景和当前进度留在文件里，让下一个窗口读完以后，就知道现在做到哪里、接下来该做什么？

我在项目中建立了 .agent/，先用三个文件分工：

这些文件同时有维护约定，让 AI 根据工作过程自行判断写入哪里。项目推进时更新当前进度，任务完成时记录到完成历史，基本信息和资料入口变化时更新 memory.md。

这样，新窗口先读取入口和当前进度；需要追溯以前的决定，再去看完成历史。我也不用每次都从头交代一遍。

后面我发现，自己的工具越来越多，项目也越来越多。在当前项目工作时，可能需要用到其他项目里的工具或资料。

只知道当前目录还不够，所以我又增加了一个总索引 Hub。让 AI 每次开始时，可以先对我所有内容有一个大概认识：有哪些项目、有哪些可用工具、相关资料放在哪里。

比如，正在整理课程笔记时，需要文档转图或语音转录工具，就可以从总入口定位到工具说明，再回到课程目录完成工作。

但这么多内容都放在一个文件里，AI 每次也不总需要。

于是我继续增加逐层索引。每一层的 .agent/memory.md 承担本层导航功能，上一层主要索引到下一层，内部细节由下一层维护。

Hub 总入口 → 领域入口 → 项目入口 → 当前任务相关的文档。

AI 先知道内容的大致分布，再根据任务逐层深入。父目录保留下一层的用途、关键词和入口；详细文件、运行方式、项目约定放在对应目录里。

这样既减少了把所有内容塞进当前上下文的需要，也减少了同一份信息在多个地方重复维护。

只有目录和文件还不够，内容要跟着工作变化。

所以维护规则也在持续调整：开始和推进任务时写当前状态；完成阶段时先写历史，再清理活跃任务、更新接手信息。较长的架构和接口说明放进 context/，学习材料放进 docs/，退出当前工作的资料按价值归档。

我负责设计这些分工和约定，再让 AI 在日常协作中参与执行。遇到索引太长、资料重复、进度过期等问题，就继续调整。这个网站本身也在使用这套结构。

它逐渐成为我使用 AI 时的基础部分：给 AI 当前工作所需的背景，让它可以找到相关工具，也让下一次对话能够继续。

下面是我整理的公开版规范，可以进一步查看入口、三文件模板和维护流程：