一句话定义：上下文工程（Context Engineering）是围绕“模型这一次能看到哪些信息”做系统设计：筛选、排序、压缩、更新，让有限AI 词典：上下文窗口">上下文窗口里放的都是高价值内容。提示词工程（Prompt Engineering）管“话怎么说”，上下文工程管“该让模型看到什么、看多少、什么时候换掉”。
打个比方：上下文窗口像一张办公桌，不是仓库。桌子就这么大。你把所有文件都堆上去，真正要签字那页反而找不到。模型注意力像一盏灯，桌面越乱，每份文件分到的光越少。再像内存管理：预算固定，进程多了就得换页、压缩、丢弃。上下文工程就是给模型做内存调度。
四类常见占用
| 占用 | 典型内容 | 处理思路 |
|---|---|---|
| 系统提示 System Prompt | 身份、规则、边界、输出格式 | 短而硬，只留不可协商项 |
| 工具定义 Tool Definitions | 函数名、参数、说明 | 按需加载，别一次全给 |
| 历史 History | 多轮对话、执行记录 | 近期保留，旧内容摘要 |
| 检索结果 Retrieval Results | 知识库片段、网页摘录 | 先筛后塞，去重、限长、排序 |
还要留出输出空间：上下文窗口通常要同时容纳输入和输出，别把输入塞满。
为什么加更多上下文反而更差
第一，注意力被稀释。长上下文里，关键信息若在中间，容易被忽略。第二，噪声和冲突。过期资料、无关片段、旧工具说明会互相打架。第三，成本和延迟上升，token 越多越慢越贵，具体以官方页面为准。第四，上下文漂移，多轮之后早期规则被淹没。所以目标不是“塞得多”，而是“相关性密度高”。
与提示词工程的分工
提示词工程是上下文工程的一层。前者优化表达，后者优化信息架构。实际做事时，先列上下文预算：系统提示占多少、工具占多少、历史占多少、检索占多少，剩下多少给输出。历史滚动摘要，检索先重排再截断，工具按需暴露。普通人写需求也一样：别粘整份文档，给关键段落、目标、格式；长对话及时总结或开新会话。这样模型才更容易答到点上。