大模型为什么不听话？我的 Context 优化实战复盘

让人抓抗的场景很多刚接触Agent的开发者都有过类似的体验刚跑通第一个Agent demo时还颇有成就感改个简单代码、读写文件都十分顺畅可一旦交给它稍复杂的任务效果立刻大打折扣。要么API频繁报错提示token超出上限要么Agent运行效率越来越低明明提供了完整的参考资料它却始终抓不住关键信息甚至会在同一个问题上反复出错。这几乎是所有新手进阶都会踩的核心坑——Agent的Context上下文管理。这篇内容会把这个问题彻底拆透不光讲清背后的核心逻辑也分享经过大量实操验证、被很多开发者跑通的落地方法拿到手就能直接调整自己的代码。先把文中会反复出现的几个核心概念用通俗的方式讲清楚避免理解偏差Token是大模型计算内容体量、接口收费的最小单位1个汉字约等于2个token传给大模型的内容超出它的处理上限后要么直接触发报错要么会出现类似“失忆”的问题无法关联前文的关键信息。Context Window也就是上下文窗口指大模型单次调用能记住、能处理的最大token上限就像考试的答题卡内容写超了之后大模型就无法完整读取、处理全部信息。ReAct是目前Coding Agent最常用的工作逻辑核心就是「思考→调用工具执行操作→查看工具返回结果」的循环直到完成全部任务。MCP全称Model Context Protocol即模型上下文协议是目前主流的Agent工具对接通用规范可以理解为给Agent使用的插件包想要给Agent拓展读文件、查数据库、操作Git这类能力都可以通过它快速实现。什么是Context开发者每次调用API传给大模型的上下文也就是Context到底包含哪些内容翻来覆去核心就是这几类开头固定的系统提示词用来给Agent设定基础规则与身份用户提出的原始需求此前的对话交互记录Agent过往的工具调用记录与传参内容每次工具调用返回的结果比如文件内容、终端执行日志等还有额外补充的项目说明、技术文档等参考资料。Context构成​​​​​说白了上下文优化的核心目标只有两个一是用最少的token承载最关键的信息不浪费大模型的上下文窗口空间二是让大模型能快速定位核心内容不会因为信息过载出现“看了后面忘前面”的问题。 不少开发者刚接触时都会陷入一个误区觉得上下文窗口开得越大越好但实操后会发现事实并非如此。行业内常说的“Lost in the middle”现象本质就是上下文越长大模型对关键信息的识别准确率就越低。就像让一个人背完整本小说后再提问第三章的一个细节绝大多数人都无法准确回答。如何进行Context优化静态Context优化先从最容易落地调整的静态上下文说起。所谓静态上下文就是开发者在系统提示词里提前写死的内容从任务启动开始就占用token额度其中最容易失控的就是MCP工具的预埋。很多新手刚接触MCP时都会犯同一个错误觉得工具加得越多Agent的能力就越强于是把读文件、写文件、数据库操作、接口调用、终端执行等上百个工具全部塞进系统提示词里。但每个工具都需要给大模型标注清楚名称、功能、入参出参规范也就是工具的Schema说明仅50个工具的说明内容就能轻松占用7-8万token直接吃掉大半的上下文窗口空间。更影响效果的是这些提前预埋的工具90%都不会在当前任务中被用到。大模型不仅不会调用自己完全不熟悉的工具还会因为可选工具过多无法匹配到当前任务真正需要的能力最终要么胡乱调用工具要么直接无法推进任务。第二个被广泛验证有效的优化方法是Skill渐进式加载核心逻辑就是用不到的工具绝对不提前预埋到上下文中。开发者可以把同一场景的工具打包成一个独立的技能包Skill比如数据库操作技能包、Git操作技能包、测试执行技能包只有当用户的需求触发对应场景时才把这个技能包的工具说明加载到上下文中无需使用时就不占用token空间。常规的落地方式是在系统提示词中只保留触发规则不写入完整的工具说明比如告知Agent当用户需求符合以下场景时先输出「加载XX技能包」系统会提供对应的工具使用说明1. 需要操作数据库时加载【数据库操作Skill】2. 需要操作Git时加载【Git操作Skill】3. 需要执行项目测试时加载【测试执行Skill】。除上述场景外仅可使用基础的文件读写、终端执行指令。只有当Agent输出对应的加载指令后才把对应技能包的工具说明补充到下一轮的上下文中。这个方法完美解决了“工具越多Agent执行准确率越低”的问题既保留了Agent的能力扩展性又不会让上下文被无用的工具说明占用。还有一个很容易被忽略的优化点就是工具的语境增长控制。很多开发者写的Agent从任务启动到结束上下文里始终保留着全量的工具说明哪怕当前步骤根本用不到对应能力。但实际上完全不需要这样操作只需要给Agent提供当前任务步骤真正需要的工具即可。实操中可以先让Agent将用户需求拆解成分步执行计划再根据它的执行计划匹配当前步骤需要的工具。比如第一步是读取项目README文件、了解项目结构就只提供文件读取工具第二步需要修改代码修复bug再补充文件写入工具第三步需要运行测试验证修改效果再提供测试执行相关的工具。每完成一个步骤就把上一步无用的工具说明从上下文中清理掉只保留当前步骤需要的内容。动态Context优化搞定了静态上下文的优化接下来就要解决最让开发者头疼的动态上下文膨胀问题。所谓动态上下文就是随着任务推进不断新增到上下文中的内容其中90%的体量膨胀都来自工具返回的结果也就是ReAct循环里的Observation。可以简单算一笔账让Agent修复一个代码bug它需要经历读文件、改代码、跑测试、看结果、再调整代码的完整流程每一步的工具返回结果都会被完整塞入上下文中。一次测试执行可能返回上千行日志一次项目编译可能输出几万行的终端内容十几轮循环下来上下文窗口就会被完全占满最终要么触发token超限报错要么大模型直接丢失前文的关键信息。最先要落地的优化就是砍掉运行时的噪音只给大模型传入真正有用的信息。很多新手在实操中常会出现的问题是无论工具返回什么内容都完整塞入下一轮的上下文中。比如运行pytest测试97个用例执行成功、3个用例执行失败却把97个成功用例的完整日志全部传入上下文真正有用的报错信息被大量无效内容稀释大模型很难快速定位问题核心。这些内容里90%都是无用的噪音完全可以在传入上下文之前先做一层过滤只把需要大模型做决策的关键信息保留下来。比如运行测试时通过参数调整只返回失败用例的简短报错信息成功用例仅统计数量token占用能直接减少90%项目编译、依赖安装这类操作执行成功就只返回一句「执行成功」执行失败才传入核心报错堆栈读取文件时也只返回和当前任务相关的代码片段不把完整文件内容全部传入。实操中还可以加一层兜底规则只要工具返回的内容超过1000token就先自动做摘要处理只把核心结论和关键信息传给大模型绝对不把全量日志直接塞入上下文。第二个被大量开发者验证有效的方法是给Agent做经验沉淀让它记住过往踩过的坑不需要每次任务都从零开始。很多开发者写的Agent都是“一次性”的这次给某个项目修复完bug下次再问同一个项目的相关问题它又会忘记项目结构需要重新读取一遍所有项目文件平白浪费大量token。不少资深开发者会形成固定的实操习惯在所有项目的根目录下都创建一个AGENT.md文件里面写清项目的基础信息、技术栈、核心目录结构、关键执行命令、已知注意事项。同时给Agent设定固定规则处理该项目的任务时第一步必须先读取根目录的AGENT.md文件根据里面的指引定位对应文件绝对不能无差别读取整个项目的全部文件。每次Agent完成任务后还可以自动把本次任务的关键信息比如修改的文件、踩过的坑、解决的问题更新到这个AGENT.md文件里后续任务可以直接复用。仅这一个简单的文件就能大幅减少重复读文件带来的token消耗同时让Agent对项目的理解越来越深不会在同一个问题上反复出错任务完成率也会有明显提升。还有一个能从根源上解决日志膨胀的方法就是让工具执行与上下文解耦不要把全量执行日志都塞入上下文。很多开发者不管工具执行返回了多少内容都会完整塞入下一轮的上下文中比如执行依赖安装命令返回了上万行的下载日志也全部传入上下文完全没有必要。大模型根本不需要知道工具执行的完整过程只需要知道执行结果即可工具执行成功且不需要大模型做后续操作的就只传入一句「XX指令执行成功」工具执行失败才把需要大模型排查解决的核心报错信息传入上下文。如果大模型确实需要查看完整执行日志可以让它单独输出对应的查看指令再提供全量内容默认状态下绝对不返回全量执行日志。这个方法在大量实操场景中验证后发现尤其是需要多次执行终端命令、运行测试的任务token占用能减少80%以上。自适应上下文剪枝聊到这里很多开发者会问有没有更省事的终极优化方案这里可以给开发者推荐一个被广泛应用的开源工具SWE-Pruner专门解决Agent无差别读文件浪费token的问题。先看一组行业内的统计数据Coding Agent的token消耗分布中78.1%的token都用在了文件读取上命令执行、测试运行占12.4%而真正的代码修改操作仅占5.1%。说白了绝大多数token都被Agent无差别的文件读取操作浪费了。而SWE-Pruner就相当于给Agent装了一个专属的代码搜索引擎它会先给目标项目建立代码索引把每个函数、类、变量的位置与依赖关系完整记录下来当Agent需要处理对应任务时只会把和当前任务相关的代码片段加载到上下文中而不是读取完整文件、甚至整个项目。这个工具对新手也十分友好官方提供了现成的Python包一行命令就能完成安装给项目建立索引也只需要一行命令。开发者只需要给Agent加一个前置步骤接到任务后先通过SWE-Pruner搜索和任务相关的代码片段仅读取这些匹配到的内容不读取完整文件。它的优化效果十分突出在行业标准的SWE-bench测试集中能帮开发者节省28%-38%的token同时Agent的问题解决率还能提升1.2-1.4个百分点真正实现了效率与效果的双重提升。总结经过大量的实操与优化验证行业内对Agent上下文优化形成了一个共识这件事的核心从来都不是给大模型开更大的上下文窗口而是给它传入更精准、更聚焦的有效信息无用的内容绝对不要塞入上下文。开发者不需要一次性落地所有优化方法可以先从最简单的AGENT.md文件创建、工具返回结果过滤开始调整落地后就能看到明显的优化效果再逐步把其他方法补充进来。毕竟Coding Agent的搭建与优化本身就是一个不断踩坑、不断调整的过程能解决自身实际需求的方法就是最合适的方法。最后大家还有其他优化Context小妙招吗评论区留言关注我分享更多大模型开发的干活文章