> ## Documentation Index
> Fetch the complete documentation index at: https://docs.profy.cn/llms.txt
> Use this file to discover all available pages before exploring further.
# 上下文引擎
> 智能上下文管理——压缩、恢复、与无限对话的艺术
大语言模型有一个物理限制：上下文窗口。无论模型多聪明，它一次能「看到」的信息量是有限的。袋袋的上下文引擎解决了这个矛盾——让专家在有限的窗口中保持对无限长对话的理解力。
## 两大核心机制
```mermaid theme={null}
graph TB
subgraph 上下文引擎
Compaction[上下文压缩
Context Compaction]
Recovery[输出恢复
Output Recovery]
end
Long[超长对话历史] --> Compaction
Compaction --> Fit[适配模型窗口]
Truncated[输出被截断] --> Recovery
Recovery --> Complete[完整的回复]
```
当对话超出模型窗口时，智能总结旧消息，释放空间给新内容——而不丢失关键信息。
当模型的单次输出超出 Token 上限时，自动检测并无缝续写——用户完全无感知。
***
## 上下文压缩：五层管线
上下文压缩不是简单的「删除旧消息」——它是一个精细的五层管线，每一层处理不同粒度的信息压缩：
```mermaid theme={null}
graph TD
Input[原始对话历史] --> L1[第一层: 工具结果预算
单轮总量管控]
L1 --> L2[第二层: 历史工具结果收缩
旧轮次结果压缩]
L2 --> L3[第三层: 冷区消息折叠
远端消息摘要化]
L3 --> L4[第四层: 记忆刷出
关键信息转移到长期记忆]
L4 --> L5[第五层: 实时工具输出压缩
过长结果即时截断]
L5 --> Output[精简后的上下文
≤ 模型窗口]
```
### 第一层：工具结果预算
当一轮对话中有多个工具调用（比如专家并行搜索 10 个网页），所有工具结果的总量受聚合预算管控。超出预算的结果会被按优先级截断。
### 第二层：历史工具结果收缩
越早的消息中的工具结果，对当前决策的参考价值越低。这一层自动将旧轮次的工具输出压缩为摘要——保留「做了什么、结论是什么」，丢弃原始细节。
### 第三层：冷区消息折叠
对话中最早的一批消息（「冷区」）被 AI 摘要为一段结构化总结，作为系统消息注入。摘要保留：
* 用户的关键决策和偏好
* 重要的工具执行结果
* 对话中建立的约定和上下文
### 第四层：记忆刷出
在压缩发生前，将对话中识别出的有长期价值的信息（用户偏好、项目上下文、关键决策）写入专家的长期记忆。即使对话消息被折叠，这些信息不会丢失。
### 第五层：实时工具输出压缩
工具执行返回的结果如果过长（比如一个 `bash` 命令输出了数千行日志），在进入对话状态之前就被智能截断：
| 工具类型 | 压缩策略 | 保留逻辑 |
| ---- | ---- | ---------------- |
| 命令执行 | 头尾保留 | 保留开头 + 结尾，中间折叠 |
| 文件读取 | 头部保留 | 保留开头，提示「需要时重新读取」 |
| 网络搜索 | 头尾保留 | 保留核心摘要和关键片段 |
| 文件写入 | 不压缩 | 写入确认是短文本，无需压缩 |
压缩策略的设计哲学是「宁可让 AI 重新获取，也不要给它错误的半截信息」。文件读取被压缩后，AI 可以随时再次调用 read 工具获取完整内容。
## 输出恢复：透明续写
有时候专家需要生成很长的内容——一篇完整的文章、一个复杂的代码文件、一份详尽的分析报告。当输出长度超过模型的单次最大 Token 限制时，输出恢复机制会自动接管。
### 工作原理
```mermaid theme={null}
sequenceDiagram
participant LLM as 大模型
participant RT as Runtime
participant User as 用户
RT->>LLM: 推理请求
LLM-->>RT: 输出 tokens...
LLM-->>RT: ⚠️ 达到 max_tokens 限制
RT->>RT: 检测截断信号
Note over RT: 自动恢复 (用户无感知)
RT-->>User: 继续流式输出 >>>
RT->>RT: 压缩已截断内容为尾部锚点
RT->>LLM: 携带尾部锚点 + 续写指令
LLM-->>RT: 继续输出...
LLM-->>RT: ✅ 正常结束
RT-->>User: 完成
```
Runtime 监听模型的停止信号——不同供应商有不同的截断标记（`max_tokens`、`length`），统一识别。
被截断的输出可能长达数万 Token。将其压缩为最后约 2000 字符的「尾部锚点」——AI 只需要知道它「说到哪了」就能续写。这一步节省了 91% 的重复输入成本。
注入一条特殊指令："你的输出被截断了。直接从中断处继续，不要道歉，不要复述，不要摘要。"
如果截断发生在工具调用的参数中间，自动剥离不完整的工具调用，指示 AI 重新发起完整的调用。
最多恢复 3 次。如果 3 次恢复后仍未完成，展示一个「输出被截断」提示并提供「继续生成」按钮。
### 用户体验
整个恢复过程对用户完全透明：
| 场景 | 用户看到的 | 实际发生的 |
| ---- | ------------------- | ------------- |
| 正常回复 | 文字流畅出现 | 单次模型调用 |
| 超长回复 | 文字流畅出现（无中断） | 2-4 次模型调用自动拼接 |
| 极长回复 | 文字 + 🟡 截断提示 + 继续按钮 | 4 次恢复仍未完成 |
输出恢复不是「让 AI 写得更多」的 hack——它是对模型物理限制的工程化解决方案。就像网络传输中的分包和重组一样自然。
## 反应式压缩
除了预防性的分层压缩，系统还有一道反应式防线：
当模型调用返回一个上下文溢出错误时（某些供应商会直接拒绝过长输入），Runtime 不会简单报错——而是：
1. 识别溢出信号
2. 触发紧急压缩（更激进的摘要策略）
3. 用压缩后的上下文重新发起请求
用户看到的只是一个短暂的「正在思考」——甚至不会意识到后台发生了溢出和恢复。
## 智能摘要的质量保证
上下文压缩的核心挑战不是技术实现，而是「不丢失关键信息」。袋袋的摘要策略遵循几个原则：
用户明确做出的决策（「用 React」「不要 TypeScript」「预算 1 万」）在摘要中享有最高优先级，永不被压缩掉。
工具执行的结论（「文件创建成功」「测试通过 42/42」）比执行过程（完整的命令输出）更重要。
文件内容可以被 AI 重新读取，网页可以重新搜索——这类信息在空间紧张时优先被压缩。但用户口头描述的需求无法重获取，必须保留。
最近 2-3 轮的对话保持完整原文；更早的消息逐步被更高层次的摘要取代。这模拟了人类的记忆衰减——近期事件细节清晰，远期只记得要点。
## 与记忆系统的协作
上下文引擎不是独立工作的——它与专家的长期记忆系统深度协作：
```mermaid theme={null}
graph LR
Conv[当前对话] --> CE[上下文引擎]
CE --> |压缩前刷出| Memory[长期记忆]
Memory --> |检索相关记忆| CE
CE --> Context[最终上下文]
subgraph 上下文组成
Context --> Recent[近期消息
完整原文]
Context --> Summary[冷区摘要
结构化总结]
Context --> Mem[记忆注入
长期关联信息]
end
```
每次构建上下文时，系统先从记忆中检索相关信息，再加上当前对话历史（经过压缩），共同构成 AI 的「工作记忆」。这让专家既能记住上周的对话要点，又能保持当前对话的流畅性。
上下文引擎的终极目标是让用户感觉在和一个「记忆力无限」的 AI 对话，而实际上它在有限的窗口中精心管理着信息的取舍。