上下文工程是什么？大模型一次能看多少内容由它决定

上下文工程是为大模型挑选、组织和维护推理时信息的一套做法：模型每次回答前，只能看到放进上下文窗口的那部分内容，它要决定的，就是该放什么、什么时候换掉。2025 年 9 月，Anthropic 把它定义为“推理时筛选并维护最优 token 集合的策略”，目标是用最少的高信号 token 换最符合预期的结果。

上下文里到底装了什么

上下文不只是你写的那句提示词。一次调用里，模型能看到系统提示、工具定义、少量示例、对话历史、检索到的资料、工具返回的结果，这些合起来就是它的“工作记忆”。Karpathy 把它比作大模型的内存：窗口有限，装进去什么，决定了下一步能做什么。常见手法是：按需检索资料，RAG是最常见的取法；把长对话压成摘要再续写；用结构化笔记代替散乱记录；子任务交给子智能体，只带结论回来。

它和提示词工程、上下文学习有什么不同

提示词工程关心“指令怎么写”，上下文工程关心“模型这次该看到什么”，前者是后者的一部分。两者常被混淆，是因为早期用法里上下文几乎就是提示词；任务一变长、工具一变多，提示词只占窗口一小部分，起决定作用的是不断变化的资料、历史和工具结果。上下文学习则是另一种东西：模型不更新参数，只靠上下文里的几个例子学会新任务，是模型的能力，不是组织信息的方法。

信息越多越好吗？什么时候需要它

不是。2025 年 Chroma 测试了 18 个主流模型，输入量增大时，所有模型表现都下降了，这就是“上下文腐烂”：窗口越满，注意力越分散，关键信息越容易被淹没。另一个误解是把标称容量当成可用容量：100 万 token 的窗口不等于能稳定用满，长上下文“中间遗忘”至今存在。所以第一原则是做减法：先保证最少的高信号信息，再考虑补什么，别全塞进去。

需要它的场景有两个特征：任务长、信息多。比如智能体连续几小时改代码、做调研，中间产生大量工具结果和对话历史，不取舍、不压缩，模型很快会在旧信息里迷路；客服、助手类应用要记住用户偏好，也靠记忆和检索维护上下文。反过来，单次问答、短对话基本不需要它，写好提示词、控制输入长度就够了。判断标准很直接：一次调用能完成，别搭系统；任务跨很多次调用、信息不断膨胀，它就是决定成败的那一层。