我最早意识到上下文工程是独立问题是在一个内部工具的第五次联调上。功能明明都对齐了模型却能在一段对话里反复失忆上午刚确认的筛选规则下午就问第二遍用户上一轮给了三条约束模型下一轮只记得两条。当时组里第一反应是换更大的模型结果换来换去该忘还是忘。后来才想明白推理能力再强也架不住输入里根本没有那段信息。这就是上下文工程的价值它不解决“模型会不会答”而解决“模型有没有条件答好”。从记忆存储到智能决策中间隔着一整套流水线。这篇文章把我过去几个月打磨这条流水线的过程、取舍和踩过的坑完整梳理一遍适合已经跑通 agent demo、正在往生产环境推、开始被“记忆和一致性”折磨的开发者参考。1. 记忆存储的三个层次工作记忆、情景记忆、语义记忆的区别与落地很多人一提“给 agent 加记忆”第一反应就是“把聊天记录存进向量库”。这个做法不能说错但太粗糙了。人的记忆本来就分层次agent 也一样。我把记忆拆成三层分别处理后面所有结构都是基于这个分层展开的。1.1 工作记忆每一轮对话都要重新算的 token 预算工作记忆就是“当前这轮请求里模型上下文窗口里装的东西”。它不持久但它是所有决策的直接输入。我见过最典型的问题是把所有历史消息一股脑塞进上下文。早期我图省事直接拼接最近 20 轮对话结果发现两个问题一是 token 成本飙升二是模型注意力被长尾信息稀释反而容易忽略最新指令。后来我给工作记忆设置了严格的预算分配通常按这样划分系统提示词固定占用控制在几百 token只放角色、全局规则、安全边界。会话级上下文滑动窗口取最近若干轮关键消息并附带一个自动生成的滚动摘要。检索记忆片段从情景记忆和语义记忆里检索出来的增量知识单条限制长度总预算设上限。工具描述与输出把可能用到的工具 schema 放进来但只放当前意图下可能命中的工具。这个预算不是死的要根据实际场景调。比如客服场景历史对话的权重就高数据分析场景用户实时输入的表格结构可能比历史更重要。关键是要有明确的分配意识而不是让 token 窗口自己“随缘”。滑动窗口的具体做法我用的是“摘要 最近 N 轮”的组合每轮对话结束后把超过窗口上限的历史内容交给一个小模型做增量摘要摘要存进上下文里原始内容落到情景记忆的存储层。这样模型永远能看到“到目前为止发生了什么”的高层概括以及最近几轮的原始细节不至于既要拼图又要读原文。1.2 情景记忆会话历程的结构化存储情景记忆对应“这个用户之前和 agent 发生过什么”核心是事件流。我不建议只存向量更推荐以结构化的方式存事件同时附带向量索引。原因很实际向量索引适合相似度检索但不适合精确回溯。比如“用户上周三说过什么”这种查询用结构化字段很容易用向量要跑一圈相似度还不一定准。我的消息结构大致长这样session_id会话归属。event_type比如 user_message、agent_reply、tool_call、tool_result。ts事件发生时间。content原始文本或结构化数据。embedding内容向量化后的结果用于语义检索。meta自定义标签比如对应业务线、用户 id、关联的订单号。存储层用关系型数据库存事件本体旁边配一个向量索引组件。写入时先落库再算 embedding读取时根据场景决定走哪条路。这种设计的好处是弹性大要精确回溯走 SQL要相似度召回走向量要混合检索就先过滤再向量。情景记忆的写入时机也要讲究。不是每条消息都值得存更不是每条消息都要立刻向量化。我在实践中做了分级普通对话异步落库含关键动作的对话比如用户确认了一个方案、下了一个指令、拒绝了某个建议额外打上高优先级标签确保后续检索时能被加权命中。1.3 语义记忆从碎片对话里抽取长期事实语义记忆是我后期才补上的一层却是整个系统从“能用”到“好用”的分水岭。它的作用是回答一个问题这个用户到底在意什么他偏好什么格式他说过哪些长期有效的要求抽取语义记忆需要专门的流水线对话发生之后定期运行一个抽取任务把“短期事件”总结成“长期事实”。比如用户说“以后报告都用表格别用段落”这句话不应该只活在某一段历史里它应该被抽取成一条语义记忆在后续所有报告类任务中生效。这里有个坑抽取任务不能太激进否则会把一次性事件误写成长期偏好。我的方案是两层校验。第一层是规则过滤只有包含明确偏好词、状态描述、重复出现的强信号的句子才进入候选第二层是“强化确认”如果用户后续行为验证了这条偏好——比如连续三次都要求表格输出——才把它的权重调高否则逐渐降权。语义记忆的存储我采用“事实三元组”加向量双通道。三元组用于精确查询比如“用户A-偏好-表格”向量用于模糊召回比如“这个用户通常希望输出长什么样”。两条通道合并后进决策层。2. 记忆检索不是查数据库相关性排序、上下文压缩与时效性有了存储下一步是怎么取。这一步我从“top-k 遍历”改成“先召回、再过滤、再压缩、再排序”的流程后效果提升非常明显。很多人把检索看成数据库操作但检索的结果是要塞进 prompt 给模型看的它必须符合“对当前决策有用”这个标准而不是仅仅“语义相似”。2.1 相关性排序为什么裸的向量 top-k 经常不够裸向量相似度有个常见问题语义接近但对当前任务无用。举个真实案例。我们做某内部客服 agent用户问“上次你说那个问题怎么解决的”检索系统按向量相似度召回了好几段“用户反馈问题、agent 道歉、约定下次处理”的记录但真正的解决方案——一段工具调用返回的错误码解释——因为措辞跟问题不相似排在很后面。按 top-k 截断这段关键信息就被截掉了。这个场景说明检索相关性不能只靠文本相似度。我在向量召回的基础上叠加了三个维度的信号关键词/实体命中用户的问题里出现的具体实体词、产品名、错误码直接命中记忆内容时加权。元数据过滤与加权时间距离、事件类型、业务标签比如“上次解决过程”就优先 tool_call 和 tool_result 类型的事件。动作关联度预判当前最可能的意图把与该意图对应的历史动作片段置顶。这三个信号可以做成轻量级排序模型也可以做成规则加权。我们早期是规则加权后面积累数据后训练了一个粗排模型把规则输出当特征。如果你的数据量没到那个程度先从规则开始完全够用。2.2 上下文压缩让模型吃到高信息密度检索出的原始片段往往很长直接塞进 prompt 既不经济又容易干扰。这里需要一层压缩处理。压缩有两个方向。第一个是截断提取把长片段里的关键句抽出来。比如一段 500 字的工具执行日志里面可能只有两行错误摘要和一行结果码有用。我用一个专门的小模型来做“关键句提取”它接收原始片段输出带优先级标签的摘要句列表。第二个是改写合并把多条相关片段合并成一条连贯的上下文说明。比如用户过去三次提到了同一个需求压缩之后只需要一条“用户长期偏好需要 XX 格式多次强调”而不是三条几乎重复的原话。这个也是用小模型做但注意改写时不能丢失事实细节我一般在提示词里明确“保留数字、专有名词、时间、否定词”。压缩率我控制在 60%-80% 之间不是压得越狠越好。压太狠会丢失可追溯性导致模型出现幻觉时无法归因。我的经验是保留一个“溯源链接”字段不管压缩到什么程度每条压缩片段都挂着原始事件 ID方便排查。2.3 记忆的时效性让过期信息自然衰减这是最容易忽略的一环。记忆不是越全越好也不是永久有效。一个用户三个月前的偏好很可能已经被新偏好覆盖一段历史方案可能已经被新决策推翻。如果不做时效性处理旧的记忆会在检索里反复冒头干扰当前判断。我引入了“记忆衰减机制”。每条记忆在存储时就带一个 lifespan 参数视类型不同设置不同生命周期会话级临时信息几个小时到几天长期偏好可以到几个月但到期后自动降权而不是直接删除。降权后的记忆仍然存在但排序时会被压到很后面除非当前任务确实没有更好记忆可用。另外还要做“反事实标记”当新事件明确推翻旧记忆时比如用户说“之前说的方案作废”后台直接把旧记忆标记为失效而不是等它自然衰减。这个处理非常关键因为 agent 最怕的就是拿着被推翻的旧结论做新决策。3. 从记忆到决策上下文如何驱动工具调用和推理路径记忆只是原材料真正的目标是让 agent 基于正确的上下文做对决策。这一层我把决策拆成了三个步骤先构建实时画像再决定调什么工具最后约束推理路径。3.1 实时画像进入决策前先把上下文聚合成决策要素每次用户请求进来我不会直接拿记忆去拼 prompt而是先做一次“画像聚合”。做法是把相关工作记忆、情景记忆、语义记忆汇总成一个结构化画像它包含三个字段用户当前状态比如“尚未完成身份验证”“正在处理订单 A 的售后”。用户长期偏好的当前生效集合比如“喜欢简洁输出”“需要每一步都确认”。当前任务的上下文约束比如“只能使用 B 工具”“必须等结果返回后再继续”。画像的构建来源于记忆检索但它本身也是一次模型调用用来“归纳”检索出的零散信息。这一步看起来多花了一点 token但收益极大模型在正式处理业务前先有了一个结构化的“小抄”后续无论是走推理还是调工具都基于这份小抄展开一致性明显提升。画像构建的核心技巧是“信息去重和冲突检测”。当画像里出现两条冲突的记忆比如用户偏好 A 又偏好非 A我会把冲突当作显性信息传给模型让它知道这里有历史矛盾并让它在行动前向用户二次确认。这比让模型默认选其中一个要安全得多。3.2 工具调用的场景化路由不是每个请求都走同一套决策链agent 接的工具一多工具选择就成了决策链上最容易出错的环节。我采用的是“场景路由 工具子集”的分层策略先根据画像判断当前属于哪个场景再为该场景加载对应的工具子集和调用规则。举个例子我们的 agent 同时处理信息查询、参数配置、异常处理三类场景。信息查询场景只暴露检索和读取类工具参数配置场景暴露写入类工具但要求二次确认异常处理场景则额外加载日志和回滚工具。这样做直接把工具调用的搜索空间缩小了决策准确率和响应速度都跟着上升。场景判定用什么我试过纯规则和纯模型两条路。纯规则对固定句式有效但变异一多就漏纯模型灵活但偶尔会乱跳场景。最后我采用的是“规则快速过滤 模型兜底判定”的组合命中了强规则比如明确包含某个工具名、错误码直接走场景没命中就交给模型结合画像做一次场景分类。3.3 用记忆约束推理路径给模型一张“路线图”最后一个容易被低估的环节是让记忆参与模型推理的路径约束而不仅仅作为背景信息。具体做法是在系统提示词里给它一个“决策路线图”结构路线图由当前画像推导出来大致长这样用户目标是 X。当前已经掌握的关键事实是A、B、C。需要向用户确认的未知项是D。可选路径按优先级排列方案一如果 A 成立、方案二如果 C 成立。这个路线图不是固定模板而是每次根据画像动态生成的。它的价值在于模型在被生成时才不会漫无目的地自由发挥而是先看路线图再决定下一步输出。这里有个我的核心心得模型遵循结构的能力比遵循“不要乱来”这种口头约束强很多。与其在提示词里反复强调“不要瞎猜”不如给它一个要走的步骤序列。实测下来加入这个动态路线图后agent 在复杂多步任务中的任务完成率提升最明显出错的类型也从“方向性错误”变成了“单步细节错误”后者通常可以通过后续校验直接兜住。4. 全栈流水线的工程化编排、评估与持续演进把存储、检索、决策三层串成一条流水线之后真正的工程挑战才开始。这条流水线涉及的组件多、调用链长任何一层出问题都会导致整体效果下降所以编排和评估必须从一开始就设计好。4.1 数据流分层设计从用户输入到动作执行的完整链路我的流水线按这样的顺序执行输入归一化把用户消息、附件、系统事件统一成标准消息结构。画像聚合按前一章的方法构建实时画像。记忆检索根据画像和当前输入从三层记忆里召回增量上下文。上下文装配把画像、增量记忆、工作记忆按预算拼接成最终 prompt。决策与执行模型先生成路线图再生成动作序列执行工具调用并记录结果。记忆回写把本轮对话、工具结果、用户反馈异步写回存储。这个链路看起来简单但工程上容易忽略两个点。第一是各层之间的“隔离”记忆检索失败不能阻断决策画像聚合超时要有降级路径。我给每一层都设了超时和兜底宁可让某一路上下文为空也不能让整条链路 hang 死。第二是“版本兼容”流水线里的模型、工具和记忆 schema 都在不断迭代。我要求每次 schema 变更都带 migration 脚本同时为不同版本的记忆记录打版本号避免老数据和新逻辑之间出现不兼容。4.2 评估闭环离线沙盘与线上精确 trace评估是我认为这条流水线最容易被忽视但最值得投入的部分。上下文工程的效果评估和模型本身的效果评估不一样模型看生成质量上下文工程看的是“每一层有没有把该传的信息传到位”。我在离线侧搭了一套沙盘环境收集了真实会话数据抽成回放集合流水线改动后先离线回放一遍对比“改动前后检索命中的记忆片段是否更相关”“画像聚合是否更准确”“最终动作是否一致”。不追求纯自动化打分而是让评估脚本标记出“差异引发的结果变化”再由人抽查。线上侧则要求链路里每个环节都输出结构化 trace。特别是记忆检索我只记录命中了哪些记忆、排序权重如何、哪些被压缩丢弃了。一旦线上出现回答质量问题第一件事就是拉 trace 看上下文里到底有没有关键信息、模型是不是因为信息缺失才答错。这里我想强调一个反直觉的结论很多回答质量问题的根因不在模型而在上下文。模型没答好往往是因为它需要的关键事实不在 prompt 里。有了 trace你就能快速区分“是模型推理错了”还是“是上下文没给到位”这决定了你后面应该调模型还是调流水线。方向对了调试效率至少翻倍。4.3 记忆的治理与安全权限、生命周期与多租户隔离流水线跑起来后记忆数据会快速增长而且里面全是用户隐私和业务敏感信息治理问题必须提前想清楚。我做的第一个治理措施是权限分层。不同角色对记忆的读写权限分开只允许 agent 在执行当前业务时读取对应业务线的记忆跨业务线读取直接拒绝。这个用简单的标签隔离就能实现每条记忆存储时打上业务线标签检索时强制过滤标签。第二个措施是存储生命周期管理。记忆不是永久保留我会按策略定期清理超出保留期的原始对话归档到冷存储语义记忆里的长期偏好如果半年没被触发进入“休眠”状态再次触发时会询问用户确认是否仍然有效。这种“让记忆和时间挂钩”的设计既降低了存储成本也避免拿旧信息干扰新决策。第三点是多租户隔离如果你的 agent 服务多个团队或客户记忆的隔离就是硬需求。最稳妥的方案是按租户拆分数据库实例或者至少拆 schema检索时只允许访问当前租户的命名空间。我见过有人为了省成本共用一个索引结果租户 A 的偏好检索到了租户 B 的内容这种问题一旦发生信任成本远高于省下的那点资源费用。隔离这件事不建议省。5. 一次线上事故复盘记忆失效如何伪装成模型问题前面讲的都是方法论最后分享一个真实案例它完整展示了“上下文工程调优”和“模型调优”之间的边界也踩中了整条流水线最隐蔽的一个坑。某天线上反馈一个问题用户多次明确要求“数据报表只需要核心指标不要附带所有原始字段”但 agent 每次生成报表时仍然会带上完整字段。第一反应肯定是模型指令遵循能力不行但我们拉 trace 发现了一个更诡异的现象画像聚合层面这条偏好根本没有被检索出来自然也就没有进入决策上下文。顺着 trace 往下查发现两个原因叠加。第一这条语义记忆的 embedding 在存储时用的还是一个旧嵌入模型版本而线上检索阶段用的是新版本两个版本向量空间不一致结果相似度检索始终命中不了。这就是版本不一致的坑之前的检索链路一直没做“嵌入版本对齐”的校验。第二这条记忆没有元数据标签导致场景路由过滤时被当作“无法归类”而排除掉了。排查出来的修复方案分两步临时方案是给这条偏好补打标签并在场景过滤规则里增加“偏好类记忆必须参与画像聚合”的强制路径长期方案是在记忆写入时记录 embedding 版本检索时如果发现版本不一致就触发重建向量索引。这个案例让我彻底明白了 trace 的价值如果只看最终回答你大概率会去调整系统提示词或者换模型问题可能依然存在因为根因在记忆层完全不在模型层。上下文工程里的每一层都可能成为卡点但每一层也都能被观测和修正这恰恰是它作为一门工程学科最有意思的地方。那天的故障解决后我把这条经验写进了团队的排查手册。现在每当有“agent 表现奇怪”的报告第一步永远是“先看上下文里有什么”而不是“先怀疑模型”。这条工作习惯我觉得比任何具体技术方案都更值得带走。