官方 compact 加密块卡在厂商边界

官方 compact 机制把压缩后的对话摘要封装成加密块。这种设计在单一模型环境下工作良好，但一旦 Chatbot 决定切换底层大模型，加密块就过不了厂商边界。不同厂商的 API 对消息格式的校验规则不同，加密块被直接拒绝，导致整个长对话历史无法继续使用。

这不是理论问题，而是真实工程场景里反复出现的卡点。很多自研 Chatbot 早期依赖某一家厂商的官方 compact 功能，积累了大量压缩后的历史记录。换模型时，这些记录全部失效，用户对话突然被截断，上下文丢失。开发者不得不重新设计压缩逻辑，把 compact 从厂商绑定状态解放出来。

官方加密块的本质是把压缩结果当作特殊系统消息处理。这种特殊性带来了便利，也带来了强绑定。厂商通过加密确保压缩内容不被篡改，同时也把这部分能力锁死在自家模型生态内。跨模型使用时，新的模型既无法解密，也无法识别这个特殊消息类型，最终只能丢弃。

从实际工程角度看，这暴露了当前主流 LLM 应用架构的一个普遍痛点：上下文管理与模型推理服务往往深度耦合。很多团队在初期为了快速上线，选择直接使用厂商提供的上下文压缩接口，却没有预留切换模型的余地。等到业务增长或成本压力出现，需要换模型时，才发现 compact 成了最大障碍。

自研 compact 用旧段摘要加近窗原文

自研方案不再依赖官方加密块，而是自己构造压缩输入。具体做法是取出较早的对话段落摘要，再拼接最近窗口内的原始对话文本，把这两部分一起发给新模型，让它生成新的压缩结果。

旧段摘要保留了历史对话的核心信息，近窗原文则保证最近几轮对话的细节不丢失。这种混合输入方式让模型在压缩时既有全局视野，又能抓住当前焦点。相比只发原始长文本，这种做法显著降低了输入 token 数，同时保留了足够的关键信息。

在实际实现中，开发者需要仔细设计摘要的粒度和近窗的大小。摘要太短会丢失重要事实，近窗太小则可能遗漏最近的用户意图。很多团队会根据具体业务场景反复调优这两个参数，比如客服类 Chatbot 可能更重视历史事实的准确性，而创意对话类应用则更看重最近几轮的情绪连贯性。

这个自研 compact 流程本质上是把原来厂商封闭的能力开放出来。开发者现在可以完全控制压缩的时机、输入内容和输出格式，不再受单一模型限制。这也意味着每次模型升级或切换时，都能平滑迁移历史对话记录，而不需要用户从头开始。

压缩结果做成可跨模型的普通消息

压缩完成后，最关键的一步是把结果转成普通消息格式，而不是继续使用特殊加密块。这样新模型就能像处理普通用户消息一样读取它，不需要任何特殊解密逻辑。

具体做法通常是把 compact 后的文本包装成一条系统消息或助手消息，放在对话历史的最前面。新的模型切换进来后，直接就能看到这条压缩消息，从而继承之前的对话上下文。这种方式彻底打破了厂商边界，只要模型支持标准消息格式，就能无缝衔接。

把压缩结果做成普通消息还有一个额外好处：调试和监控变得更容易。开发者可以直接查看压缩内容是否准确，是否遗漏了关键信息，而不需要去解析加密块。运维团队也能更方便地追踪上下文长度变化，及时发现潜在的 token 溢出风险。

这种设计体现了当前 LLM 应用架构的一个重要趋势：把上下文管理从模型服务层上移到应用层。应用层掌握压缩逻辑和消息格式，就能更灵活地适配不同厂商、不同版本的模型。这虽然增加了应用侧的开发工作量，但显著降低了长期的切换成本。

上下文窗口限制下的 token 成本压力

当前主流大模型的上下文窗口虽然不断增大，但实际可用的有效窗口仍然有限。长对话积累几十轮后，token 消耗迅速上升，直接推高推理成本。compact 操作正是为了对抗这种压力而存在的。

以目前常见的 8k 到 32k 窗口模型为例，一次长对话很容易就把窗口塞满。每次调用都要把全部历史重发一遍，token 用量和费用随之水涨船高。compact 把历史浓缩成几百 token 的摘要，能把单次调用成本降低 60% 到 80%，对商业应用来说是实打实的节省。

除了成本，窗口限制还直接影响响应速度。输入 token 越多，模型推理时间越长，用户等待时间也越久。自研 compact 能在保持对话连贯性的同时，把输入长度控制在合理范围，既控制了成本，也改善了用户体验。

在实际工程中，团队通常会设置动态 compact 触发机制。当历史 token 数接近窗口上限的 70% 时自动启动压缩。这种主动管理方式避免了突然的上下文截断，也让成本曲线更加可预测。很多中大型 Chatbot 项目都把 compact 模块当作核心基础设施来维护。

模型切换时用户体验的连续性保障

对用户来说，最糟糕的体验是换模型后对话历史全部消失，不得不把之前说过的话再重复一遍。自研 compact 方案有效避免了这种情况，让用户感觉不到后台模型的切换。

中文用户对对话连贯性尤其敏感。很多垂直领域 Chatbot 承载着用户长期积累的偏好、历史事件和特定术语。如果上下文突然断裂，用户需要花费大量精力重新解释背景，这会显著降低产品粘性。自研 compact 保留了这些关键信息，让切换过程对用户几乎透明。

从开发者角度看，这套方案也降低了模型迁移的风险。过去切换模型往往意味着用户数据重置，现在则可以做到平滑过渡。这对希望尝试不同厂商最新模型的团队来说，是一个重要的能力保障。

实际效果上，很多采用自研 compact 的 Chatbot 在模型切换后，用户留存率和对话时长都没有明显下降。这说明技术方案已经比较成熟，能够在不牺牲体验的前提下完成底层模型的更替。

目前仍未解决的边界与兼容问题

尽管自研 compact 解决了官方加密块的跨厂商问题，但仍存在一些边界情况没有完全解决。比如不同模型对相同内容的压缩效果差异很大，同一个摘要在新模型上可能丢失部分语义。

另外，压缩后的普通消息虽然能跨模型，但无法保证所有厂商都同样重视系统消息的权重。有些模型可能会弱化早期系统消息的影响，导致压缩内容的作用被稀释。目前开发者主要通过反复测试不同模型组合来缓解这个问题，但还没有形成通用解决方案。

未来随着模型能力提升和窗口进一步扩大，compact 的必要性可能会降低。但在可预见的几年内，token 成本和窗口限制仍将是主要矛盾，自研 compact 仍将是多数中大型 Chatbot 项目的必备模块。

目前还不清楚各大厂商是否会推出真正开放、可跨模型的 compact 标准。如果出现这样的标准，开发者将能进一步降低维护成本。但在标准落地之前，自行实现 compact 仍然是应对模型切换最现实的做法。

参考来源