原创解读：上下文工程——AI时代被遗忘的核心战场

📋 版权声明与免责声明

本文是作者基于个人实践经验的原创分析文章，灵感来源于 Kaggle 白皮书《Context Engineering: Sessions & Memory》。

观点归属声明：

• 文中所有具体案例、实践数据、踩坑经历均来自作者个人项目经历
• 核心方法论和框架重构为作者原创思考
• 仅在部分概念定义上参考了白皮书的学术表述

原文参考：

• 标题：《Context Engineering: Sessions & Memory》
• 链接：阅读原文

原创性质：本文为独立创作的实践总结类文章，非翻译或改写作品。文中观点仅代表作者个人理解，与原文作者立场可能不同。

---

引子：那个让客户当场离场的演示

那是2024年春天，我们团队花了三个月精心打造的智能销售助手即将迎来最重要的考验——向一家年营收超过50亿的制造业集团做产品演示。如果能拿下这个客户，不仅意味着一笔七位数的年费合同，更会成为我们进入 enterprise 市场的关键案例。

演示前半段进行得相当顺利。Agent流畅地回答了关于产品功能的问题，准确调用了CRM系统展示客户画像，甚至根据客户的行业特点主动推荐了几个相关的成功案例。客户方的IT总监频频点头，采购负责人也开始询问实施周期和付款方式。

转折发生在第47分钟。

当时客户方的生产副总突然问了一个关键问题：“你们这个系统能不能和我们现有的MES系统打通？我们刚才提到的那个数据同步需求…”

Agent停顿了一下，然后说出了让全场陷入尴尬的话：“抱歉，我不太确定您提到的MES系统和数据同步需求是指什么。能否请您再详细介绍一下您的业务场景？”

生产副总愣住了：“我们刚才已经讨论了半天了，从订单管理系统聊到MES的数据接口，你当时还说这个对接方案可行…”

我看着屏幕上那个无辜的Agent，立刻意识到发生了什么——上下文窗口溢出了。

在这47分钟的对话中，Agent已经用掉了大约12万个token的上下文容量。当生产副总问出那个问题时，系统为了腾出空间给新的输入，自动截断了最早期的对话记录。而那些被截断的内容里，正包含着过去半小时关于MES系统对接的所有讨论。

最终，客户方以”技术成熟度不足”为由终止了合作洽谈。三个月的努力，47分钟的希望，在那一刻化为泡影。

那一刻我深刻地意识到：上下文管理不是技术细节，是决定AI产品生死的核心能力。

这个教训让我开始深入研究上下文工程的方方面面。在接下来的两年里，我和我的团队经历了无数次类似的踩坑、试错、迭代，逐渐建立起一套相对完善的上下文工程方法论。这篇文章，就是我对这段实践历程的系统总结。

---

第一章：被忽视的冰山——为什么上下文工程是Agent的”阿喀琉斯之踵”

1.1 误区一：把上下文当”技术参数”而非”产品能力”

在AI产品开发的早期阶段，我和我的团队也犯过这个错误。我们把上下文窗口大小当作一个纯粹的技术参数——“GPT-4支持128K，那我们肯定够用了”。我们把记忆管理当作一个后端实现细节——“让工程师找个Redis存一下就行”。

这种认知的代价是巨大的。

在我们第一个正式交付的项目中，一个面向法律咨询的Agent在上线第一周就收到了大量投诉。用户的反馈出奇地一致：“刚开始聊得挺好的，聊着聊着AI就失忆了”。

我们排查了整整三天才发现问题的根源：当对话超过15轮后，系统为了保证响应速度，会丢弃最早的几轮对话。而在法律咨询场景中，用户在最初的对话里会详细描述案情背景、涉案各方关系、关键时间节点——这些正是后续所有法律分析的基础。

一旦这些信息被”优化”掉，Agent就像一个突然失忆的律师，不得不反复询问客户”您刚才说被告是谁来着”。

这个案例让我深刻认识到：上下文工程不是后端优化，而是产品核心体验的决定性因素。

当我们把上下文管理当作技术参数时，我们实际上是在把用户的核心体验当作可牺牲的变量。在法律咨询这个场景下，用户愿意付费的前提是Agent能够像专业律师一样，完整理解案件的每一个细节。一旦Agent”失忆”，用户感受到的不是技术限制，而是专业能力的缺失。

这种认知转变对我们团队产生了深远影响。我们开始在产品设计阶段就将上下文管理纳入核心考量，而不是等到性能优化阶段才想起它。

1.2 误区二：低估长对话场景的普遍性

很多人以为AI Agent的主要使用场景是简短的一次性问答。但我们在实际运营数据中看到的情况截然不同。

在我们的一个客服Agent项目中，分析了过去三个月的10万条真实对话记录：

• 对话轮次少于5轮的仅占31%
• 对话轮次在5-15轮的占42%
• 对话轮次超过15轮的占27%

这意味着，接近三成的用户会话会进入”长对话”区间——而这恰恰是上下文管理最容易出问题的区间。

更关键的是，高价值用户往往倾向于长对话。我们的数据分析显示：

• 平均客单价在1万元以上的用户，平均对话轮次是18.7轮
• 平均客单价在1千元以下的用户，平均对话轮次只有6.2轮

这意味着上下文管理问题对高价值用户的伤害尤为严重。

这个发现彻底改变了我们的产品优先级排序。在此之前，我们主要关注新用户的 onboarding 体验，因为那是用户流失最严重的阶段。但数据告诉我们，在长对话场景下的上下文管理问题，实际上是在驱赶最有价值的用户群体。

一个具体的例子是，我们有一位年付费超过20万的企业客户，他们的采购负责人曾经反馈：“你们的AI在聊到第20分钟的时候就开始重复问同样的问题，这让我怀疑它是否真的理解我们的需求。“这个问题如果发生在普通用户身上，可能只是一个小差评；但发生在这样的大客户身上，可能意味着续约风险。

