长上下文这一轮到底改变了什么：从 context window 扩张到 context engineering 的工作流转向
过去一段时间，很多模型更新最醒目的 headline 都是上下文窗口又变大了。
从 128K、200K，到 1M，数字越来越大，讨论也越来越热。但如果你真的在做产品、做 agent、做 RAG、做 AI coding，慢慢会发现一个事实：
长上下文这一轮最重要的变化，不是“模型一次能塞更多字”，而是团队开始重新理解：上下文不是一段 prompt，而是一套工程系统。
以前我们说 context，常常只是在说：
- system prompt 写多长
- user message 怎么拼
- retrieval chunk 放几个
- 会不会超窗
现在这套理解已经不够了。真正影响效果的，越来越不是某一段 prompt 文案，而是：
- 哪些信息该直接塞进上下文
- 哪些信息应该先压缩
- 哪些信息只在需要时再取回
- 哪些状态应该跨轮保留
- 哪些工具结果应该缓存
- 哪些步骤应该拆成子任务，避免把整个工作流一次性灌给模型
这就是为什么现在很多团队不再只谈 context window，而开始谈 context engineering。
这篇文章想讲清楚三件事：
- 长上下文这一轮到底改变了什么
- 为什么它不是简单替代 RAG，而是逼着工作流重构
- builder 团队该怎样从“凑 prompt”转向“设计上下文系统”
先给结论：窗口变大只是表象，真正变化是上下文开始从“文本块”变成“系统资源”
过去，很多团队对上下文的默认理解是：它是一块有限的文本空间。
所以最主要的问题是“怎么塞进去”。
一旦窗口变大，这个问题表面上好像被缓解了。文档可以少切一点，历史对话可以保留更久，工具结果不用那么快裁掉，agent 也能一次带着更多背景工作。
但窗口变大以后，新问题马上又出现了：
- 塞得下，不等于读得好
- 读得好，不等于记得住
- 记得住，不等于知道哪些重要
- 知道哪些重要，也不等于生成时能稳定调用
所以很多团队后来发现，真正该问的已经不是“能不能塞进去”，而是：
上下文该怎么组织、压缩、刷新、分层和复用。
这时候，上下文就不再只是 prompt 的一部分，而更像一种系统资源。它和缓存、检索、工具调用、状态管理一样，都需要被设计。
第一层变化：RAG 不再只是“切块+召回”，而是开始和长上下文重新分工
前几年很多人理解 RAG 的方式很单一：
- 文档切块
- 建向量索引
- 查询时召回 top-k
- 拼到 prompt 里
这套方法今天当然还没过时，但它的边界越来越清楚了。
长上下文上来以后，很多原来必须依赖 aggressive chunking 的场景，开始可以直接带更完整的原文。比如：
- 长会议纪要总结
- 多文档合并比对
- 合同或政策条款 cross-reference
- 较长代码库片段的局部推理
这带来的第一个变化，不是“RAG 被淘汰”，而是 RAG 终于不用替代所有事情了。
以前因为窗口太小，RAG 经常被迫承担两种工作：
- 帮你把内容塞进模型
- 帮你决定什么内容重要
窗口变大以后，第一种压力下降了，第二种压力反而更明显了。
也就是说，RAG 的价值开始从“压缩存储”更多转向“选择和路由”。
这会让很多工作流重心变化：
- 不是把每个 chunk 都切得更碎
- 而是先决定哪一类信息值得整体保留
- 哪一类内容只需要摘要
- 哪一类只在需要时再召回
所以这轮变化更准确的说法不是“long context 打败 RAG”，而是：
long context 迫使 RAG 回到它更擅长的位置：筛选、路由、定位，而不是承担全部上下文管理。
第二层变化：Prompt 开始从“写一句更聪明的话”转向“设计信息流”
以前很多 prompt 优化，本质是在打磨局部措辞：
- 语气更明确一点
- 步骤写得更细一点
- 结构再规整一点
- 多给两个 few-shot 示例
这当然还有价值，但在长上下文场景下，它已经不是最重要的变量。
真正拉开差距的，往往是信息流设计。
比如同样是一个复杂 agent 任务，问题可能不在提示词，而在这些地方：
- 历史消息顺序不对
- 工具输出没有二次压缩
- 检索结果和用户任务没有对齐
- 状态信息混在普通对话里
- 关键约束在第 200 段，被后面的无关内容冲淡
这时候你再去微调 prompt wording，收益会很有限。因为模型不是没听懂句子，而是上下文结构本身就不合理。
所以 context engineering 的核心，不是“让 prompt 更高级”，而是让信息以更适合模型消费的方式流动。
这个思路会带来几个明显实践变化：
1. 先做分层，再做拼接
不是所有信息都应该平铺进同一层 prompt。
更有效的做法通常是分层：
- 全局约束
- 当前任务目标
- 状态摘要
- 检索片段
- 工具结果
- 临时工作记忆
这样模型读到的不是一长段混杂文本，而是一套有角色分工的信息结构。
2. 先压缩历史，再保留窗口
窗口变大不意味着历史消息应该原样无限累积。
很多团队一开始很兴奋，觉得“终于不用裁历史了”，结果很快发现模型在很长历史里会被旧目标、旧语义、旧失败路径干扰。
所以更好的策略往往不是“保留全部”，而是：
- 保留必要原文
- 把阶段性过程压成状态摘要
- 把已经完成的子任务抽成结构化记忆
3. 把工具结果当上下文对象，而不是聊天文本
工具调用越来越多以后，一个常见问题是：工具输出都被直接贴回消息流里。
这会让上下文快速膨胀，而且很难被再次消费。
更成熟的做法是把工具结果视为单独对象：
- 有 ID
- 有类型
- 有摘要
- 有原始结果链接
- 有“是否仍有效”的状态
这样模型真正读取的是“结果的结构化引用”，而不是反复重看大片原始输出。
第三层变化：上下文成本不只是 token 成本，而是注意力成本和判断成本
很多人讨论长上下文，只看 token bill。
但真正的工程问题其实有三层成本：
- token 成本
- 注意力成本
- 判断成本
token 成本最好理解，就是钱和延迟。
但注意力成本更关键。模型上下文再长，也不是所有位置都被同等对待。你把太多弱相关内容塞进去，模型可能不是“完全看不到”，而是注意力被稀释，关键约束失焦。
判断成本则是团队自己的。上下文系统越大，越难回答这些问题：
- 为什么这次结果变差
- 是模型问题还是上下文问题
- 是检索问题还是状态摘要问题
- 是旧约束残留还是新工具结果污染
这也是为什么很多团队从“长上下文很方便”走到后面，会更重视 observability 和 tracing。
因为上下文一旦成为系统资源，就必须能被调试。
为什么这轮变化会直接影响 AI coding、agent 和企业知识工作流
如果你只把长上下文理解成“适合文档总结”，会低估它的影响。
它真正改变的，是很多工作流的系统边界。
对 AI coding
过去代码助手很多时候只能处理比较局部的文件、函数、diff。
长上下文上来以后，模型可以在一次推理里带更多仓库背景、规范、历史修改、测试失败信息。
但这并不意味着“整仓塞进去就行”。真正有价值的是：
- 哪些仓库约束做成常驻上下文
- 哪些 diff 变化需要原文
- 哪些测试日志只保留摘要
- 哪些 reviewer 规则应该结构化而不是写成长文
所以 coding workflow 的升级方向，不是纯扩窗，而是更像仓库级 context engineering。
对 Agent
Agent 比单轮聊天更依赖上下文，因为它有状态、有计划、有工具、有中间结果。
窗口变大确实让 agent 更容易把连续工作留在同一个任务里，但同时也暴露出新问题：
- 长历史会污染当前目标
- 失败路径可能反复被继承
- 工具结果会迅速把上下文挤满
- 子任务之间需要隔离而不是共享一切
所以 agent 这条线最近越来越强调：
- 工作记忆
- 状态摘要
- context reset
- subagent 隔离
- traces
这背后本质上都是 context engineering 问题。
对企业知识工作流
企业场景最常见的误解是：长上下文一来，知识库和检索都不重要了。
其实恰恰相反。企业知识通常更杂、更旧、更长、更有权限边界。窗口再大，也不意味着你应该把全量内容一次性交给模型。
长上下文真正改善的是：
- 可以少切碎关键文档
- 可以保留更完整的上下文关系
- 可以做更大粒度的 cross-doc reasoning
但真正决定质量的，仍然是：
- 哪些内容先路由进来
- 哪些需要权限过滤
- 哪些需要版本新鲜度判断
- 哪些要结构化摘要后再给模型
一个更有用的新框架：把上下文看成四层
如果你今天要重新整理自己的工作流，我更建议用这四层看上下文。
第一层：固定上下文
包括：
- 系统规则
- 产品约束
- 输出格式
- 长期不变的角色定义
这层应该稳定、简短、少变化。
第二层：任务上下文
包括：
- 当前目标
- 用户输入
- 当前轮次关键条件
这层应该高相关、明确、尽量贴近当前任务。
第三层：工作记忆
包括：
- 当前阶段的中间结论
- 已经完成的子任务
- 暂存的判断
- 接下来要做什么
这层不能无限增长，必须被周期性压缩。
第四层：外部上下文
包括：
- 检索结果
- 工具结果
- 文档片段
- 代码片段
这层最容易膨胀，所以必须有选择、排序、摘要和引用机制。
很多系统一旦乱，通常不是模型太弱，而是四层混在一起。
现在 builder 最该补的不是更大的 prompt，而是三件工程能力
如果你问“长上下文这一轮我最该补什么”，我觉得不是 prompt 技巧，而是下面三件事。
1. 上下文分层能力
你要知道什么该常驻，什么该临时，什么该摘要，什么只保留索引。
2. 上下文压缩能力
不是简单 truncate，而是能把历史过程、工具结果、失败路径压成可继续使用的状态。
3. 上下文可观测能力
你得能看到：
- 这轮模型到底读了什么
- 哪些信息真正被带入
- 哪一步把上下文搞乱了
- 哪些结果应该被清掉
没有这三件能力，窗口再大，你也只是把混乱放大了。
最后一句：这一轮的真正升级，不是“能塞更多”，而是“终于要把上下文当系统设计了”
所以如果要一句话总结这轮变化，我会说：
长上下文把上下文问题从 prompt 问题，升级成了系统工程问题。
这就是为什么今天再看 context，已经不能只盯着模型规格表上的 window size。
真正值得跟的，是这几个问题：
- 上下文怎么分层
- 历史怎么压缩
- 检索怎么路由
- 工具结果怎么结构化
- agent 怎么避免长流程污染
也就是说，下一阶段真正重要的，不只是 long context model，而是谁更懂得做 context engineering。