先判断是不是这个问题
出现下面任一症状，就按本手册处理：
prompt too longfailed to compact context- 同一任务在长会话里突然开始答非所问
参考文档：
第 0 步：先采样，不要盲改（3 分钟）
每次报错先记这 5 个字段：
sessionIdchannel- 最近消息轮数
- 是否触发过 compaction/pruning
- 失败发生阶段（生成前/生成中/工具后）
第 1 步：30 分钟止血流程
1. 降历史窗口
先把历史窗口收窄到可控范围（示例：最近 8-12 轮）。
目标是先恢复可用，不是一次做最优解。
2. 强制任务分片
把单次大请求拆成 3 段：
- 收集信息
- 生成草稿
- 校验与修正
每段单独发起，避免“一条请求塞完整流程”。
3. 开启或收紧 pruning
没有 pruning 就先启用；有 pruning 但失败，就先降低历史进入量再调策略。
第 2 步：用这个模板拆任务（可直接复制）
你现在只做第 1 段：提取关键输入，不要生成最终答案。
输出格式：
1) 关键事实（最多 8 条）
2) 缺失信息（最多 5 条）
3) 下一段需要的输入
你现在只做第 2 段：基于上一步关键事实生成草稿，不要扩展新主题。
输出格式：
1) 草稿正文
2) 待核对项
你现在只做第 3 段：检查草稿中的错误与冲突，给出修正后版本。
输出格式：
1) 发现的问题
2) 修正后的最终版本
第 3 步：回归测试（10 次）
同一类型请求连续跑 10 次，记录：
- 报错次数
- 平均响应时间
- 是否出现上下文污染
通过标准：
- 10 次中 0 次 overflow 报错
- 结果结构稳定
- 失败可复现并可定位
失败对照表
-
总是第 1 轮就超长
动作：检查输入模板是否一次带入太多背景 -
长会话后才超长
动作：优先收紧历史窗口 + pruning -
compaction 常失败
动作：先减输入量，再调 compaction，不要反过来
近期案例（建议持续跟踪）
下一步
把这套排障并入监控：