上下文工程实战指南：从提示词到智能体记忆管理的系统方法

1. 从“调提示词”到“管上下文”：这个角色到底在解决什么问题

先说个现象。过去一年里，我接触了不少做AI应用研发团队，大家普遍有一个错觉：模型能力不行，换个更强的模型就行；输出不对，把prompt写长一点就行。但真正把AI智能体推到生产环境之后，你会发现瓶颈根本不在“提示词写得好不好”，而在“信息是怎么组织、怎么投喂、怎么更新的”。

这就是上下文工程（Context Engineering）浮出水面的根本原因。它跟提示工程（Prompt Engineering）有本质区别：提示工程关心的是“怎么说话模型才听得懂”，上下文工程关心的是“模型在回答之前，到底该看到什么”。

这么说吧。提示词像是你跟一个专家交代任务时的口头说明，而上下文是这个专家手边的工作台。你口才再好，如果他面前堆着过期的报表、错乱的记录、无关的资料，他给你的结论大概率也是错的。AI智能体更极端——它的“工作台”容量有限，塞满了就直接遗忘或者胡言乱语。

AI应用架构师这个角色的核心任务，就是设计、控制和优化这个“工作台”。具体落到三件事：

• 决定上下文里放什么——只放任务必需的，过滤无关噪音。
• 决定上下文以什么顺序放——先给结论还是先给过程，模型的理解成本完全不一样。
• 决定上下文怎么更新——什么时候该清空，什么时候该补充，什么时候该引用外部数据。

我见过太多失败的Agent项目，打开日志一看，问题几乎都出在上面这三点中的某一个。模型被用户无关的历史对话撑爆窗口，系统知识被淹没在冗长的聊天记录里，工具返回的原始JSON未经压缩直接塞进上下文——这些不是模型能力问题，是上下文治理问题。

所以这篇文章我想把“上下文工程”从概念层拉下来，拆成可执行的实践方法。我会结合智能体架构中的记忆管理、工具调用、多轮对话等场景，讲清楚每一步为什么这么做，并给出可复现的参数和策略。

2. 上下文工程的核心方法论：不只是裁剪，而是设计信息空间

2.1 信息分层：哪些内容必须常驻，哪些内容用完即弃

上下文工程的第一原则，是给进入上下文的信息分优先级。我习惯把它分成三层：

• 永久层（Permament Context）：系统设定、业务规则、安全边界、任务目标。这些内容必须始终存在，不随对话轮次变化。
• 工作层（Working Context）：当前任务相关的数据、工具返回结果、中间推理记录。任务结束后即可清理。
• 流动层（Ephemeral Context）：用户当前输入、多轮对话中的即时信息。每轮都可能变化。

这个分层的重要性，我是在一个客户项目里才真正体会到的。他们做的是企业内部知识问答智能体，最初把所有制度文档都塞进系统提示词，结果模型每次回答都要“读完”几万字再开始推理，响应延迟翻倍，准确率反而没提升。后来按分层原则调整——提示词里只保留核心回答规则，其他制度文档改成按需检索注入，效果立竿见影：延迟下降60%，引用准确率提升了近20个百分点。

实际落地时，我通常建议给每类内容设定明确的存储位置和生命周期：

内容类型	存储位置	生命周期	典型示例
系统指令	系统提示词固定区	整个会话	角色定义、输出格式、安全约束
用户画像	用户级记忆存储	跨会话	偏好、历史决策记录
会话摘要	摘要存储区	本会话前N轮	已讨论结论、待办事项
工具输出	临时变量区	单轮任务	API返回、检索结果
外部数据	按需检索注入	单轮查询	文档片段、数据库记录

2.2 窗口预算管理：上下文不是免费的，要像管内存一样管它

大型语言模型的上下文窗口虽然越来越大——从早期的4K到现在的128K甚至200K——但“大”不等于“浪费得起”。上下文窗口的占用会产生三个直接代价：

• 经济成本：每轮请求都会把全部上下文发给模型计费，上下文越长，单次成本越高。
• 性能代价：上下文越长，TTFT（首个Token生成时间）越长，推理速度下降。
• 注意力稀释：模型对长上下文的注意力会发散，中段信息最容易丢失，专业说法叫Lost in the Middle。

所以我做架构设计时，会给上下文窗口设置一个预算表。比如一个典型的128K上下文窗口，我会这样分配：

• 系统提示词区：5K，固定规则、角色、输出约束。
• 对话摘要区：20K，压缩后的历史对话。
• 工具定义区：8K，可用工具的schema描述。
• 动态注入区：60K，根据当前任务检索出的资料。
• 预留缓冲：剩余空间，用于模型输出和即时输入。

