"Prompt 工程"这个词，我其实一直有点抵触。

不是因为它没用——精心设计的 prompt 确实能明显提升效果。抵触是因为它暗示了一种工作方式：似乎只要把"那一句话"打磨好，一切问题就解决了。这种暗示在简单对话里成立，在 Agent 系统里基本是幻觉。

让我真正想通这件事的，是一次具体的翻车。

一次翻车引出的问题

我给 Agent 写过一个挺好的系统 prompt——角色清晰、规则明确、格式规范。单轮测试效果很好，我很满意。

然后把它放进真实的多轮任务里跑。第十轮左右，Agent 的输出质量开始明显下降——开始重复之前说过的话、忘记早期的约束、甚至把几轮前已经废弃的方案当成现行方案。

Prompt 没改过。模型没换过。为什么单轮好好的，多轮就崩？

排查了很久才意识到：第十轮时模型"看到"的东西，和第一轮完全不一样了。上下文里塞了前九轮的对话、每次工具调用的完整返回（有的几千 token）、检索进来的文档片段。我精心写的系统 prompt 只占这个大杂烩的一小角，而且被越推越远。

那一刻我明白了：模型的表现不取决于你的 prompt 写得多好，取决于它在决策那一刻的整个信息环境。这个信息环境，就是上下文。

Prompt 工程关注"怎么问"，上下文工程关注"模型在那一刻能看到什么"。前者优化一句话，后者优化一整个信息环境。

拆开看：上下文的三个层次

把 Agent 的上下文管理拆开，我自己的分法是三层。每层的问题不一样，管法也不一样：

系统层：常驻的信息

角色设定、行为规则、工具列表、安全约束——Agent 启动时就有的东西。相对静态，但也不是完全不变。

这一层的原则是精简。每一行都常驻上下文，写多了就是白烧 token。我见过几千字的系统 prompt，一大半是"你是一个乐于助人的……"之类的废话。一条好的系统规则 = 一个清晰的约束，不是一段价值观宣言。

会话层：最危险的一层

对话历史、工具返回结果、中间推理记录。这一层会持续增长，是最容易把系统拖垮的地方。

核心手段就三个词：压缩、摘要、淘汰。

那次翻车之后我做的第一件事就是加"工具结果压缩"——超过 500 token 的工具返回先过一个摘要步骤。就这一条改动，长对话的稳定性改善非常明显。

任务层：按需来去的临时信息

RAG 检索结果、Skill 文档、中间变量。特点是"用到时注入，用完就清理"。

这一层的原则是按需、精准、及时清理。RAG 检索回来 10 个片段，可能只有 3 个相关——只注入 3 个。任务完成后，这些临时信息应该从上下文里移走，给下一个任务腾地方。

不清理的后果很隐蔽：上一个任务检索进来的文档片段还留在上下文里，下一个任务时模型可能被它干扰——把不相关的旧信息当成当前任务的依据。这种错误特别难排查，因为看起来"模型莫名其妙引用了一个没人提过的东西"。

工作记忆和长期记忆

写到这儿我想借一个认知科学的类比，因为它真的很准：

上下文窗口 = 工作记忆。容量有限，但延迟低、精度高——模型"直接看到"。这是它做决策时实际依赖的信息空间。

外部存储 = 长期记忆。容量无限（向量库、知识图谱、结构化存储），但需要"检索"才能进入工作记忆。模型不直接"记得"，而是通过搜索把相关信息调到上下文里。

人也是这样的。你"记得"昨天开会讨论了什么，但你记得的方式不是把那两个小时的每一句话都装在脑子里——你记得关键结论，细节需要时翻笔记。

Agent 记忆管理的核心矛盾：工作记忆有限，但"往里放什么、什么时候放、放多少"直接决定模型的表现。这就是上下文工程要干的活。

RAG 的位置，和它的局限

RAG 是"长期记忆 → 工作记忆"的标准通道。但它不是终点，我用下来至少有三个局限：

检索质量取决于 query 质量。用户问了个模糊的问题，检索回来的就是"关键词匹配但语义不对"的文档。模型被带偏。

片段化打断结构。很多知识是有结构的——一个流程、一个体系。RAG 切成片段检索，模型只能看到局部，看不到全局。

一问一检，不会探索。标准 RAG 检索一次就完。但复杂问题需要"先查 A，看了 A 发现要查 B，再查 B"——多步检索。标准 RAG 做不到。

所以现在的演进方向我觉得比较靠谱的两个：一是 Agentic RAG——把检索变成 Agent 的一个行动，模型自己决定"要不要检索、检索什么、结果够不够、要不要再来一次"；二是结构化知识——不只检索文本片段，还检索知识图谱、表格这些有结构的东西。

RAG 不是方案，是方案里的一个组件。把它当"记忆问题的终极答案"，会失望。

一个实操检查清单

把上面的东西收拢成一个日常设计的检查清单，每次搭 Agent 过一遍：

  1. 模型此刻需要看到什么？——不是"有什么可以放"，是"做这个决策必需什么"。少即是多。
  2. 这些信息从哪来？——系统层常驻、会话层压缩保留、任务层按需注入。来源不同管法不同。
  3. 信息结构化了吗？——模型理解结构化数据的能力远强于散文。能用 JSON 别用段落，能用列表别用叙述。
  4. 用完清理了吗？——任务结束后的临时信息该移就移。上下文不是储物间。

还没想明白的问题

压缩的度在哪？压缩历史对话能省空间，但压缩必然丢信息——有时候模型恰恰需要那个"被丢掉的细节"。什么时候该信摘要、什么时候必须留原文，我现在是拍脑袋定阈值（超过 10 轮开始摘要），没有什么理论依据。

长上下文模型会不会让这个问题消失？百万 token 的窗口出来后，有人说"上下文工程是过渡学科，窗口够大就不用管了"。我不太同意——窗口再大也有成本（每次请求都是全量计费），而且"注意力稀释"的问题不是窗口大就能解决的。但我承认这个判断可能是错的，等窗口便宜到可以忽略不计的那天再说。

小结

从 Prompt 工程到上下文工程，本质是视角的切换：从优化"一句话"到优化"整个信息环境"。

当应用从单轮问答进化到多步 Agent，前者的边际收益迅速递减，后者的权重迅速上升。系统 prompt 还是要好好写，但光写好它远远不够。

对传统行业的信息化团队，我想说个好消息：上下文工程的很多思路，和你们已经做了多年的信息治理、知识管理是相通的——分类、摘要、索引、淘汰。你不是从零开始学，你只是把已有的经验搬到一个新容器里。