长上下文（Long Context）

什么是长上下文

**上下文窗口（context window）**是模型单次输入+输出能容纳的最大 token 总量。2023 年主流还是 4K～32K；到 2026 年，格局已经变成：

128K 大约对应 30 万字中文或一个中型开源项目的核心代码。1M 窗口意味着可以把整本技术书、整个微服务仓库直接塞进对话。

为什么重要

AI 编程是长上下文最刚性的场景：

• 跨文件重构：改一个被 50 个文件引用的函数，模型需要同时看到调用方与被调用方
• Agent 长程任务：CLI Agent 跑几十轮工具调用，探索轨迹、读过的文件、失败尝试全部堆在上下文里
• 代码库问答：「这个项目的鉴权逻辑在哪」——先得让模型读到整个仓库

这也是为什么编程类模型的上下文军备最凶：Kimi K2.7 Code 直接把 256K 当卖点，K3 干脆上 1M。

窗口大 ≠ 用得好：Context Rot

长上下文最大的认知陷阱：以为窗口够大就能随便塞。Context Rot（上下文腐烂） 的实测结论是——18 个前沿模型无一例外，远没到窗口上限，输出质量就随输入变长持续下降。

一个 200K 窗口的模型，可能在 50K 时就明显退化。下降是连续的、渐进的，不是「满了才崩」。所以：

容量是错误的指标，信噪比才决定输出质量。

实践含义：

• 上下文里塞满无关文件、失败尝试、历史噪声，模型会「捞不出」关键信息
• 与其问「窗口够不够」，不如问「当前任务真正需要的内容放进去了多少」
• Agent 的 compaction（压缩）机制不是免费的：每次压缩都可能丢信息，长任务质量仍会缓慢下滑

长上下文 vs RAG：不是替代关系

「1M 窗口会杀死 RAG」是流传最广的误解。实际上两者解决的是同一问题的不同侧面：

工程上的共识做法是混合：先检索/总结把候选范围缩小，再把真正相关的内容塞进长上下文做深度推理。Chroma 的研究恰恰证明：窗口越大，越需要 RAG 来控制信噪比——两者是共生关系。详见 RAG 与 Context Engineering。

成本：长上下文的隐藏账单

长输入是按 token 计费的，但有一条常被忽略的省钱通道——输入缓存（context caching）：

以百炼 qwen-max 为例：输入 ¥2.4/百万 token，缓存命中只要 ¥0.48/百万——同样的系统提示词 + 仓库代码反复请求时，成本差 5 倍。

编程 Agent 是缓存的最大受益者：系统提示、项目规则文件（AGENTS.md）、已读过的代码在多轮请求中高度重复，缓存命中率天然高。选模型时除了看单价，要看有没有缓存计费、缓存价格多少。

对超长文档场景，阿里专门留了 qwen-long 档（1000 万 token 窗口），定价远低于旗舰档——长上下文本身也可以是一种「档位策略」。

选型建议

1. 编程主力模型选 256K 起步：128K 在多文件任务里捉襟见肘，256K 是 2026 年的甜点位
2. 别为用不上的窗口付钱：日常问答/补全用 128K 档更划算，1M 档留给真正的仓库级任务
3. 看缓存计费：Agent 工作负载下，缓存价格对月账单的影响可能超过单价
4. 窗口再大也做上下文工程：清噪声、先总结、按需检索——这三件事的价值不随窗口变大而消失

常见误区

• 「窗口 1M 就能塞 1M」：错。Context Rot 在远未到上限时就开始拖垮质量
• 「长上下文让 RAG 过时」：错。窗口越大越需要控制信噪比，RAG 是共生而非被替代
• 「上下文没满就没事」：错。退化是渐进的，容量充足不代表质量稳定
• 「所有 token 一个价」：错。缓存命中的输入价格可能只有原价的 1/5（如 qwen-max 的 ¥0.48 vs ¥2.4）

相关阅读

• Context Rot：上下文腐烂 —— 长上下文质量下降的机制
• Token：计费与窗口的基本单位
• Context Engineering：上下文工程
• RAG：检索增强生成
• AGENTS.md：项目级上下文规范
• 国产编程模型盘点