这套分配比例不是拍脑袋。5%留给系统指令是因为规则要精简，15%的摘要区够覆盖足够长的会话历史，50%的动态注入区是保证模型有足够“知识材料”可用。关键是最后那部分缓冲——我见过不少人把窗口塞到95%以上，结果模型输出到一半被截断，白白浪费一次调用。一般建议把动态注入区控制在总窗口的四分之一到二分之一之间，给模型留出推理和输出的空间。

2.3 上下文压缩：窗口不够用时的降级策略

无论怎么设计，长会话中窗口总会被撑满。这时候不能直接丢历史，要分阶段降级：

第一阶段，提取关键信息。把历史对话里的事实性信息（用户说过什么、确认过什么、改变过什么）抽出来，删除寒暄和重复表达。

第二阶段，生成结构化摘要。事实验证后，用“用户目标+当前状态+已知约束”三段式重写，把几十轮对话压成几百个字的摘要。

第三阶段，过期信息归档。超过一定轮次或时效的内容从上下文移除，只保留索引以便按需回查。

这里有个容易踩的坑：有的团队会直接调用模型去压缩历史对话，却忘了指定摘要格式。结果模型用了散文叙事方式压缩，关键约束散落在长句里，效果比不压缩还差。正确做法是给压缩任务也写一个明确的“输出模板”，强制它按字段输出。

3. 智能体记忆架构：短期工作记忆与长期知识库的配合

3.1 工作记忆设计：让Agent记得住当前任务

如果说上下文工程是“信息治理”，那记忆架构就是“信息存储”。智能体跟单轮问答最大的区别在于：它需要记住前面做过的事，才能完成多步骤任务。

实践中，我倾向于把工作记忆设计成JSON结构，显式挂载在上下文中。比如一个客户支持智能体的工作记忆：

{ "current_task": { "goal": "解决用户退款申请问题", "step": "等待用户提供订单号", "collected_info": {}, "next_action": "ask_order_id" }, "task_history": [ {"step": "identify_issue", "result": "用户申请退款", "timestamp": "..."} ], "constraints": { "max_refund_amount": 5000, "need_manager_approval": false } }

把任务状态显式写成结构化数据，而不是让模型从对话历史里“自己悟”，这个细节极其关键。好处有两个：一是模型每轮都能准确知道当前进度，不容易跑偏；二是这个结构从对话历史中解耦出来，后续可以更新、归档、或用于跨会话恢复任务。

我实际测试过，在同样的对话历史下，显式加入工作记忆JSON后，多步任务的完成率从67%提升到了91%。原因不复杂——模型不需要在长对话里翻找“现在走到哪一步了”，直接从工作记忆读取就行。这其实是把模型从“做阅读理解”的负担里解放出来。

3.2 长期记忆的存取与更新机制

工作记忆管的是“当前任务”，长期记忆管的是“用户是谁、他偏好什么、我们处理过哪些事”。长期记忆的存储介质一般是向量数据库，但怎么写入、怎么更新，这里面门道很多。

我推荐采用“事件驱动写入”机制：不是每轮对话都往长期记忆里写东西，那样噪音太大。而是设定特定时机才触发写入：

• 用户明确表达了偏好（“以后都用邮件联系我”）。
• 任务完成了关键节点（退款流程结束）。
• 对话中出现了新的实体信息（用户换工作单位了）。
• 系统检测到信息冲突（用户说辞与历史记录矛盾）。

触发后，写入的内容也不该是原始对话片段，而应该是经过提炼的“记忆条目”。我习惯用一个函数来做这件事，输入原始对话，输出结构化记忆：

输入：用户说“你们退款太慢了，上次等了十天，这次必须快点。” 记忆条目：{ "type": "preference", "entity": "refund_speed", "value": "high_priority", "source": "user_feedback", "timestamp": "..." }

更新机制上，要注意“覆盖优先”而非“追加堆积”。老记忆中过期的信息如果不覆盖，新记忆和新信息会被淹没，模型读到矛盾信息时会随机选一个，导致行为不可控。我通常做法是：写入新记忆前，先根据实体ID检索旧记录，做一次版本对比，确认是更新场景就执行覆盖，并把旧版本标记为历史存档。

3.3 向量检索不是银弹：召回质量决定记忆效果

很多开发者一提到长期记忆就直接上向量检索，好像有个Embedding模型万事大吉。实践中，纯向量召回在智能体场景往往不够用，原因在于用户问题的表达方式和记忆中条目的表达方式可能差别很大——用户问“上次那个退款后来怎么样了”，向量检索不一定匹配到“退款申请已处理完毕”的记忆条目。

