上下文工程（Context Engineering）

(Updated: )
AI

在 LLM 的上下文窗口内动态的组装和管理信息的过程，就是上下文工程，目的是开发具备状态感知能力的智能 Agent。

1. 为什么会出现上下文工程？

LLM 模型本质上是无状态的，除了 LLM 本身的训练数据外，它的推理能力和知识储备仅限于单次 API 调用的时候“上下文窗口”中提供的信息。所以为了构建能记忆、学习并实现个性化交互的有状态的 Agent，开发者必须在每次对话轮次中动态构建和管理这个“上下文窗口”。这种针对 LLM 进行动态信息组装和管理的技术，就是“上下文工程”。

2. 上下文工程在做什么事？

首先要说提示词工程，提示词工程一般是静态的，并且专注于构建最优的系统指令，比如说让 LLM 做翻译、摘要、扩写或格式化输出等任务，我们会不断的调整系统提示词，达到最好的效果，这个提示词通常是一段静态的系统提示词。

上下文工程就是提示词工程的演进版本，上下文工程专注于构建整个请求的 payload，根据用户、对话历史和外部数据，动态生成具备状态感知能力的提示词。具体而言，上下文工程通过策略性的选择、摘要和注入不同类型的信息，让提示词中的内容，最大化与用户提出的问题相关，并且最小化可能干扰到问题的内容。这就是上下文工程主要做的事情。

上下文工程的重要性可以类比为我们做饭，上下文工程就是我们根据菜谱（用户任务），去菜市场买菜，精心挑选新鲜蔬菜和肉（RAG 或外部记忆信息），然后回来细心的处理洗菜，洗肉（整理成有条理的提示词）等，备好菜，然后给 LLM 做饭，这个时候 LLM 做出来的菜有滋有味，因为食材都具备并且不缺。如果没有上下文工程，就是只给 LLM 一个菜谱（用户任务），LLM 可能会利用手边的食材勉强做出来，但是可能存在问题，比如说LLM 缺少某个食材（信息）。所以上下文工程做的事情可以理解为是我们为一个高级厨师“备菜”的工作！

3. 上下文工程怎么实施？

上下文工程里面可能包含很多组件，就目前而言包括三大部分。

3.1 用于指导推理的上下文

定义 Agent 基本推理模式和动作。

  1. 系统提示词：定义 Agent 角色、能力和限制的高层次提示词。
  2. 工具定义：定义 Agent 可与外界交互的 API 或者函数。
  3. 少样本示例：指导模型上下文学习的推理样例。

3.2 知识数据上下文

这里是为 Agent 做推理的时候，提供正确的知识背景，作为 Agent 推理的“证据”。

  1. 长期记忆：多个会话积累的、关于用户或者主题的持久性知识。
  2. 外部知识：从数据库或文档中检索的信息，通常采用检索增强生成（RAG）的方式。
  3. 工具输出：Agent 调用工具的返回结果。
  4. 子代理输出：被委派特定子任务的专业代理返回的结果。
  5. 附件：与用户会话相关联的非文本数据比如文件或图片等信息。

3.3 当前任务上下文

即时对话信息让 Agent 处于当前交互的语境中，从而能明确当前任务。

  1. 对话历史：当前交互的历史记录。
  2. 状态/暂存区：Agent 在即时推理中使用的临时、正在进行中的信息或计算结果。
  3. 用户的提示词：用户的任务。

3.4 总结

上下文的动态构建很重要。例如，记忆并不是静态的，必须根据用户与 Agent 的交互或者新数据的引入，从而被有选择地检索和更新。并且上下文学习中的少样本示例也非常重要，提供学习示例，Agent 才能进行更有效的推理。

4. 上下文越来越多怎么办？

那根据上下文工程的理念，会不断的完善上下文窗口中的信息，用户的对话历史是不断增长的，上下文也会越来越大，会导致模型的成本和延迟都越来越高，并且还会出现“上下文衰退”现象，模型对关键信息的捕捉能力会逐渐减弱，特点就是对开始的上下文和提示吃结束部分的上下文注意力集中，提示词中间部分的信息丢失。

为了应对上面的现象，上下文公车给你需要通过一系列策略，比如说摘要生成、选择性精简或者其他压缩技术，对历史记录进行动态调整与优化，从而在有效控制总 token 数的同时，精准保留核心信息，最终实现稳定并且个性化的 AI 体验！

5. Agent 的上下文管理流程

  1. Fetch Context：获取上下文，Agent 首先会检索上下文，例如用户记忆、RAG 文档和最近的对话时间。
  2. Prepare Context：Agent 会动态构建用于调用 LLM 的完整 Prompt，这个是一个阻塞操作，比如准备好 Prompt 才能调用 LLM 和 工具。
  3. Invoke LLMs + Tools：Agent 会迭代的调用 LLM 和必要的工具，直到给用户生成了最终响应。工具和 LLM 的输出都会被追加到上下文中。并且调用完毕后，Agent 也可以动态的 Fetch Context，获取其所需要的信息。
  4. Upload Context：在本轮收集到的新信息会被异步上传到持久化存储中（记忆整合或其他后处理操作），通常是一个后台进程在做这个事情。

这个生命周期有两个基本组件：会话和记忆，会话负责管理单个对话的逐轮状态，记忆提供长期持久化以及机制，跨会话捕获并整合关键信息。

会话可以理解为临时搭建的工位，用于处理单次会话信息，记忆系统可以理解为精心整理过的文件柜，帮助它在后续互动中灵活自如的调用关键信息，从容应对各种场景