从提示词工程到上下文工程：构建稳定 LLM 应用的实践笔记

# 从提示词工程到上下文工程：构建稳定 LLM 应用的实践笔记

 

这两年做大模型应用，一个很明显的感受是：很多团队在早期都把注意力放在“提示词怎么写”，但真正把系统做起来之后，决定效果上限的往往不是某一句 prompt，而是整条上下文链路是不是稳定、干净、可控。

 

如果把 LLM 看成一个很强但也很“情境依赖”的执行器，那么提示词工程解决的是“你想让它怎么想”，而上下文工程解决的是“你到底给了它什么材料去想”。后者往往更接近生产环境里的真实问题。

 

## 为什么单靠 Prompt 很难救场

 

很多 Demo 在本地跑得不错，到了线上就开始出现各种问题：

 

- 同一个问题今天答得很好，明天答得发散

- 多轮对话之后开始遗忘约束

- 工具调用顺序不稳定，偶尔跳步

- 用户一旦提供冗长上下文，输出质量明显下降

 

这些问题表面上看像是“模型不稳定”，但本质上经常是上下文组织方式不稳定。

 

LLM 的输入不是一句 prompt，而是一个完整上下文包：系统提示、用户输入、历史消息、工具返回、检索片段、记忆信息、结构化约束，都会一起影响结果。任何一个环节引入噪声，都会放大到最终输出里。

 

所以在我看来，真正进入工程阶段以后，应该把关注点从“写一条完美 prompt”，逐渐切换到“设计一套稳定的上下文装配机制”。

 

## 上下文工程到底在解决什么

 

我习惯把上下文工程分成四个问题：

 

### 1. 给什么

 

不是所有信息都应该塞给模型。很多系统的问题恰恰来自“贪多”：把历史消息、检索结果、日志片段、工具输出一股脑丢进去，结果模型被噪声淹没。

 

更好的做法是做信息分层：

 

- 永久约束：系统规则、角色边界、输出格式

- 当前任务：用户目标、成功标准、限制条件

- 辅助证据：检索结果、文件内容、工具输出

- 背景记忆：用户偏好、长期上下文

 

模型并不需要“看到所有东西”，它需要的是“看到最相关、最可信、最可执行的东西”。

 

### 2. 以什么顺序给

 

信息顺序会显著影响模型的注意力分布。把关键约束埋在长文本中间，和把它放在前面做明确声明，效果完全不同。

 

实践里通常有几个经验：

 

- 高优先级规则尽量前置

- 证据和任务目标尽量靠近

- 相同类型的信息尽量聚合

- 冲突信息不要并列堆放，先做裁决再喂给模型

 

很多人会花大量时间调 prompt wording，却忽略了消息排序本身就是一种强控制手段。

 

### 3. 以什么粒度给

 

检索增强场景里，最常见的问题不是“没检索到”，而是“检索到了太大的块”。

 

如果一次丢给模型 5 段大文档，每段都包含很多无关内容，模型虽然“理论上看到了”，但未必能稳定抓住重点。合理的切分粒度、摘要策略、字段提取，往往比换 embedding 模型更立竿见影。

 

我通常会优先考虑：

 

- 能否先抽结构化字段，而不是直接贴原文

- 能否先压缩成任务相关摘要

- 能否只给命中的段落，而不是整页内容

- 能否把证据转换成“结论 + 依据”形式

 

核心目标不是增加 token 使用量，而是提高有效 token 密度。

 

### 4. 什么时候丢弃

 

上下文不是越长越好。很多系统一旦支持多轮对话，就默认把历史一直累加，最后模型开始在旧信息和新目标之间摇摆。

 

成熟的做法应该是建立“上下文生命周期”：

 

- 当前轮必须保留什么

- 哪些历史只需要摘要保留

- 哪些工具输出只在本轮有效

- 哪些长期偏好应该沉淀到记忆，而不是反复拼接

 

如果没有这套生命周期管理，系统很容易从“有记忆”滑向“有包袱”。

 

## 在 Agent 系统里，这件事更重要

 

到了 Agent 或工作流系统，上下文工程的复杂度会进一步上升。因为这时输入不再只是用户文本，还包括：

 

- 计划状态

- 子任务结果

- 文件读写内容

- 外部 API 返回

- 浏览器操作状态

- 错误重试轨迹

 

这些信息如果不加整理，Agent 很快就会出现“会做事，但做不稳”的情况。你会发现它能力并不弱，但它经常被自己前面产生的噪声干扰。

 

我最近比较认同一个思路：把 Agent 的上下文看成一个有预算的工作内存，而不是无限聊天记录。

 

这意味着需要做几件事：

 

1. 明确当前任务的唯一目标

2. 让工具返回尽量结构化、短而可验证

3. 把中间推理和最终结论分层存放

4. 对长链路任务定期压缩上下文

5. 对跨会话稳定信息使用记忆层，而不是历史堆叠

 

这几个动作看起来很工程化，但它们直接决定了 Agent 的稳定性。

 

## 一个很实用的判断标准

 

如果你怀疑系统问题出在上下文，不妨问自己三个问题：

 

- 模型失败时，究竟是“不会”，还是“没拿到关键材料”

- 模型输出波动时，输入上下文是否真的完全一致

- 当结果变差时，新增信息到底是增益还是噪声

 

很多时候答案会很直接：不是模型退化了，而是上下文污染了。

 

## 结语

 

提示词工程当然仍然重要，但它更像是表达层优化；而上下文工程是在搭建 LLM 的认知工作台。工作台乱，再好的模型也容易发挥失常；工作台清楚、信息密度高、层次分明，模型才能稳定输出。

 

做 LLM 应用到最后，拼的往往不是“谁写出了一句最神的 prompt”，而是“谁能持续为模型提供干净、可信、适量、按顺序组织好的上下文”。

 

这件事听上去不如调参数那么酷，但它往往才是真正的分水岭。