我们还发现，长对话用户往往对Agent的期望值更高。他们投入的时间和精力更多，因此也更难以忍受体验上的瑕疵。一个在长对话中”失忆”的Agent，会让用户感到被辜负——“我花了这么长时间和你聊，你却连我最基本的信息都记不住”。

这种情感上的伤害比功能上的缺陷更严重。用户不会因为Agent偶尔犯错而放弃使用，但如果用户感到Agent”不尊重”自己的投入，他们很可能会永久流失。

1.3 误区三：混淆”能记住”和”记得好”

即使意识到上下文的重要性，很多团队对”记住”的理解仍然停留在”不丢失信息”的层面。但真正的挑战远不止于此。

在我们的一次A/B测试中，对比了两种记忆策略：

• 对照组：简单的滑动窗口，保留最近20轮完整对话
• 实验组：智能分层策略，识别关键信息后保留摘要

测试结果出乎我们的意料：

• 实验组的”信息保留率”（即用户询问之前讨论内容时能正确回答的比例）比对照组高出47%
• 但实验组的”用户满意度”却比对照组低了12%

深入分析后我们发现原因：实验组虽然”记得”更多关键信息，但丢失了太多细节和语境。用户问”上次我们说的那个方案后来怎么样了”，实验组能说出”是优化数据库查询的方案”，但完全忘记了当时讨论的具体技术细节和决策理由。

这个案例揭示了一个关键洞察：好的上下文管理不是最大化信息量，而是最大化信息的相关性和可用性。

用户并不关心Agent记住了多少token，他们关心的是Agent能否在合适的时机提供合适的信息。一个”记得”很多但用不好的Agent，还不如一个”记得”很少但用得恰到好处的Agent。

1.4 误区四：忽视上下文与业务逻辑的耦合

这是我在实践中踩过的最大的坑之一。

在我们早期的一个电商导购Agent项目中，我们把上下文管理完全抽象成了一个通用模块。这个模块负责存储和检索对话历史，业务逻辑模块只管调用它。看起来这是一个很好的分层设计，但实际上它带来了严重的问题。

问题在于：不同的业务场景对”什么信息重要”有着不同的定义。在电商导购场景下，用户的预算范围、品牌偏好、尺寸要求是核心信息；而在医疗咨询场景下，用户的症状描述、用药历史、过敏信息才是核心。

我们的通用模块无法区分这些差异，只能一视同仁地处理所有信息。结果是在某些场景下，关键信息被淹没在噪音中；在另一些场景下，无关信息占用了宝贵的上下文空间。

关键洞察：上下文管理必须与业务逻辑深度耦合，不能简单抽象为通用模块。

这个教训促使我们后来采用了”领域驱动”的上下文管理策略——每个业务领域定义自己的信息优先级、摘要策略、保留规则。虽然这增加了系统的复杂度，但显著提升了各场景下的用户体验。

---

第二章：Agent记忆的三重境界

经过两年多的实践摸索，我逐渐形成了对Agent记忆系统的分层理解。这种分层不是教科书式的理论划分，而是基于无数次踩坑后总结出的工程实践框架。

2.1 第一重：工作记忆——与模型共舞

工作记忆对应着大语言模型的上下文窗口。这是最直观、最容易理解的一层，但也最容易被误用的一层。

核心矛盾：有限容量 vs 无限需求

无论模型厂商如何把上下文窗口从4K扩展到128K再到200K，本质上都是在解决一个伪问题——因为用户的对话需求是无限的。

在我们的一个企业知识管理项目中做过测算：

• 一次典型的企业政策咨询对话平均消耗token数：约8000
• 包含详细技术方案讨论的项目规划对话：约25000-40000
• 需要回顾多份历史文档的复杂问题：轻松超过50000

即使使用最大的上下文窗口，仍然无法避免”装不下”的问题。

我们的解决思路：动态优先级管理

与其纠结窗口大小，不如思考如何在有限空间内装入最有价值的信息。

我们在实践中建立了一个动态优先级系统：

• P0级（永驻）：系统指令、用户画像、关键约束
• P1级（近期）：最近5-8轮原始对话
• P2级（摘要）：早期对话的智能摘要
• P3级（按需）：通过RAG动态检索的相关历史

这种分层管理让我们的Agent在128K上下文的限制下，实际能”感知”的信息量相当于300K+的原始对话——代价是一些细节被摘要取代，但核心信息基本保留。

踩坑实录：摘要不是万能的

第一次实施智能摘要时，我们过于激进地把所有早期对话都压缩成一句话摘要。结果出现了一个诡异的现象：Agent在回答问题时显得”很懂”，但总是差那么一点关键细节。

一个典型例子：用户在第3轮提到”预算控制在50万以内，这是硬性要求”。我们的摘要系统把它压缩成”用户有预算考虑”。到了第20轮，当Agent提出一个80万的方案时，用户暴怒：“我一开始就说了50万上限！”

教训：摘要必须保留关键约束和数值，不能过度压缩。

这个教训让我们后来建立了”约束保留清单”——在摘要过程中，必须识别并保留所有数值约束、时间约束、布尔约束等关键信息。

2.2 第二重：长期记忆——跨越时间的认知连续性

如果说工作记忆解决的是”当前对话不遗忘”，长期记忆解决的就是”跨会话认知连续性”。

真实案例：从”陌生人”到”老熟人”的转变

在我们迭代第三个版本之前，用户对Agent的普遍反馈是”每次聊天都要重新介绍自己”。一个典型场景：

周一的对话：

• 用户：“我是做电商的，主要卖户外用品”
• Agent：“了解了，您是户外用品电商卖家。有什么可以帮您的？”
• 用户：“我想优化一下库存管理”
• Agent给出了针对性的建议

