Memoh上下文管理与压缩机制AI Agent长对话不跑偏的关键设计【免费下载链接】Memoh✨ The open-source multi-agent platform. Every agent gets its own computer, desktop, network, and long-term memory. You can bring your own key, or host your coding agent like Claude Code, Codex and so on.项目地址: https://gitcode.com/gh_mirrors/me/Memoh如果你用 AI Agent 处理长对话多半遇到过聊着聊着就失忆的尴尬——上下文塞满模型窗口后要么报错、要么开始胡说。Memoh 是一个开源的多智能体平台每个 Agent 都有独立的电脑、桌面、网络和长期记忆。它的上下文管理采用预算准入 自动压缩双机制先用 token 预算做硬边界裁剪再按 50%/75%/40% 三档阈值自动把旧对话蒸馏成摘要让 Agent 在数小时的长对话中依然保持记忆连贯。为什么长对话会让 AI Agent 跑偏大模型有一个硬约束上下文窗口有限比如 128K、200K token。对话越长原始消息占用的 token 越多直到撞上窗口天花板。此时常见三种灾难直接报错请求超出窗口模型拒收注意力稀释关键信息被淹没在海量历史里回答质量下降服务端 OOMMemoh 团队曾遇到一个约 8000 条历史消息的讨论会话拼装出的上下文估算高达 174 万 token直接压垮了 8 GiB 内存的服务器进程。Memoh 在设计文档 context-memory-scheduling.md 中把这次事故拆成了三个缺陷防护检查跑在数据物化之后、同一份上下文被复制了多个表示、没有进程级内存调度。针对它们Memoh 建立了一套分层防御。上下文管理先算账再装车传统做法是把所有历史塞进 prompt超了再说。Memoh 的原则相反先做预算决策再决定是否装载。统一 token 估算全仓库只用一个估算公式此前chars/2与len/4两套估算相差 2 倍的问题已被收敛预算、压缩触发、裁剪判断口径一致预算准入检查在把消息拼装成上下文之前仅凭元数据条数、字节数判断是否超过预算预算为min(模型窗口 − 输出预留, 绝对上限)绝对上限兜底即使用户没给模型配置窗口大小服务端也有一个默认 200K 的绝对上限永远不会发出无界请求确定性裁剪确实超预算时按优先级保留——系统片段 → 当前触发消息 → 已有的压缩摘要 → 能塞下的最近历史窗口被丢弃的内容都会记录原因可观测可审计失败即封闭如果连必须保留的部分都放不下Memoh 会返回稳定的context_too_large错误而不是悄悄发一半。这套逻辑的核心实现在 service_compaction.go 与上下文视图选择器中配套的准入与裁剪逻辑可通过结构化日志context_admission等键位在日志里追踪到每一次决策。上下文压缩把旧对话蒸馏成摘要光裁剪不够——丢掉的历史再也找不回来。Memoh 的解法是分层压缩Compaction把最旧的一段对话交给 LLM 总结成摘要用摘要替换原文后续拼装时只加载摘要 未压缩的近期消息。三档阈值设计50% 软触发、75% 硬兜底、40% 目标压缩节奏由三个百分比控制代码见 service_compaction.go档位阈值行为软触发窗口 50%异步触发压缩不阻塞当前回合硬兜底窗口 75%调用模型前同步压缩确保本回合安全压缩目标窗口 40%压缩后上下文应回落到此水位这个目标低于触发线的滞回设计很关键压缩完成后压力降到 40%要涨回 50% 才会再次触发避免每回合都压缩一次浪费 LLM 调用。异步触发还有一个细节——单次触发最多连续执行 3 轮摘要来排空积压防止小窗口的压缩模型一次压不完把大段历史留给下一个回合。摘要 Prompt只留干货压缩质量取决于摘要 Prompt。Memoh 的摘要提示词见 prompt.go明确要求保留关键事实、决策与约定用户偏好与请求继续对话所需的上下文人名、日期、数字等具体细节工具调用的结果忽略中间步骤和报错。此外还有一层摘要链融合frontier fusion当历史已经被压缩过多次、存在多条旧摘要时融合提示词会把仍相关的旧摘要与新段落合并成一条替换性摘要而不是层层嵌套参见上次摘要——保证摘要链不会越滚越长。手动压缩一条命令立即执行自动压缩之外用户还可以随时发送/compact命令立即压缩当前会话实现在 compact.go。它直接调用同步压缩服务不发起新的 Agent 回合适合对话明显变长、想主动清一下记忆时使用。压缩使用的模型按优先级解析显式配置的压缩模型 → 当前回合模型 → Bot 默认聊天模型。稳定性细节失败了怎么办长链路系统里压缩本身挂了是最容易被忽视的故障。Memoh 的处理方式单飞锁single-flight同一会话同时只允许一次压缩运行并发调用者复用进行中的结果避免选到重叠的消息集互相踩踏失败冷却压缩失败后会进入 5 分钟冷却期硬压力路径按 30 秒起步、指数翻倍退避失败的模型不会每个回合都白烧一次 LLM 调用质量校验空摘要、截断的摘要、摘要比原文还长的无效摘要都会被拒绝被压缩的消息仍可恢复绝不标记为已压缩降级只向下不向上压缩摘要加载失败时宁可走裁剪兜底或返回可重试错误也不会悄悄退回全量未压缩历史——那才是最危险的退化方向。如何开启与配置压缩压缩是按 Bot 配置的路径Bot 设置 → 高级 → 压缩Compaction区域提供四个选项Enable Context Compression总开关Compaction Threshold手动指定软触发阈值token 数留 0 则自动取模型窗口的 50%Context Kept After Compression (%)压缩后保留比例默认 40%Compaction Model指定用于摘要的模型默认跟随 Bot 聊天模型。配置存储在数据库Postgres中服务端核心逻辑分布在 internal/agent/context/compaction/压缩服务、摘要 Prompt、工件与边界管理和 internal/agent/application/触发与调度。想深入设计全貌推荐通读 docs/design/context-memory-scheduling.md。小结Memoh 让长对话不跑偏的答案不是更大的窗口而是一套纪律分明的机制预算先行——任何上下文在装载前先过一道基于元数据的准入检查确定性裁剪——超限内容按优先级丢弃且全程可审计自动压缩——50% 软触发、75% 硬兜底、40% 回落目标把旧对话持续蒸馏成高质量摘要失败安全——冷却、单飞、质量校验与向下降级保证压缩本身不成为新的故障点。最终达成的不变式很直白服务器峰值内存 ≈ 单个在预算内上下文的体积 × 并发回合数与历史总长度无关。这就是聊多久都不失忆背后的工程秘密。【免费下载链接】Memoh✨ The open-source multi-agent platform. Every agent gets its own computer, desktop, network, and long-term memory. You can bring your own key, or host your coding agent like Claude Code, Codex and so on.项目地址: https://gitcode.com/gh_mirrors/me/Memoh创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考