上下文工程：Prompt、记忆和上下文如何管理？

你有没有发现一个现象？

有时候 AI 明明记得你之前说过什么，却在关键时刻突然忘记；有时候你刚刚纠正了一个错误，它过一会儿又按照之前的信息回答；还有时候，你给它提供了大量资料，它反而没有抓住真正重要的内容。

很多人会认为，这是模型不够聪明，或者提示词写得不够好。

但问题可能出在另一个地方：AI 究竟拿到了哪些信息，又是怎样组织和使用这些信息的？

这就涉及一个重要的概念------上下文工程（Context Engineering）。

一、为什么只优化 Prompt 还不够？

我们先认识两个容易混淆的概念。

Prompt Engineering（提示词工程）

简单来说，就是设计给 AI 的指令，告诉它应该做什么、怎么做，以及需要遵守哪些要求。

例如：

你是一名专业的客服助手。
请根据用户的问题回答。
不确定的信息不要编造。
输出内容使用 JSON 格式。

这些内容都属于提示词设计。

它解决的是：怎样把任务要求清楚地告诉 AI。

Context（上下文）

上下文则不只是提示词，而是模型在当前一次处理过程中能够接触到的全部相关信息。

它可能包括：

系统指令和开发者设置。
用户当前提出的问题。
之前的对话记录。
从知识库检索到的资料。
从数据库或 API 获取的业务数据。
工具调用的结果。

例如，用户询问订单退款进度。

AI 不仅需要知道应该如何回答，还需要知道用户问的是哪个订单、之前发生过什么、当前退款状态是什么，以及退款规则是什么。

这些信息共同构成了回答问题所需的上下文。

因此，两者的区别是：

对比	Prompt Engineering	Context Engineering
核心问题	告诉 AI 怎么做	决定 AI 能看到什么
关注重点	指令设计	信息获取与组织
主要内容	角色、目标、约束、格式	指令、历史、记忆、知识、工具结果
解决问题	指令不清晰	信息缺失、过时、冲突或过载

可以把 Prompt 理解为一份工作说明书，而 Context 是完成工作所需要的全部资料。

Prompt 是 Context 的组成部分，但 Context 远不止 Prompt。

二、AI 需要的信息究竟从哪里来？

如果希望 AI 持续、准确地完成任务，就不能把所有信息都寄托在一段提示词或一段聊天记录里。

不同类型的信息，应该由不同的信息来源负责。

1. 当前对话：解决眼前的问题

当前对话主要保存正在进行的交流信息。

例如：

用户刚刚提出的问题。
用户补充的条件。
当前任务已经完成的步骤。
双方在本次交流中达成的决定。

它适合处理短期任务状态，但不能保证所有历史内容永远保留在模型当前可用的上下文中。

2. Memory：保存需要长期使用的信息

Memory（记忆）主要解决跨对话的信息延续问题。

例如：

用户长期偏好的回答方式。
稳定的个人背景。
长期项目的关键约束。
需要在未来继续使用的决定。

这些信息可以保存在外部存储中，在后续任务需要时再读取。

这里有一个重要区别：

记忆不等于模型永久记住了所有对话。

真正的记忆管理需要经历信息筛选、保存、读取和更新。

如果把每次对话的所有内容都保存下来，不仅会增加检索负担，还可能把已经失效的信息带入新的任务。

因此，记忆应该保存具有长期价值的信息，而不是简单地保存全部聊天记录。

3. RAG 知识库：解决专业知识查询

RAG（检索增强生成）是一种让 AI 在回答问题前，先从外部知识库中检索相关资料的技术。

例如：

企业客服需要回答产品使用规则、售后政策和内部操作流程。

这些内容可能非常多，不适合每次全部交给模型。

RAG 的处理方式是：

将文档整理并建立索引。
用户提出问题。
系统根据问题检索相关资料。
将检索结果作为上下文提供给模型。
模型结合资料生成回答。

这样，模型不需要提前掌握企业全部知识，而是根据当前问题获取所需资料。

需要注意：知识库负责提供经过整理的知识，不一定代表业务当前的实时状态。

4. 数据库和 API：解决实时业务事实

如果用户询问：

我的订单现在是什么状态？
退款是否已经完成？
当前账户还有多少积分？
商品库存还有多少？

这类问题需要查询真实业务数据。

数据库负责保存业务状态，API 则提供系统之间读取这些数据的接口。

AI 可以通过应用程序调用 API，获取最新的业务结果，再将其纳入当前上下文。

这与 RAG 有明显区别：

知识库适合回答相对稳定的专业知识和业务规则。
数据库/API 适合查询动态变化的业务事实。

不能因为知识库里有一份退款规则，就认为它能够回答某个订单是否已经退款。

5. 不同信息来源如何协作？

