修炼AI技能
AI 教程 / 大模型应用 / 上下文工程：长上下文、记忆与提示组织

上下文工程：长上下文、记忆与提示组织

过去两年里，围绕大语言模型（LLM）的工程实践，重心正在悄然转移。早期我们谈论”如何写好一条 prompt”，注意力集中在措辞、角色扮演与示例技巧上；而今天，越来越多的团队把问题重新定义为：“如何让模型在每一次推理时，都看到正确、有序、低噪声的那一组信息”。前者是 prompt engineering，后者被越来越多的人称为 context engineering（上下文工程）。

本文系统梳理这一范式的由来、动机，以及它在长上下文、记忆管理与 Agent 场景下的具体工程取舍。

一、“上下文工程”概念由来

“Context engineering”一词并非来自某篇正式论文，而是在行业实践中自然沉淀下来的说法。值得注意的来源性质如下：

  • Shopify CEO Tobi Lütke 在个人社交媒体（X/Twitter）上提出过”prompt engineering is dead, long live context engineering”一类表述，将工程重点从”雕琢单条提示”转向”系统性地为模型组织可见信息”。这属于非正式、个人观点来源。
  • Andrej Karpathy 在多次公开演讲与访谈中也反复强调：真正的难点不在模型，而在”把正确的上下文喂给模型”，例如他讨论过”上下文窗口就是一种工作记忆”，以及生产系统里大量代码其实是在管理上下文而非写模型逻辑。这类表达同样属于演讲/访谈性质的非正式来源。

需要明确：这不是一个被严格定义或被学术界统一采纳的术语，而是一个用来概括一类工程实践的统称。它的核心主张是——模型在每个 token 上的输出，取决于它”此刻能看见的全部信息”，而这部分信息的结构、来源与调度方式，本身就值得被当作一门工程学科来设计。

二、为什么重要：长上下文不等于更好

一个常见误解是：只要把上下文窗口开到最大，把所有相关资料一股脑塞进去，模型就会更聪明。现实远比这复杂。

第一，输出质量高度依赖上下文的”内容”。无关或错误的材料会直接污染推理，模型会从噪声中归纳出错误前提。第二，质量依赖”顺序”。相关信息的摆放位置会显著改变模型利用它的程度（见下一节）。第三，质量依赖”噪声比”。当有效信号被淹没在冗长冗余中，模型倾向于走捷径、忽略关键信息。

因此，上下文工程的本质矛盾是：我们既希望模型拥有足够的背景以做出正确判断，又必须防止信息过多导致注意力被稀释、成本飙升、延迟变高。优秀的上下文设计，是在”信息充分”与”信号纯净”之间做动态平衡。

三、长上下文窗口的取舍

主流模型已支持数十万到百万级 token 的上下文窗口（具体数字随厂商发布节奏变化，引用时应以对应厂商官方文档为准并标注”截至某时”）。但更大的窗口不等于更优的结果，原因有三：

注意力稀释与 lost-in-the-middle

Nelson F. Liu 等人于 2023 年发表的论文《Lost in the Middle: How Language Models Use Long Contexts》（arXiv:2307.03172）给出了一项关键结论：在需要定位长上下文中相关信息的任务上，模型表现会在相关信息位于输入开头或结尾时最佳，而当相关信息落在长上下文的”中部”时，性能显著下降——即便对于明确支持长上下文的模型也是如此。

这意味着”长上下文”并不自动保证”长上下文被有效利用”。相关信息的丢失是一种结构性现象，而非偶然。

成本与延迟

上下文越长，预填充（prefill）阶段的计算与显存占用越高，单次请求的延迟与费用随 token 数近似线性增长。把 200 页文档全文塞进每次对话，往往既不经济也不必要。

何时用长上下文，何时用检索

经验法则如下：

  • 当任务需要”跨大量材料做整体一致性判断”（例如通读一份长合同找出矛盾条款），长上下文更合适。
  • 当任务只需”找到并依据少数关键片段”（例如根据某几段规范回答一个问题），检索增强（RAG）配合短上下文更稳、更省。
决策判据（简化）：
若关键证据稀疏且可定位  -> 检索 + 短上下文
若关键证据分散且需全局比对 -> 长上下文（并注意 lost-in-the-middle）
若二者兼具           -> 检索召回候选 + 长上下文精读

四、系统提示（System Prompt）设计

系统提示是上下文工程的”固定地基”，它在每次请求中先行出现，决定模型的角色、边界与输出协定。

角色与约束

明确告诉模型”你是谁、不能做什么”。约束要可执行、可验证，避免空泛的”请尽量好”。例如禁止输出、必须遵守的格式、必须调用的工具，都比”请细心”更有效。

输出格式协定

用结构化格式（JSON、Markdown 表格、固定字段）锁定输出形态，便于下游程序解析。下面是带语言标识的示例：

