上下文窗口与上下文工程
大模型一次请求能「看到」的全部输入叫上下文。模型再强，装不进上下文的信息它就看不到；塞太多又会互相干扰——于是 2025 年前后诞生了「上下文工程」：系统化地决定该放什么、怎么排、如何压缩与缓存。本章讲清这套概念。
上下文窗口
上下文窗口指单次请求允许的最大输入长度，按 token（词元）计数。2024-2025 年主流模型的窗口普遍达到 128K token 级别，部分支持百万级，足以放进整本技术书甚至一个大代码仓库：
| 量级 | 大约能装下的内容 | 适用 |
|---|---|---|
| 8K~32K | 几页到几十页文本 | 轻量任务 |
| 128K~200K | 一部长篇小说 | 主流旗舰区间 |
| 1M 上下 | 数本书 / 中等仓库 | 少数模型支持 |
各型号的具体窗口、计费与超长策略随版本变化，一律以官方文档为准。
token 怎么估算
上下文按 token 计数与计费。粗估时可参考：一个英文单词约 1.3 个 token，一个汉字约 1 个 token 上下（各家分词器差别不小）。精确值有两个可靠来源：用各家的官方 tokenizer 工具，或看接口返回的 usage 字段：
{"prompt_tokens": 318, "completion_tokens": 42, "total_tokens": 360}
写代码时永远以 usage 字段为准，不要依赖直觉估算。
上下文工程：该放什么
窗口有限，放进去的每一段都要「有用」。经验上按优先级取舍：
| 优先级 | 内容 | 说明 |
|---|---|---|
| 最高 | 系统指令、工具定义 | 决定行为，不能丢 |
| 高 | 当前任务相关事实 | 检索到的资料、用户目标 |
| 中 | 多轮对话历史 | 可裁剪、可压缩 |
| 低 | 旧日志、过期摘要 | 尽量不放 |
放不下的知识交给检索（RAG）按需取用，而不是整库硬塞。
上下文工程：顺序、压缩与缓存
- 顺序：系统指令放最前，关键事实尽量靠近提问处。研究发现模型对长文本「中间段」的注意力偏弱（俗称 lost in the middle），重要信息别埋在正中间。
- 压缩：历史太长就老化——把旧对话压成摘要，只保留关键事实与未完成事项；或用检索从长历史里挑出相关片段。
- 缓存：多轮请求往往共享同一段前缀（系统提示词、工具定义）。主流服务商普遍提供提示缓存：相同前缀命中后显著降价、加快响应。前缀如何组织、缓存如何计费，以官方文档为准。
长上下文 ≠ 无限
窗口大不等于可以乱塞：输入越长，费用与首字延迟越高；信息挤在一起互相干扰，模型还可能「记住了却没用上」。长窗口解决的是「能不能装下」，上下文工程解决的才是「装下了能不能用好」。实践中两者配合：该装就装，该省就省。
小结
上下文是 Agent 的「工作台」：窗口大小决定台面，token 估算决定成本，上下文工程决定利用率——按优先级选内容、把关键信息放在显眼位置、用压缩与缓存控制体积。台面再大也装不下整个世界，学会取舍比追求更大的窗口更实际。