信息来源	主要负责	典型问题
Prompt	指令和任务要求	应该怎么回答？
Memory	长期稳定信息	用户有什么长期偏好？
对话历史	当前交流状态	刚才讨论到了哪里？
RAG 知识库	专业知识和文档	退款规则是什么？
数据库/API	实时业务事实	这笔退款完成了吗？
Context	统一组织当前所需信息	本次回答需要使用哪些资料？

这里最重要的是：这些信息来源并不是互相替代的。

它们各自负责不同类型的信息，最后由上下文管理机制决定哪些内容需要提供给模型。

三、为什么不能把所有信息都交给 AI？

既然信息越多，AI 能参考的内容越丰富，为什么不直接把所有历史对话、知识库和业务数据全部交给它？

因为模型存在上下文窗口（Context Window）的限制。

上下文窗口可以理解为模型一次处理任务时能够接收的信息容量，通常以 Token 作为计量单位。

Token 是模型处理文本时使用的基本词元单位，并不严格等于一个汉字或一个单词。

上下文窗口不仅要容纳用户输入，还可能需要容纳系统指令、历史对话、工具定义、检索资料和工具返回结果。

因此，真正可用于当前任务的信息空间是有限的。

即使模型支持很大的上下文窗口，也不意味着应该把所有信息都放进去。

原因主要有三个：

第一，信息干扰。

如果上下文中包含大量无关资料，模型需要在更多信息中识别当前任务真正需要的内容。

第二，历史信息可能已经失效。

例如，用户最初表示退款正在处理中，后来退款已经成功。

如果旧记录没有被更新，模型可能同时看到两个不同的状态。

第三，成本和延迟增加。

上下文越长，通常意味着需要处理更多输入 Token，也可能增加推理耗时和调用成本。具体影响取决于模型和服务实现。

因此，上下文管理的目标不是尽可能多地提供信息，而是提供当前任务真正需要的信息。

四、上下文工程究竟要做哪些事情？

上下文工程不是简单地把几段文字拼接起来，而是围绕当前任务管理信息的完整过程。

可以拆成五个关键步骤。

1. 信息筛选：只获取当前任务需要的内容

假设用户询问退款进度。

系统可能拥有：

用户的历史聊天记录。
用户的长期偏好。
退款规则文档。
订单数据库。
其他历史订单。
用户的其他业务资料。

但这次任务真正需要的可能只有：

当前订单编号。
退款规则。
当前退款状态。
必要的历史处理记录。

其他资料即使存在，也不一定需要进入本次上下文。

这就是按需获取信息。

2. 信息排序：明确哪些信息更重要

不同来源的信息可能具有不同的权威性。

例如：

当前业务数据库中的订单状态。
一周前的聊天记录。
一个月前保存的历史摘要。

如果三者发生冲突，就不能简单地把它们放在一起让模型自行猜测。

系统需要根据业务规则，明确数据来源的权威性、更新时间和适用范围。

对于实时订单状态，应该优先以可信业务系统的最新结果为准，而不是以历史聊天记录为准。

3. 信息结构化：让模型知道每条信息是什么

如果把所有信息直接拼成一大段文本，模型可能难以区分哪些是规则、哪些是历史记录、哪些是当前状态。

可以通过结构化方式组织：

json 复制代码

{
  "task": "查询退款进度",
  "order_id": "ORDER001",
  "business_status": {
    "refund_status": "已完成",
    "source": "订单服务API",
    "updated_at": "2026-11-05 10:30:00"
  },
  "policy": {
    "source": "已审核退款规则",
    "content": "退款完成后以支付渠道到账记录为准"
  },
  "history": {
    "previous_status": "处理中",
    "superseded": true
  }
}

这个结构让模型更容易识别：

当前任务是什么。
当前业务事实是什么。
信息来自哪里。
数据是什么时候更新的。
哪条旧信息已经被新状态替代。

结构化不是为了让内容看起来更复杂，而是为了减少信息歧义。

4. 信息压缩：保留重要内容，减少冗余

长对话和大量工具调用可能不断增加上下文长度。

这时可以采用摘要、历史压缩和工具结果清理等方式。

例如，一段很长的讨论可以提炼成：

最终确定的方案。
已完成的步骤。
尚未解决的问题。
必须保留的关键数据。
下一步需要执行的任务。

但是压缩并不意味着随意删除。

尤其是订单编号、金额、时间、权限条件和关键业务状态，不能为了缩短文本而丢失准确性。

如果某些信息未来还可能使用，也可以保存在外部存储中，需要时再重新读取。

5. 实时更新：避免旧信息污染新任务

上下文不是一次组装之后就永远不变。

随着任务推进，可能出现：

用户修改需求。
业务状态发生变化。
新资料替代旧资料。
工具调用返回新的执行结果。
原有判断被后续证据推翻。

