共计 2618 个字符，预计需要花费 7 分钟才能阅读完成。
我一直是个“单会话重度依赖症”患者。
用 ChatGPT、Claude 或者是本地部署的各类 AI Agent 时，我总喜欢在一个对话框里没日没夜地聊下去。总觉得只要不关会话，AI 就能一直保留上下文，不用我每次前情提要。在飞牛 NAS 上跑 Hermes Agent（跑了 hermes-agent 网关容器加上 hermes-webui 网页端）之后，我也自然而然把这个毛病带了过来。
我在网页端给每个项目建了个分类，每个项目底下就开一个会话，代码、排错、配置文件全堆里面，一用就是几个月。直到前几天，一个主力项目的会话突然毫无预兆地暴毙了——发什么消息都一直在转菊花，AI 像被施了定身法一样，一句话都吐不出来。
这次事故让我花了整整一个晚上翻容器日志和数据库，不仅揪出了一个极其离谱的死锁 Bug，也彻底逼我重构了用 AI 管理多项目的整套工作流。
一、翻车现场：就差 1 个 Token 的绝望
刚开始卡死的时候，我照例以为又是老毛病：是不是网络抖了？是不是模型 API 限流了？还是 NAS 资源被占满了？
一顿检查下来，硬件状态健康得很，网络通畅，API 额度充足。没办法，只能进 NAS 终端翻 Hermes 和 WebUI 的后台容器日志。扒了一大堆报错堆栈之后，我整个人都惊呆了。
根本不是网络问题，而是一个 由于自动压缩上下文触发的“1 Token 溢出死锁”：
- 我那个会话断断续续聊了 1923 条消息，上下文堆到了恐怖的 25.9 万 tokens；
- Hermes 内部有个自动保护机制：当会话膨胀到阈值（大概 12.8 万 tokens）时，后台会调用辅助小模型把早期历史“打包压缩”成摘要，腾出空间；
- 我当时配置里负责干脏活累活的压缩模型，用的是硅基流动的 Qwen，它的最大输入窗口是 262144 tokens；
- 极其黑色幽默的事情发生了：那次系统提交给它的压缩请求，算上提示词正好需要 262145 tokens——不多不少，刚好超了 1 个 Token！
因为超了这 1 个 Token，服务商直接回了个 400 Bad Request 并且拒绝重试。而 Hermes 的状态机又认定压缩没做完就不能交卷，于是死循环重试：压缩失败 → 报错 → 再触发压缩 → 再被 400 拒收……整个会话被死死卡在 working 状态，彻底脑死亡。
二、紧急抢救：两步把会话拉出泥潭
找到病根之后，抢救其实就两条路：一个治本，一个解眼前的围。
1. 治本：换个能扛大窗口的压缩模型
用 256k 窗口的模型去压缩十几万甚至二十万 tokens 的会话，容错率实在太低了。我直接改了 WebUI 数据目录下的 config.yaml，把负责压缩的辅助模型（auxiliary.compression）换成了大窗口的主力通道模型，同时把超时时间从默认的 60 秒放宽到 300 秒。让大模型来吞海量上下文做总结，再也没出现过因为差几个 token 溢出的乌龙。
2. 治标：物理超度臃肿的废弃会话
那个 25.9 万 tokens 的老会话既然已经卡死在数据库状态机里，就别指望能正常退出了。我直接连进 WebUI 的内部数据库，把这条会话的状态强行改成 ended 和 archived（数据留着当历史记录查，但不再激活），重启网页端，整个界面立马恢复了顺畅。
三、痛定思痛：分类、工作区与“会话短命化”法则
这次事故彻底把我打醒了：在大模型时代，把“会话”当成永久笔记本，绝对是脑子进水了。
因为就算压缩机制不报错，随着会话被反复压缩成摘要，信息丢失和幻觉只会越来越严重，而且每次单轮问答的 Token 开销和响应延迟都会被拉到天际。经此一役，我立下了三条不可动摇的使用军规：
法则 1：会话必须“短命化”，到了节点就断舍离
一个项目可以持续一年，但一个会话绝不应该超过一周。以“模块完成”或者“任务收尾”为节点，聊完一个功能，或者发现消息数超过一百条，立刻主动封存归档，另开新会话。保持上下文永远轻量、敏捷。
法则 2：让 PROJECT.md 成为项目的唯一真实记忆
既然会话随时要扔，那项目的上下文靠什么传承？答案是 把记忆固化成硬盘上的 Markdown 文件。
我在全局注入规则（SOUL.md）里加了一条死命令：
- 每次新会话开始，第一件事先去读当前项目目录下的
PROJECT.md； - 只要在聊天的过程中敲定了重要架构、关键命令、环境参数、或者踩坑排错结论，哪怕是随口说的，AI 必须立刻落盘写入
PROJECT.md（新记录置顶、带上日期）； - 任务收尾时检查一遍有没有遗漏；历史记录不准删，密码敏感信息不准写明文。
这样一来，即便旧会话随时灰飞烟灭，新会话一上来扫一眼 PROJECT.md，两秒钟就能无缝接管上一任的所有进度和经验。
法则 3：千万别把“分类”和“工作目录（Workspace）”搞混
这是 Hermes 网页端非常容易踩坑的一个交互设计盲区：
很多人在网页端新建会话时，以为选了项目分类，AI 就自动去对应的项目目录干活了。其实完全不是一码事！
“分类（Category）”仅仅是网页前端为了方便你肉眼分类做的一个虚拟标签；真正决定 AI 把代码和 PROJECT.md 写在哪里的，是那个单独填写的 工作目录（Workspace）！
比如做影视源项目，分类选了“玩偶”，但 workspace 必须老老实实写具体的绝对路径 /vol1/1000/docker/1panel/www/.../pro。Linux 系统大小写极其敏感，错一个字母就会直接在别处另立山头。现在我把每个常用目录直接设为默认工作区，开新会话时扫一眼路径对不对，再也不会张冠李戴。
四、聊聊日常落地的两个小习惯
跑顺了这套体系之后，日常多项目管理基本就像呼吸一样自然了。不过为了防翻车，我还保留了两个简单习惯：
- 新开会话第一句打个招呼带暗号 ：虽然系统提示词里有自动读取规则，但新会话第一轮我依然习惯随手敲一句：“ 看下本项目的 PROJECT.md，我们接着弄上回那个功能”。这一句就像握手协议，能确保 AI 的上下文绝对对齐；
- 关键结论手动兜底 ：大模型偶尔也会开小差忘了自动落盘，一旦它帮我调试出一个极难找的命令或搞定了配置，我会立刻补一句：“ 把这段排错结论写进 PROJECT.md”，确保干货永远留在硬盘上。
五、写在最后
AI Agent 越聪明、能帮我们做的事越多，我们就越容易产生一种盲目依赖的怠惰感。但说到底，机器的上下文窗口永远是有限的物理资源。指望一个会话聊到天荒地老，迟早会被各种玄学 Bug 和 Token 黑洞教做人。
会话负责高频交互，随时可以扔；文件负责低频固化，永远刻在盘上。 想明白了这一层，多项目管理才算真正走上了正轨。