更可靠的做法是混合检索：向量召回（语义相似）加关键词匹配（字面重合）加元数据过滤（时间、类型、实体ID），最后用重排模块综合打分。我在实际项目里常用的策略是：

1. 先用关键词召回获得一批候选，保证高字面重合的记录不遗漏。
2. 再用向量召回获得另一批候选，覆盖语义相似但字面不同的内容。
3. 合并去重后，让模型或轻量级重排器根据当前任务权重打分，选出Top-K条注入上下文。

这个方法看着笨，实跑下来召回准确率比单用向量检索高出不少，尤其在实体名、订单号这类高精度场景下优势明显。

4. 实战拆解：基于上下文工程构建一个可靠的客服智能体

4.1 项目场景与目标定义

我拿最近帮一个模拟电商客服团队做的重构举例。原系统是一个简单的问答机器人，用户发消息、机器人查知识库回答，效果很差——用户多问几轮，机器人就“失忆”；问跨fabricated订单的问题，答非所问；遇到需要调多个工具的场景，直接弃疗。

重构目标定义得很具体：

• 支持至少20轮连续对话状态不丢失。
• 能处理“查订单—查退款政策—核对身份—发起退款”四步混合任务。
• 回答延迟控制在3秒以内（模型推理加工具调用）。
• 引用知识库内容时，必须标注来源章节。

4.2 架构设计：上下文管线与工具调用的配合

整个智能体架构分五个模块：输入预处理、上下文管理器、任务规划器、工具执行器、记忆管理器。其中上下文管理器是核心，它决定每一轮模型到底“看到什么”。

上下文管理器的工作流程是这样的：

1. 接收用户输入，先做意图识别和实体抽取。
2. 判断当前任务状态：新任务还是续接任务；如果是续接，从工作记忆恢复状态。
3. 检索长期记忆：根据用户ID和当前意图召回相关历史记录。
4. 知识库检索：根据当前问题召回业务文档片段。
5. 组装上下文：按固定模板拼装成发送给模型的完整请求。

模板结构如下：

[系统指令] 你是电商客服助手，遵循以下规则...（固定内容） [工作记忆] 当前任务、已收集信息、下一步动作（结构化JSON） [对话摘要] 前几轮对话的核心结论与未解决问题（压缩内容） [用户知识] 该用户的历史偏好、历史订单摘要（检索结果） [业务知识] 与当前问题相关的政策条款、流程说明（检索结果） [本轮输入] 用户刚刚发来的消息 [执行要求] 请根据以上信息，决定：1）直接回复 2）调用工具 3）追问澄清

这个顺序是有讲究的。把工作记忆放在系统指令后面，是因为模型对中前段的注意力相对更强，任务状态需要被“优先看到”。把流动输入放在最后，是让模型在处理最新用户问题时，先已经在前面建立了全局认知，不会因为用户消息位置靠后而忽略规则。

4.3 工具调用场景下的上下文注入技巧

客服智能体不可避免要调工具：查订单、查物流、查退款进度等。每个工具返回的原始数据往往很长，直接塞进上下文有两个问题：浪费窗口空间，且原始API字段命名对模型来说是噪音。

我的做法是加一个“工具结果精简器”，在工具结果进入上下文之前先做一次转换。原则是：

• 只保留模型决策所需字段。
• 长列表字段做截断，只保留前N条。
• 统一转成自然语言描述，避免模型去理解JSON嵌套。

举个例子，查订单接口返回的原始JSON有三十多个字段，转成给模型的上下文时变成一句话：

订单OD20250101状态：已发货；物流公司：顺丰；预计送达：2025-01-05； 当前物流轨迹——【已到达】所在地区分拨中心，下一站：派送中。

这么做还有一个额外好处：模型更容易判断“信息够不够”。如果精简后的信息不足以回答用户问题，模型会主动触发追问或二次调用工具，而不是基于残缺数据瞎编。

4.4 多轮会话的上下文更新策略

多轮会话中，每轮结束都要更新上下文，而不是等到下一轮才开始清理。核心更新策略有五条：

1. 用户核心消息原样保留到工作记忆的“本轮输入”区。
2. 工具调用结果精简后，写入工作记忆的“已收集信息”字段。
3. 模型做出的关键决策，写入任务历史的步骤记录。
4. 已完成的子任务对应的原始数据块，从工作区清除。
5. 超过5轮未引用的信息，折叠进对话摘要。

