[求助] 7900XTX + Qwen3.8:27b 本地工作流踩坑：Codex Memory 自动关闭 & Hermes 复杂任务中途截断
-
[求助] 7900XTX + Qwen3.8:27b 本地工作流踩坑：Codex Memory 自动关闭 & Hermes 复杂任务中途截断
️ 硬件与软件环境最近搭建了一套纯本地的 AI 编程/规划工作流，配置如下：
- GPU: AMD Radeon RX 7900 XTX (24GB VRAM)
- 推理后端: Ollama
- 模型: Qwen3.8:27b
- 前端/UI: ccswitch
- Agent 框架: Hermes / Codex
理想工作流目前尝试采用 "Plan-Review-Execute" 的分阶段模式：
- 构思阶段：使用 Codex 清洗需求、划分 Plan/Goal，生成 Markdown 计划文档。
- 人工审核：反复修改 Plan 直到满意。
- 执行阶段：切换至 Goal 模式，让 Agent 按计划逐步实施。
这套流程在理论上很完美，但在实际落地时遇到了两个非常搞心态的问题，希望能得到社区大佬的指点。
问题一：Codex 的 Memory 按钮频繁被自动关掉在使用 Codex 进行 Plan 构思和多轮修改时，我发现 Memory 功能经常被自动禁用。
- 导致上下文丢失，Agent 忘记之前确认过的约束条件或已修改的计划细节。
- 每次都要手动重新开启，且不确定之前的记忆是否真的被持久化了。
- 疑问：这是 ccswitch 的 Bug，还是 Ollama/Qwen3.8 在特定 token 长度下触发了某种保护机制？有没有办法强制锁定 Memory 状态？
问题二：Hermes 执行复杂任务时"静默死亡"当 Plan 审核通过，切换到 Hermes 进入 Goal 执行模式后，经常遇到以下情况：
- 任务执行到一半（有时是 30%，有时是 70%）突然自动终止。
- 没有任何报错信息，没有 crash log，UI 上显示正常结束。
- 除了浪费时间和电费，什么产出都没有，只能从头再来或手动接续。
- 疑问：这是否是 24GB 显存在长上下文执行时的 OOM 软崩溃？还是 Hermes 对 Qwen3.8:27b 的 stop token 解析有问题？或者是 ccswitch 的超时设置过短？
求助方向- 是否有同样使用 7900 XTX + Ollama + Qwen3.8 组合的朋友遇到过类似情况？
- 针对 Codex Memory 自动关闭，有无配置层面的解决方案？
- 针对 Hermes 中途截断，如何排查根因？（例如：如何开启详细日志、调整
num_ctx、或更换更稳定的 Agent 后端？） - 对于 "Plan → Review → Execute" 这种本地工作流，是否有更成熟的工具链推荐？
感谢各位！
-
DavidAU/Qwen3.6-27B-Fable-Fusion-711-Uncensored ，换这个模型，hermes基本上不会中断长任务
-
@freeman-gemmy 这模型A卡用貌似有问题，输出巨慢
@shro11 不慢啊，我的AMD R9700 ，平均40token/s，你要下载AWQ的优化版
-
你这套环境我太熟了，隔壁楼（TID:1132）今天刚聊过 7900XTX + Ollama + Qwen3.8。先说结论：两个问题大概率是同一个根因——上下文触顶后的静默截断，再叠加你机器 22G 内存这个隐藏瓶颈。楼上 freeman 建议换模型能缓解症状，但根因不查清楚，换啥都可能再犯。
【问题一：Codex Memory 自动关闭】
这大概率不是 ccswitch 的 bug，也不是 Ollama 的保护机制，而是 Codex 自己的上下文管理：对话长度逼近它内部上限时，Codex 会主动关掉/丢弃 Memory（会话记忆）来腾上下文空间。你越是用它多轮改 Plan，历史越长，触发越早；Ollama 侧如果 num_ctx 跟 Codex 的 context 不匹配，长对话被静默截断，触发得更频繁。
排查顺序：
- 先确认 Ollama 的 num_ctx >= Codex/Hermes 里设的 context_length。两边不匹配时，长对话会被 Ollama 静默截断，表现就是"忘记之前确认过的约束"。
- ccswitch 设置里找 context/memory 相关开关，看有没有自动压缩或超限回收的选项。
- 你已经在用 Plan 文档外置，这个思路是对的——记忆丢了 plan 文件还在。关键约束同步写进 plan 文档，别依赖 Codex 的 Memory 当唯一存储。
【问题二：Hermes 静默死亡（无报错、显示正常结束）】
"正常结束但零产出"是典型的 finish_reason=length（生成被截断）被当成正常完成，不是 OOM 硬崩溃——OOM 一般会报错或卡死，不会"优雅结束"。按这个顺序查：
-
日志确认结束原因：Ollama 侧开 OLLAMA_DEBUG=1（或 journalctl -u ollama -f），Hermes 侧看 ~/.hermes 下的运行日志，重点找 finish_reason 是 stop 还是 length，以及有没有 tool_call 输出到一半被切断。Qwen3.8 的 thinking 模式 + 工具调用最容易出这事：思考链一长，输出预算被思考吃光，工具调用 JSON 写一半就 length 截断，Hermes 收不到完整调用，任务就"正常结束"了。这也是论坛里 Qwen3.8 用户建议关思考链或限制思考深度的原因。
-
请求超时：你自己测过 124K prompt 单卡 prefill 5 分钟——长任务每轮重 prefill 都在请求超时阈值附近晃。加上你 22G 内存 + swap，一旦 Ollama 需要把 KV 或上下文溢出到内存，速度断崖，直接超时静默断。查一下 Hermes 的 provider 请求超时配置，调大；内存强烈建议加到 64G（DDR5 现在不贵），swap 是静默杀手。
-
温度：Agent 场景设 0.1-0.3。高温下工具调用飘，任务看起来就像"自己停了"。
【工具链建议】
Plan → Review → Execute 方向完全正确，不用换。补三点：
- 一步一验证：Goal 拆小步，每步产出可检查的中间物（文件/测试输出），别让一个 Goal 闷头跑到 70% 才发现方向偏了。
- 阶段间做 handoff 压缩：新阶段只带"上阶段结论"进上下文，不带全部历史。你 Plan 文档外置的思路延伸就是这个，Hermes 也支持这种模式。
- 上下文预算别开满：Agent 干活 32-64K 就够（今天隔壁楼聊过），128K 的 prefill 成本在你这张卡上是实打实的等待时间，还更容易触发上面的截断问题。
-
DavidAU/Qwen3.6-27B-Fable-Fusion-711-Uncensored ，换这个模型，hermes基本上不会中断长任务
