上下文不是越多越好：把长任务切开的五种做法
窗口都到百万了，为什么塞得越满效果越差，以及怎么切才不丢信息
文章目录
共 11 节2026 年主流模型的上下文窗口普遍标到了 100 万 token 这一档：Claude Opus 5.5 和 Fable 5.1 都是 1M，GPT-6 三档都是 1,048,576，Gemini 3.8 Flash 同样是 1,048,576，国产这边 Qwen3.8-Max、Kimi K3、DeepSeek V4.1-Flash、GLM-5.3、MiniMax M3 标的也都是 100 万。
于是很多人的用法变成了：把整个项目、整本手册、整年的聊天记录一股脑塞进去，然后问一句话。
窗口装得下，不等于它能把里面的东西都用好。下面讲五种把长任务切开的做法——不是因为塞不下，是因为塞满之后你会为自己找不到的错误买单。
先说清楚「窗口大」和「成本」的关系
不同厂商对长上下文的收费逻辑完全不一样，这件事直接决定你该不该塞。
| 厂商 | 长上下文怎么收费 |
|---|---|
| Anthropic（Claude 4.6 及之后） | 1M 上下文是标准配置，不加价——90 万 token 的请求和 9 千 token 的请求同一单价 |
| OpenAI GPT-6 Astra | 输入超过 272K token 时，整个请求按 2 倍输入、1.5 倍输出重新计价，不是只对超出部分加价 |
| Google Gemini 3.1 Pro | ≤200K 时输入 $2.00 / 输出 $12.00；>200K 时涨到 $4.00 / $18.00（每百万 token） |
| xAI Grok 4.7 | <200K 时 $2.00 / $6.00；≥200K 时 $4.00 / $12.00（每百万 token） |
| 阿里 qwen-plus（百炼） | 0–128K 档输入 0.8 元/百万 token；256K–1M 档涨到 4.8 元/百万 token |
注意 OpenAI 和阿里那两行的坑：是整单重算，不是超出部分单算。 你为了多塞一点参考资料，把请求从 26 万推过了 27.2 万那条线，整个请求的单价就翻倍了。
再加一条容易被忽略的：Anthropic 从 Claude 4.7 这一代起换了分词器，同样一段文本产生的 token 数比旧分词器多约 30%。跨代对比「每百万 token 单价」的时候，这一条会系统性地低估新模型的实际花费。
为什么塞满了效果反而变差
这件事不是玄学，有两个可查的来源。
Anthropic 在《Effective context engineering for AI agents》里用了一个说法叫注意力预算：Transformer 里每一个 token 都要跟其他所有 token 建立关系，关系数随长度平方增长，所以上下文一长，注意力必然被稀释。他们在文里直接写了一句：随着上下文窗口里 token 数增加，模型准确回忆信息的能力会下降——而且这在所有模型上都发生。
另一个来源是 Chroma 2025 年 7 月发的《Context Rot》研究，评测了 18 个模型（Anthropic 5 个、OpenAI 7 个、Google 3 个、阿里 Qwen 3 个），核心结论一句话：模型并不均匀地使用上下文，输入越长，表现越不可靠。 这份研究里还有一个反直觉的发现：模型在被打乱的干扰材料上，表现反而好于结构连贯的干扰材料。
落到日常使用上，有三个你能直接感受到的后果：
第一，注意力被稀释。 二十份文档里只有两份跟当前问题相关，另外十八份不是中立的背景，它们是干扰项。
第二，矛盾信息没人裁决。 长文档里出现前后不一致的描述（旧版本的参数、已经废弃的流程）是常态。你不指明哪份为准，它会挑一个，而且不会告诉你它挑了哪个。
第三，你失去了验收能力。 这一条最要命。输入是两万字的时候，它说错了你能发现；输入是八十万字的时候，它给的结论你根本无法核对——你只能选择相信。一个你无法验证的输出，价值是零，风险是满的。
官方给的四种手段，和下面四种做法的对应关系
Anthropic 那篇文章给长任务列了四种手段，下面要讲的前四种做法基本就是它们的落地版：
| 官方说法 | 这篇里对应的做法 |
|---|---|
| just-in-time retrieval（运行时按需取，而不是预载） | 做法一：先检索，再问 |
| compaction（压缩后重启） | 做法二：分段处理，再合并 |
| sub-agent 架构（隔离上下文，只回传摘要） | 做法三：开独立会话干独立的活 |
| structured note-taking（把状态写进外部笔记文件） | 做法二和做法三共用的中间产物 |
先说一句结论再展开：这四种手段的共同点，是都在把「模型这一刻需要看到的东西」压到尽量小，而不是想办法让它一次看更多。
做法一：先检索，再问
最常用，也最有效。
不要把资料库整个扔给它，而是先用关键词或向量检索把范围缩到三到十篇，再把这几篇给它。
具体操作上有个细节很多人漏了：检索完之后，把「为什么选中这几篇」也告诉它。
最后那句「不要用常识补」是整个模板里最关键的一句。没有它，资料里查不到的时候它会用通用知识回答，而你看不出来那一段是查出来的还是编出来的。
做法二：分段处理，再合并
用于文档太长、必须全看一遍的场景——比如一份两百页的合同、一年的客服记录。
流程是三步：
- 1切段。按自然结构切（章节、日期、客户），不要按字数硬切。硬切会把一句话劈成两半，两边都理解不了。
- 2每段单独处理，产出结构化中间结果。不要让它每段写一段总结——总结是有损的，而且损失不可控。让它产出固定字段：比如每段输出「涉及的金额 / 时间点 / 责任方 / 有疑问的地方」。
- 3只把中间结果拿去合并。这时候输入量已经小了一两个数量级，合并环节的质量就有保障了。
这个做法的额外好处是可审计：中间结果是结构化的，你能抽查几段核对，而不是只能相信最后那一句结论。
做法三：开独立的会话干独立的活
一个长会话里干五件不相干的事，是很多人的默认习惯，也是效果衰减最快的用法。
前面四件事的全部细节都还堵在上下文里，第五件事开始的时候，它已经背了一身跟当前任务无关的包袱。而且这些包袱会主动干扰——它会试图把第五件事跟前四件联系起来。
正确做法：一件事一个会话，做完就关。 需要跨会话传递的信息，写成文件落盘，下一个会话从文件里读。
在命令行编程工具里，这件事有更彻底的做法：子代理。Claude Code 的 subagent 有独立的上下文窗口和独立的工具列表，冗长的探索过程留在子代理里，主会话只拿到结论。查资料、跑测试、读一大堆文件这类「过程脏、结论短」的活，全都适合扔给子代理。
但也别反过来用过头。Anthropic 自己的提示词最佳实践里承认了一件事：新模型对子代理有很强的偏好，需要用提示去抑制——简单任务、顺序操作、单文件编辑，直接做就行，派子代理是净亏损（多一轮往返、多一次上下文搬运）。OpenAI 在 GPT-6 的指南里给的提醒是反方向的：Astra 会「委派不足」，需要显式提示它更积极地并行派子代理。两家的调校方向相反，说明这个参数得你自己按手上的模型试。
做法四：把稳定的部分放前面，让缓存生效
这一条是省钱的，但也顺带改善效果。
各家都提供提示词缓存，价格差异很大：
| 模型 | 缓存命中价（每百万 token） | 相对输入价 |
|---|---|---|
| Claude Opus 5.5 | $0.20 | 输入 $4.00 的 0.05 倍 |
| Claude Sonnet 5 | $0.20 | 输入 $2.00 的 0.1 倍 |
| GPT-6 Astra | $1.00 | 输入 $10.00 的 0.1 倍 |
| GPT-6 Sol | $0.20 | 输入 $2.00 的 0.1 倍 |
| DeepSeek V4-Pro | 峰时 $0.044 / 谷时 $0.022 | 未命中峰时 $1.32 |
| 豆包 Seed 2.1 Pro | 1.2 元 | 输入 6 元的 0.2 倍 |
命中缓存的前提是前缀逐字节相同。所以工程上的规矩只有一条：
顺序反了，缓存一次都命不中。更隐蔽的坑是：你在开头插了一个时间戳、一个随机 ID、一个「今天是几号」，前缀就每次都不一样，缓存等于没配。
这一条同时改善效果的原因是：它强迫你把「稳定的规则」和「本次的任务」分开写。分开之后你自己也更容易看出哪些规则是长期的、哪些是这次临时的。
做法五：材料放前面，问题放最后
这一条不用改架构，改一下顺序就行，而且官方给了量化结论。
Anthropic 的提示词最佳实践里写得很明确：处理长上下文（2 万 token 以上）时，把长文档放在提示的最前面、把问题放在最后，测试中可以把回答质量提升最多 30%，多文档场景尤其明显。
配套还有两个官方写法：
- →每篇文档包一层标签，里面再分「正文」和「来源」等子标签。结构化之后模型更容易分清哪句话出自哪份材料。
- →让它先摘引文再作答：先把相关的原文片段摘出来放进一个「引用」区，再基于这些引文回答。这一步的作用是把无关内容挡在推理之外，同时你也拿到了可核对的依据。
注意这一条跟前面「做缓存要把不变的放前面」是同一个方向：稳定的长材料在前、这次的具体问题在后。两个收益可以一起吃。
一个可以直接套的上下文预算表
给单次请求定一个预算，超了就走上面几种做法之一。经验值：
| 任务类型 | 建议输入上限 | 超了怎么办 |
|---|---|---|
| 问答 / 查资料 | 2 万 token | 走做法一，先检索 |
| 长文档处理 | 5 万 token | 走做法二，分段 |
| 代码任务 | 单次只给相关的 3–8 个文件 | 走做法三，子代理去探索 |
| 批量重复任务 | 固定前缀 + 短变量 | 走做法四，吃缓存 |
这些数字不是硬线，是「超过这个量你就该停下来想想还有没有别的办法」的提醒线。
怎么验证切对了
切完之后必须验一次，不然你不知道切的过程中丢了什么。
做法是：拿同一个问题，分别用「全量塞进去」和「切开处理」各跑一次，对比结论。
- →两边结论一致 → 切法没问题，以后用切开的（便宜、可审计）。
- →切开的漏了东西 → 说明切段时切断了某个跨段的信息，调整切段边界。
- →全量的那边给了切开这边没有的结论 → 重点核对那一条。多出来的结论有相当比例是编的。
这一步大概花你二十分钟，但它决定了后面几百次调用你是不是在自欺欺人。
最后
窗口从 20 万涨到 100 万，改变的是「能不能装下」，没改变「装下之后怎么用好」。
真正变化的一件事是：以前上下文不够是硬约束，逼着所有人必须做检索和切分；现在装得下了，这个逼迫消失了，于是大量的人退回到「一股脑塞进去」。塞得下和用得好之间那段距离，现在得靠自己走完。