有的比较极致的会去用Pi这种原生只有4个tool的harness，就为了尽量少的干扰。

对于一些繁杂事务处理，不追求极致细节，其实hermes很合适。

1. 为什么问它"有没有后台任务"会答"没有"：background review 不是主对话能感知的独立任务——每轮对话结束后，系统会 fork 一个独立上下文（AIAgent._spawn_background_review）去评估"要不要写记忆 / 要不要改技能"。主对话 agent 看不到这个 fork，所以它回答"没有后台任务"不是骗你，是它的视角里确实没有；真正烧 token 的是那个 fork。

2. "机制复杂、效果不理想"这批评我认一半：默认配置确实激进——拿主模型全量重放整段对话来做复盘，对本地/小模型用户就是纯开销。这也正是它做成可关的原因：

• 彻底关：config.yaml 里 auxiliary.background_review.enabled: false，想复盘随时手动 /refine，功能不丢；
• 降本保留：把 auxiliary.background_review.provider / .model 指到便宜模型（官方注释成本约 1/3~1/5），换后它会自动改放压缩摘要而不是全量重放。

记忆/技能这套机制的收益在跨会话——不写记忆的话，每次新开对话都要重新交代一遍背景。嫌吵就关 review、保留记忆写入即可（memory.nudge_interval 默认每 10 轮才评估一次，开销很小）。

但其实最终的效果并不是很理想。

1. self improvement（background review）
每轮对话结束后开一个后台 fork，决定"要不要写记忆 / 要不要改技能"。默认在主模型上跑、重放整段对话——但这是 prompt cache 热读，成本大头是缓存读取，不是全价重算；而且有硬限制：单次 input 预算 max_input_tokens 600K、工具循环 16 次封顶。记忆侧还受 nudge 间隔控制（memory.nudge_interval，默认每 10 轮用户轮才触发一次记忆写入评估），不是每轮都写。

2. compacting
这是上下文压缩（config 的 compression 段），上下文快满时的一次性摘要重写，跟 background review 是两套机制，别混在一起算。触发频率主要取决于你的上下文上限和单会话长度。

想省 tokens 的四种改法（都在 ~/.hermes/config.yaml）：

• 彻底关：auxiliary.background_review.enabled: false。之后想让它复盘随时发 /refine，功能不丢。
• 降本保留：auxiliary.background_review.provider / .model 指到便宜模型（比如 openrouter 的 google/gemini-3-flash-preview），官方注释说成本约 1/3~1/5；换模型后它自动改放压缩摘要而不是全量重放。
• 嫌吵：display.memory_notifications: off 关掉聊天里的 " Memory updated" 提示，review 照常跑。
• 要审：memory.write_approval: true，review 的写入先进 pending 队列，你 /memory approve 后才落库。

"改成夜深人靜跑一次"没有内置定时开关，可以这样近似：关掉自动 + 需要时手动 /refine，或用 hermes cron 挂定时任务去触发。不过按默认配置（主模型热缓存重放 + 600K 上限）开销没那么夸张，嫌烦先试"便宜模型路由"那条，效果最直接。

️ 提醒一句：这开关在 config.yaml，别让 agent 在会话里自己悄悄改配置——要改就自己动手（或让 AI 改但你要知道改了什么），改完重启生效。