AI Agent 的上下文工程：让大模型"记住"对话的艺术

AI Agent 的上下文工程：让大模型"记住"对话的艺术

当你在凌晨两点向 AI 助手倾诉一段心事，它温柔地回应了你。第二天你再次打开对话，它却像什么都没发生过一样——这种"失忆"体验，几乎是所有 AI Agent 用户的共同痛点。

这不是 bug，而是架构设计的必然结果：大语言模型本身是无状态的，每一次推理都是独立的_forward pass_。要让 Agent 真正"理解"你是谁、你们聊过什么、你的偏好是什么，必须在模型之外构建一层记忆系统。

这，就是**上下文工程（Context Engineering）**的核心命题。

什么是上下文工程？

如果你熟悉 RAG（检索增强生成），可能觉得上下文工程不过是 RAG 的另一个名字。实则不然。

RAG 的重点是检索——把知识从外部向量数据库里捞出来，塞进 prompt。上下文工程则更宽泛：它关注的是如何在正确的时间、以正确的形式、把正确的信息传递给模型，让它做出正确的判断。

信息源不限于向量检索，还包括：

• 对话历史（Chat History）
• 用户画像与偏好（User Profile）
• 工具调用结果（Tool Response）
• 跨会话持久状态（Persistent Memory）
• 世界知识与常识（World Knowledge）
• 当前任务上下文（Task Context）

上下文工程要做的事，就是把这些异构信息源统一建模、精选压缩、动态组装，让模型在每一个 Token 位置看到的都是"此刻最需要知道的事"。

为什么这件事突然变得重要了？

2023 年以前，大多数 AI 应用是单轮问答——问一句答一句，上下文窗口填满了就截断（Truncate），体验粗糙但架构简单。

2024 年，Agent 范式崛起。AI 开始调用工具、操控浏览器、执行代码。每一个工具调用都是一个决策节点，决策依赖历史、依赖状态、依赖对用户目标的理解。单轮范式彻底失效。

与此同时，上下文窗口虽然越卷越大（Gemini 1.5达到 100 万 Token），但上下文窗口的大小从来不是答案——真正的问题是：模型在海量上下文中找到最相关信息的能力，远不如人意。

这不是模型太笨，是注意力机制（Attention）的根本局限：所有 Token 的两两注意力是 O(n²) 成本，当上下文长度达到百万级，有效注意力实际上集中在了窗口后半段的最近 tokens 上，前面的信息早已被"稀释"。

所以，上下文工程的本质，不是往窗口里塞更多东西，而是帮模型减负——只喂它此刻真正需要的信息。

三大核心问题与解法

问题一：对话历史的无尽膨胀

用户和 Agent 的对话可能持续数月，产生数万轮交互。完整塞入 prompt 既不现实，也无必要。

解法：摘要压缩（Summarization） + 重要度打分（Importance Scoring）

每隔 N 轮对话，对历史做一次摘要，提取关键事实、决策和未解决的问题。同时，用一个小型分类模型对每条历史做重要度打分——"用户的核心诉求"和"已确定的约束"打高分，"客套寒暄"和"试错尝试"打低分。

最终，模型每次推理时拿到的历史，是一个动态权重加权的压缩摘要，而不是完整的对话记录。