周三的对话（同一个用户）：

• 用户：“上次说的那个库存方案我试了一下”
• Agent：“抱歉，我不太确定您指的是哪个方案。能否请您详细介绍一下您的业务场景？”
• 用户：”…我们周一刚聊过，我是做户外用品电商的”

这种体验让用户感觉在和”不同的AI”对话，完全没有 continuity。

解决方案：用户画像 + 记忆图谱

我们后来建立了一个相对完善的长期记忆系统：

事实层：用户的基本属性

• 行业、公司规模、角色
• 技术栈、工具偏好
• 沟通风格偏好（喜欢详细解释 vs 直接给答案）

经历层：与用户的互动历史

• 之前的对话主题
• 给出的建议和用户的反馈
• 成功的案例和失败的尝试

关系层：用户与信息的关联

• 用户关注的知识点
• 用户经常提问的模式
• 用户的知识盲区

实施后，用户满意度提升了34%，重复询问率下降了67%。更重要的是，用户开始用”你”来称呼Agent，而不是用”它”——这个微妙的语言变化，说明用户开始把Agent当作一个连续的对话伙伴，而非一次性的工具。

深度思考：长期记忆的边界在哪里

在长期记忆的实践中，我们面临一个根本性的问题：Agent应该记住用户多久？应该记住多少？

我们在一个项目中尝试过”永久记忆”——记住用户从第一次使用到现在的所有互动。结果发现这不仅带来了巨大的存储成本，还产生了意外的负面影响。

一个用户在半年后反馈：“你们的AI总是提起我半年前问过的问题，但我早就解决了。这让我感觉它跟不上我的成长。”

这个反馈让我们意识到：长期记忆也需要遗忘机制。 不是记住越多越好，而是记住对用户当前状态最有价值的信息。

我们后来引入了”记忆衰减”机制——随着时间推移，旧记忆的影响力逐渐降低；同时引入了”记忆冲突检测”——当新信息与旧记忆矛盾时，优先相信新信息。

2.3 第三重：外部记忆——突破边界的知识接入

RAG（检索增强生成）的出现，让Agent的上下文工程进入了一个新阶段。但RAG不是银弹，它带来了新的复杂性。

我们的RAG演进之路

V1阶段：简单向量检索

最初的实现很直接：把所有文档切分、向量化、存入Pinecone，用户提问时检索最相关的片段。

问题很快显现：

• 检索精度不够：用户问”退货政策”，检索结果里有”招聘政策”、“隐私政策”，只是都包含”政策”这个词
• 上下文碎片化：信息分散在多个文档片段，Agent只看到片段看不到全貌
• 时效性问题：检索不到最新的信息更新

V2阶段：混合检索 + 重排序

我们增加了关键词匹配作为补充，引入了Cross-Encoder进行重排序，显著提升了检索精度。

但新的问题出现了：检索到不等于用得好。

一个典型案例：用户问”如何申请研发费用的加计扣除”。我们的RAG系统成功检索到了正确的政策文档片段，但Agent的回答却把政策条文原封不动地贴给用户，没有任何解释和适用性分析。

用户反馈：“这些我都能自己查，我要的是告诉我该怎么做”

这个案例揭示了一个关键问题：RAG只是解决了”信息获取”的问题，但没有解决”信息加工”的问题。Agent需要的不只是原始文档片段，而是经过理解、整合、 contextualized 的知识。

V3阶段：检索后处理 + 知识图谱

现在的方案增加了：

• 检索结果的后处理（摘要、关联、冲突检测）
• 知识图谱支持（理解概念间的关系）
• 用户查询意图预判（提前加载可能相关的知识）

这个版本的表现好多了，但维护成本也显著上升——需要专门的知识管理团队来维护文档质量和知识图谱准确性。

关键洞察：RAG的效果高度依赖知识质量。没有好的知识管理，再先进的检索技术也白搭。

这个认识促使我们建立了专门的知识运营团队，负责文档的质量控制、更新维护、结构优化。这在传统软件开发中是不可想象的——我们通常不会在知识内容上投入专门的运营资源。但在Agent时代，知识本身成为了产品竞争力的核心组成部分。

---

第三章：上下文工程的五大实战难题

3.1 难题一：冷热数据的分层策略

在长期记忆的存储上，我们走过一段弯路。

最初的做法很简单：所有记忆都存PostgreSQL，查询时全表检索。结果在用户数超过1万后，查询延迟从50ms飙升到800ms+。

我们尝试过纯Redis方案，查询延迟降到了5ms，但内存成本爆炸——每个用户的记忆平均占用2MB内存，10万用户就是200GB。

最终方案：热-温-冷三层架构

层级	存储介质	数据范围	查询延迟	成本
热数据	Redis	最近7天	<5ms	高
温数据	Pinecone	7天-1年	20-50ms	中
冷数据	PostgreSQL	1年以上	100-500ms	低

实际运行效果：

• 85%的查询命中热数据层
• 12%命中温数据层
• 仅3%需要查询冷数据

平均查询延迟控制在15ms以内，存储成本相比纯内存方案降低了70%。

实践中的权衡

这个三层架构听起来很美好，但实际落地时面临很多艰难的权衡。

首先是”热数据”的定义。我们最初把”最近7天”作为热数据，但对于某些业务场景，用户可能一周只来一次，但一次对话就决定是否购买。在这种场景下，7天的窗口可能太长，也可能太短。

我们后来引入了”动态热数据”的概念——不是基于固定时间窗口，而是基于用户活跃度和业务价值动态调整。高价值用户的数据在热层保留更久，低频用户的数据更快下沉到温层。

其次是数据一致性问题。当一个记忆从热层迁移到温层时，如何确保Agent在不同查询中获得一致的体验？如果用户刚问了一个问题涉及某条记忆，这条记忆恰好在此时被迁移，Agent的回答可能出现不一致。

