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

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

实践中，这带来了一个精妙的 trade-off：摘要会丢失细节，但保留结构；过于详细的记录则让模型淹没在噪声里。优秀的上下文工程，就是在这个光谱上找到最优位置。

问题二：跨会话的持久记忆

你告诉 AI 助手"我叫李明，在上海工作，习惯用中文交流"——这应该在所有对话中持续生效，而不需要每次重新说明。

解法：User Profile Memory + Preference Store

将用户的关键属性（身份、位置、偏好、禁忌、目标）抽离出来，存入独立的 Profile Store。这个 Store 的更新频率远低于对话历史，但读取频率极高——每次推理时，Profile 数据优先于对话历史被注入。

更进阶的做法是构建层次记忆（Hierarchical Memory）：

• 工作记忆（Working Memory）：当前会话中最近的 N 条交互
• 会话记忆（Session Memory）：本次会话的压缩摘要
• 长期记忆（Long-term Memory）：跨会话累积的用户画像和偏好

模型在推理时，根据当前任务的类型和阶段，动态决定从哪一层读取哪些信息。

问题三：工具调用结果的上下文污染

当 Agent 调用了10 次搜索、5 次数据库查询，返回了 50 条结果——这些信息如果全部塞入 prompt，模型会面临严重的信息过载。

解法：工具响应压缩（Tool Response Summarization）

工具调用的结果不应该直接进入 prompt，而是先经过一个压缩层（Compression Layer）：对原始响应做摘要，提炼出关键结论和数据点，丢弃原始的中间过程和无关细节。

更进一步，可以引入因果图（Causal Graph）：记录每次工具调用与其输入输出的依赖关系，形成一个小型知识图谱。模型在决策时，不仅知道"有哪些可用信息"，还知道"这些信息之间的因果链条是什么"。

行业实践：从 Anthropic 到 OpenAI

Anthropic 在 Claude 的 Agent 开发中引入了 Memory Beta 功能，允许模型在对话中动态读写持久化记忆。这一设计的核心理念是：让模型自己决定"什么值得记住"，而不是由工程师预设规则。

OpenAI 的 o3 和 GPT-4o 则在系统 prompt层面引入了结构化上下文模板（Structured Context Template），通过强制性的 schema 分段（如 [user_info], [relevant_history], [task_context]），让模型更稳定地利用上下文。

在国内，字节跳动的 Coze 平台和百度的千帆平台也各自推出了 Agent 记忆模块，但总体上还停留在"存储-读取"的简单范式，距离真正动态、自适应、层次化的上下文工程还有距离。

上下文工程的工程挑战

光有算法不够，上下文工程落地有三大工程难题：

1. 一致性（Consistency）

记忆的读写操作如果在多轮对话中出现不一致——模型读取的 profile 和实际存储的不符——会引发用户信任崩塌。尤其在涉及用户隐私数据时，需要事务性写入和版本控制。

2. 延迟（Latency）

压缩、摘要、检索——这些操作每一个都会引入延迟。如果每次推理前需要 500ms 做上下文准备，用户感知到的响应时间会明显变差。必须在压缩质量和服务延迟之间做严格 profiling。

3. 评估（Evaluation）

如何衡量上下文工程做得好不好？传统 RAG 有 retrieval metrics（F1、Hit Rate），但上下文工程的核心指标是下游任务准确率——模型是否在正确的时间看到了正确的信息，并做出了正确的决策。这需要构建专门的 eval 基准，不能靠人工抽样判断。

写在最后

上下文工程不是一个酷炫的新概念，它是一个被严重低估的工程问题。

当行业都在追逐更大的模型、更长的上下文窗口、更强的推理能力时，真正能决定 Agent 用户体验天花板的，是如何让模型在每一个决策瞬间，都拥有恰到好处的信息集——不多不少，正中靶心。

这不是算法的问题，也不是模型的问题。这是一道系统设计题。而答案，往往藏在细节里。

---

如果你也在做 AI Agent 相关的工作，欢迎在评论区分享你在上下文管理上的实践与踩坑。