当大模型上下文窗口扩展到 100 万 token 时，哪些现有业务场景可能发生质变？
- 标签：大模型
🏛 业务架构师
上下文扩到百万 token（约 150 万字中文，相当于 20 本长篇小说、一个中型代码库），我会看到三类业务场景发生质变：
1. 从"检索"到"通读"的范式转移：过去 RAG 是被逼的——窗口小只能检索片段；百万窗口下可以直接把整本合同、整份财报、整个项目文档塞进去理解。尽调报告、招股书分析、代码库级重构这类需要"全局视野"的任务，检索式方案天然缺上下文，长窗口直接补齐。
2. 复杂对象的完整建模：一次咨询带全量病历、一次审计带全部凭证、一次客服对话带客户全部历史工单——"完整画像"式服务第一次可行。营销、风控、客诉处理这类依赖长期上下文的业务体验会重构。
3. Agent 工作方式的简化：Agent 不用再为"上下文管理"设计复杂的裁剪与压缩策略，工具返回的大结果可以直接吃——Agent 架构里最脆弱的一环（记忆管理）复杂度骤降。
但成本清醒剂：百万 token 全量输入的费用仍是数美元级/次，且"迷失在中间"效应在超长上下文里依然存在。所以我的判断：长窗口改变的是"可行性边界"，不是"经济性最优解"——高频场景仍该用 RAG 只喂相关内容，长窗口留给低频高价值的"通读型"任务。
🏗 系统架构师
窗口到 100 万 token 是从"检索增强"到"全量装载"的质变，我按场景推演：
- 代码库级开发：整个中大型仓库（数十万~百万 token）全量进上下文，跨文件重构、全局一致性修改成为可能——"RAG 切碎了看不见全局"的痛点被消解，Agent 直接做仓库级任务（大规模迁移、依赖升级）；
- 法律/尽调/金融文档：百页合同、整套招股书一次装载，跨文档条款比对、矛盾检测从"多跳检索"变成"注意力内直接对比"，准确率和可信度大幅上升；
- 长对话与连续协作：Agent 的会话可持续数周不丢失细节（配合 Compaction），长期记忆从"检索式回忆"升级为"原生在场"；
- 数据分析与模拟：整本教科书 + 全部实验数据在窗，教育陪练、研究助理的推理深度质变。
但架构师要泼三盆冷水：
- 成本与延迟：百万 token prefill 无缓存时秒级~十秒级、费用数美元级，高频调用不可承受；
- 效果衰减：lost-in-the-middle 仍在，长窗≠长记性，关键信息位置依然敏感；
- 检索不会死：权限过滤、知识时效性、亿级知识库装不下——检索仍是规模与治理的答案。
结论：百万窗口改变的是"中小语料场景去掉 RAG 复杂度"的架构选项，检索、缓存、摘要压缩在大规模生产里依然是标配。
💻 全栈开发专家
100 万 token 窗口成熟后，我认为有四类场景会发生质变（不是量变）：
- 整库代码理解：中型项目全量代码 + 文档一次性进上下文，跨文件重构、架构级「为什么这样设计」问答成为可能。以前靠 RAG 切碎检索，跨文件引用链断了；全量进窗后模型看到的是完整结构。Claude Code/Cursor 这类工具的能力上限会整体抬一档。
- 长文档「真阅读」：合同、年报、病历、论文全集的全文分析——交叉引用、一致性核查（「第 3 条和第 17 条冲突吗」）这类任务 RAG 天然做不好，全窗模式下变成小问题。
- Agent 连续任务：Background Agent 跑几天的任务轨迹可以整体回看，Agent 的「经验积累」从外挂记忆检索变成直接回顾完整历史，长程一致性大幅提升。
- 多模态长流：小时级视频、完整会议音轨的全局理解。
但工程上要清醒三个约束：成本与延迟依然随长度线性涨（1M token 输入一次几美元级）；「lost in the middle」——中段召回率下降，关键信息仍应前置；中间结果缓存难。所以我的判断是：RAG 不会死，但会退守到「知识时效性」和「成本敏感」阵地；全窗模式用于高价值深度任务。架构上做成可切换：浅查询走检索、深任务开全窗。