上下文工程是什么

它是什么

上下文工程是决定一次请求里模型应该看到哪些信息、以什么顺序、用什么形式的工程实践。它关心的不是把窗口塞满，而是在有限预算里放入最有用的材料，并让模型能正确使用。系统提示、工具定义、检索结果、对话历史、工具输出，都在它的范围里。

先分层。最稳定的是系统提示和角色约束；其次是工具定义与长期参考资料；再往下是检索到的材料；最不稳定的是本轮问题和最近对话。按稳定度从前往后排，变化的内容放后面。

然后选对信息。检索不是越多越好：按相关性筛选、去重、按重要性截断。与问题无关的材料既分散注意力，也占预算。宁少而准，不多而杂。

长对话要压缩。滚动摘要保留决策、约束和未完成事项，丢掉寒暄和重复；工具输出（日志、文件内容、网页正文）先裁到关键片段再放进上下文。

工具定义也要精简：只保留当前任务会用到的工具，把每个工具的用途和参数写清楚。工具越多，模型选错的概率越高，描述含糊则会让它反复试探。

稳定内容放前面还能命中提示缓存：缓存按前缀匹配，前缀越稳定越容易命中。时间戳、请求 ID 这类每次都变的内容要移到末尾或请求参数里。

最后用评测判断。改上下文结构后，用固定问题集对比答案正确率、延迟和 token 成本。感觉「好像变好了」不算数。上下文的效果要落在指标上，否则就是在猜。

当你在搭 Agent、RAG 应用或长对话系统，需要决定每次请求带哪些材料、怎么排、怎么压缩、哪些放进工具返回而不是提示里时，就是在做上下文工程。