做个AI应用架构师之后我接手过不少“智能体”项目但真正让我意识到上下文工程重要性的是一次售后场景的翻车现场。那个智能体上线第一周任务完成率只有六成出头用户重复提问、工具调用错乱、回复格式五花八门。一开始我以为是模型能力不够后来逐条扒日志才发现模型用的上下文压根是“一锅乱炖”——全部历史对话直接拼接、工具描述又长又模糊、检索结果不排序就塞进去。从那次之后我把上下文工程当成智能体性能的核心抓手。这项目的本质就是围绕“怎么把有限的上下文窗口用出最大价值”做整套改造适合那些正在做AI智能体应用、被模型表现忽上忽下困扰的架构师和开发者参考。1. 项目概述智能体性能差问题大多出在“上下文”而不是“模型”1.1 智能体不是“更强的聊天机器人”很多人把AI智能体理解成“能多轮对话的机器人”这是最大的误区。智能体的本质是一个能自主完成任务的执行体它要读用户输入结合记忆和知识决定调哪个工具解析工具返回值再决定下一步动作最后组织语言输出结果。这个过程里模型本身的参数规模当然有影响但真正决定任务能不能跑通的核心变量是——每一轮模型到底看到了什么信息。我见过不少团队智能体一跑不动就想着换更大的模型、调更高的温度参数、加更长的超时时间结果问题依旧。你换再大的模型如果喂进去的上下文是残缺的、矛盾的、无优先级的模型也只能在错误信息上“一本正经地胡说八道”。这个阶段瓶颈不在模型在于上下文。1.2 上下文工程的边界与价值什么是上下文工程往小里说是提示词设计往大里说是一整套“在调用模型之前如何筛选、组织、压缩、注入信息”的工程方法。它覆盖的工作包括系统提示词结构设计、工具描述的编写规范、对话历史的窗口管理、长期记忆的检索注入、上下文压缩策略、以及token预算的分配。我特别喜欢的一个类比是模型像个新来的实习生能力底子不差但你给他开会不给议题、给材料不给目录、给工具不给说明书他就只能瞎猜。上下文工程就是给这个实习生准备一套“干净、有序、够用”的工作台。做完这个项目之后我更加确信智能体性能提升的杠杆一半以上在上下文工程里而且它不依赖模型迭代改了立竿见影。2. 核心设计思路把上下文当成一套“分层的输入系统”来管2.1 五层上下文模型我做完这个项目之后把智能体的上下文归纳成五个层级每一层有独立的来源、更新频率和token预算。实际写代码之前先把这五层想清楚后面的一切改造都顺了。核心指令层就是系统提示词里的角色、目标、决策流程、硬性约束。它回答“模型应该怎么想”基本固定个别字段比如当前日期按天更新。事实数据层用户信息、订单状态、知识库检索结果、工具返回的实时数据。它回答“模型现在知道什么”每轮都可能变。工具层可用工具的声明、参数schema、使用场景说明。它回答“模型能做什么”按场景裁剪后注入。对话历史层最近N轮问答、中间推理过程。它回答“我们聊到哪了”用滑动窗口摘要管理。临时推理层模型上一步输出的思考过程、待确认的中间状态。它回答“当前处理到哪一步”通常与工作记忆状态块结合。这种分层最大的价值是出了问题你能快速定位是哪一层的信息质量不行。比如模型频繁遗忘用户需求那是对话历史层被截断了工具调用格式错误那是工具层描述不规范回答没有业务依据那是事实数据层检索没做好。2.2 系统提示词模块化从“一段话”变成“一页说明书”以前写提示词喜欢写成一篇散文角色、目标、注意事项都揉在一起。模型处理长文本时的注意力分配是有偏好的越靠前的内容权重越高越靠近结尾的内容影响输出格式。散文式提示词最大的问题不是信息不够而是重点不突出、约束不可枚举。我在这个项目里把系统提示词完全模块化固定为六块角色定义、任务目标、决策流程、硬性约束、输出格式、兜底策略。每一块用明确的章节标题包起来决策流程用带编号的步骤写。改造之后模型在关键决策点上基本都能按流程走很少再出现遗漏步骤的情况。2.3 工具集的上下文裁剪少而准永远好过多而全智能体接的工具一多问题就来了十几个工具全部塞进提示词token占掉一大截更麻烦的是模型开始“选择困难”。尤其在工具名相似、描述模糊的情况下模型经常挑错工具。我在日志里见过模型用查询订单的工具去查库存就是因为工具描述里都写了“查询信息”四个字。解决办法是双轨并行第一按场景裁剪工具集用户在“售后”场景就只注入售后相关的工具而不是全量注入第二工具描述统一改写成“何时使用输入输出schema注意事项”三段式尤其是“何时使用”要写清楚适用条件和反例。成本很低收益极明显工具调用准确率从72%直接跳到94%。3. 记忆与检索让智能体“记得住”也“分得清”3.1 工作记忆用结构化状态块替代“零散历史”多轮对话里最常见的问题是聊到第五轮模型忘了用户在第三轮确认过的关键约束。最开始我用“把全部历史拼进去”的笨办法上下文一长就截断反而忘得更快。后来改成“工作记忆状态块”每一轮结束前让模型把关键信息抽出来更新到一个固定结构的JSON里。下一轮推理时把这份状态块放在对话历史之前模型的“记忆”就变成稳定的短时记忆而不是依赖残缺的长文本。这个状态块相当于给智能体配了个“便利贴”把最重要的信息钉在最显眼的位置。改造后关键约束的保持率提升非常明显用户不用再反复重复自己说过的话。3.2 长期记忆与RAG检索注入不是“搜到就塞”知识库检索是智能体做专业问答的标配但检索注入做得不好反而帮倒忙。我见过不少实现检索出五条内容不管相不相关全塞进提示词还都标成“事实”。模型把冲突的、低相关的信息当真一本正经给出错误答案。在这个项目里我做了三个关键改动一是检索前先做意图分类区分“订单查询”“政策咨询”“投诉处理”等不同意图再决定检索哪个知识库二是检索结果必须带相关度排序和来源标记注入时按相关度从高到低排列三是在提示词里明确告诉模型“如果检索结果与用户问题无关请忽略并基于通用知识回答”。这三招极大减少了“检索噪音误导模型”的情况。3.3 上下文压缩信息密度优先而不是长度优先上下文窗口再大也是有限的。8K上下文的模型如果系统提示词用掉1.5K、工具描述用掉2K、历史对话用掉3.5K留给真正重要信息的空间就所剩无几了。所以token预算是上下文工程里非常实操的一步。我的分配习惯是系统提示词控制在800-1200token工具描述按场景裁剪后控制在1.5K以内工作记忆状态块控制在500以内最近对话历史保留1500-3000输出预留500-1000。如果发现某段历史很重要但占用太多空间就定期让模型生成中间摘要用摘要替换掉早期的原始对话。这一步叫“时间换空间”做下来单次会话token消耗平均节省了三成左右模型的响应速度和稳定性都上来了。4. 实操复盘一个售后工单智能体的上下文优化全流程4.1 基线表现与失败原因定位这个项目是一个售后工单处理智能体核心职责是理解用户售后诉求核对订单状态检索售后政策判断退款、换货、维修等处理路径最后生成结构化工单并回复用户。初始版本用的是市面上一个主流商用大模型整套实现看起来“骨架完整”但上线后的数据很打脸任务完成率61%工具调用准确率72%平均每个工单要来回对话4轮以上。扒日志之后问题非常清晰一是系统提示词写了一整段“你是一个热情的客服助手”没有决策流程模型经常跳过订单状态核对二是工具描述文档混乱有些工具甚至没写参数必填规则三是对话历史无脑拼接模型经常忘掉用户最开始描述的故障现象四是知识库检索结果直接全量注入相关政策权重相同模型经常引用低优先级的条目。这些全属于上下文工程问题。4.2 五轮关键改造与代码示例第一轮改造系统提示词重构。我把角色定义、决策流程、硬性约束、输出格式拆成四个独立章节决策流程写成了编号步骤并且把“信息不足时一次只追问一个问题”这条写进了约束里。下面是重构后的系统提示词核心片段你是售后工单处理智能体负责根据用户描述完成工单创建与初步处理。 【决策流程】 第1步从用户描述中提取订单号、商品名称、问题类型。 第2步调用query_order工具核对订单状态未经核对禁止生成工单。 第3步根据订单状态和用户问题检索售后政策知识库。 第4步若信息不足调用ask_user追问每次最多追问1个问题。 第5步调用create_ticket生成结构化工单字段必须完整。 第6步输出简洁结论控制在150字内。 【硬性约束】 - 订单状态为“已退款”或“已关闭”时禁止创建退款工单。 - 金额单位统一为元保留两位小数。 - 工具调用连续失败2次以上时转入人工处理并说明原因。 【输出格式】 统一输出JSON字段为action、target_tool、arguments、message。第二轮改造工具描述规范化。原来工具描述像写散文改成“何时使用参数schema注意事项”三段式并在JSON Schema里锁死必填参数。以订单查询工具为例工具名query_order 何时使用用户提到订单号、物流、退款、换货、发票等订单相关问题时调用 反例用户咨询退货政策时不应调用本工具应调用search_policy。 输入{order_id: 字符串订单号} 输出{order_status: 枚举[待付款,待发货,已发货,已完成,已退款,已关闭], amount: 数字, logistics: 字符串或null} 注意order_id不存在时返回error字段禁止编造订单数据。第三轮改造引入工作记忆状态块。每一轮更新结构化JSON模型推理时先读状态块再读历史。状态块核心结构如下{ user_id: U12345, order_id: O20241001, current_intent: 申请退货, confirmed_facts: [订单已签收, 商品有质量问题], pending_steps: [确认退货地址, 生成退货运单], tool_used_this_round: query_order, last_action: verify_order_status }第四轮改造知识库结果分级注入。检索返回十条结果只取相关度最高的前三条并在注入时带相关度标记。同时增加一条提示“若检索结果与用户问题无关请忽略并基于通用知识回答。”检索注入模板以下是售后政策知识库检索结果按相关度降序排列 [1] 来源售后政策V3.1 | 相关度0.92 内容签收7天内支持无理由退货运费由买家承担。 [2] 来源售后政策V3.1 | 相关度0.85 内容商品质量问题退货运费由商家承担。 [3] 来源售后政策V3.1 | 相关度0.63 内容保外维修需收取检测费。 处理原则优先采用高相关度条目若结果与用户问题无关请忽略并基于常识回答。第五轮改造输出后校验与兜底。模型输出JSON后用程序做字段完整性校验缺字段就不提交而是重新生成一次。同时把“连续失败转人工”通过业务代码硬校验不依赖模型自觉。这一步是工程兜底保证上下文再优化模型也总有“打盹”的时候系统不能被单次坏输出拖死。4.3 优化前后的数据对比这一整套上下文工程改造做下来效果是实打实的指标优化前优化后变化幅度任务完成率61%89%28个百分点工具调用准确率72%94%22个百分点平均交互轮次4.2轮2.8轮-1.4轮单次会话token消耗基线降低约31%明显下降用户重复提问率18%6%-12个百分点尤其让我意外的是token消耗反而降下来了。以前把全部历史和全量工具描述塞进去看着“信息全”实际上有大量冗余。裁剪之后模型注意力更集中一次就选对工具、一步就问到关键问题连带多轮重试都少了。5. 常见问题与排查技巧实录5.1 上下文截断导致智能体“失忆”这个场景太常见了。对话轮次一多逻辑代码直接做token截断截掉的偏偏是用户最早描述的核心诉求。结果聊到后面模型反复问“您刚才说的订单号是多少”。排查技巧是在每一轮请求日志里记下上下文的组装明细包括截断了哪些内容、保留了多少轮。一旦发现关键词命中不对先看是不是被截断了。解决思路是“滑动窗口关键信息摘要”窗口只留最近三轮更早的信息抽成状态块放在前面这样既控制token又保住了核心信息。5.2 检索结果噪音干扰判断知识库命中不相关的内容时模型很可能被带偏。比如用户问退货政策检索结果里第一条是“保外维修需收费”模型就开始讲维修费用。这个问题的核心不是RAG检索算法而是注入策略。我建议至少做三件事限制注入条数最多三条、附带相关度排序、在提示词里给“忽略权”。值得强调的是“忽略权”这句提示词效果出乎意料好它让模型敢于怀疑检索结果而不是盲从。5.3 工具参数幻觉模型“编”参数模型调用工具时如果参数缺失或不在枚举值内程序端直接报错。你会发现模型经常编造订单号、编造金额甚至把“已发货”写成“已退款”。这不是模型“坏”而是上下文里没给出严格边界。解决靠两堵墙一是在JSON Schema里把字段类型、枚举值、必填项全部锁死程序端同样做校验不合法就直接拒绝并返回错误原因二是在工具描述里反复强调“必须从给定枚举值中选择禁止自创”。两堵墙一堵是上下文层面的引导另一堵是代码层面的拦截缺一不可。5.4 “反思死循环”问题很多团队喜欢在提示词里加“自我反思”之类的环节结果模型在反思里转圈反复修改自己的答案问题没解决token却耗掉一大截。我后来限制反思次数最多两次并且规定反思只能用于校验“工单字段是否齐全、金额单位是否正确”这类可枚举的问题不能用来重新生成整段回答。反思的目标必须是可验证的具体事项而不是一个模糊的“想一想哪里不对”。6. 个人实操体会上下文工程不是某个单一技巧而是一套系统性的“信息治理”方法。做这个项目最大的体会是智能体的每次输出都是对输入上下文的直接映射。模型能力决定的是“天花板”上下文工程决定的是“当前能摸到多高”。想提升智能体性能别总想着换更大的模型先把每轮调用喂给模型的信息变干净、变有序、变精炼很多“玄学”问题会直接消失。后来我每新接一个智能体项目第一周基本不做模型调参只做上下文结构梳理和失败日志分析效果比盲目调参要稳得多。
