请教你们都是怎么解决上下文总是满了的问题？
-
各位大神介绍一下经验，我的折腾如下：
1、修改rag大小：
文件 之前 现在 上下文占用
───────── ────────── ────────── ─────────────
MEMORY.md 2,200 字符 4,400 字符 ~1,600 tokens
USER.md 1,375 字符 2,750 字符 ~1,000 tokens
2、搞了个Watchdog 核心：• ✅ 进程存活检测 • ✅ Dashboard 端口检测 • ✅ Worker 数量监测 • ✅ 会话数量监测 上下文水位检测当前显示"未知"是因为没有活跃对话。等你或 另外一台计算机上有活跃 session 时，它会从日志里读到 context_pct 数据。如果发现水位 > 60% 就会自动保存。3、 手段 做什么
─────────────────────── ────────────────────────────
\ head -100``
save-state.py + /new 存快照开新会话
anti-loop skill 避免重复失败撑爆
/compress 主动压缩上下文
一个 session 只做一件事 从源头控制
————————
但还是会有报错的时候，如果解决不了，这就没法长时间跑批处理，要一直盯着。大神们有没有办法，请教。 -
│完整配置一览：
硬件 项目 规格 ───── ─────────────────────────────────── CPU Intel i5-12600KF GPU AMD Radeon RX 7900 XTX（24GB VRAM） 内存 30GB（9.3GB 在用，21GB 可用） 硬盘 937GB NVMe（258GB 已用，29%） 系统 Ubuntu 26.04，内核 7.0.0 有线 192.168.2.120（enp5s0） Wi-Fi 192.168.200.107（wlp6s0，备用） 模型推理 项目 值 ──────── ─────────────────────────────────────── 模型 Qwen3.6-27B-MTP Q4_K_M 上下文 98,304 tokens 上下文 98,304 tokens 推理 MTP draft 模式（最大 2 个 draft token） 速度 ~45 tok/s GPU 全层 offload（-ngl 99） KV cache q4_0（省显存） 模板 temp 0.4、top-p 0.95 Hermes 配置 项目 值 ─────────── ────────────────────────────────── 版本 v0.17.0（~/bin/hugo v0.163.3） 最大轮次 50 压缩 开启，50% 阈值 → 压缩到 40% MEMORY 上限 4,400 字符 USER 上限 2,750 字符 SOUL.md 31 行（防死循环 + skill 加载规则） Dashboard :9119，auth: basic（vanvj） fallback DeepSeek V4 Flash 部署项目（~/project/） 项目 说明 ───────── ───────────────────── monkvan 神话传说（hugo-book） monkvancn 中国神话 oldvan 老梵博客（LoveIt） wellness 养生站（FixIt） 当前会话状态 项目 值 ─────────────── ────────────────────────────── 活跃会话 1 当前水位 38,204 / 98,304 tokens（39%） 缓存命中 58% Watchdog 每 5 分钟检测，>60% 自动存快照 Save-state cron 每 10 分钟自动备份 -
Hermes自己有一個compaction_threshold的設定, 我自己平時是習慣調低點讓上下文壓縮的時間點推前
然後我平時在Cron jobs跟Skills會要求Hermes在過程當盡可能將重要點寫成MD, 然後Compress之後再叫Hermes自己按需求拿MD繼續工作
基本上上下文限制這個沒辦法避免, 人在的時候盡可能觸發Compression, 人不在的時候就只能依賴Auto Compress
@566656661 确实，我也认命了，这个最佳解是提高硬件配置，要么就是把cache进ram，用速度换上下文的容量。