我们采用的方案是”写时复制”——迁移时不删除热层数据，而是标记为”迁移中”，直到温层数据确认可用后才删除。这带来了额外的存储开销，但保证了体验一致性。

3.2 难题二：跨设备的状态同步

一个用户可能在手机、电脑、平板三个设备上同时使用Agent。如何保持体验的一致性？

我们遇到的诡异bug

用户在手机上和Agent讨论了半小时的项目方案，然后切换到电脑继续。Agent在电脑上表现得很”陌生”——完全不知道手机上的讨论内容。

排查后发现：手机会话和电脑会话在系统中是两个独立的session，它们各自维护自己的工作记忆，互不相通。

解决方案：用户级状态中心

我们建立了一个统一的用户状态中心：

• 工作记忆仍然分设备维护（保证响应速度）
• 关键记忆实时同步到用户级存储
• 设备切换时自动拉取用户级记忆

实施后，跨设备体验评分从3.2分提升到4.6分（满分5分）。

更深层的挑战：设备差异

跨设备同步不只是技术问题，还涉及产品设计的复杂性。

不同设备有不同的使用场景和约束。手机上的对话通常是简短、碎片化的；电脑上的对话通常是深度、长时间的。用户在手机上可能更愿意接受简洁的回答，在电脑上可能期待更详细的解释。

如果简单地把所有记忆在所有设备间同步，可能会产生体验上的错配。我们在一个项目中就遇到过这样的问题：用户在手机上快速确认了某个方案，但在电脑上Agent基于同样的记忆给出了详细的解释，用户反而觉得啰嗦。

我们后来引入了”设备感知”的记忆系统——不仅存储记忆内容，还存储记忆产生的上下文（设备类型、对话时长、用户行为模式）。当在不同设备上回忆时，Agent会考虑这些上下文因素，调整回答的风格和详略程度。

3.3 难题三：隐私与个性化的平衡

这是最难的问题之一，因为它涉及伦理、法律和产品策略的交叉。

真实困境：一个金融咨询Agent，应该记住用户的投资组合细节吗？

记住的好处：

• 可以提供更精准的建议
• 用户体验更连续
• 对话效率更高

风险：

• 敏感金融数据泄露
• 合规风险（GDPR、金融数据保护条例）
• 用户可能不希望被”记住”

我们的做法

建立分级的记忆策略：

• 显式敏感信息（账户余额、持仓明细）：不记忆，每次对话重新询问
• 隐式偏好（风险偏好、投资风格）：脱敏后记忆
• 通用知识（投资理念、市场观点）：正常记忆

同时提供用户控制面板：

• 查看系统记住了什么
• 删除特定记忆
• 设置”遗忘”时间（如”1个月后自动忘记这次对话”）

伦理思考：记忆即权力

在解决隐私问题的过程中，我逐渐意识到一个更深层的议题：在AI时代，记忆即权力。

谁控制着Agent的记忆，谁就控制着用户与Agent互动的规则。如果我们作为产品开发者单方面决定记住什么、忘记什么，我们实际上是在行使一种隐蔽的权力。

这个认识促使我们在产品中大力推行”记忆透明化”——不仅让用户知道我们记住了什么，还让用户理解为什么记住这些、这些记忆会如何影响Agent的行为。我们相信，只有透明的权力才是正当的。

我们还建立了一个”记忆伦理委员会”，定期审查我们的记忆策略，确保它们符合伦理标准。这听起来可能有些过度，但在涉及用户数据的产品中，这种审慎是必要的。委员会的工作包括审查新功能的隐私影响、处理用户的数据删除请求、制定记忆保留策略等。

跨文化视角：不同文化对记忆的态度

在全球化部署中，我们发现不同文化对”被记住”有着不同的态度。欧美用户普遍更关注隐私，倾向于选择”不记住”或”短期记住”；而亚洲用户通常更期待个性化服务，愿意让Agent记住更多信息以换取更好的体验。

这种文化差异要求我们的产品具备灵活的配置能力，不能一刀切地应用同样的记忆策略。我们为不同地区设置了不同的默认配置，同时允许用户根据个人偏好进行调整。

3.4 难题四：评估的困难

最后一个难题是：你怎么知道你的上下文工程做得好还是不好？

传统软件有明确的测试标准：输入A，期望输出B，实际输出C，对比即可。

但上下文工程的评估是模糊的：

• “记住”多少算够？
• “遗忘”多少算少？
• 什么该记什么不该记？

我们建立的评估框架

定量指标：

• 记忆命中率：用户提问历史相关内容时，Agent能正确回忆的比例
• 重复询问率：Agent重复询问已知信息的频率
• 上下文相关性：Agent使用的上下文与用户当前问题的相关度

定性评估：

• 用户满意度调研
• 专家人工评估（抽样检查对话质量）
• 对比测试（不同记忆策略的A/B测试）

实际效果

在我们的客服Agent上：

• 记忆命中率：从61%提升到89%
• 重复询问率：从23%降到4%
• 用户满意度：从3.4分提升到4.5分

但这些数字背后，仍然有很多”感觉不对”的case，需要持续的人工调优。

评估的本质困境

经过两年多的评估实践，我认为上下文工程评估面临一个本质困境：我们无法用简单的指标来度量一个本质上主观的体验。

用户是否觉得Agent”记得好”，不仅取决于客观的记忆准确率，还取决于记忆的时机、方式、语境。一个技术上完美的记忆系统，如果总是在不合适的时机提起旧信息，用户仍然会觉得烦。

我们最终的解决方案是”人在回路”的评估——自动化指标用于快速筛选明显的问题，但最终的判断权交给人工评估员。这成本高，但在目前的技术水平下，这是唯一可靠的方案。

量化与质化的结合

