从一次客服机器人改版说起我把一个看起来什么都懂的智能体从准确率72%调到了91%单次调用成本还降了一半以上。这个过程中最深刻的体会是——模型本身没换prompt也没有玄学式的反复修改真正的杠杆在上下文怎么组织。今天这篇文章我想围绕上下文工程Context Engineering这个主题把我作为AI应用架构师在一线项目中用到的思路、方法和踩过的坑尽可能完整地复盘一遍。这件事适合谁看凡是正在做AI智能体、RAG应用、或者被大模型自己会处理把它丢给它就行这句话坑过的人应该都能从中找到共鸣。我尽量少讲虚的概念多讲可复用的判断标准和操作细节。1. 为什么聪明模型会在小事上翻车从一次交付事故说起先讲一次真实事故。某内部客服系统需要做一个质检智能体职责是自动阅读客服和用户的对话记录输出三件事会话是否包含情绪冲突、坐席是否有承诺不一致、是否存在敏感事件漏报。初版实现非常简单。开发同学把所有对话历史、企业知识库中与客服相关的几十条制度文档、系统原始字段一股脑塞进system prompt然后把整段长对话作为单次输入发给模型。单看对话样本模型推理思路是对的可在抽样评测里问题全暴露了标签打偏、把旧政策当新政策、关键事件被淹没在冗长文本里。这种事故我已经见得太多了。它说明一个事实大模型确实聪明但它的注意力资源不是无限的。Transformer在长上下文上的表现并不像展示出来的那么均匀中间部分很容易被遗忘位置靠后的内容权重容易偏高而且当无关信息占比过大时模型会把注意力浪费在干扰项上。你给它一车杂物它就只能从杂物里翻找。Prompt工程解决的是把话说清楚上下文工程解决的是把信息摆对位置、匹配好需求。两者的区别可以用下表概括维度Prompt工程上下文工程关注点指令措辞、角色设定、输出格式信息选择、组织、时序、位置、记忆结构核心问题怎么说模型才听得懂给什么模型才用得对典型手段措辞优化、few-shot示例上下文分区、检索重排、动态裁剪、记忆压缩优化目标单次输出的稳定性多轮任务下的长期表现与成本控制能否独立生效依赖输入信息质量可以主动改造输入信息来源这个表格不是我总结出来凑字数的。在实际项目里我发现很多团队把80%的精力花在调prompt却忽略了真正让系统质变的是上下文结构。prompt再精准只要上下文里塞入过时政策、无关知识、冗余历史模型依然会被带偏。反过来上下文组织得清爽一句朴素的任务指令就能发挥出80分以上的水平。2. 上下文工程的核心棋盘可控变量的拆解与取舍上下文工程这个词听起来很学术拆开看其实就四组变量信息分区、检索策略、记忆结构、注入时序。我一个个展开说这四件事决定了智能体的智商上限。2.1 上下文窗口不是垃圾桶信息分区与注意力预算第一件事是把上下文窗口当成一个有预算限制的舞台而不是无限大的垃圾箱。模型处理上下文时每个token都会消耗计算量更重要的是注意力会被分散。我把上下文按功能切成六个区任务指令区当前任务定义、输出JSON结构、判断标准角色约束区回答风格、禁用语、合规边界知识参考区从知识库检索到的内容带来源标注对话历史区最近轮次原文以及更早内容的摘要工具状态区调用了哪些工具、返回了什么结果业务上下文区当前会话绑定的用户信息、订单信息等为什么分区有效因为模型对哪里是指令、哪里是参考这件事天然敏感。混在一起它还要自己区分分开了它就能直接进入执行模式。我在改造质检Agent时第一个改动就是把职责定义和操作细则从一大段散文改成结构化区块几乎没有任何prompt技巧的加成错误率立刻降了6个百分点。{ context_blocks: { task: 检测本会话中的情绪冲突、承诺不一致、敏感事件漏报输出JSON。, rules: [ 情绪冲突指客服出现贬低、嘲讽、不耐烦等行为, 承诺不一致指坐席前后给出互相矛盾的处理方案, 敏感事件指投诉升级、法律风险、安全事故类关键词 ], knowledge_sources: [ SOP-042-客诉处理流程, SOP-071-赔偿权限说明 ], recent_turns: 6, history_summary: 前面20轮已完成身份核验与问题描述用户情绪平稳。 } }这个JSON仅仅是一个示例但它代表了一个原则让模型第一眼就知道自己该干什么、能看什么资料、按什么标准干活。信息分区的本质就是给模型的注意力安装路标。2.2 检索不是越多越好相关性与冗余的度量第二个变量是知识检索。RAG检索增强生成几乎是智能体的标配但绝大多数项目的检索策略是召回Top K塞进去。K3是3K10也是3K20还是3问题是堆数量而不堆质量。我在实践中给团队定了一条规则先粗召回再重排最后裁剪。粗召回阶段可以用向量相似度取Top 50然后用一个更强的方式做重排——不一定用模型直接用规则加交叉编码器就够用。重排的评分不是只看内容相似度还要看时效性、来源可信度、与当前用户意图的匹配度。比如客服场景里一个文档说退款必须在7天内完成另一个文档说特殊商品可延长至30天如果用户问的恰好是特殊商品向量相似度完全可能把第一个文档排到前面。这时如果没有时效性和业务规则的加权模型就会给出错误答案。裁剪则是把重排后的文档里真正有用的话提取出来而不是整篇塞入。我见过一个知识库文档明明核心内容只有三句话但全文有2000字最终模型要在这2000字里找三句话效果可想而知。冗余的衡量标准很简单删除某段内容后输出质量是否下降如果没有下降那它就不该出现在上下文里。2.3 动态裁剪与压缩让长任务的上下文维持新鲜感第三个变量是压缩。多轮对话场景里对话历史会无限膨胀。很多团队的方案是给模型塞最近20轮或者塞最近5000字这非常粗糙。因为对话的信息密度不均身份核验阶段的叫什么名字、手机号是多少可能5轮就看完了而后面关于退款的你来我往可能每一轮都包含新的决策信息。我在项目中采用双轨记忆策略短期轨道保留最近N轮原文N根据业务复杂度取4~8轮。为什么是这个数字因为大多数客服会话中最近4到6轮覆盖了用户最核心的最新诉求再往前就是重复陈述。长期轨道对N轮以前的对话做结构化摘要摘要按实体、诉求、承诺、情绪四个维度组织。每次摘要更新时不是从头生成而是在旧摘要基础上做增量更新控制token消耗。这个双轨设计还有一个隐藏好处摘要本身就是智能体的状态表示。当对话被压缩后模型不必重新理解前因后果直接基于摘要就能做出判断。这也解释了为什么同样的模型换了一种上下文组织方式后多轮任务成功率会显著上升。2.4 注入时序什么时候给信息比给什么信息更关键最后一个变量是时序。我犯过的一个典型错误是在一开始就把所有知识库内容注入结果模型在推理过程中已经忘记了早期的知识。后来我改成按需注入会话启动阶段只注入角色约束和任务定义不注入知识接收到用户消息后先做意图识别判断是否需要知识检索需要工具调用时才注入工具描述和工具返回结果做出决策时注入与当前决策点相关的知识片段这个逻辑很像人类的阅读习惯先看标题和目录再翻到具体章节而不是把整本百科全书直接背下来。上下文的注入时机越贴近决策点模型的推理越精准。3. 一个客服质检智能体的改造全过程问题定位、方案设计与效果验证理论说多了容易飘我拿完整案例把改造过程走一遍。这个项目就叫客服质检智能体目标是检测客服会话中的情绪冲突、承诺不一致和敏感事件漏报。改造前后对比非常明显我把每一个步骤和思考过程都记录下来。3.1 初始方案的三个结构性缺陷先看初始方案。系统把以下内容全部塞进一个prompt系统的全部质检规则约20条细则完整对话记录有时长达100轮知识库里所有跟客服相关的制度文档每次召回Top 10每篇全文客服工单的结构化字段JSON原样拼接当我拿到这个prompt时第一感觉就是模型不是被调教坏的是被喂饱撑坏的。我总结出三个结构性缺陷缺陷一指令密度过低。20条规则的信息量如果按token算只占整个prompt的3%左右。模型被几百个噪声token包围真正有效的指令弱得像背景音。缺陷二知识库召回无重排。制度文档存在大量相似条款向量召回返回的Top 10里有6条在讲同一件事剩下4条信息冲突。缺陷三完整对话历史无压缩。100轮对话里有60轮是嗯好的稍等这类无信息量回复却依然占据上下文还会把早期承诺埋进遗忘区。这三个缺陷叠加起来直接后果就是智能体对情绪冲突的召回率只有62%对承诺不一致的准确率仅58%。3.2 分步改造每一处改动都对着明确的病灶第一步重构上下文分区。我把system prompt彻底打散拆成任务指令、判断标准、输出模式三块。判断标准不再用如果出现...则...的散文形式改成带严重等级的枚举列表。这一步做完准确率提升到75%左右。第二步改造知识检索链路。我给知识文档增加了元数据标注适用场景、有效版本、优先级。检索后增加一个重排层用规则加交叉编码器对候选文档打分重点惩罚与当前用户问题场景不匹配的文档。这一步把承诺一致性检测的准确率从58%拉到了81%。第三步引入对话记忆双轨机制。我设置最近的6轮对话保留原文更早的对话每3轮做一次结构化摘要。摘要字段包括用户诉求、已给出承诺、情绪状态、待办事项。这一步最大变化是漏报率下降因为模型能记住更早出现的敏感词了。第四步压缩知识条目。对重排后的文档做信息提取只保留与当前检测任务相关的条款并把长段落切成带编号的小条款。每次注入不超过6条每条不超过约120字。这一步是压死稻草的最后一根准确率最终跨过90%大关。3.3 效果对比与成本核算改造前后的核心指标对比如下指标改造前改造后变化三级任务平均准确率72%91%19个百分点敏感事件漏报率14%3%-11个百分点单次调用输入token约8000约2200-72.5%单次调用成本0.08元0.03元-62.5%平均响应延迟2.8秒1.4秒-50%我特意把成本数据放出来是因为很多团队误以为上下文工程是增加投入实际上恰恰相反做好上下文管理通常意味着用更少的token获得更好的效果。输入token减少72%不只是省钱更是延迟的改善。用户可不会关心你用了多少token但1.4秒和2.8秒的差别用户是能直接感知到的。这里我也想强调一句整个改造过程中我没有换过任何模型。模型还是那个模型变的只有上下文工程策略。这也说明一个问题——当模型性能已经足够时应用架构师的价值不在于召唤更贵的模型而在于让已有模型工作在它最擅长的方式下。4. 把上下文工程落地成工程体系生产、消费与观测闭环单次改造成功不等于体系成熟。到了第二个项目、第三个项目我发现自己重复做了很多组装上下文的体力活清洗知识、写重排规则、设计摘要格式、观察线上效果。后来我逼着自己把上下文工程当成一个正式的技术模块来建设分三条线来推进。4.1 生产侧知识切片、元数据标注与时效管理先讲知识侧。很多团队把RAG失败归咎于向量模型不够好但我见过的大量问题其实是源头数据没治理。上下文工程的前提是知识库里的每条信息都足够干净、能够独立回答一个问题。我们在实践中给每条知识切片都加了元数据valid_from/valid_to有效时间范围解决政策更替带来的新旧冲突applicable_scenario适用场景用于检索后的场景匹配conflict_group冲突组标记哪些条目彼此可能矛盾交给重排层特殊处理source_priority来源优先级比如内部SOP高于互联网转载内容这套元数据听起来增加工作量但长期回报非常可观。重排阶段可以直接用元数据硬过滤掉过期文档不必把每一篇都交给模型去判断。时效管理尤其重要——政策类知识经常更新如果不做外部化过滤模型只能靠prompt里的请使用最新政策来提醒自己而这种提醒在长上下文里很快就会失效。4.2 消费侧组装路由、按需检索与决策点触达消费侧的核心是什么时候组装什么上下文。我设计过一个简化版的决策逻辑if is_task_opening: context build_task_block() build_role_block() elif requires_knowledge: retrieved search_and_rank(query, top_n50) filtered apply_metadata_filter(retrieved) context build_knowledge_block(filtered[:6]) elif requires_tool_call: context build_tool_block(tool_schema, tool_result) elif is_history_turn: context build_recent_turns(last_n6)这段伪代码体现的核心原则是上下文按需组装不搞一次性全量注入。尤其要避免的是在工具调用还没发生前就把工具结果塞进上下文或者在用户还没有表达新意图之前就把一批可能无关的知识注入进去。还有一个容易被忽略的触点决策点前置。质检智能体在判断是否有承诺不一致时需要的上下文是早前承诺摘要当前对话片段相关赔偿规则而不是完整的全部聊天记录。所以我给智能体设计了独立的小型决策上下文每个决策点各自组装自己需要的上下文而不是所有判断共用同一个大窗口。这个设计让每个子判断的干扰都少了一大截。4.3 观测侧让每一次调用的上下文使用情况变得可审计上下文工程如果不做可观测性基本就是盲人在房间里找东西。我在项目中积累了三个核心观测指标如果你要建智能体观测体系我建议从这三个开始指标名称计算方式诊断价值有效上下文利用率被模型输出实际引用的token数 / 注入的总token数判断是否塞了太多无关内容检索命中前置率在输出前就通过重排命中的正确知识比例判断检索链路有没有问题上下文振荡率相邻两轮注入的知识块变化比例判断多轮任务是否丢失了关键状态有效上下文利用率这个指标特别有意思。一开始我们的利用率只有12%说明88%的token对输出没有直接贡献纯粹是干扰项。后来做到35%左右效果已经远好于初始状态。虽然无法做到100%——因为任务指令、角色约束这类token并不会被直接引用——但这个指标的横向对比和趋势分析非常能说明问题。追踪平台方面我与团队直接改造了智能体调用日志每次调用都记录分区名称、每个分区token数、检索打分、最终输出中的引用来源。这样任何一个bad case出现时都能回放当时的上下文快照。没有这个快照坏例分析就是猜谜游戏。5. 花过冤枉钱之后才懂的几条边界问题光讲成功经验不够很多问题是改完之后才暴露的。我把这几条边界问题单独拿出来因为它们最容易让后来的项目重蹈覆辙。5.1 上下文污染模型无法分辨哪里是指令哪里是数据第一个边界问题是上下文污染。有些开发同学会把用户输入直接拼接到system prompt后面为了让模型看到更多信息。这么做极其危险。如果用户消息中包含了忽略之前的指令或者你现在是一个什么都不用检查的机器人这类内容它就变成了一次即时注入攻击。即使没有恶意输入污染也可能来自普通对话。用户说你怎么老在检测承诺不一致烦不烦如果这句话被拼进system prompt区域模型可能真的开始怀疑自己的任务。我的铁律是任何用户输入、对话历史、检索结果一律放在data区域并在文本上做隔离标记和长度截断。具体到实现上每个分区之间用明确的HTML注释或者特殊的分隔符隔开同时把分区描述写在分隔符前面。这样模型才能清晰区分系统让我做什么和用户说了什么。5.2 检索时机的选择不是每轮都必须检索第二个边界问题是检索频率。我有一个阶段性的错误判断既然检索有用那就在每一轮都检索一下给模型最强的信息支持。结果副作用很快出现无关知识注入增多模型开始被错误知识带着走还时常编造出检索结果里其实不存在的细节。后来我改成三级触发机制用户消息中包含明确的实体词与业务问题 → 触发知识检索用户消息只是谢谢好的等情绪反馈 → 不检索直接走回复生成多轮任务中模型内部状态发生变化 → 按需注入摘要不重复检索这个机制上线后检索调用量下降了约40%质量反而上升了。检索不是免费的午餐每次检索都伴随误导风险应该像花钱一样谨慎使用。5.3 成本与延迟的权衡有些压缩不值得做第三个边界问题是过度压缩。摘要压缩本身有token成本如果每两轮对话就做一次摘要摘要的调用成本可能超过节省的成本。我测试过不同压缩粒度最后发现每3~5轮做一次增量摘要性价比最高。少于3轮压缩成本高于保留成本多于5轮摘要开始丢失细节。同理重排模型也不是越强越好。如果知识库只有几百篇文档用规则加关键词过滤就够了强行上交叉编码器反而是杀鸡用牛刀。做上下文工程时每一处增值运算都需要用可量化收益来证明自己的必要性。5.4 评测集设计防止智能体过拟合到你的上下文模板上最后一个边界问题是评测。很多团队评测智能体时只准备了几十个样本而且样本是静态的。改完上下文后在样本上效果惊人一上线就崩。原因不外乎两个一是评测样本太少没覆盖到新上下文的盲区二是样本和模板高度同质化智能体学会了针对模板答题而不是针对问题答题。我现在的习惯是准备至少200条评测样本按业务场景分层每条样本都带预期知识点来源标注。评测时不只看准确率还要看每一条错误的错误类型是检索漏召回、重排误置顶、摘要丢失关键承诺还是指令被忽略。没有这样的分层评测你就永远不知道下一次该优化哪个环节——是补知识还是修路由还是调摘要策略。最后再分享一点我的个人体会做了这几个项目之后我对智能体性能优化这件事有了一层新的认识与其说我们在调模型不如说我们在给模型的注意力装栅栏。大模型的推理能力是固定的但注意力往哪里看完全由上下文工程决定。你给它的上下文越干净、越贴切、越结构化它的推理能力就越能百分百用在刀刃上。如果读者只想记住一条我会说下一次遇到智能体表现不稳定时不要急着换更强的大模型也不要反复试prompt话术先把一次调用的上下文完整打印出来问自己三句话——每一段信息为什么在这里它离决策点有多远有没有一段内容是可以删掉而不影响输出的把这三句话逼出来性能瓶颈大概率会自动现出原形。上下文工程不是某种特定工具它更像一套把模型能力变成系统稳定性的施工方法论。这条路我也还在继续探索欢迎有类似实战经历的朋友多交流尤其是那些在特定业务场景里把上下文工程做到极致的案例——这种东西光靠理论是真的学不来的。
从一次客服机器人改版说起我把一个看起来什么都懂的智能体从准确率72%调到了91%单次调用成本还降了一半以上。这个过程中最深刻的体会是——模型本身没换prompt也没有玄学式的反复修改真正的杠杆在上下文怎么组织。今天这篇文章我想围绕上下文工程Context Engineering这个主题把我作为AI应用架构师在一线项目中用到的思路、方法和踩过的坑尽可能完整地复盘一遍。这件事适合谁看凡是正在做AI智能体、RAG应用、或者被大模型自己会处理把它丢给它就行这句话坑过的人应该都能从中找到共鸣。我尽量少讲虚的概念多讲可复用的判断标准和操作细节。1. 为什么聪明模型会在小事上翻车从一次交付事故说起先讲一次真实事故。某内部客服系统需要做一个质检智能体职责是自动阅读客服和用户的对话记录输出三件事会话是否包含情绪冲突、坐席是否有承诺不一致、是否存在敏感事件漏报。初版实现非常简单。开发同学把所有对话历史、企业知识库中与客服相关的几十条制度文档、系统原始字段一股脑塞进system prompt然后把整段长对话作为单次输入发给模型。单看对话样本模型推理思路是对的可在抽样评测里问题全暴露了标签打偏、把旧政策当新政策、关键事件被淹没在冗长文本里。这种事故我已经见得太多了。它说明一个事实大模型确实聪明但它的注意力资源不是无限的。Transformer在长上下文上的表现并不像展示出来的那么均匀中间部分很容易被遗忘位置靠后的内容权重容易偏高而且当无关信息占比过大时模型会把注意力浪费在干扰项上。你给它一车杂物它就只能从杂物里翻找。Prompt工程解决的是把话说清楚上下文工程解决的是把信息摆对位置、匹配好需求。两者的区别可以用下表概括维度Prompt工程上下文工程关注点指令措辞、角色设定、输出格式信息选择、组织、时序、位置、记忆结构核心问题怎么说模型才听得懂给什么模型才用得对典型手段措辞优化、few-shot示例上下文分区、检索重排、动态裁剪、记忆压缩优化目标单次输出的稳定性多轮任务下的长期表现与成本控制能否独立生效依赖输入信息质量可以主动改造输入信息来源这个表格不是我总结出来凑字数的。在实际项目里我发现很多团队把80%的精力花在调prompt却忽略了真正让系统质变的是上下文结构。prompt再精准只要上下文里塞入过时政策、无关知识、冗余历史模型依然会被带偏。反过来上下文组织得清爽一句朴素的任务指令就能发挥出80分以上的水平。2. 上下文工程的核心棋盘可控变量的拆解与取舍上下文工程这个词听起来很学术拆开看其实就四组变量信息分区、检索策略、记忆结构、注入时序。我一个个展开说这四件事决定了智能体的智商上限。2.1 上下文窗口不是垃圾桶信息分区与注意力预算第一件事是把上下文窗口当成一个有预算限制的舞台而不是无限大的垃圾箱。模型处理上下文时每个token都会消耗计算量更重要的是注意力会被分散。我把上下文按功能切成六个区任务指令区当前任务定义、输出JSON结构、判断标准角色约束区回答风格、禁用语、合规边界知识参考区从知识库检索到的内容带来源标注对话历史区最近轮次原文以及更早内容的摘要工具状态区调用了哪些工具、返回了什么结果业务上下文区当前会话绑定的用户信息、订单信息等为什么分区有效因为模型对哪里是指令、哪里是参考这件事天然敏感。混在一起它还要自己区分分开了它就能直接进入执行模式。我在改造质检Agent时第一个改动就是把职责定义和操作细则从一大段散文改成结构化区块几乎没有任何prompt技巧的加成错误率立刻降了6个百分点。{ context_blocks: { task: 检测本会话中的情绪冲突、承诺不一致、敏感事件漏报输出JSON。, rules: [ 情绪冲突指客服出现贬低、嘲讽、不耐烦等行为, 承诺不一致指坐席前后给出互相矛盾的处理方案, 敏感事件指投诉升级、法律风险、安全事故类关键词 ], knowledge_sources: [ SOP-042-客诉处理流程, SOP-071-赔偿权限说明 ], recent_turns: 6, history_summary: 前面20轮已完成身份核验与问题描述用户情绪平稳。 } }这个JSON仅仅是一个示例但它代表了一个原则让模型第一眼就知道自己该干什么、能看什么资料、按什么标准干活。信息分区的本质就是给模型的注意力安装路标。2.2 检索不是越多越好相关性与冗余的度量第二个变量是知识检索。RAG检索增强生成几乎是智能体的标配但绝大多数项目的检索策略是召回Top K塞进去。K3是3K10也是3K20还是3问题是堆数量而不堆质量。我在实践中给团队定了一条规则先粗召回再重排最后裁剪。粗召回阶段可以用向量相似度取Top 50然后用一个更强的方式做重排——不一定用模型直接用规则加交叉编码器就够用。重排的评分不是只看内容相似度还要看时效性、来源可信度、与当前用户意图的匹配度。比如客服场景里一个文档说退款必须在7天内完成另一个文档说特殊商品可延长至30天如果用户问的恰好是特殊商品向量相似度完全可能把第一个文档排到前面。这时如果没有时效性和业务规则的加权模型就会给出错误答案。裁剪则是把重排后的文档里真正有用的话提取出来而不是整篇塞入。我见过一个知识库文档明明核心内容只有三句话但全文有2000字最终模型要在这2000字里找三句话效果可想而知。冗余的衡量标准很简单删除某段内容后输出质量是否下降如果没有下降那它就不该出现在上下文里。2.3 动态裁剪与压缩让长任务的上下文维持新鲜感第三个变量是压缩。多轮对话场景里对话历史会无限膨胀。很多团队的方案是给模型塞最近20轮或者塞最近5000字这非常粗糙。因为对话的信息密度不均身份核验阶段的叫什么名字、手机号是多少可能5轮就看完了而后面关于退款的你来我往可能每一轮都包含新的决策信息。我在项目中采用双轨记忆策略短期轨道保留最近N轮原文N根据业务复杂度取4~8轮。为什么是这个数字因为大多数客服会话中最近4到6轮覆盖了用户最核心的最新诉求再往前就是重复陈述。长期轨道对N轮以前的对话做结构化摘要摘要按实体、诉求、承诺、情绪四个维度组织。每次摘要更新时不是从头生成而是在旧摘要基础上做增量更新控制token消耗。这个双轨设计还有一个隐藏好处摘要本身就是智能体的状态表示。当对话被压缩后模型不必重新理解前因后果直接基于摘要就能做出判断。这也解释了为什么同样的模型换了一种上下文组织方式后多轮任务成功率会显著上升。2.4 注入时序什么时候给信息比给什么信息更关键最后一个变量是时序。我犯过的一个典型错误是在一开始就把所有知识库内容注入结果模型在推理过程中已经忘记了早期的知识。后来我改成按需注入会话启动阶段只注入角色约束和任务定义不注入知识接收到用户消息后先做意图识别判断是否需要知识检索需要工具调用时才注入工具描述和工具返回结果做出决策时注入与当前决策点相关的知识片段这个逻辑很像人类的阅读习惯先看标题和目录再翻到具体章节而不是把整本百科全书直接背下来。上下文的注入时机越贴近决策点模型的推理越精准。3. 一个客服质检智能体的改造全过程问题定位、方案设计与效果验证理论说多了容易飘我拿完整案例把改造过程走一遍。这个项目就叫客服质检智能体目标是检测客服会话中的情绪冲突、承诺不一致和敏感事件漏报。改造前后对比非常明显我把每一个步骤和思考过程都记录下来。3.1 初始方案的三个结构性缺陷先看初始方案。系统把以下内容全部塞进一个prompt系统的全部质检规则约20条细则完整对话记录有时长达100轮知识库里所有跟客服相关的制度文档每次召回Top 10每篇全文客服工单的结构化字段JSON原样拼接当我拿到这个prompt时第一感觉就是模型不是被调教坏的是被喂饱撑坏的。我总结出三个结构性缺陷缺陷一指令密度过低。20条规则的信息量如果按token算只占整个prompt的3%左右。模型被几百个噪声token包围真正有效的指令弱得像背景音。缺陷二知识库召回无重排。制度文档存在大量相似条款向量召回返回的Top 10里有6条在讲同一件事剩下4条信息冲突。缺陷三完整对话历史无压缩。100轮对话里有60轮是嗯好的稍等这类无信息量回复却依然占据上下文还会把早期承诺埋进遗忘区。这三个缺陷叠加起来直接后果就是智能体对情绪冲突的召回率只有62%对承诺不一致的准确率仅58%。3.2 分步改造每一处改动都对着明确的病灶第一步重构上下文分区。我把system prompt彻底打散拆成任务指令、判断标准、输出模式三块。判断标准不再用如果出现...则...的散文形式改成带严重等级的枚举列表。这一步做完准确率提升到75%左右。第二步改造知识检索链路。我给知识文档增加了元数据标注适用场景、有效版本、优先级。检索后增加一个重排层用规则加交叉编码器对候选文档打分重点惩罚与当前用户问题场景不匹配的文档。这一步把承诺一致性检测的准确率从58%拉到了81%。第三步引入对话记忆双轨机制。我设置最近的6轮对话保留原文更早的对话每3轮做一次结构化摘要。摘要字段包括用户诉求、已给出承诺、情绪状态、待办事项。这一步最大变化是漏报率下降因为模型能记住更早出现的敏感词了。第四步压缩知识条目。对重排后的文档做信息提取只保留与当前检测任务相关的条款并把长段落切成带编号的小条款。每次注入不超过6条每条不超过约120字。这一步是压死稻草的最后一根准确率最终跨过90%大关。3.3 效果对比与成本核算改造前后的核心指标对比如下指标改造前改造后变化三级任务平均准确率72%91%19个百分点敏感事件漏报率14%3%-11个百分点单次调用输入token约8000约2200-72.5%单次调用成本0.08元0.03元-62.5%平均响应延迟2.8秒1.4秒-50%我特意把成本数据放出来是因为很多团队误以为上下文工程是增加投入实际上恰恰相反做好上下文管理通常意味着用更少的token获得更好的效果。输入token减少72%不只是省钱更是延迟的改善。用户可不会关心你用了多少token但1.4秒和2.8秒的差别用户是能直接感知到的。这里我也想强调一句整个改造过程中我没有换过任何模型。模型还是那个模型变的只有上下文工程策略。这也说明一个问题——当模型性能已经足够时应用架构师的价值不在于召唤更贵的模型而在于让已有模型工作在它最擅长的方式下。4. 把上下文工程落地成工程体系生产、消费与观测闭环单次改造成功不等于体系成熟。到了第二个项目、第三个项目我发现自己重复做了很多组装上下文的体力活清洗知识、写重排规则、设计摘要格式、观察线上效果。后来我逼着自己把上下文工程当成一个正式的技术模块来建设分三条线来推进。4.1 生产侧知识切片、元数据标注与时效管理先讲知识侧。很多团队把RAG失败归咎于向量模型不够好但我见过的大量问题其实是源头数据没治理。上下文工程的前提是知识库里的每条信息都足够干净、能够独立回答一个问题。我们在实践中给每条知识切片都加了元数据valid_from/valid_to有效时间范围解决政策更替带来的新旧冲突applicable_scenario适用场景用于检索后的场景匹配conflict_group冲突组标记哪些条目彼此可能矛盾交给重排层特殊处理source_priority来源优先级比如内部SOP高于互联网转载内容这套元数据听起来增加工作量但长期回报非常可观。重排阶段可以直接用元数据硬过滤掉过期文档不必把每一篇都交给模型去判断。时效管理尤其重要——政策类知识经常更新如果不做外部化过滤模型只能靠prompt里的请使用最新政策来提醒自己而这种提醒在长上下文里很快就会失效。4.2 消费侧组装路由、按需检索与决策点触达消费侧的核心是什么时候组装什么上下文。我设计过一个简化版的决策逻辑if is_task_opening: context build_task_block() build_role_block() elif requires_knowledge: retrieved search_and_rank(query, top_n50) filtered apply_metadata_filter(retrieved) context build_knowledge_block(filtered[:6]) elif requires_tool_call: context build_tool_block(tool_schema, tool_result) elif is_history_turn: context build_recent_turns(last_n6)这段伪代码体现的核心原则是上下文按需组装不搞一次性全量注入。尤其要避免的是在工具调用还没发生前就把工具结果塞进上下文或者在用户还没有表达新意图之前就把一批可能无关的知识注入进去。还有一个容易被忽略的触点决策点前置。质检智能体在判断是否有承诺不一致时需要的上下文是早前承诺摘要当前对话片段相关赔偿规则而不是完整的全部聊天记录。所以我给智能体设计了独立的小型决策上下文每个决策点各自组装自己需要的上下文而不是所有判断共用同一个大窗口。这个设计让每个子判断的干扰都少了一大截。4.3 观测侧让每一次调用的上下文使用情况变得可审计上下文工程如果不做可观测性基本就是盲人在房间里找东西。我在项目中积累了三个核心观测指标如果你要建智能体观测体系我建议从这三个开始指标名称计算方式诊断价值有效上下文利用率被模型输出实际引用的token数 / 注入的总token数判断是否塞了太多无关内容检索命中前置率在输出前就通过重排命中的正确知识比例判断检索链路有没有问题上下文振荡率相邻两轮注入的知识块变化比例判断多轮任务是否丢失了关键状态有效上下文利用率这个指标特别有意思。一开始我们的利用率只有12%说明88%的token对输出没有直接贡献纯粹是干扰项。后来做到35%左右效果已经远好于初始状态。虽然无法做到100%——因为任务指令、角色约束这类token并不会被直接引用——但这个指标的横向对比和趋势分析非常能说明问题。追踪平台方面我与团队直接改造了智能体调用日志每次调用都记录分区名称、每个分区token数、检索打分、最终输出中的引用来源。这样任何一个bad case出现时都能回放当时的上下文快照。没有这个快照坏例分析就是猜谜游戏。5. 花过冤枉钱之后才懂的几条边界问题光讲成功经验不够很多问题是改完之后才暴露的。我把这几条边界问题单独拿出来因为它们最容易让后来的项目重蹈覆辙。5.1 上下文污染模型无法分辨哪里是指令哪里是数据第一个边界问题是上下文污染。有些开发同学会把用户输入直接拼接到system prompt后面为了让模型看到更多信息。这么做极其危险。如果用户消息中包含了忽略之前的指令或者你现在是一个什么都不用检查的机器人这类内容它就变成了一次即时注入攻击。即使没有恶意输入污染也可能来自普通对话。用户说你怎么老在检测承诺不一致烦不烦如果这句话被拼进system prompt区域模型可能真的开始怀疑自己的任务。我的铁律是任何用户输入、对话历史、检索结果一律放在data区域并在文本上做隔离标记和长度截断。具体到实现上每个分区之间用明确的HTML注释或者特殊的分隔符隔开同时把分区描述写在分隔符前面。这样模型才能清晰区分系统让我做什么和用户说了什么。5.2 检索时机的选择不是每轮都必须检索第二个边界问题是检索频率。我有一个阶段性的错误判断既然检索有用那就在每一轮都检索一下给模型最强的信息支持。结果副作用很快出现无关知识注入增多模型开始被错误知识带着走还时常编造出检索结果里其实不存在的细节。后来我改成三级触发机制用户消息中包含明确的实体词与业务问题 → 触发知识检索用户消息只是谢谢好的等情绪反馈 → 不检索直接走回复生成多轮任务中模型内部状态发生变化 → 按需注入摘要不重复检索这个机制上线后检索调用量下降了约40%质量反而上升了。检索不是免费的午餐每次检索都伴随误导风险应该像花钱一样谨慎使用。5.3 成本与延迟的权衡有些压缩不值得做第三个边界问题是过度压缩。摘要压缩本身有token成本如果每两轮对话就做一次摘要摘要的调用成本可能超过节省的成本。我测试过不同压缩粒度最后发现每3~5轮做一次增量摘要性价比最高。少于3轮压缩成本高于保留成本多于5轮摘要开始丢失细节。同理重排模型也不是越强越好。如果知识库只有几百篇文档用规则加关键词过滤就够了强行上交叉编码器反而是杀鸡用牛刀。做上下文工程时每一处增值运算都需要用可量化收益来证明自己的必要性。5.4 评测集设计防止智能体过拟合到你的上下文模板上最后一个边界问题是评测。很多团队评测智能体时只准备了几十个样本而且样本是静态的。改完上下文后在样本上效果惊人一上线就崩。原因不外乎两个一是评测样本太少没覆盖到新上下文的盲区二是样本和模板高度同质化智能体学会了针对模板答题而不是针对问题答题。我现在的习惯是准备至少200条评测样本按业务场景分层每条样本都带预期知识点来源标注。评测时不只看准确率还要看每一条错误的错误类型是检索漏召回、重排误置顶、摘要丢失关键承诺还是指令被忽略。没有这样的分层评测你就永远不知道下一次该优化哪个环节——是补知识还是修路由还是调摘要策略。最后再分享一点我的个人体会做了这几个项目之后我对智能体性能优化这件事有了一层新的认识与其说我们在调模型不如说我们在给模型的注意力装栅栏。大模型的推理能力是固定的但注意力往哪里看完全由上下文工程决定。你给它的上下文越干净、越贴切、越结构化它的推理能力就越能百分百用在刀刃上。如果读者只想记住一条我会说下一次遇到智能体表现不稳定时不要急着换更强的大模型也不要反复试prompt话术先把一次调用的上下文完整打印出来问自己三句话——每一段信息为什么在这里它离决策点有多远有没有一段内容是可以删掉而不影响输出的把这三句话逼出来性能瓶颈大概率会自动现出原形。上下文工程不是某种特定工具它更像一套把模型能力变成系统稳定性的施工方法论。这条路我也还在继续探索欢迎有类似实战经历的朋友多交流尤其是那些在特定业务场景里把上下文工程做到极致的案例——这种东西光靠理论是真的学不来的。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
