Hermes Agent 内存优化完整指南缓存策略与资源释放实操【免费下载链接】hermes-agentThe agent that grows with you项目地址: https://gitcode.com/GitHub_Trending/he/hermes-agent跑一个长会话两小时RSS 从 800 MB 爬到 4 GB新回复越转越慢直到报 context full——Hermes Agent 内存优化的问题通常就出在这类长跑场景。这篇指南按可执行步骤拆解先定位瓶颈在哪一层再决定缓存 TTL 怎么设、上下文压缩怎么开最后给容器任务兜底限额。每个参数都给默认值和取舍建议改完有验证方法。Hermes Agent 的缓存分三层提示词缓存Anthropic cache_control 标记5m/1h 两档、模型元数据缓存进程内 1 小时上下文长度落盘到 context_length_cache.yaml、技能索引缓存1 小时写在磁盘上。资源释放靠两块上下文压缩和容器资源限额。先诊断Hermes Agent 内存瓶颈在哪一层内存占用大致分三类进程 RSS、上下文 token 数、磁盘缓存文件。别急着改参数先判断属于哪类。# 找到主进程每分钟采样一次 RSS单位 KB ps aux | grep -E hermes | grep -v grep watch -n 60 ps -o rss -p PIDRSS 随轮次持续上涨上下文没在压缩看压缩配置RSS 平稳但响应变慢多半是提示词缓存命中率掉了看 TTL磁盘目录变大索引缓存堆积。# 定位 HERMES_HOME检查技能索引缓存大小与文件新鲜度 echo $HERMES_HOME du -sh $HERMES_HOME/skills/.hub/index-cache ls -lt $HERMES_HOME/skills/.hub/index-cache | head另一个容易漏的点上下文压缩默认是静默的后台执行、只在服务端日志留痕。想看它有没有在工作临时把compression.progress_notices设为 true聊天平台会开始推送 compaction 进度。确认完记得改回。长会话场景Hermes Agent 上下文压缩怎么开、缓存 TTL 设多少现象会话超过 1 小时后 RSS 单调上涨prompt tokens 逼近模型上下文上限回复延迟明显升高。改哪里配置文件里的compression段和prompt_caching段标记注入逻辑在 agent/prompt_caching.py。prompt_caching: cache_ttl: 1h # 默认 5m只有人在交互时才值得 1h compression: threshold: 0.50 protect_first_n: 0 # 长跑会话建议 0默认 3 max_attempts: 6 # 工具调用密集时 3 轮压不下去改多少有讲究。压缩默认在 prompt tokens 达到模型上下文窗口 50% 时触发protect_last_n默认保留最近 20 条消息这个不用动。protect_first_n默认保留开头 3 条非系统消息且永不被摘要长会话里它们早就和当前语境脱节设 0 只保系统提示词最干净。TTL 这一档要算账1h 档的缓存写入成本是基础输入价的 2 倍5m 档是 1.25 倍只有轮次间隔超过 5 分钟的人机交互才回本。代码里对 subagent、cron、webhook 这类机器节奏的来源会自动按 5m 处理你手动设 1h 也救不回来Qwen 等阿里系路由不支持 1h会被自动钳回 5m。所以这个场景下不建议无脑拉满人跑 1h、机器跑 5m。怎么验证改完跑一个 30 分钟以上的会话观察两点——RSS 在压缩触发后回落或走平聊天里偶尔出现 compaction 通知再看 API 用量的缓存写入 token 占比比改之前低才说明选对了档位。技能批量加载场景1 小时索引缓存怎么用现象批量安装或升级技能时请求 hub 频繁首次列表加载慢怀疑缓存失效。改哪里技能中心 tools/skills_hub.py 把各源索引写到HERMES_HOME/skills/.hub/index-cache/TTL 固定 1 小时INDEX_CACHE_TTL 3600过期自动重取。改多少默认值就是权衡过的一般不动。想省请求就别去手动刷新缓存想省磁盘就清理老文件代价是清理后首次访问该源要重新拉一次索引# 删除超过 1 天的过期索引缓存下次读取自动重建 find $HERMES_HOME/skills/.hub/index-cache -name *.json -mtime 1 -delete怎么验证ls -lt该目录文件修改时间应全部在近 1 小时内对同一批技能再跑一次列表操作明显变快且不产生新的索引文件说明命中了缓存。容器隔离场景给单任务内存封顶现象agent 跑构建或测试命令时把宿主内存吃满整机变卡甚至触发 OOM killer 误伤别的服务。改哪里terminal配置段的container_memory对 docker、singularity、modal、daytona 四个容器后端生效local/ssh 忽略。Singularity 后端把它翻译成--memory MB参数拼进命令见 tools/environments/singularity.py。terminal: container_memory: 8192 # 默认 5120按任务峰值上浮 30% 左右改多少先跑一次目标命令记下容器内峰值再按峰值的 1.3 倍设。命令本身吃不到 2 GB 就设 2048封顶的意义就是留安全垫设成默认 5120 而实际只用 1 GB等于没设。怎么验证跑一个故意吃内存的命令比如 Python 里循环分配大列表预期容器内进程被杀、宿主 RSS 曲线不受影响再跑正常任务确认没被限额误杀。参数速查表参数默认值建议值适用场景prompt_caching.cache_ttl5m人在交互设1h机器节奏保持5m长跑会话、定时任务compression.threshold0.501M 窗口设0.30128K 窗口设0.60上下文压缩触发点compression.protect_last_n20保持默认压缩时保留的尾部消息数compression.protect_first_n3长会话设0永不被摘要的头部消息数compression.max_attempts3工具密集会话设6压缩重试轮数上限 10compression.idle_compact_after_seconds0长期线程设1800闲置 30 分钟后回来先压一轮memory.memory_char_limit2200保持默认约 800 tokenMEMORY.md 字符限额memory.user_char_limit1375保持默认约 500 tokenUSER.md 字符限额技能索引缓存 TTL3600秒保持默认skills/.hub/index-cache/模型元数据缓存3600秒保持默认进程内免重复请求container_memory5120MB任务峰值 × 1.3最小 2048容器后端内存封顶落地顺序先改compression段并跑一个长会话确认 RSS 走平这是收益最大的一步再把交互场景的cache_ttl调到 1h 观察缓存写入成本是否回落容器限额最后加它只影响隔离任务和前面两项互不干扰任何一条出问题单独回滚即可。【免费下载链接】hermes-agentThe agent that grows with you项目地址: https://gitcode.com/GitHub_Trending/he/hermes-agent创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
方法)