在评估实践中，我们发现量化指标和质化评估各有优劣。量化指标可以大规模应用，快速发现问题趋势；但它们无法捕捉主观体验的细微差别。质化评估可以提供深度洞察，但成本高、难以规模化。

我们的最佳实践是”分层评估”：

• 第一层（自动化）：监控核心指标，识别异常
• 第二层（抽样人工）：对异常样本进行人工分析
• 第三层（深度访谈）：对关键用户进行深度访谈，获取质化洞察

这种分层方法让我们既能保持对整体质量的把控，又能深入理解用户的真实感受。

3.5 难题五：多Agent系统的上下文协调

随着系统复杂度的增加，我们越来越多地面临多Agent协作的场景。这带来了新的上下文管理挑战。

场景：一个用户咨询涉及订单查询Agent、物流追踪Agent、售后处理Agent三个专业Agent的协作。

问题：每个Agent都有自己的记忆，但用户期望的是统一的体验——不希望对三个Agent分别重复同样的问题。

我们的解决方案

建立了”共享上下文层”——在多个Agent之上，有一个统一的上下文协调器：

• 用户的基础信息（身份、偏好）对所有Agent可见
• 当前对话的核心意图对所有Agent可见
• 各Agent的专业判断只在自己的领域内保留

这个架构还在持续演进中，但它已经显示出多Agent系统上下文管理的复杂性远超单Agent场景。

---

第四章：上下文工程与产品设计的深度融合

4.1 上下文即产品界面

在AI产品设计中，我们通常把界面理解为可视化的UI元素——按钮、输入框、卡片。但在Agent产品中，上下文本身就是界面的一部分。

当Agent在对话中提起用户上周问过的问题时，这是在向用户传达：“我记得你”。当Agent主动询问某个之前讨论过的细节时，这是在向用户传达：“我在认真听”。这些都不是传统的UI元素，但它们是用户体验的核心组成部分。

设计原则：上下文暴露的可控性

我们需要有意识地设计”上下文如何暴露给用户”。不是所有记忆都应该被显式表达，也不是所有遗忘都应该被隐藏。

我们采用的原则是：

• 主动暴露：Agent主动提起相关历史，显示”我在连接上下文”
• 被动响应：用户询问时准确回忆，但不主动提及
• 隐性融合：将历史信息融入当前回答，但不显式标注来源

不同的场景适合不同的策略。在客服场景，我们通常采用主动暴露，让用户感到被重视；在咨询场景，我们通常采用被动响应，避免给用户造成”被监视”的感觉。

微妙的平衡：何时提起过去

在实际设计中，我们发现”何时提起过去”是一个微妙的平衡。提得太频繁，用户会觉得Agent”翻旧账”；提得太少，用户又觉得Agent”不重视历史”。

我们通过A/B测试发现，最佳的策略是”相关性触发”——只有当历史信息与当前话题高度相关时，Agent才主动提起。例如，用户询问”上次的问题”，Agent自然应该提起；但如果用户只是闲聊，Agent不应无端提起过去的事情。

我们还发现，提起的语气也很重要。“您之前提到过…”比”我记得您说过…”更容易被用户接受。前者显得更客观，后者可能让用户感到被”监视”。

4.2 遗忘作为产品设计工具

在传统的软件设计中，我们不常考虑”遗忘”的功能。但在Agent产品中，遗忘是一个重要的设计工具。

场景一：尴尬记忆的遗忘

用户可能在一次对话中分享了过于私人的信息，事后感到后悔。如果Agent永远”记得”这些信息，用户会感到不安。我们需要提供”选择性遗忘”的功能——让用户能够指定某些内容不被记住。

场景二：过时信息的遗忘

用户的偏好会变化， yesterday’s truth 可能成为 today’s mistake。Agent需要能够识别信息的时效性，适时遗忘或更新旧信息。

场景三：认知负荷管理

有时候，记住太多反而是一种负担。Agent可能陷入”过度拟合”历史信息的陷阱，失去灵活性。适度的遗忘可以帮助Agent保持开放和适应性。

4.3 上下文工程的组织能力要求

上下文工程不仅是技术问题，还涉及团队组织能力的建设。

跨职能协作

上下文工程需要产品、工程、运营的紧密协作：

• 产品定义”什么信息重要”的业务规则
• 工程实现高效的记忆存储和检索
• 运营维护知识库的质量和时效性

传统的职能分工往往导致上下文工程被当作”工程问题”丢给工程师，结果是与业务需求脱节。我们后来建立了专门的”上下文工程小组”，由三个职能的人员组成，对上下文体验负整体责任。

持续运营

上下文工程不是一次性的开发任务，而是需要持续运营的工作。知识会过时，用户偏好会变化，业务规则会调整——这些都要求记忆系统的持续维护和更新。

我们建立了”记忆审计”机制——定期审查Agent的记忆内容，识别过时信息、错误关联、隐私风险等问题。这在传统软件开发中是罕见的，但在Agent时代成为了必要的运营工作。

---

第五章：给实践者的建议

5.1 起步阶段的 checklist

如果你正在或即将开始构建Agent的记忆系统，以下是我基于踩坑经验总结的checklist：

必须有的基础能力

• 工作记忆管理（即使是简单的滑动窗口）
• 用户身份识别和持久化
• 基础的长期记忆存储（至少记住用户是谁、偏好什么）
• 关键信息的显式标记（让用户能说出”请记住…”）

强烈建议的能力

• 智能摘要（不要直接截断，要提取关键信息）
• 分层记忆（热数据、温数据、冷数据）
• 跨会话记忆（让用户感觉在和同一个Agent对话）
• 隐私控制（让用户能看到和删除自己的数据）

进阶能力（根据场景决定）

• RAG集成
• 多设备同步
• 记忆的自学习和优化
• 复杂的用户画像系统

5.2 常见的过度设计陷阱

