上下文管理
Myrm 上下文管理确保 Agent 在 200+ 轮对话中不丢信息，并通过智能压缩与缓存优化控制成本。架构概览
每条消息在到达 LLM 前经多阶段流水线：压缩流水线
第 1 层：即时过滤
大工具输出（文件内容、搜索结果等）立即截断，仅保留最相关部分。零 API 成本。第 2 层：Cache TTL 剪枝
过期缓存内容自动清除，避免陈旧数据占用上下文窗口。第 3 层：优先级感知压缩
消息分三档优先级：| 优先级 | 处理 |
|---|---|
| Critical | 永不压缩（用户指令、活跃错误） |
| Important | 最后压缩（近期工具结果、关键决策） |
| Standard | 优先压缩（较早对话轮次） |
第 4 层：结构化摘要
仅压缩不足时，LLM 生成 11 字段结构化摘要（用户目标、活跃任务、错误、决策等）替换压缩历史。第 5 层：缓存优化
注入提供商特定缓存标记（Anthropiccache_control、Qwen 前缀缓存）以最大化后续请求的 Prompt 缓存命中。
可逆压缩
不同于永久丢弃压缩内容的竞品，Myrm 压缩可逆：- 工具输出卸载到
.context/存储，非删除 - 归档检查点在压缩前捕获完整状态
- 可按需恢复内容
Prompt Cache 优化
Prompt 缓存命中时输入 Token 成本最高可降 90%。设计原则
- 静/动分离 — 系统提示词冻结（可缓存）；动态内容进用户消息
- 4 层稳定前缀 — 系统提示词 → 工具 → 工作区规则 → 首条用户消息形成稳定前缀
- 缓存断裂检测 —
cache_break_detector主动监控失效并报告原因 - 仅追加策略 — 历史消息就地不改，保持前缀稳定
保护特性
| 特性 | 说明 |
|---|---|
| Hot Cache Bypass | 缓存已热时跳过不必要压缩以保留命中 |
| Anti-Thrashing | 检测并跳过重复低收益压缩周期 |
| 90% 安全网 | 上下文利用率 90% 时紧急压缩防 OOM |
| Cache-TTL Archive | 过期缓存条目归档（非删除）可恢复 |
思考内容管理
使用推理/思考模型（DeepSeek、MiMo、Kimi、Anthropic Claude）时，ThinkingBlockCleaner 自动管理 reasoning_content 与 thinking_blocks 防上下文膨胀：
- Anthropic — 移除
reasoning_content（与thinking_blocks冗余）；保留thinking_blocks - DeepSeek/MiMo/Kimi — 选择性移除末条用户消息之前的历史
reasoning_content，除带tool_calls的消息（API 要求）。当前轮推理始终保留 - 模型切换 — 会话中从非思考模型切到思考模型时，自动为历史 assistant 消息回填空
reasoning_content防 400 错误
极端场景防爆
大规模上下文与多模态自主任务下，Myrm 采用 4 层防护：1. 网关卫生（Token 阻断）
请求进 Harness 前，控制平面网关扫描载荷。超大恶意或畸形载荷（>120K tokens）即时400 Bad Request，防 LLM 节点 OOM 与系统 halt。
2. 辅助比例护盾（优雅降级）
主模型（如 200K 窗口）接近上限时用辅助模型压缩。若辅助模型过小（如 8K），传 100K tokens 会致命崩溃并丢历史。Myrm 动态检查比例；过小时静默降级用主模型摘要并警告，会话仍存活。3. 智能媒体剥离
视觉模型自主操作（如 Computer Use）会大量追加截图。Myrm 实现滑动视觉证据窗口，仅保留最近 2 条含媒体消息用于视觉推理，剥离更早历史中的大 Base64 图，大幅降 Token 膨胀且保持视觉能力。4. 尾部预算比例
非任意截断消息，而是为主模型最大上下文预留专用 Token 预算（如 20%）给最近对话尾部，确保当前工作记忆与活跃工具结果不被挤出，保证任务连续性。会话笔记
Agent 可在会话中创建结构化笔记 — 零 API 成本持久于上下文（无需 LLM 调用），是完整压缩的轻量替代。动态阈值
压缩阈值随上下文利用率自适应：| 利用率 | 动作 |
|---|---|
| 40% | 开始监控，准备压缩 |
| 50% | 轻压缩（去重、截断） |
| 70% | 全压缩（优先级移除） |
| 90% | 紧急压缩（安全网） |
辅助模型防护
用小 LLM 做摘要时，Myrm 动态检测辅助模型上下文窗口并在发送前截断消息，防小模型压缩时崩溃 — 任意输入规模均可优雅处理。后台任务的极致降噪与 Token 优化
Myrm 对后台辅助任务（如自动生成会话标题）的 Token 消耗进行了极致优化：- O(1) 截断与结构化剥离：精准剥离代码块、URL 链接、HTML 标签等对生成标题毫无帮助的“高 Token 密度”结构，只保留核心自然语言。
- 0 Token 拦截机制：如果经过降噪后文本为空（例如用户只发了一段代码），系统会直接触发本地兜底文案（如
Snippet），实现 0 Token 消耗，彻底避免无效的 API 调用。