上下文太长怎么办——Token 限制与压缩策略
先理解 Token
Token 是大模型处理文本的最小单位：
- 1 个英文单词 ≈ 1~2 token
- 1 个汉字 ≈ 1~3 token
- 1 个代码 token（变量名 / 操作符）≈ 1 token
K3 的 1M token 上下文窗口 ≈ 75 万汉字。
上下文太长的表现
当 Session 接近 token 上限时，你会观察到这些现象：
| 表现 | 原因 |
|---|---|
| Kimi "忘记"早期说的细节 | 早期内容被自动压缩成摘要 |
| Kimi 回答里提到了不存在的细节 | 压缩过程中信息丢失或扭曲 |
| 响应变慢 | Token 越多，模型推理越慢 |
| 界面提示"建议开始新对话" | Session 接近上限 |
Kimi 的自动压缩机制
Kimi 在后台自动管理上下文窗口：
- 正常范围（< 80% 窗口）：所有历史完整保留
- 接近上限（80%~95%）：最早的 Turn 开始被摘要压缩
- 超过上限（> 95%）：最早的 Turn 被截断移除
压缩过程：
原始 Turn 1: "本次对话讨论了 XX 项目的架构，选择了 React + Node.js + PostgreSQL，
原因是：1. React 生态成熟 2. Node.js 前后端统一 3. PostgreSQL
支持丰富的数据类型..."
压缩后: "Turn 1: 讨论 XX 项目架构 → React + Node.js + PostgreSQL，原因：生态 + 统一 + 数据类型"压缩的好处：保留关键信息、节省 token 空间。压缩的代价：丢失细节（具体原因、备选方案的讨论、权衡过程）。
手动延长上下文的三种策略
策略一：主动让 Kimi 做阶段性总结
这是最简单、最推荐的方式。每隔 20~30 个 Turn，主动说：
总结一下本次对话里讨论过的所有关键决定和信息点
Kimi 会生成一份结构化总结。你可以：
- 让 Kimi 把这份总结当成后续对话的"锚点"（它会自动做）
- 或者复制这份总结 → 开一个新 Session → 把总结粘进去当起点
策略二：拆分独立任务
如果你的 Session 已经膨胀到接近上限：
- 暂停当前 Session（不要继续往里加内容）
- 让 Kimi 生成一份"当前状态快照"：
给我一份目前已完成了什么、还剩下什么的结构化清单
- 保存这份快照
- 开新 Session → 把快照粘进去 → 继续剩余任务
策略三：用文件代替上下文
不要把大段内容直接粘在对话里：
- 上传 PDF / Word / Excel 作为文件 → Kimi 会在需要时读取
- 给文件起有意义的名字（不要
文档1.pdf） - 告诉 Kimi "在处理中参考我上传的 XXX 文件"
文件解析是独立通道，不占用对话上下文 token。
各模型的上下文窗口
| 模型 | 上下文窗口 | 适合什么 |
|---|---|---|
| K2.6 | 较小（可能 128K~200K） | 简单问答、短文本 |
| K3 | 1M token | 长文档处理、复杂多步骤任务 |
| K3 Swarm | 同 K3 | 并行 + 长上下文 |
1M token 的 K3 能做什么？
- 一份 500 页 PDF（约 15~20 万字）直接上传 → Kimi 能完整理解并处理
- 一个完整的代码库（几百个文件、几万行代码）→ Kimi Code 能完整读取并分析
- 万字级深度研究报告的完整生成过程（搜索 + 分析 + 写作全在一个 Session）
什么时候真的需要 1M token
| 场景 | 估算 token |
|---|---|
| 普通问答（5 轮） | ~5K |
| 代码审查（一个文件） | ~10K |
| 3 万字 Word 文档处理 | ~50K |
| 万字研究报告生成 | ~200K |
| 500 页 PDF 解析 | ~300K |
| 完整代码库分析 | ~500K |
| 极长对话（50+ Turn） | ~500K~800K |
继续阅读
- Session 与 Turn 基础：核心概念理解
- 新 Session vs 长对话：什么时候该开新对话
- Agent 工作原理：Agent 的上下文管理
- K3 模型选择：模型和上下文窗口的关系