8 月 17 日凌晨，赛博义父 Tibo 发了条推文，三行配置，Codex 里的 GPT-5.6 Sol 就能用上 1M 上下文。model_context_window 写成 1000000，重启客户端，开个新会话，完事。

model = “gpt-5.6-sol” model_context_window = 1000000 model_auto_compact_token_limit = 900000

本来这功能只对 API 用户开放，现在 ChatGPT 和 Codex 账号都解锁了。长上下文是刚需，推文一发出圈。

结果评论区第一条留言是，千万别用。

理由是 token 消耗会翻倍。Tibo 本人给这条留言点了赞，还补了一句，默认设置是我们精心调过的，祝大家玩得开心。

说完后，Tibo 本人也点赞了，意思就是 Tibo 也同意这种说法

鸭鸭把整件事从头看到尾，记住了一句更狠的话，能开满，和该开满，是两件事。

OpenAI 手里本来就有 1M 的能力，GPT-5.6 Sol 官方文档写得清清楚楚。Codex 默认只给 272k，这个窗口是他们自己关的。Tibo 在模型刚上线的时候解释过，把限制从 272k 提到 372k，实际用量就超出了预期，更别说 100 万。

钱的账算完了，还有一笔效果账。OpenAI 自己公布的 MRCR v2 长上下文评测里，GPT-5.6 Sol 处理 256K 到 512K 的内容，成绩 91.5%。拉到 512K 到 1M 区间，掉到 73.8%。

窗口开大了，模型反而抓不住中间的内容。十万里塞进去，它可能只对头尾那点东西敏感。钱多花了，事没办得更明白。

Noam Brown 出来安利 Codex 的自动压缩，也是这个道理。Agent 跑得越久，历史里值得原样保留的东西占比越低，与其每轮把几十万 token 重新喂进去，不如把旧信息压成摘要接着跑。

面试官爱问这道题，是有原因的。上下文窗口为什么是 Agent 工程最核心的约束，答不出这笔账，光会背一句"1M 很大"，过不去。

回去把你自己 Agent 的上下文账算一遍。每轮塞进去多少 token，压缩在哪触发，工具定义占了多少，心里有个数。下次面试再被问 1M 上下文好不好，你能答出门道。

今天和大家分享一道 AI 大模型面试题。

什么是 Agent 的上下文窗口？为什么它是 Agent 工程中最核心的约束？

回答重点

上下文窗口（Context Window）就是大模型一次能处理的文本长度上限，用 token 数来衡量。主流旗舰模型一般在 128K~200K token 之间。对 Agent 来说，窗口里需要塞的东西特别多：系统提示词、工具定义、对话历史、工具调用结果、中间推理过程，全都挤在这一个有限空间里。

它是 Agent 工程最核心约束的原因有三个：

1）Agent 是多轮执行的，每一轮循环都产生新内容：思考过程、工具调用、返回结果，不断累积。一个复杂任务跑个 20-30 轮循环，上下文轻松膨胀到几十万 token，很快撞到天花板

2）窗口大不等于好用。研究表明模型在超长上下文中注意力会衰减，中间部分的信息容易被忽略，这就是**“Lost in the Middle”**问题。塞了 10 万 token 进去，模型可能只对头尾各 1-2 万 token 敏感

3）上下文长度直接决定成本和延迟。token 越多 API 费用越高、推理越慢。一个不做上下文管理的 Agent 跑个复杂任务，一次对话花掉 5-10 美元 API 费用很常见，响应时间也从几秒拉到几十秒

扩展知识

上下文膨胀的真实案例

拿 Cursor Agent 举例。你让它重构一个项目，它需要读文件、改代码、跑测试、看报错、再改，每一轮循环都会把文件内容、diff、测试输出塞进上下文。一个 2000 行的文件读进去就是大几千 token，跑 10 轮循环就可能用掉 5-8 万 token。

如果不做管理，到后面几轮模型开始"忘记"前面的修改意图，产出质量断崖式下降。

Claude Code 和 Cursor 在实现上都做了积极的上下文管理：自动压缩早期对话、对大文件只读取相关片段、工具返回结果做截断。

工程上的应对策略

对话历史压缩是最基础的策略。把较早的对话轮次用摘要替代，比如前 10 轮对话压缩成一段 500 token 的总结，保留关键决策和结论，丢掉中间的试错过程。Claude Code 的 /compact 命令就是干这个的。

工具结果截断也很关键。一次数据库查询可能返回几千行数据，全塞进上下文既浪费 token 又干扰模型注意力。实践中一般只保留前 50-100 行，或者让模型自己指定只要哪些字段。

动态工具加载是另一个重要手段。如果 Agent 接入了 50 个工具，光工具描述就占 1-2 万 token。解决办法是根据当前任务上下文只加载相关的 5-10 个工具，用不到的不塞进去。

滑动窗口与分层记忆

滑动窗口机制就是只保留最近 N 轮的完整对话，更早的逐步丢弃或压缩。这个做法简单有效，但有个明显缺陷：如果用户在第 3 轮提了个关键需求，到第 20 轮时可能已经被滑出去了。

分层记忆是更高级的方案：把重要信息写入外部存储，比如向量数据库或文件系统，需要的时候通过检索拉回来。这样上下文窗口里只保留当前任务最相关的信息，历史知识按需召回。

Claude 的 memory 文件、Cursor 的 .cursorrules 本质上都是这种思路的体现。

为什么不能无脑等模型窗口变大

有人会问，模型窗口不是越来越大吗？等它到 1000 万 token 是不是就不用管了？答案是不行：

1）成本跟 token 数线性甚至超线性增长，100 万 token 的推理费用可能是 10 万 token 的 15-20 倍

2）延迟随 token 数增加，首 token 延迟从几百毫秒涨到几秒甚至十几秒

3）Lost in the Middle 问题并没有随着窗口变大而消失，模型对中间内容的注意力依然明显弱于首尾

所以上下文管理不是临时方案，是 Agent 工程的长期核心能力。

篇幅有限，更多 AI 大模型相关面试题可以进入面试鸭进行查阅。