人工智能AI Agent代码智能体自主智能体MCP ClientsCLI【免费下载链接】atomcodeClaude Code 的开源替代方案。连接任意大模型编辑代码运行命令自动验证 — 全自动执行。用 Rust 构建极致性能。 An open-source alternative to Claude Code. Connect any LLM, edit code, run commands, and verify changes — autonomously. Built in Rust for speed. Get Started项目地址https://gitcode.com/atomgit_atomcode/atomcode点击查看免费下载导读在 atomcode 的 Rust 内核中自动上下文压缩compaction是防止长会话上下文溢出、维持模型窗口利用率的关键机制。但早期实现只在handle_prompt接受用户或宿主注入的合成提示词时触发而输出截断恢复、LifecycleHooks驱动的验证继续verification continuation这类内核内部继续会绕过该入口导致长时间 Hook 驱动循环可能一路越过compact_threshold却始终得不到压缩机会。本文基于 内部继续压缩设计文档结合 内核实现、消息与策略模型 与 测试套件完整还原其问题、设计边界、阶段限流与失败语义。读完你将理解内核如何在不新增压缩策略、不改变持久化模型的前提下让每类内部继续在追加合成消息前获得一次自动压缩机会以及如何通过will_summarize判定做到中等压力不刷屏、高压力不被压制。一、问题自动压缩的两条入口之间存在盲区atomcode 内核的自动压缩策略围绕compact_threshold上下文窗口利用率阈值工作。文档明确指出原有自动压缩只发生在一条路径上handle_prompt接受用户或宿主提供的合成提示词。这覆盖了通过AgentCommand::SendSyntheticMessage派发的 Goal-controller 继续——在 engine.rs 的命令分发 中可以看到SendSyntheticMessage与SendMessage走完全相同的路径process_send_message→PromptKind::Synthetic→ 任务边界压缩 → 回合执行。问题出在内核内部继续上。文档列出两类典型的绕过入口输出截断恢复output-truncation recovery模型回复因输出 token 上限被截断且没有产生工具调用时内核判断回复未完成注入一条继续写完的合成用户消息并启动新一轮模型调用LifecycleHooks::offer_typed_continuationHook 链在模型停下时主动返回一个Continuation如验证节奏VerifyCadence内核将其作为合成消息追加并继续。这两类继续直接在run_turn内部追加合成消息绕过了handle_prompt这个拥有任务边界压缩检查的入口。文档点出的核心风险是一个漫长的 Hook 驱动验证或恢复循环可以一轮又一轮地追加消息、反复调用模型却始终不触发已有的压缩策略——上下文利用率和消息总量持续增长最终越过compact_threshold甚至逼近窗口上限。二、设计在内部继续的安全边界复用既有压缩管线文档给出的解决方案非常克制不引入新的压缩策略、命令或持久化模型而是在内部继续被追加之前的安全边界上复用内核已有的两个构件should_compact压力检查——判定当前历史是否达到自动压缩触发条件run_compaction策略执行——把压力事实交给注入的CompactionStrategy规划并执行压缩。选这个边界的原因在文档中写得很清楚此时具备三个安全前提Provider 流已经结束本轮模型调用已完成Assistant 消息及其元数据已经存储meta.used_tokens、meta.ctx_window等压力事实已冻结可供should_compact读取没有工具调用挂起或正在执行不会出现压缩与工具执行交错的状态竞争。因此在语义上这个边界与回合结束、新回合开始的任务边界几乎等价只是发生在同一个回合turn内部的继续之前。文档同时强调这保持了CodingRuntime 作为唯一生命周期所有者的地位——压缩时机由内核统一决定宿主层不需要为内部继续引入额外的压缩编排。三、核心机制 1压力检查should_compact与窗口解析先看内核如何判定该压缩了。在 engine.rs 的should_compact中判定逻辑是从会话历史倒序找到最后一条 Assistant 消息读取其冻结的meta.used_tokens原始提示 token 数与meta.ctx_window记录窗口用当前模型窗口live window重新计算利用率而非使用存储的利用率比值——文档注释解释了原因存储的比值如针对 1M 窗口记录的 0.23在切换到更小窗口模型后会失真必须基于新窗口重新评估否则首次发送就可能溢出窗口调用auto_compact_triggerengine.rs计算utilization used_tokens / ctx_window当utilization threshold时返回CompactTrigger::Auto { utilization }窗口未知ctx_window 0时返回None不采取行动。窗口解析还有一层保险effective_compact_windowengine.rs优先使用 live 窗口当 live 窗口未知但存在记录窗口时用记录窗口截断到保守下限UNKNOWN_WINDOW_SAFE_FLOOR 128_000对应 serde 默认context_window。文档与注释都指出这修复了 issue #1499 的over-window 400模型切换后若未能上报新窗口仍会按一个合理预算判定压力而不是按旧的大窗口算出偏低的利用率、跳过压缩、最终把超窗请求发给 Provider 被 400 拒绝。should_compact是纯读操作不改动会话因此可以被安全地嵌入继续边界。四、核心机制 2compact_before_internal_continuation与每阶段一次限流新引入的边界函数是 engine.rs 的compact_before_internal_continuation它承担两个职责1判定策略阶段stage内部继续复用run_compaction的同一套窗口解析计算出utilization然后调用策略的will_summarize(CompactionView)得到一个布尔值映射为阶段下标usize::from(...)即 0 或 1。will_summarize是 message.rs 中CompactionStrategytrait 上的廉价、无 LLM 调用的副作用预检返回true表示该策略在本次压力下将执行慢速的排干旧回合并生成 LLM 摘要工作返回false则表示只会做快速的就地 stub 或直接 no-op。2每阶段每回合最多尝试一次函数接收调用方持有的attempted_stages: mut [bool; 2]——每回合初始化一次engine.rs 的run_turn中let mut internal_auto_compaction_attempted_stages [false; 2];。如果当前阶段已被尝试过就直接返回否则标记后调用run_compaction。这个设计的精妙之处在于防止两类错误防止无操作抖动no-op thrashing中等压力下策略可能给出重写/无操作的温和计划如 stub 几个工具结果如果每次继续都重复执行它会徒增开销甚至反复触发防止过早压制suppression记录温和阶段已尝试不等于永远放弃——当压力继续升高、will_summarize判定进入高压力摘要阶段时即使第一阶段已尝试过第二阶段仍然可以触发真正的 drainsummarize。也就是说[false; 2]的两个槽位分别对应温和阶段与摘要阶段各自独立计数互不阻塞。五、共享边界截断恢复与 Hook 验证继续走同一条路compact_before_internal_continuation被两处调用正是文档所说的同一边界由 output-limit recovery 和 hook-driven verification continuations 共享。调用点 1输出截断恢复。在 engine.rs 的回合主循环 中当truncated !redump且截断继续次数未超过MAX_TRUNCATION_CONTINUATIONS常量为 4见 engine.rs时内核发出OutputTruncationRecovery事件、调用压缩边界函数、然后convo.push(Message::synthetic_user(TRUNCATION_RESUME_NUDGE))继续。注意truncation_is_redump检查如果模型上一轮原样重灌了相同内容而不是继续写就不再盲目催它避免空转。调用点 2Hook 类型化继续。在 engine.rs 的offer_typed_continuation消费点 中Hook 链返回的Continuation被完整解构text、kind、visibility在追加Message::synthetic_user(text)之前先调用压缩边界函数。这里还叠加了安全熔断max_continuations默认Some(50)可传None解除见 engine.rs一个永远返回Some的offer_continuationHook 会被计数截断避免内核驱动无限循环。Hook 侧的语义在 hook.rs 中定义得相当清晰offer_continuation返回OptionString注入后续用户消息offer_typed_continuation则返回OptionContinuation其中ContinuationKind区分Generic/VerifyCadence/TruncationResumeContinuationVisibility区分Normal/InternalControlverify_cadence构造器默认标记为内部控制可见性见 hook.rs。多条 Hook 通过 HookChain 顺序观察第一个Some生效后续被忽略。六、保持不变的既有路径明确的不变式文档用一段清单划定了行为边界避免新机制污染既有语义。以下路径不经过新的内部继续压缩边界保留原有行为路径说明正常回复模型自然停止、无工具调用正常结束回合工具执行工具调用循环内的执行/结果应用外部 Goal 合成提示词SendSyntheticMessage走handle_prompt已拥有任务边界压缩手动压缩AgentCommand::Compact无论阈值如何都触发见 compaction.rs 测试Overflow 恢复Provider 拒绝超窗请求时的硬恢复路径CompactTrigger::Overflow专门驱动其升级阶梯取消与 Provider 重载各自的既有处理路径这种只新增一条内部继续边界、其余一概不动的取向正符合 文档 强调的不引入另一种压缩策略、命令或持久化模型的约束。七、失败语义best-effort 与事件契约自动压缩在内部继续路径上保持best-effort尽力而为其失败语义与既有压缩完全一致成功发出AgentEvent::Compacted携带triggerAuto/Manual/Overflow、epoch缓存世代、removed移除消息数、bytes_before/bytes_after、committed标志见 event.rs被拒绝/无操作同样发出Compacted但committed false——例如策略返回 no-op 计划或apply_plan的净损失保护net-loss guard判定摘要后上下文反而变大时拒绝提交历史字节不变、epoch不变、removed 0参见 net_loss_plan_is_refused_no_epoch_bump 测试失败AgentEvent::CompactionFailed仅在手动压缩的持久化检查点保存失败时发出CompactionCheckpointError对话与缓存世代保持原样event.rs。关键保证无论压缩计划是失败还是被拒绝都不会丢弃会话状态——内部继续照常以原始对话继续执行。压缩只是顺势而为的机会不是继续的前提。压缩执行本身走 engine.rs 的run_compaction构建只读的CompactionView含messages借用、trigger、ctx_window、used_tokens、utilization、sacred_floor若will_summarize为真则先发CompactionStarted供驱动显示 compacting… 进度行调用策略plan再由内核独占执行prepare_plan/commit_prepared——策略永远只提议、内核永远是唯一写者这保证即使策略有缺陷也无法破坏神圣前缀sacred floor、净损失或缓存世代等不变量。可替换策略的模型定义在 message.rsCompactionStrategy是单实现、只规划PLAN-ONLY的注入点且约定实现绝不能 panicworkspace 采用panic abort时 panic 会直接终止宿主进程。八、配套实现压力侧的策略与配置要理解will_summarize阶段判定在真实策略中如何工作需要看默认策略的实现StubCompactioncompaction.rs默认策略缓存友好的 stub 压缩。它对保护窗口按上下文窗口缩放的 token 预算recent_keep_budget之外的、大于MIN_COLLAPSE_SIZE 500字节的工具结果做就地重写为一行摘要 stub默认豁免read_file避免模型虚假自信地重复编辑同一文件。纯就地 stub不排干、不摘要、无恢复注记——因此will_summarize默认返回false对应温和阶段OverflowCompactioncompaction.rs溢出恢复策略其 will_summarize 在升级阶梯到达摘要档位时返回true对应摘要阶段。配置侧产品层通过 atomcode-coding 的compact_threshold控制类型为f32语义是真实利用率Provider 上报的提示 token 相对当前窗口的比例达到该值即触发任务边界压缩默认值0.7设置 1.0可等效禁用。该配置经由 on_harness.rs 的组装 以CompactionTailPatch { threshold: cfg.compact_threshold, keep_turns: 2 }注入运行树。九、验证矩阵测试如何守卫新边界文档承诺了三类测试验证对应到 compaction.rs 测试套件 与内核测试中超过阈值的 Hook 继续 → 继续前产生压缩事件利用注入的SummarizeOldestStrategy加compact_threshold(0.5)构造上一回合已越阈的历史断言在继续/新回合边界处恰好发出一次Compacted参见 injected_strategy_compacts_at_task_boundary 对恰好在边界、恰好一次的断言模式低于阈值的继续 → 不压缩default_kernel_never_compactscompaction.rs验证默认无阈值/无策略时任何回合都不发Compactedcache_epoch保持 0——这是不误伤的基准线既有截断/压缩套件行为不变包括手动压缩的CompactionStarted先于Compacted顺序、no-op 手动压缩仍发出committed: false的Compacted、提交压缩后利用率下降且不再重复触发committed_compaction_relieves_pressure_and_does_not_refire、压缩开启新缓存世代并保留系统前缀compaction_opens_new_epoch_preserving_system_prefix等。此外 hook.rs 测试 验证了offer_typed_continuation将旧式纯文本继续包装为Generic可见继续的兼容行为。十、小结与阅读索引内部继续压缩的本质是把任务边界已有的压力检查能力以最小侵入的方式平移到回合内部的继续边界复用should_compact判定压力、复用run_compaction执行计划、用will_summarize划分两个独立计数的策略阶段防止抖动与压制同时明确所有既有路径不受影响。它让截断恢复和 Hook 驱动的验证/恢复循环在上下文增长上获得了与外部提示词完全同等的刹车机会而不需要为内部继续设计第二套压缩世界观。如需深入可按以下路径继续阅读仓库源码设计文档docs/plans/2026-08-06-internal-continuation-compaction-design.md边界函数与调用点engine.rs 的compact_before_internal_continuation、截断恢复调用、Hook 继续调用压力与窗口解析engine.rs 的should_compact/auto_compact_trigger/effective_compact_window策略契约与数据模型message.rs 的CompactTrigger/CompactionView/CompactionPlan/CompactionStrategy事件契约event.rs 的CompactionStarted/Compacted/CompactionFailed默认策略实现atomcode-capabilities 的StubCompaction与OverflowCompaction产品层配置atomcode-coding 的compact_threshold测试套件compaction.rs 全量测试赞分享人工智能AI Agent代码智能体自主智能体MCP ClientsCLI【免费下载链接】atomcodeClaude Code 的开源替代方案。连接任意大模型编辑代码运行命令自动验证 — 全自动执行。用 Rust 构建极致性能。 An open-source alternative to Claude Code. Connect any LLM, edit code, run commands, and verify changes — autonomously. Built in Rust for speed. Get Started项目地址https://gitcode.com/atomgit_atomcode/atomcode点击查看免费下载相关推荐CodePilot 会话管理与上下文压缩实战脱离 SDK 的自管理恢复与三层压缩体系CodePilot 会话管理与上下文压缩实战脱离 SDK 的自管理恢复与三层压缩体系 本文基于 docs/research/session managemen人工智能AI 应用AI Agent交互助手MCP Clients本地部署OpenChamber 上下文必读Context Obligatory机制会话压缩后固定消息的自动恢复原理与实现OpenChamber 上下文必读Context Obligatory机制会话压缩后固定消息的自动恢复原理与实现 导读 本文深入解析 OpenChambeAI Agent人工智能代码智能体交互助手Crush 会话自动摘要summary.md 提示词模板与上下文压缩机制全解析Crush 会话自动摘要summary.md 提示词模板与上下文压缩机制全解析 导读 本文围绕 Crushcharmbracelet/crush的会话自动AI 应用代码智能体交互助手CLIMCP Clients人工智能上一篇Flut Renamer让文件命名从混乱到优雅的故事下一篇PhotoRec专业级数据恢复神器从误删到格式化的全方位救援方案创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考