上下文工程：决定模型看到什么

语言模型在每次调用时，能访问的只有落在其上下文窗口中的那些 token。它不记得上一次会话，看不到你的数据库，也不知道某个工具返回了什么——除非那些文本就在当前的 prompt 里。模型看似知道的一切，都是因为系统的某个部分决定把它放进去的。

上下文工程就是这样一门学科：在每一次请求中、在严格的 token 预算约束下，做出这个决定。它悄无声息地成为了区分"令人眼前一亮的 AI 演示"与"在真实用户面前撑住几个月不崩的系统"的关键。

为什么上下文比 Prompt 措辞更重要

模型质量很少再是瓶颈。当正确的信息摆在面前时，前沿模型能力极强；而当信息缺失时，它们的失败方式也是可以预测的。

一个给出错误退款答案的客服，通常是因为正确的政策就躺在知识库里，只是根本没有被检索到上下文中。一个改错了函数的编码助手，通常是因为根本没看到那个重要的文件。这些不是推理失败，而是上下文失败——instruction 写再多遍也修复不了一个窗口缺失了答案所依赖的那份文档。

Prompt 工程是真实存在的技能，但它只是上下文工程的一个子集。Prompt 是你写一次、重复使用的静态文本。而上下文是在运行时从指令、对话历史、检索到的知识、长期记忆、工具定义和工具结果中组装出来的，每一次请求的最优配比都不相同。

Token 预算作为设计约束

当答案出错时，本能反应是往窗口里塞更多东西。更长的窗口让这件事变得容易，但通常这是错误的做法。

即使模型宣传很大的窗口，窗口填得越满，性能也会下降。不相关的 token 会稀释相关的 token，注意力在全部内容上铺得更薄。而且每一个 token 都要花钱，都会有延迟，每一次调用都跑不掉。

所以有用的框架是把它当作预算，而不是储物柜。系统规则有一份配额。实时对话有一份配额。检索到的知识、记忆和工具输出各有各的配额。任何超出配额的内容都在调用发出前被摘要或丢弃。值得优化的数字是相关密度——窗口中实际与当前请求相关的 token 占比。为了回答一个物流问题而在窗口里塞一整本手册，相关密度很低，产生的答案会比窗口里只有物流那一节的答案更差，尽管从技术上讲，塞满内容的窗口里确实也包含答案。

Agent 中上下文失效的地点

Agent 系统让这一切变得更难，因为窗口是一个移动靶。每次工具调用都会增加输出。每一步都会增加历史。一个运行二十步的循环，在第 20 步和第 1 步的窗口内容差异巨大。

由此产生的失败是最让人沮丧的那种——间歇性的。同一个问题周一能答上来周五就不行了，因为检索索引增长了，一份几乎重复的文档现在排名比正确的那份还高。漫长的对话悄悄地把系统指令推出了窗口，Agent 开始忽略一小时前还遵守的规则。没有任何报错，只是输出越来越差。

一条明确的上下文流水线，加上每个窗口部分明确的包含规则和固定预算，把这些静默失败变成了可以测量、可以测试、可以调试的东西。

记忆作为上下文层

检索回答的是"哪些文档与这个查询相关"。记忆回答的是另一个问题："关于这个用户、这个项目、这个任务，我们已经知道什么，这些应该影响答案"。

把记忆当作另一个检索索引来用，是很多系统出错的地方。记忆需要作用域划分，这样一个团队的事实不会渗透到另一个团队的答案中；它需要一种让旧条目被替代而不是积累矛盾的方式；它需要像其他所有东西一样，在每次调用时挣得自己在预算中的位置。做好这一点，你的系统就不会让用户每次会话都重新解释自己的情况——而这正是人们悄无声息地停止使用助手最常见的原因。

上下文工程不是换了个名字的 prompt 调优。它是决定模型看到什么的运行时系统，其目标说来简单、做起来难：在固定预算内、在生产环境足够快的速度下，让相关 token 的占比尽可能高。

如果你在调试糟糕的输出，先问问那次失败的调用中窗口里实际放了什么。大多数时候，答案能解释一切。

完整分解，包括四种上下文策略、token 预算和常见失败模式，见这里：https://www.adaptiverecall.com/context-engineering/