{
  "role": "你是一名严谨的技术审阅者",
  "constraints": [
    "只输出中文",
    "不得编造引用",
    "结果必须是合法 JSON"
  ],
  "output_format": {
    "verdict": "pass | fail",
    "issues": ["string"]
  }
}

few-shot 示例的组织

示例应贴近真实分布：覆盖典型成功路径，也要包含一两个边界/失败样例，帮助模型校准。示例顺序也有讲究——当上下文较长时，把最关键的示例放在开头或结尾，以规避中部衰减。

五、动态上下文组装

静态系统提示只解决”地基”，真正的难点是”为每一次请求动态拼装上下文”。典型做法是从多个来源检索并拼接：

  • 知识检索：向量库 / 关键词检索召回的相关文档片段；
  • 工具结果：上一步函数调用返回的 JSON、日志或查询结果；
  • 历史：压缩后的对话摘要与关键轮次；
  • 状态：当前任务的进度、待办与中间结论。
def assemble_context(user_query, memory, retriever, tools):
    # 1. 检索相关知识
    docs = retriever.search(user_query, top_k=5)
    # 2. 取短期记忆窗口
    recent = memory.recent_turns(window=6)
    # 3. 取长期记忆摘要
    long_term = memory.summary()
    # 4. 组装（顺序：系统 -> 长期摘要 -> 检索知识 -> 近期历史 -> 工具结果 -> 用户）
    return build_prompt(system, long_term, docs, recent, tools, user_query)

状态压缩

当历史超出预算，需要压缩而非简单截断：用模型对旧轮次做摘要、只保留决策与结论、丢弃寒暄与冗余。压缩的目标是”保住信号，丢掉噪声”，而非”保住字数”。

六、记忆管理：短期与长期

记忆是上下文工程中被低估的一环。它把”单次对话”扩展为”跨会话的连续智能”。

短期记忆

短期记忆即当前会话的对话历史窗口，受上下文长度硬约束。管理策略包括：滚动窗口（保留最近 N 轮）、摘要回写（把早期对话压缩为一段摘要放入上下文）、以及关键信息抽取（把用户偏好、已确认事实单独存为结构化字段）。

长期记忆

长期记忆跨越会话，常见载体有：

  • 向量库：适合语义检索”相似经历/知识”；
  • 结构化数据库 / 文件：适合精确存取的”用户档案、偏好、订单状态”；
  • 分层存储：热数据放高频上下文，冷数据按需检索。

读写策略

写入时要去重、去噪、带时间戳与来源；读取时要按相关性召回而非全量加载。一个常见反模式是”把所有历史都读进来”，这既慢又会被 lost-in-the-middle 惩罚。正确的读法是：先检索、再精选、最后组装。

写入：提取事实 -> 去重合并 -> 标注来源与时间
读取：当前任务向量 -> 相似度召回 -> Top-K 精选 -> 组装进上下文

七、Agent 场景下的上下文工程

在 Agent（自主多步智能体）里，上下文工程从”一次请求”变成”一个持续演化的状态机”，复杂度骤增。

多轮工具调用的上下文维护

Agent 每调用一次工具，就把”调用请求 + 返回结果”追加进上下文。若不加管理，上下文会迅速膨胀并出现两类问题：

  • 上下文污染：早期错误的中间结论被后续步骤当作事实沿用，错误被”自我确认”；
  • 上下文超限：长链路任务超出窗口，关键前提被截断丢失。

稳定输出的工程手段

  • 显式状态分离：把”任务目标、已完成步骤、待办、当前观察”用结构化字段维护，而不是依赖模型从冗长聊天史中自己回忆；
  • 工具结果摘要：对超长返回（如大段日志）先做截断或摘要再入上下文；
  • 关键信息回写记忆：把跨步骤必须记住的结论写入长期记忆，避免依赖脆弱的历史窗口；
  • 定期重锚定：在长链路中周期性地把”精简后的进度摘要”重新置顶，对抗中部衰减。
Agent 上下文骨架（推荐）：
[系统提示]
[任务目标 + 约束]
[精简进度摘要]   <- 周期性重锚定
[长期记忆召回]
[最近 2-3 步：动作 + 观察]
[当前待决策问题]

这样即便链路很长，模型每次决策时”抬头看见的”都是高信号、低噪声的上下文，输出更稳定。

小结

上下文工程把我们的注意力从”写一条好 prompt”提升到”系统性地组织模型可见的全部信息”。它的核心命题包括：长上下文并不自动等于更好，相关信息的位置会因其处于开头/结尾或中部而显著影响利用效果（Liu et al., 2023）；系统提示负责锁定角色与输出协定；动态上下文组装按请求检索、压缩与拼接知识、工具结果与历史；记忆管理区分短期窗口与长期存储并配以精选的读写策略；而在 Agent 场景下，稳定输出依赖显式状态分离、结果摘要与周期性重锚定来对抗污染与超限。掌握这些取舍，比单纯堆长上下文更能决定一个生产系统的可靠性。

参考与延伸阅读

本文累计阅读 — 次