陷阱一：过早优化记忆系统

症状：在只有100个用户时，就设计了能支持100万用户的复杂记忆架构。

后果：开发周期长，代码复杂难维护，很多功能根本用不上。

建议：从简单开始，根据实际数据和用户反馈逐步演进。我们最初的版本只用了Redis做简单缓存，支撑到1万用户后才引入分层架构。

陷阱二：追求”记住一切”

症状：把用户的每一句话都永久保存。

后果：存储成本爆炸，检索噪音大，隐私风险高。

建议：建立记忆价值评估机制，定期清理低价值记忆。我们设定了”90天无访问即归档”的规则，大幅降低了存储成本。

陷阱三：忽视冷启动问题

症状：新用户第一次使用，Agent表现得像个完全不了解用户的陌生人。

后果：新用户体验差，流失率高。

建议：设计新用户引导流程，建立通用的默认画像。我们还为新用户准备了”通用行业模板”，根据用户选择的行业自动加载预设的常用知识。

陷阱四：技术驱动而非需求驱动

症状：因为向量数据库很火，所以要用向量数据库；因为知识图谱很先进，所以要建知识图谱。

后果：技术栈复杂，但业务价值不清晰。

建议：始终从用户问题出发，选择最简单的可行方案。我们有很多场景其实用简单的关键词匹配就够了，不需要上向量检索。

5.3 技术选型的思考框架

在选择上下文工程的技术栈时，我们建立了一个评估框架，希望能帮助其他团队做出更明智的决策。

评估维度一：延迟要求

不同场景对查询延迟的敏感度不同：

• 实时对话场景：要求<100ms，通常需要内存级存储（Redis）
• 异步任务场景：可接受1-5秒，可以使用磁盘存储或远程检索
• 离线分析场景：可接受分钟级，可以使用批处理和数据仓库

评估维度二：数据规模

• 小规模（<1万用户）：单机存储即可，PostgreSQL + Redis足够
• 中规模（1-100万用户）：需要分布式方案，考虑分片、复制、分层
• 大规模（>100万用户）：需要专门的向量数据库、分布式缓存、数据湖

评估维度三：查询模式

• 点查询为主：Key-Value存储（Redis）效率最高
• 相似度搜索为主：向量数据库（Pinecone、Milvus）更合适
• 复杂条件查询：关系型数据库（PostgreSQL）或搜索引擎（Elasticsearch）

评估维度四：团队能力

技术选型必须考虑团队的运维能力。一个需要专门SRE团队维护的方案，对于小团队来说可能不是好选择。我们最初选择Pinecone而不是自托管Milvus，就是考虑到团队没有专门的向量数据库运维经验。

5.4 成本控制的实战经验

上下文工程的成本往往被低估。在我们的实践中，存储成本、计算成本、运维成本都需要精细管理。

存储成本优化

• 数据压缩：对历史对话进行压缩存储，文本通常可以压缩到原大小的30-50%
• 分层存储：热数据用昂贵的内存，冷数据用廉价的对象存储
• 自动清理：设定TTL（生存时间），自动删除过期数据

计算成本优化

• 延迟加载：不要一次性加载所有记忆，按需加载
• 缓存策略：对频繁访问的记忆进行缓存
• 批量处理：向量嵌入等操作尽量批量进行

运维成本优化

• 托管服务优先：除非有强烈的自托管需求，否则优先选择托管服务
• 自动化运维：建立自动化的监控、告警、扩容机制
• 成本监控：建立成本仪表板，及时发现异常支出

5.5 从0到1的实施路径

基于我们的经验，一个典型的上下文工程实施路径如下：

第一阶段：基础搭建（1-2周）

• 实现工作记忆的基础管理
• 建立用户身份系统
• 搭建简单的长期记忆存储

第二阶段：体验优化（2-4周）

• 实现智能摘要
• 优化查询性能
• 添加跨会话记忆

第三阶段：规模扩展（4-8周）

• 引入分层存储架构
• 实现数据同步和备份
• 建立监控和告警

第四阶段：高级特性（8周+）

• 集成RAG
• 实现多设备同步
• 建立自动评估体系

这个时间表是基于一个5人团队的估算，实际时间可能因团队规模和技术基础而异。

5.6 避坑指南：我们犯过的错误

错误一：忽视了边缘情况

我们曾经遇到过一个诡异的bug：当用户对话恰好达到上下文窗口的边界时，Agent会生成无意义的重复内容。原因是我们的截断逻辑在处理边界情况时有缺陷。

教训：一定要测试各种边缘情况，包括空输入、超长输入、边界值等。

错误二：过度依赖自动化

我们曾经尝试过完全自动化的记忆摘要，希望减少人工干预。结果是在某些场景下，摘要丢失了关键信息，导致Agent做出错误的判断。

教训：在关键业务场景下，人工审核仍然是必要的。自动化可以提高效率，但不能完全替代人工判断。

错误三：忽视了数据迁移的复杂性

当我们从V1架构升级到V2架构时，低估了数据迁移的难度。旧数据的格式与新系统不兼容，需要大量的清洗和转换工作。这个过程导致了数天的服务中断。

教训：在设计初期就考虑数据格式的向后兼容性，建立数据迁移的SOP。

错误四：没有建立回滚机制

在一次更新中，新的记忆算法出现了bug，导致大量用户的记忆数据损坏。由于没有建立有效的回滚机制，我们花了整整一周时间才恢复服务。

教训：任何涉及记忆系统的更新都必须有回滚方案，并且定期演练。

5.7 团队能力建设

上下文工程对团队能力有特定要求，需要在以下方面投入：

技术能力

• 分布式存储和缓存技术
• 信息检索和NLP基础
• 数据建模和架构设计
• 向量数据库和相似度计算

业务能力