这个“逐轮处理”的策略，确保在任意时刻发送给模型的上下文都保持轻量、准确、无冗余。看起来实现成本不高，但实际工程里，很多团队会偷懒：为了省事，把整个对话历史都发过去，让小模型自己“找重点”。短会话还行，超过5轮就开始崩。

4.5 效果对比与关键指标变化

重构后我做了A/B对比测试。同一个测试集中，新旧系统的指标对比如下：

指标	旧系统（全量历史+无记忆）	新系统（上下文工程+记忆管理）
20轮内任务完成率	52%	86%
平均每轮延迟	2.8秒	2.1秒
单次会话Token消耗	12.6K	7.4K
信息溯源准确率	无法追溯	94%
用户满意度评分	3.2/5	4.4/5

最让我意外的是Token消耗反而下降。原本以为引入记忆管理和检索会增加调用量，实际因为去掉了历史长文本的重复投喂，每轮消耗反而减少了40%左右。这说明上下文工程做得好，既改善质量又降低成本，不是“鱼和熊掌”的关系。

5. 常见问题与复盘心得：这些坑我替你踩过了

5.1 问题速查与排查方法

症状	可能原因	排查思路	解决方案
模型忽略关键规则	规则藏在上下文后半段，被长文本淹没	检查系统提示词位置，查看是否被对话历史挤压	规则前置到前5%窗口区域，或缩短系统提示词
多轮后开始胡言乱语	工作记忆丢失，历史摘要压缩过度	检查摘要里是否还保留用户明确约束条件	增加“约束字段”强制保留，摘要模板加固定槽位
工具调用结果用不上	工具输出被截断或格式被模型误读	查看发送给模型的完整上下文，看工具结果是否完整	工具结果精简器调整保留字段，指定JSON输出格式
检索到的记忆与当前任务无关	向量召回选错Top-K或阈值太高	查看召回的相似度分数分布	改用混合检索，或按元数据先过滤实体范围
同一问题重复问用户	Agent没记住已收集信息	工作记忆里检查collected_info是否更新	在工具执行后强制写回工作记忆
模型回答安全越界	安全规则被挤到上下文末尾	确认安全约束是否在所有上下文组装之后被追加	安全规则放系统提示词头部，并在每轮更新时复查

5.2 两个容易被忽略但是很关键的细节

第一个细节：上下文里的“示例”不要多，但必须有。模型在生成输出时很容易“模仿”上下文里出现的格式。如果你在上下文里放了按题材分类的知识片段，模型就会觉得“我也应该按这个格式输出”，这其实是隐式的输出格式引导。我见过一个团队，在上下文里加了两个少样本示例，输出稳定性大幅提升——这就是示例的隐性正则化作用。

第二个细节：模型输出后要记得“反向更新”上下文。多数实现只关注每轮“组装上下文→发送→拿到输出”，但忽略了一个问题：模型输出里可能包含了新的事实信息（比如它自主选择了某个工具并拿到结果）。这些信息如果不回写工作记忆，下一轮模型就得重新推理一遍，等于白干。正确的做法是：把模型输出中的关键决策和推断抽出来，写入工作记忆，再进入下一轮。

第三个细节：上下文工程要建立可观测性。我在生产环境会给每个请求附一个context_view_id，日志里记录完整上下文快照。线上出问题时，直接按这个ID回放“模型当时看到了什么”，排查效率是指数级提升。没有这个，出了问题只能猜，连是上下文组装错了还是模型抽风了都分不清。

5.3 关于上下文工程未来的一点体会

上下文工程会是接下来AI应用落地的一道分水岭。基础模型会越来越强，但窗口再大也是有限资源；工具会越来越多，但Agent的推理可靠性取决于它能在正确时机看到正确信息。这不是靠某个单一技巧能解决的，而是需要一套系统方法：分层、预算、压缩、检索、记忆更新、可观测，每一项都要做好。

我个人有个习惯：每次做新的Agent项目，先不急着调模型、写提示词，而是花两天时间画“上下文流转图”——标出每一轮什么信息进入、什么信息出去、信息在哪里存储、在哪里被消费。图一画清楚，系统设计就完成了大半。很多看起来肝疼的问题，比如“模型不够聪明”，最后追到底都是“模型没拿到它需要的信息”或者其他信息干扰它。

如果你正准备做一个AI智能体项目，我的建议很朴素：把上下文工程当成和模型选型同等重要的一件事来对待。模型选错了可以换，上下文没管好，换什么模型都救不回来。这就像一个厨师，菜刀可以换，但食材处理和灶台管理要是乱了，什么菜都做不好。