不要相信大型上下文窗口

大型上下文窗口的使用体验

• 对“变笨区”的严重程度和阈值存在明显分歧。
  • 有些人认为，一旦上下文超过窗口的约 10–20%（例如在 1M 窗口中达到 100–200k），性能就会明显下降，出现更多检索错误，以及很难恢复的“被污染”路径。
  • 也有人表示，在 300–500k，甚至 700–900k tokens 之后行为依然稳定，并且几乎从不去考虑上下文本身。
• 很多人认为性能高度依赖任务：简单的“管道”工作或局部编辑比复杂、整体性的重构更能容忍长会话。
• 另有几位指出，上下文质量和一致性可能比原始长度更重要；“碎屑”、相互冲突的指令，以及反复失败的尝试，似乎会污染后续推理。

上下文管理策略

• 常见模式：保持顶层对话简短，把工作卸载给拥有自己全新上下文的子代理、工作流或递归调用。
• 另一些人会定期重置：把计划或当前状态总结成 markdown（AGENTS.md、DESIGN、ROADMAP 等），从那里开启一个新的会话并继续。
• 有些人会强制设置硬上限（例如窗口的 15–20%、200–400k tokens）、自动压缩阈值，或使用“no brown M&Ms”检查（例如如果模型忘记某个自定义构建命令就直接失败）。
• 少数人会激进地最小化上下文：每个功能一个对话、手动“/last”式压缩，或者坚持先有设计文档/PRD 再开始写代码。
• 也有几位认为，仓库中的外部文档比把事实塞进实时上下文或专有记忆系统更适合作为“记忆”，因为后者可能保存错误或过时的数据。

模型、Harness 和采样差异

• 行为会随模型版本和工具而变化。有些人报告旧版或更便宜的模型更早退化；较新的前沿模型和某些工具（例如 agent 框架、工作流）则提升了长周期可靠性。
• 注意力机制、分词器粒度，以及采样策略（例如像 min_p 这样的“现代”采样器）被认为可能是体验分歧的原因，但这仍然只是轶事性观察。

成本、UX 与厂商激励

• 一派会并行运行多个代理并打分（例如 ELO 风格），尽管 token 消耗很高，仍认为结果和节省的时间压倒成本。
• 另一些人认为这是浪费，并强调 prompt 缓存、增量更新以及更严格的范围控制，以减少 token。
• 许多人仍然认为 1M-token 窗口是一次重大的 UX 改进，即便并不总能安全使用。

严谨性、基准与不确定性

• 有几位批评这场讨论大多只是轶事式的“园艺建议”，并呼吁进行系统性评测：先预填上下文，再进行标准化测试。
• 也有人回应说，模型迭代太快，使得稳定、最新的基准很难维持，因此从业者更多依赖不断演化的经验法则。