《大语言模型的上下文工程指南》
在使用大语言模型（LLMs）时，一个非常反直觉的事实是：给模型更多的信息，反而可能让它表现得更差。2025年，Chroma 对18个主流模型进行测试，结果显示，当输入长度超过某个临界点后，模型准确率会从接近95%骤降至60%。这说明，“信息越多越好”其实是一个误区。
真正重要的，不是信息的数量，而是信息的选择与组织方式。这正是“上下文工程”（Context Engineering）要解决的问题。
理解上下文工程，首先要从模型如何处理信息说起。大语言模型并不是像人类一样从头到尾阅读文本，而是通过“注意力机制”同时比较所有token之间的关系。Token是模型处理文本的基本单位，通常是词的一部分；而上下文窗口，则是模型在一次交互中可以看到的全部token总量。
虽然模型理论上可以关联长距离信息，但实际上注意力分布并不均匀。研究表明，模型更关注输入的开头和结尾，而中间部分的信息容易被忽略，这种现象被称为“中间丢失问题”。如果关键信息被埋在中间位置，模型的表现可能下降超过30%。
除了位置问题，还有一个更严重的现象叫“上下文腐化”。随着输入内容增加，模型的表现并不会线性下降，而是可能在某个点突然崩溃。这是因为注意力是一种有限资源，过多无关或“似是而非”的信息会干扰模型判断，使真正重要的信息被淹没。
此外，大语言模型本身是“无记忆”的。它不会真正记住之前的对话，每一次交互都是重新加载上下文。因此，每一次调用模型，都需要重新决定：哪些信息应该被保留，哪些应该被舍弃，以及如何组织这些信息。
这就引出了上下文工程的定义：它是对模型在生成回答前所看到的“全部信息环境”的设计与管理。与提示工程只关注“如何提问”不同，上下文工程关注的是“模型此刻应该看到什么”。
在一个典型的系统中，真正的用户问题往往只占很小一部分。上下文中还包括系统指令、对话历史、外部检索内容、工具描述以及工具输出等。这些“基础设施”才是决定模型表现的关键。
围绕这些约束，业界逐渐总结出四种核心策略。
第一是“写入”（Write）。由于上下文窗口有限，应将重要信息存储在外部，例如作为长期记忆或中间推理记录。模型在需要时再读取这些信息，而不是一直占用上下文空间。
第二是“选择”（Select）。不要把所有信息都塞进模型，而是只提供当前任务最相关的内容。最典型的方法是检索增强生成（RAG），从外部数据库中提取相关片段。这一策略的关键在于检索精度，如果检索结果不够精准，反而会成为干扰。
第三是“压缩”（Compress）。随着对话变长，上下文会迅速膨胀，因此需要对历史信息进行总结或裁剪。例如对话摘要或精简工具输出。但压缩本质上是一种信息丢弃，一旦丢掉关键细节，就无法恢复。
第四是“隔离”（Isolate）。当任务复杂时，可以将其拆分为多个智能体，每个智能体处理不同子任务，并拥有独立的上下文。例如一个负责检索信息，一个负责写作。这种方式可以避免信息混杂带来的注意力稀释。
这些策略各有优缺点。例如，压缩可以节省token，但可能丢失重要信息；多智能体可以提升表现，但会增加复杂度与成本；检索可以补充知识，但也可能引入噪声。因此，上下文工程本质上是一系列权衡。
最终可以得出的核心结论是：模型的能力，很大程度上取决于它所接收到的上下文。随着模型越来越强大，失败的原因不再是“模型不够聪明”，而是“上下文设计不当”。
换句话说，未来使用大语言模型的关键能力，不只是选择哪个模型，而是如何为它构建一个正确的信息环境。