上下文窗口
Context Window
中级通用上下文窗口（Context Window）是模型一次处理请求时可容纳的内容范围，包括发给它的消息，以及为回复预留的空间。理解它能帮你判断为什么长对话里早期要求可能失效，或为什么一次塞进整个项目后，AI 仍没按关键文件写代码。
你可能会说：「我把需求和代码都发给 AI 了，它怎么像没看见前面说过的话？」
动手看看改价格页的长对话
拖动消息数，再切换上下文容量。上方的条形图把本次请求里的消息和为回复预留的空间分开；灰掉的记录仍在聊天界面，却没有带入这一次请求。
容量较小时，新消息继续进入，第 1 条要求就被挤出本次上下文。模型这次看不到“用人民币”，后续回答可能不再遵守它。
要点上下文窗口会怎样影响一次请求？
- 1
它装的是本次可见的内容
你发的消息、带上的对话历史、文件片段和工具返回结果，都可能占用上下文窗口。模型只能根据本次实际收到的内容回答；某段话曾在聊天界面出现，不代表这次请求仍把它发给了模型。
- 2
输入和回复共享容量
窗口不是专门留给你粘贴材料的。输入占得越多，可供生成回复的空间就越少，具体限制还取决于模型和调用方式。所以把整个仓库塞进去，未必比提供相关文件和明确任务更有效。
- 3
超出范围时要看处理方式
内容太多时，应用可能拒绝请求、截掉部分历史，或先做摘要；这取决于它怎么实现。你可以让 Agent 列出本轮参考了哪些文件和约束，再核对关键需求有没有被遗漏。
容易混淆的地方
上下文窗口说的是一次请求能处理多少内容；对话历史是先前聊过的消息，只有被重新带进请求，模型这次才能看到。它也不是长期记忆：窗口再大，也不保证下次会话自动知道你的项目约定。需要跨会话保留的信息，我们可以写进项目文档或持久化存储，再按任务取用。
什么时候用
适合用
- 和 Agent 修改大型项目时，用它判断该提供哪些相关文件、接口约定和验收条件。
- 长对话里发现 AI 忘了早期限制时，用它检查历史是否仍被带入本轮请求。
- 设计 AI 产品的文档问答流程时，用它规划检索片段与回答空间如何分配。
不适合用
- 想让 AI 跨会话记住用户偏好时，单靠上下文窗口不合适；把偏好存起来，并在需要时读取。
- 想确认 AI 写的代码能否通过测试时，窗口大小不能代替验证；运行测试并检查结果。
- 只是要降低重复传输材料的费用时，不必一味换更大窗口；先评估精简输入或可用的缓存方案。
练一练选一个答案，看看解释
你让 Agent 连续修改后台项目。聊了很久后，它开始违反最初约定的权限规则。你最先怎么排查？
让 AI 帮你做复制给 AI Agent 直接用
请先检查这次任务需要的需求、权限约定和相关代码是否都在当前上下文中。若材料可能超出上下文窗口，先告诉我哪些内容缺失或需要分批提供；修改前列出你实际参考的文件和约束，不要猜测未读到的代码。