导读：Kimi Code近期更新针对413上下文溢出先压缩再重试，并限制压缩输出，避免再次超过服务端max_tokens。长任务真正的问题不是窗口数字，而是工具日志、重复文件和旧对话持续堆积。盲目压缩又可能丢失约束，因此需要结构化任务状态与证据索引。
哪些内容最容易撑爆上下文
完整构建日志、压缩后的单行JSON、重复读取文件、大段依赖代码和多轮失败输出增长最快。工具层应先截取关键错误、保存文件路径，再按需读取。不要每轮重复发送稳定项目规则。
图像和媒体先按模型限制压缩，保留原文件地址与尺寸。代码只加载当前任务相关区域，仓库索引与搜索结果代替全量拼接。
压缩前保存结构化状态
状态包含目标、不可违反约束、已读文件、已改文件、测试结果、待办和风险。关键决定链接到提交或日志文件。压缩后先核对状态，不直接继续执行。
需求原文、用户批准和安全限制不可被普通摘要替代。将它们放在固定系统层或任务文件。临时讨论与已完成工具输出可以压缩。
重试必须幂等
413后自动重试前确认前一次没有产生写入副作用。创建文件、工单、数据库记录和部署都用唯一操作ID并先查询状态。不能因为模型没收到响应就假设操作失败。
每步骤限制重试次数，连续同类错误暂停并报告。官方配置支持每步骤重试上限，生产任务应低于默认宽松值，并设置总运行时间和Token预算。
恢复质量如何验收
准备长任务中途压缩样本，检查模型是否记得接口契约、用户选择、改动范围和未解决风险。比较压缩前后测试通过率、重复工具调用和错误修改。
压缩摘要保存版本和生成模型。必要时允许人工编辑关键状态。任务结束将长期规则写回项目文档，临时轨迹归档，不依赖会话永久记忆。
执行清单
- 截断工具噪声并按需读取文件。
- 压缩前保存目标、约束、改动和测试状态。
- 写操作使用唯一ID与存在性检查。
- 限制步骤重试、总时间和Token预算。
- 用中途压缩样本测试约束保留能力。
总结
上下文溢出是长任务的工程问题，不只是模型窗口问题。减少噪声、保存结构化状态并保证重试幂等，Kimi Code才能在压缩后继续正确工作。
