---
title: "上下文工程是什么"
description: "上下文工程不是把窗口塞满，而是选对信息。这一页讲清系统提示、工具定义、检索材料与对话历史的分层，压缩与摘要的做法，缓存友好的顺序，以及如何用评测判断上下文是否有效。"
updated: 2026-11-13
canonical: https://docai.cc/concepts/context-engineering/
markdown_mirror: https://docai.cc/concepts/context-engineering.md
---
## 它是什么

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

## 怎么工作

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

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

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

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

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

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

## 常见误解

- **窗口大就可以多放**：容量不等于注意力，噪声会稀释关键信息。
- **上下文工程就是写提示词**：提示词只是其中一层，检索、压缩、顺序、工具定义同样重要。
- **摘要一定无损**：摘要会丢细节，和决策相关的字段要保留原文。
- **改动靠感觉**：上下文调整必须用评测验证，否则无法判断是否变好。

## 什么时候用

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

## 延伸阅读

- 容量与注意力：[什么是上下文窗口](/concepts/context-window/)
- 前缀缓存机制：[上下文缓存](/concepts/context-caching/)
- 提示缓存实操：[用上下文缓存省钱](/learn/use-prompt-cache/)
- 系统提示写法：[写一个好的系统提示](/learn/write-a-system-prompt/)