• 领域知识理解（Agent服务的具体业务领域）
• 用户体验设计能力
• 数据分析和实验设计

运营能力

• 知识库维护
• 记忆质量监控
• 用户反馈处理

这些能力通常分散在不同团队，需要建立跨职能的协作机制。

5.8 上下文工程与产品演进的协同

上下文工程不是孤立的，它需要与产品演进保持协同。我们总结了一些实践经验：

产品发布节奏与上下文工程的配合

• MVP阶段：重点关注工作记忆，确保基础对话体验
• 增长阶段：引入长期记忆，提升用户留存
• 成熟阶段：完善外部记忆和RAG，提供深度价值
• 扩张阶段：建立多Agent协作的上下文共享机制

数据驱动的迭代

我们建立了”记忆-行为-价值”的数据分析链路：

• 记忆命中率影响对话流畅度
• 对话流畅度影响用户满意度
• 用户满意度影响付费转化率

通过这个链路，我们可以量化上下文工程的业务价值，为资源投入提供数据支持。

---

第六章：未来展望——上下文工程的演进方向

6.1 从显式记忆到隐式理解

当前的上下文工程主要依赖显式的记忆存储和检索。未来的发展方向可能是更隐式的”理解”——Agent不是机械地记住信息，而是真正地”理解”用户的意图和语境。

这涉及到几个技术方向：

• 持续学习：Agent能够从对话中持续学习用户的偏好和模式
• 概念抽象：Agent能够理解抽象概念，而不是只记住字面信息
• 情境感知：Agent能够感知当前情境，动态调整行为

6.2 多模态上下文的融合

随着多模态模型的发展，上下文不再局限于文本。图像、音频、视频都将成为上下文的一部分。

这带来了新的挑战：

• 多模态存储：如何高效存储和检索多模态信息
• 跨模态关联：如何建立不同模态之间的关联
• 统一表示：如何将多模态信息统一表示和处理

6.3 隐私计算与上下文工程的结合

隐私保护将成为上下文工程的重要考量。联邦学习、差分隐私、同态加密等技术将被引入：

• 联邦记忆：用户的敏感记忆保存在本地，只共享脱敏后的模式
• 差分隐私：在记忆检索时添加噪声，保护个体隐私
• 安全计算：在加密状态下进行记忆检索和处理

6.4 上下文的标准化与互操作

随着多Agent生态的发展，上下文的标准化将变得重要：

• 标准格式：定义通用的上下文交换格式
• 互操作协议：不同Agent之间能够共享和理解上下文
• 上下文市场：可能出现专门的上下文提供商，为Agent提供预置的上下文知识

6.5 我的思考：上下文工程的本质

经过两年多的实践，我认为上下文工程的本质不是技术问题，而是**“如何在有限资源下最大化信息价值”**的问题。

这涉及到几个核心权衡：

• 存储 vs 遗忘：记住越多成本越高，但也可能带来更好的体验
• 精确 vs 模糊：精确记忆成本高，模糊记忆可能丢失关键信息
• 个性化 vs 隐私：越个性化越需要数据，但数据越多隐私风险越高
• 实时 vs 离线：实时记忆响应快但成本高，离线处理成本低但延迟高

这些权衡没有标准答案，需要根据具体场景和业务目标做出选择。

核心洞察：优秀的上下文工程不是追求技术先进性，而是在约束条件下做出最优的权衡决策。

---

附录：三个真实的踩坑案例深度剖析

为了更具体地说明上下文工程的复杂性，我挑选了三个真实的案例进行深度剖析。这些案例涵盖了我们遇到的主要问题类型，希望能给其他团队提供参考。

案例一：那个”突然失忆”的医疗咨询Agent

背景：我们为一家互联网医疗平台开发了健康咨询Agent，用户可以向它咨询症状、用药、就医建议等问题。

问题现象：上线第一周，我们收到了大量用户投诉，核心反馈是”AI医生突然失忆”。具体表现是：用户在对话开头描述了自己的症状和病史，Agent给出了初步建议；但当用户追问具体用药剂量时，Agent却问”您刚才说您是什么症状来着”。

问题排查：

我们花了三天时间排查，最终发现问题的根源是上下文截断策略过于激进。

在医疗咨询场景下，用户通常会在对话开头进行长篇的症状描述，可能包含数百字的病史、症状细节、过敏史等信息。而我们的Agent为了控制token消耗，设置了15轮对话的截断阈值。当对话超过15轮时，系统会自动丢弃最早的对话记录。

问题在于，医疗场景下用户很少会在15轮内结束咨询。平均对话轮次是23轮，这意味着几乎所有对话都会触发截断。而最早的几轮对话恰恰是用户描述症状的关键信息。

解决方案：

我们实施了几个改进措施：

1. 医疗信息特殊保护：将症状描述、病史、过敏史等关键医疗信息标记为”高优先级”，不参与普通的截断逻辑

2. 智能摘要替代截断：不再简单丢弃早期对话，而是提取其中的关键医疗信息，生成结构化的医疗摘要

3. 主动确认机制：在提供用药建议等关键回答前，Agent会主动复述用户的症状，确认理解正确

效果：改进后，“突然失忆”的投诉下降了92%，用户满意度从3.2分提升到4.4分。

经验教训：

• 不同场景对上下文的需求差异巨大，不能用统一的策略
• 关键信息需要特殊保护机制
• 在关键节点主动确认可以显著提升用户信任

案例二：那个”越聊越慢”的客服Agent

背景：我们为一家电商平台开发了客服Agent，处理用户的售前咨询、订单查询、售后处理等问题。

问题现象：上线一段时间后，用户反馈Agent”越聊越慢”——对话开始时响应很快，但随着对话进行，响应时间越来越长，有时甚至超过10秒。

问题排查：

我们通过性能监控发现，随着对话轮次增加，上下文检索的延迟呈线性增长。当对话超过20轮时，平均检索延迟从50ms增加到800ms。

