很多朋友在开发agent的时候应该都接触上下文工程，但是可能对上下文工程了解的不是很透彻，只是知道有这么个东西，那么今天我带大家来梳理一下，什么是上下文工程？
上下文工程概念介绍
“The process of dynamically assembling and managing information within an LLM's context window to enable stateful, intelligent agents.”
译为“在 LLM 的上下文窗口内动态地组装和管理信息，以实现具有状态的智能代理的过程。”
如何理解这句话？首先我们需要知道，LLM本质上是无状态的。在大模型训练数据之外，它们的推理和意识也仅限于单次API调用“上下文窗口”中提供的信息。这提出了一个基本问题，因为 AI 智能体必须配备操作指令，识别可以采取的行动、用于推理的证据和事实信息，以及定义当前任务的即时会话信息。为了构建能够记住、学习和个性化互动的有状态、智能代理，开发者必须为会话的每一个回合构建这个上下文。这种为 LLM 动态组装和管理信息的过程被称为上下文工程（Context Engineering） 。
上下文工程作用
首先上下文工程代表了从传统的提示词工程的演进。上下文工程处理的是整个有效载荷，动态地构建一个基于用户、会话历史和外部数据的有状态提示，涉及有策略地选择、总结和注入不同类型的信息，以最大化相关性，同时最小化干扰。外部系统——例如 RAG 数据库、会话存储和记忆管理器——管理大部分这种上下文。智能体框架必须编排这些系统，以检索和组装上下文到最终的提示中。
但需要注意的是，很多人认为上下文工程和提示词工程的关系是简单的替代关系，但其实并不是，为什么说是演进，因为现在上下文工程是架构，提示词工程是细节，这里可以给一个公式大家理解一下他们的演进关系：
好了，上面扯一堆估计大家看的云里雾里的，我来用简单接地气的话告诉大家怎么理解上下文工程、以及它的作用。做过菜吧，上下文工程就是做菜前准备食材和调味料、处理食材的关键步骤。那如果我只给你一个这个菜的菜谱，那你可能有什么菜都用上，做一个差不多的饭菜。但是，如果我一开始就给你菜谱需要的所有食材和调味料，给你专业的工具，以及明确的菜品要求，是不是你就能做出极其出色的、定制化的菜品？事先的准备工作我们叫备菜，Agent上我们就叫上下文工程，上下文工程就是为了确保厨师也就是LLM能做出更完美、更定制化的菜，或者说确保大模型能不多不少、哎！恰好就完成了它任务所需要的最相关的信息，你说重要吗？我的评价是：小母牛回家，牛逼到家了。
上下文工程的载荷组成
用于指导推理的上下文（Context to guide reasoning）：定义了智能体的基本推理模式和可用操作，决定了其行为：
- 系统指令（System Instructions）：定义智能体人设、能力和限制的高级指令。（“你是一个xxx，主要xxx，请遵循以下xxx”）
- 工具定义（Tool Definitions）： 智能体可用于与外部世界交互的 API 或函数的模式（Schemas）。（例如联网搜索、数据库操作工具这些大家熟知的）
- 少样本示例（Few-Shot Examples）：通过上下文学习（in-context learning）指导模型推理过程的精选示例。
实证与事实数据（Evidential & Factual Data） 是智能体进行推理的实质性数据，包括预先存在的知识和为特定任务动态检索的信息；它作为智能体响应的“证据”：
- 长期记忆（Long-Term Memory）： 关于用户或主题的持久性知识，在多个会话中收集。
- 外部知识（External Knowledge）： 从数据库或文档中检索的信息，通常使用检索增强生成（Retrieval-Augmented Generation, RAG） 。
- 工具输出（Tool Outputs）： 工具返回的数据或结果。
- 子智能体输出（Sub-Agent Outputs）： 由被授权执行特定子任务的专业化智能体返回的结论或结果。
- 人工制品（Artifacts）： 与用户或会话相关的非文本数据（例如，文件、图像）。
即时会话信息（Immediate conversational information） 将智能体定位在当前的交互中，定义了即时任务：
- 会话历史（Conversation History）： 当前交互的轮次记录（turn-by-turn record）。
- 状态/暂存器（State / Scratchpad）： 智能体用于即时推理过程的临时、进行中的信息或计算。
- 用户提示（User's Prompt）： 需要立即处理的查询。
上下文的有效构建
上下文的动态构建至关重要。例如，内存不是静态的；当用户与智能体交互或摄入新数据时，必须对其进行选择性检索和更新。此外，有效的推理通常依赖于上下文学习（一个 LLM 通过提示词中的演示来学习如何执行任务的过程）。当智能体使用与当前任务相关的少样本示例（few-shot examples），而不是依赖硬编码示例时，上下文学习会更有效。类似地，外部知识是 RAG 工具根据用户的即时查询检索到的。 目前，管理不断增长的会话历史是构建一个上下文感知型智能体最关键的挑战之一。理论上，拥有大量的上下文窗口的模型可以处理大量的文本数据；但是在实践当中，随着上下文的增长，不管是成本还是延迟都会增加。除此之外，还可能因为这种大量上下文，大模型遭受“上下文腐烂”（这是一种随着上下文增长，模型对关键信息的关注能力下降的现象）的影响。
因此上下文工程通常需要采取策略动态地修改会话历史（例如摘要、选择性修剪或其他整体压缩技术）来直接解决这个问题，从而在管理总体token技术的同时保留重要信息，最终实现更健壮和更个性化的AI体验。
[图表：智能体的上下文管理流程图（包含 Context Storage、User Query、Fetch Context、Prepare Context、Invoke LLMs + Tools、Upload Context、Agent Response）]
这种实践体现在对话的每一轮中，作为智能体操作循环内的一个连续周期：
- 获取上下文（Fetch Context）： 智能体首先检索上下文——例如用户记忆、RAG 文档和最近的会话事件。对于动态上下文检索，智能体会使用用户查询和其他元数据来识别要检索的信息。
- 准备上下文（Prepare Context）： 智能体框架动态构建用于 LLM 调用的完整提示词。尽管单个 API 调用可能是异步的，但准备上下文是一个阻塞性的、“热路径”（hot-path）过程。智能体必须等到上下文准备好才能继续。
- 调用 LLM 和工具（Invoke LLM and Tools）： 智能体迭代地调用 LLM 和任何必要的工具，直到为用户生成最终响应。工具和模型输出会被附加到上下文中。
- 上传上下文（Upload Context）： 在当前轮次收集到的新信息会被上传到持久性存储中。这通常是一个“后台”（background）过程，允许智能体在记忆整合或其他后处理异步发生时完成执行。
在这个生命周期的核心是两个基本组件：会话（sessions）和记忆（memory）。会话管理着单次对话的逐轮（turn-by-turn）状态。相比之下，记忆提供了长期持久化的机制，用于捕获和整合跨多个会话的关键信息。
你可以将会话视为你用于特定项目的工作台或桌面... 一旦项目完成，你不会将整个凌乱的桌面推入存储。相反，你开始创建记忆的过程，它就像一个有组织的文件柜... 这种类比反映了有效智能体的运作方式：会话充当单次对话的临时工作台，而智能体的记忆则是精心组织的文件柜，使其能够在未来的交互中调用关键信息。
总结
今天的内容，我们介绍了什么是上下文工程、上下文工程的目标以及他的组成和如何构建上下文等，后续我将基于对上下文工程这个高层次概述的基础上，讨论两个核心组件：会话以及记忆。
感谢大家阅览，如果对大家有一点帮助的话，麻烦给博主点点小赞，我们下次再见！
