Codex 上下文管理策略 — 对课题十三与课题二的参考价值评估
评估日期：2026-06-01
对课题十三（推理成本优化与模型路由策略）
可直接融入的设计
1. Prompt Caching 的 stateless 模式
- 课题十三的”共享上下文窗口（复用 KV cache）“可以完全参考 Codex 的精确前缀策略
- 不需要自己维护 session state，每次传完整历史，利用 API 层的 KV cache
- 推理成本 ≈ 仅计算新增部分，和课题十三的 token 优化目标高度一致
2. 模型感知的缓存适配
- 课题十三提到”不同模型的 KV cache 特性差异对缓存策略的影响”
- Codex 模式天然支持这个方向：为不同模型定制 prompt 结构（固定前缀 + 差异化后缀），最大化各自模型的 cache 命中率
- DeepSeek 的推理缓存 vs Claude 的分段缓存 — 路由策略可加入
cache_oriented参数
3. Tool output token limit
- Codex 的
tool_output_token_limit = 10000是一个简单且有效的成本控制闸门 - 课题十三的”输出长度控制”可以照搬这个设计：不需要复杂算法，一个硬上限 + 截断策略就够了
需要注意的差异
自动压缩（第二层）差异较大
- Codex 的
/responses/compact返回的是 opaque 加密块，对用户不透明 - 课题十三的 prompt 压缩需要可编辑、可审计的压缩（因为路由决策需要可见的上下文信息）
- 建议：参考 Codex 的压缩触发时机（token 超过阈值），但压缩方式走课题三/课题二的”要点提取”而非 opaque 加密
无语义缓存
- Codex 没有做语义级别的缓存（相似请求检测），这仍然是课题十三需要自研的部分
- Codex 的 cache 是通过 infra 层的 KV cache 实现的 stateless 优化，不是应用层的语义缓存
总结 — 课题十三
| Codex 特性 | 参考价值 | 动作 |
|---|---|---|
| 精确前缀 stateless cache | ⭐⭐⭐ 高 | 融入 token 优化路线，降低 session 管理复杂度 |
| 自动压缩（opaque） | ⭐⭐ 中 | 参考触发时机，但压缩方式自研 |
| tool_output_token_limit | ⭐⭐⭐ 高 | 直接借鉴参数设计 |
| 模型感知缓存 | ⭐⭐⭐ 高 | 扩展课题十三的模型路由策略 |
对课题二（跨 Session 上下文共享）
核心启发：Stateless 模式反转了课题二的某些假设
1. Codex 的 stateless 设计证明了”不需要主动管理上下文窗口”也是一种路径
- 课题二的假设：上下文窗口有限 → 需要压缩、索引、懒加载
- Codex 的路径：上下文窗口也有限 → 但通过每次传完整历史 + API 层 KV cache，让 API 提供方去优化
- 这对课题二意味着：如果目标只是跨 session 连续性，在 API 端做 stateless 传全量可能是比自研索引更简单的方案
2. 但 Codex 的 stateless 模型不解决课题二的核心问题
- 课题二的核心是跨 channel 的实体路由和懒加载（多输入流交织、信息过时、权限控制）
- Codex 的 stateless 模式假设消息只能追加，不能修改，也不支持跨流引用
- 课题组二的需求远超”传全部历史”，Codex 模式只对单 channel 长会话场景有参考价值
3. 压缩与冷备的对比
- Codex 的压缩是 opaque 的（人不可读），面向的是 LLM 理解
- 课题二的压缩需要可审计的冷备（压缩后的”要点块”可以与人校对）
- Codex 的压缩方式不适合课题二，但压缩触发策略（token 水位触发）值得参考
4. 缓存友好度作为路由参数（课题二 open-questions#22）
- Codex 的精确前缀策略给了课题二一个重要参数维度：路由可以设计为”优先保持 prompt 前缀稳定”以最大化 cache 命中
- 课题二的 open-question #22 已经提出了这个方向，Codex 的实践验证了其可行性
总结 — 课题二
| Codex 特性 | 参考价值 | 动作 |
|---|---|---|
| Stateless 全量 history | ⭐ 中低 | 适用于单 channel 场景的简化方案，但不解决核心路由问题 |
| 精确前缀 cache | ⭐⭐⭐ 高 | 验证了 open-questions#22 的”缓存友好度作为路由参数”方向 |
| Opaque 压缩 | ⭐ 低 | 与课题二的可审计压缩需求冲突 |
| 压缩触发时机 | ⭐⭐ 中 | 参考 token 水位触发策略 |
综合建议
优先融入
- 精确前缀 + stateless 模式 → 纳入课题十三的 token 优化路线，作为降低 session 管理成本的手段
- tool_output_token_limit → 直接加入课题十三的参数设计
- 缓存友好度路由参数 → 课题二 open-questions#22 已识别，Codex 提供了实践验证；建议升格为正式设计维度
- 模型感知缓存策略 → 课题十三的模型路由扩展项，与 DeepSeek 推理缓存优化方向一致
不适合
- Opaque 自动压缩 → 两个课题都需要可审计的压缩，不适合 Codex 的黑盒方式
- Stateless 替代索引路由 → 课题二的核心场景（跨 channel 实体路由、懒加载）无法用 stateless 模式解决
需要进一步调研
- Codex 的 exact prefix 在历史超过 200K token 时的实际性能曲线（API 层 KV cache 的极限在哪）
- Codex 在模型切换/工具更新导致 cache miss 后的恢复策略