系统必须及时更新上下文。

尤其是同一事实出现新旧两个版本时，需要明确标记旧信息已经失效，而不是让两条相互冲突的信息长期共存。

五、当新旧信息发生冲突，AI 应该相信谁？

这是上下文工程中非常重要的问题。

假设用户询问退款进度。

历史对话记录：

退款正在处理中。

随后，业务 API 返回：

退款已经完成。

如果系统只是把这两条内容全部提供给模型，模型就可能出现错误回答：

"您的退款目前正在处理中，已经完成。"

显然，这两个状态存在冲突。

正确的处理方式应该包括：

识别两条信息描述的是同一笔退款。
确认数据来源。
核对更新时间。
根据业务规则判断哪条信息具有权威性。
将旧状态标记为已被新状态替代。
将最终有效状态提供给模型。

这里需要特别强调：

最新信息不一定永远正确，权威性也不能只靠时间判断。

例如，用户刚刚输入了一条信息，并不意味着它可以覆盖银行或订单系统的真实交易状态。

因此，处理信息冲突时，至少要考虑：

来源是否可信。
是否具有对应业务的权威性。
更新时间是否有效。
信息是否适用于当前对象和场景。

如果仍然无法确定，就应该重新查询或明确告知用户当前无法确认，而不是让模型自行编造一个答案。

六、上下文工程常见的失败方式

失败方式	产生的问题	改进方向
只写 Prompt，不提供必要资料	AI 不知道真实业务情况	接入正确的信息来源
把所有历史记录都塞进去	信息冗余、干扰增加	按任务筛选
使用过期记忆	回答与当前事实不符	更新和失效标记
RAG 检索到错误资料	依据不正确	检查检索质量和资料版本
业务状态依赖聊天记录	无法保证实时性	查询权威业务 API
摘要过度压缩	丢失关键条件和细节	保留关键事实及约束
多个来源相互矛盾	AI 无法确定正确结论	来源优先级与冲突处理
未考虑权限	可能把不该访问的信息提供给模型	在信息获取阶段进行身份与权限校验

还有一个容易被忽视的问题：上下文中的信息不仅需要正确，还必须是当前用户有权访问的信息。

不能因为某份文档与问题相关，就直接把它提供给模型。

权限校验应该由可信的应用程序或服务端执行，而不是仅仅告诉模型不要访问某些内容。

七、怎样判断上下文工程是否有效？

上下文工程不能只看 AI 最终回答是否流畅。

更重要的是检查它有没有获得正确的信息，以及是否正确使用了这些信息。

可以从以下几个维度评估：

评估维度	主要检查内容
相关性	提供的信息是否与当前任务有关？
完整性	是否遗漏了完成任务所需的关键资料？
准确性	信息来源和事实是否正确？
时效性	是否使用了已经失效的旧信息？
一致性	新旧信息发生冲突时是否正确处理？
权限安全	是否只提供当前用户有权访问的信息？
成本与延迟	是否存在大量无效上下文？

实际测试时，可以建立一组固定的问题和对应的预期结果。

例如：

正常场景：用户查询一笔退款。
缺失场景：没有提供订单编号。
冲突场景：历史记录与当前业务状态不一致。
过期场景：记忆中的规则已经更新。
权限场景：用户尝试查询其他账户的数据。

每次调整上下文组装策略，都使用同一批测试场景进行对比。

这样才能判断修改是否真正提升了质量，而不是只凭几次聊天感觉效果更好。

八、Prompt Engineering 与 Context Engineering 应该怎样配合？

两者不是相互替代的关系，而是不同层次的工作。

Prompt Engineering 负责告诉模型：

任务目标是什么。
应该遵守什么规则。
应该采用什么表达方式。
需要输出什么格式。

Context Engineering 负责确保模型：

能获得完成任务所需的信息。
使用正确的信息来源。
不被过期和无关信息干扰。
能处理信息更新和新旧冲突。
在有限上下文容量内保持必要的信息。

一个可靠的 AI 应用，既需要明确的任务指令，也需要合理的信息组织机制。

只有提示词，没有正确的数据，AI 可能只能给出看似合理的猜测。

只有大量数据，没有合理的上下文管理，AI 也可能无法识别真正重要的信息。

真正重要的不是给 AI 更多信息，而是让 AI 在正确的时间，获得完成当前任务所必需的、可信的、最新且有权限的信息。

这就是上下文工程的核心价值。

参考资料

OpenAI：Prompt Engineering

https://developers.openai.com/api/docs/guides/prompt-engineering
OpenAI：Conversation State

https://developers.openai.com/api/docs/guides/conversation-state?api-mode=responses
Anthropic：Context Engineering --- Memory、Compaction 与 Tool Clearing

https://platform.claude.com/cookbook/tool-use-context-engineering-context-engineering-tools