从Prompt到Context：AI代理上下文工程实战指南

# 从Prompt到Context：AI代理上下文工程实战指南

## 背景：当一个Agent的上下文窗口“吃”掉自己

2026年，AI Agent已经不再是实验室里的玩具——它们被部署在持续运行的代码编写、客户支持、数据分析等场景中。但一个尖锐的问题浮现出来：**当Agent运行数小时后，上下文窗口里塞满了高频重复的噪声，模型开始“选择性失忆”**——它记得用户三小时前问的第一句话，却找不到刚刚改过的函数定义。

老实说，Prompt engineering已经不太够用了。你精心设计的系统提示，在第五轮对话后就被淹没在冗长的历史记录和检索文档中。我们需要一套系统性的方法论来**策划、维护、压缩**每次推理时喂给模型的那组token——这就是**Context Engineering（上下文工程）**。

Anthropic给出的定义一针见血：  

> *“在LLM推断期间策划和维护最佳代币（信息）集的一套策略，包括可能出现在提示之外的所有其他信息。”*

如果Prompt talking是“如何写好一句话”，那么Context Engineering就是**构建产生这句话及它周围一切的整条管道**。

## 原理：四个支柱，撑起Agent的“注意力”

Context Engineering 与 Prompt Engineering 有着本质区别，我用下面的表格总结它们的核心差异（来自Sourcegraph 2026年发布的实践指南）：

| 维度 | Prompt Engineering | Context Engineering |

|——|——————-|———————|

| **Scope** | 单条指令字符串 | 推理时的全部token集合 |

| **Surface** | System prompt + user message | 指令、检索文档、记忆、工具定义、历史、输出schema |

| **State** | 无状态或单轮 | 有状态、多轮、运行数小时 |

| **优化目标** | 更优措辞，更少歧义 | 更高的信噪比（Signal-to-Noise Ratio） |

| **失败模式** | 模型误解任务 | 信息太多、太少或者不对 |

| **负责人** | 写prompt的任何开发者 | 构建Agent管道的平台团队 |

从表格中可以看到，Context Engineering关注的是整个“上下文窗口”的**供应链管理**。基于Sourcegraph的实践总结，我提炼出四个核心支柱：

### 支柱1：文件选择 —— 给Agent正确的“参考资料”

编码Agent需要浏览整个代码库，但不可能把全部文件塞进上下文。需要基于当前任务动态选择：哪些文件是相关模块？哪些是测试用例？哪份文档描述了这个API？

### 支柱2：工具定义 —— 精确描述Agent的“手和脚”

每个工具（函数/API）的description不能是一个固定的字符串，而应该根据当前会话状态动态调整。例如，当Agent连续3次调用search_file失败时，工具定义会临时追加“注意：文件路径需要绝对路径”。

### 支柱3：对话历史 —— 压缩而非截断

不是简单地从开头丢弃历史。需要保留核心的**意图链**（intent chain），去掉已经完成的操作细节。理想的压缩率：10轮对话压缩成3条摘要节点。

### 支柱4：事实检索 —— 每次检索都精准命中

RAG不再是一次检索塞入top-k条。而是根据当前推理状态，**在线重新评估**哪些事实需要保留、哪些可以释放。比如同一份文档提到了多个配置项，如果Agent已经用过了第一个配置项，后续检索就应该排除它，避免冗余。

## 适用场景与局限性

说完了原理，聊聊实际中Context Engineering到底该用在哪些地方、得注意什么。

**适用场景：**