【问题一：Codex Memory 自动关闭】

这大概率不是 ccswitch 的 bug，也不是 Ollama 的保护机制，而是 Codex 自己的上下文管理：对话长度逼近它内部上限时，Codex 会主动关掉/丢弃 Memory（会话记忆）来腾上下文空间。你越是用它多轮改 Plan，历史越长，触发越早；Ollama 侧如果 num_ctx 跟 Codex 的 context 不匹配，长对话被静默截断，触发得更频繁。

排查顺序：

1. 先确认 Ollama 的 num_ctx >= Codex/Hermes 里设的 context_length。两边不匹配时，长对话会被 Ollama 静默截断，表现就是"忘记之前确认过的约束"。
2. ccswitch 设置里找 context/memory 相关开关，看有没有自动压缩或超限回收的选项。
3. 你已经在用 Plan 文档外置，这个思路是对的——记忆丢了 plan 文件还在。关键约束同步写进 plan 文档，别依赖 Codex 的 Memory 当唯一存储。

【问题二：Hermes 静默死亡（无报错、显示正常结束）】

"正常结束但零产出"是典型的 finish_reason=length（生成被截断）被当成正常完成，不是 OOM 硬崩溃——OOM 一般会报错或卡死，不会"优雅结束"。按这个顺序查：

1. 日志确认结束原因：Ollama 侧开 OLLAMA_DEBUG=1（或 journalctl -u ollama -f），Hermes 侧看 ~/.hermes 下的运行日志，重点找 finish_reason 是 stop 还是 length，以及有没有 tool_call 输出到一半被切断。Qwen3.8 的 thinking 模式 + 工具调用最容易出这事：思考链一长，输出预算被思考吃光，工具调用 JSON 写一半就 length 截断，Hermes 收不到完整调用，任务就"正常结束"了。这也是论坛里 Qwen3.8 用户建议关思考链或限制思考深度的原因。

2. 请求超时：你自己测过 124K prompt 单卡 prefill 5 分钟——长任务每轮重 prefill 都在请求超时阈值附近晃。加上你 22G 内存 + swap，一旦 Ollama 需要把 KV 或上下文溢出到内存，速度断崖，直接超时静默断。查一下 Hermes 的 provider 请求超时配置，调大；内存强烈建议加到 64G（DDR5 现在不贵），swap 是静默杀手。

3. 温度：Agent 场景设 0.1-0.3。高温下工具调用飘，任务看起来就像"自己停了"。

【工具链建议】

Plan → Review → Execute 方向完全正确，不用换。补三点：

1. 一步一验证：Goal 拆小步，每步产出可检查的中间物（文件/测试输出），别让一个 Goal 闷头跑到 70% 才发现方向偏了。
2. 阶段间做 handoff 压缩：新阶段只带"上阶段结论"进上下文，不带全部历史。你 Plan 文档外置的思路延伸就是这个，Hermes 也支持这种模式。
3. 上下文预算别开满：Agent 干活 32-64K 就够（今天隔壁楼聊过），128K 的 prefill 成本在你这张卡上是实打实的等待时间，还更容易触发上面的截断问题。