深入分析后发现，问题出在我们的RAG实现上。每次用户提问时，系统会检索相关的历史对话作为上下文。但随着对话轮次增加，需要检索的历史记录也越来越多，导致检索时间线性增长。

更深层的问题是，我们没有建立有效的”上下文去重”机制。很多检索到的历史信息实际上是重复的或冗余的，但仍然被加载到上下文中。

解决方案：

1. 分层检索策略：

   • 首先检索最近5轮对话（热数据，延迟<10ms）
   • 只有必要时才检索更早的历史（温/冷数据）
   • 对历史对话进行聚类，相似问题合并处理

2. 智能预加载：

   • 根据对话主题，预判可能需要的上下文
   • 在后台异步加载，减少实时检索压力

3. 上下文去重：

   • 建立语义去重机制，相似内容只保留一份
   • 定期清理冗余的历史记录

效果：优化后，20轮对话后的响应延迟从800ms降低到120ms，用户关于”慢”的投诉下降了85%。

经验教训：

• 上下文检索的性能会随着数据量增长而恶化，需要提前设计
• 不是所有历史信息都需要实时检索，分层策略很重要
• 去重和压缩可以显著提升性能

案例三：那个”泄露隐私”的内部助手

背景：我们为一家公司开发了内部助手Agent，员工可以用它查询内部政策、提交申请、获取技术支持等。

问题现象：上线后不久，发生了一起严重的隐私泄露事件。一位员工发现，当他询问”加班费政策”时，Agent的回答中包含了其他员工的加班费申请记录——包括姓名、金额等敏感信息。

问题排查：

调查发现，问题出在我们的RAG数据隔离机制上。

为了实现跨部门的政策共享，我们将所有政策文档存储在同一个向量数据库中。但我们没有建立严格的权限隔离机制——当Agent检索相关信息时，它会检索到所有可访问的文档，包括其他员工的敏感申请。

更深层的问题是，我们的Agent没有”权限感知”能力。它不知道当前用户是谁、应该访问哪些数据，只是机械地检索和生成。

解决方案：

1. 数据分层隔离：

   • 公共政策：所有员工可访问
   • 部门政策：仅限本部门员工访问
   • 个人数据：仅限本人和授权人员访问

2. 权限感知检索：

   • 每次检索时，传入当前用户的权限信息
   • 只检索用户有权限访问的数据
   • 在生成回答时，再次检查信息权限

3. 敏感信息脱敏：

   • 自动识别人名、金额等敏感信息
   • 在检索和生成时进行脱敏处理
   • 建立敏感词库，定期更新

4. 审计日志：

   • 记录所有数据访问行为
   • 定期审计，发现异常访问
   • 建立告警机制，及时响应

效果：实施这些措施后，未再发生类似的隐私泄露事件。同时，员工对Agent的信任度显著提升，使用量增加了40%。

经验教训：

• 隐私保护必须是架构级的考虑，不能事后补丁
• Agent需要具备”权限感知”能力，理解数据的访问边界
• 审计和监控是发现和防范隐私问题的关键

三个案例的共同启示

回顾这三个案例，我发现它们有一个共同的启示：上下文工程的问题往往不是技术本身的问题，而是对场景理解不足的问题。

• 医疗案例的问题源于对医疗场景特殊性的理解不足
• 性能案例的问题源于对数据规模增长的理解不足
• 隐私案例的问题源于对权限模型复杂性的理解不足

这提醒我们，在做上下文工程时，不能只看技术实现，更要深入理解业务场景、用户行为、数据特性。技术方案必须建立在对场景的深刻理解之上。

---

回到文章开头的那个失败案例——如果当时我们有一个真正优秀的上下文管理系统：

• 它会识别出MES系统对接是这次对话的核心主题，将其标记为高优先级记忆
• 它会在上下文紧张时，优先保留与当前问题相关的信息，而非简单地丢弃最早的对话
• 它会在必要时主动确认关键信息：“您刚才提到的MES系统对接需求，我理解正确吗？”
• 它会在生产副总提问时，立即回忆起之前的所有相关讨论

结果可能会完全不同。

上下文工程之所以重要，是因为它决定了Agent能否展现出”情商”——记住该记住的，忘记该忘记的，在合适的时候提起合适的事情。

一个没有记忆的Agent，就像金鱼一样，只能给出条件反射式的回应。 一个有记忆但管理混乱的Agent，就像一个话痨但抓不住重点的人，让人抓狂。 只有拥有优秀上下文工程的Agent，才能成为一个真正理解用户、陪伴用户的智能伙伴。

这是我在两年多的实践中最大的感悟，也是本文想要传达的核心信息。

展望未来，随着多模态交互、多Agent协作、长期陪伴型Agent的发展，上下文工程的重要性只会越来越高。它不仅仅是技术实现问题，更是产品设计问题、用户体验问题、甚至是伦理问题。

作为Agent产品的构建者，我们需要把上下文工程提升到与模型选择、Prompt工程同等重要的位置，投入足够的资源和注意力。因为最终决定Agent产品成败的，可能不是它有多”聪明”，而是它有多”懂你”。

而这个”懂”，正是上下文工程的核心使命。

---

参考资源

原文：

• Kaggle Context Engineering Whitepaper

相关阅读：

• 《MemGPT: Towards LLMs as Operating Systems》
• 《Augmenting Language Models with Long-Term Memory》
• 《Large Language Model Conversations: A Framework for Memory Management》

工具推荐：

• MemGPT: https://github.com/memgpt/memgpt
• LangChain Memory: https://python.langchain.com/docs/modules/memory/
• Pinecone: https://www.pinecone.io/
• Milvus: https://milvus.io/

---

本文为原创实践总结，基于个人项目经验撰写。

最后更新：2026-03-12