6.5 本章小结

第六章将“对话变长就不稳”从模型能力问题转化为工程可控的问题：会话键决定状态归属，上下文构建控制注入顺序与预算分配，长期记忆文件承载稳定事实，裁剪（Pruning）与压缩（Compaction）保证长会话继续推进且便于回放与审计。

6.5.1 关键结论

• 会话先分桶再调优：作用域、身份链接与重置策略决定“是否串话、是否断档、是否可恢复”。

• 上下文要分层：身份先于知识，知识先于历史，历史先于工具回执；工具回注应结构化，避免原始输出堆积。

• 记忆要可维护：仅写稳定事实并附加来源与更新时间；过程噪声进入每日日志或证据文件。

• 裁剪与压缩要可验证：裁剪主要收敛模型输入体积，压缩则以可审计方式把早期对话折叠为摘要；两者都应保留可回放证据链。

6.5.2 端到端闭环示例

以下用一条消息的完整生命周期串联本章四节的核心概念：

1. 会话归属（6.1）：用户 Alice 在 Telegram 发送“帮我查一下 prod-cluster-us 的 Pod 重启次数”。系统根据当前渠道、对端身份、智能体归属与会话作用域规则推导出对应的 sessionKey，并命中已有会话。

2. 上下文组装（6.2）：Gateway 按优先级组装输入——先按 gate 注入 AGENTS.md / SOUL.md / TOOLS.md / IDENTITY.md / USER.md / HEARTBEAT.md / BOOTSTRAP.md 等项目上下文，再拼接当前会话在压缩/裁剪后保留的历史消息，并为本轮工具调用预留空间。

3. 记忆命中（6.3）：memory-core 会注入记忆工具使用指导；模型可按需调用 memory_search / memory_get，active-memory 也可能在满足条件时加入 preprompt，从而把“prod-cluster-us 使用指定服务账号运维”这类事实带入上下文。memory_recall 只在选择 LanceDB 等替代记忆插件时出现。

4. 工具调用与回注：模型决定调用 kubectl get pods 工具。工具返回 50K 字符的原始输出，系统将关键摘要（Pod 名 + 重启次数）回注进会话，全量结果落盘为证据文件。

5. 裁剪触发（6.4）：经过多轮交互，上下文达到 softTrimRatio 阈值。contextPruning 将 3 轮前的 kubectl 原始输出截为头尾各 1500 字符；更早的工具结果被 hardClear 替换为占位符，从而控制送入模型的输入规模。

6. 压缩触发（6.4）：会话接近 contextWindowTokens - reserveTokensFloor - softThresholdTokens 这个实际阈值时，预压缩记忆刷新机制先让智能体把关键进展写入 memory/2026-03-22.md，随后 Compaction 将更早的会话折叠为摘要并持久化到追踪历史中，同时保留回放线索。softThresholdTokens 是提前量，不是独立的触发总量。

排障时，可通过 sessionKey 在日志中追踪这条消息的完整链路：从会话归属 → 上下文组装 → 记忆检索 → 工具调用 → 裁剪/压缩，每个环节都有对应的 traceId 可供回放。

6.5.3 读者自检

• 能否解释某条消息落到哪个会话键，以及会话重置何时发生？

• 上下文组装时，四层信息源的注入顺序和优先级是否清晰？

• 长会话中输入体积是否可控，裁剪（Pruning）/压缩（Compaction）发生时能否在日志中对账？

• 记忆文件是否按规则维护（来源、更新时间、可撤销），并能被检索命中？

• 压缩触发后任务能继续推进，且回放链路可复现？

6.5.4 下一章预告

第七章进入多智能体与路由：把入口收敛为可控触发面，并用绑定、路由与协作模式把“由谁接管、能做什么、如何回放”做成确定性边界。