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最后用重排模块综合打分。我在实际项目里常用的策略是先用关键词召回获得一批候选保证高字面重合的记录不遗漏。再用向量召回获得另一批候选覆盖语义相似但字面不同的内容。合并去重后让模型或轻量级重排器根据当前任务权重打分选出Top-K条注入上下文。这个方法看着笨实跑下来召回准确率比单用向量检索高出不少尤其在实体名、订单号这类高精度场景下优势明显。4. 实战拆解基于上下文工程构建一个可靠的客服智能体4.1 项目场景与目标定义我拿最近帮一个模拟电商客服团队做的重构举例。原系统是一个简单的问答机器人用户发消息、机器人查知识库回答效果很差——用户多问几轮机器人就“失忆”问跨fabricated订单的问题答非所问遇到需要调多个工具的场景直接弃疗。重构目标定义得很具体支持至少20轮连续对话状态不丢失。能处理“查订单—查退款政策—核对身份—发起退款”四步混合任务。回答延迟控制在3秒以内模型推理加工具调用。引用知识库内容时必须标注来源章节。4.2 架构设计上下文管线与工具调用的配合整个智能体架构分五个模块输入预处理、上下文管理器、任务规划器、工具执行器、记忆管理器。其中上下文管理器是核心它决定每一轮模型到底“看到什么”。上下文管理器的工作流程是这样的接收用户输入先做意图识别和实体抽取。判断当前任务状态新任务还是续接任务如果是续接从工作记忆恢复状态。检索长期记忆根据用户ID和当前意图召回相关历史记录。知识库检索根据当前问题召回业务文档片段。组装上下文按固定模板拼装成发送给模型的完整请求。模板结构如下[系统指令] 你是电商客服助手遵循以下规则...固定内容 [工作记忆] 当前任务、已收集信息、下一步动作结构化JSON [对话摘要] 前几轮对话的核心结论与未解决问题压缩内容 [用户知识] 该用户的历史偏好、历史订单摘要检索结果 [业务知识] 与当前问题相关的政策条款、流程说明检索结果 [本轮输入] 用户刚刚发来的消息 [执行要求] 请根据以上信息决定1直接回复 2调用工具 3追问澄清这个顺序是有讲究的。把工作记忆放在系统指令后面是因为模型对中前段的注意力相对更强任务状态需要被“优先看到”。把流动输入放在最后是让模型在处理最新用户问题时先已经在前面建立了全局认知不会因为用户消息位置靠后而忽略规则。4.3 工具调用场景下的上下文注入技巧客服智能体不可避免要调工具查订单、查物流、查退款进度等。每个工具返回的原始数据往往很长直接塞进上下文有两个问题浪费窗口空间且原始API字段命名对模型来说是噪音。我的做法是加一个“工具结果精简器”在工具结果进入上下文之前先做一次转换。原则是只保留模型决策所需字段。长列表字段做截断只保留前N条。统一转成自然语言描述避免模型去理解JSON嵌套。举个例子查订单接口返回的原始JSON有三十多个字段转成给模型的上下文时变成一句话订单OD20250101状态已发货物流公司顺丰预计送达2025-01-05 当前物流轨迹——【已到达】所在地区分拨中心下一站派送中。这么做还有一个额外好处模型更容易判断“信息够不够”。如果精简后的信息不足以回答用户问题模型会主动触发追问或二次调用工具而不是基于残缺数据瞎编。4.4 多轮会话的上下文更新策略多轮会话中每轮结束都要更新上下文而不是等到下一轮才开始清理。核心更新策略有五条用户核心消息原样保留到工作记忆的“本轮输入”区。工具调用结果精简后写入工作记忆的“已收集信息”字段。模型做出的关键决策写入任务历史的步骤记录。已完成的子任务对应的原始数据块从工作区清除。超过5轮未引用的信息折叠进对话摘要。这个“逐轮处理”的策略确保在任意时刻发送给模型的上下文都保持轻量、准确、无冗余。看起来实现成本不高但实际工程里很多团队会偷懒为了省事把整个对话历史都发过去让小模型自己“找重点”。短会话还行超过5轮就开始崩。4.5 效果对比与关键指标变化重构后我做了A/B对比测试。同一个测试集中新旧系统的指标对比如下指标旧系统全量历史无记忆新系统上下文工程记忆管理20轮内任务完成率52%86%平均每轮延迟2.8秒2.1秒单次会话Token消耗12.6K7.4K信息溯源准确率无法追溯94%用户满意度评分3.2/54.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智能体项目我的建议很朴素把上下文工程当成和模型选型同等重要的一件事来对待。模型选错了可以换上下文没管好换什么模型都救不回来。这就像一个厨师菜刀可以换但食材处理和灶台管理要是乱了什么菜都做不好。
