让人抓抗的场景

        很多刚接触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过往的工具调用记录与传参内容；每次工具调用返回的结果，比如文件内容、终端执行日志等；还有额外补充的项目说明、技术文档等参考资料。

        说白了，上下文优化的核心目标只有两个：一是用最少的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小妙招吗？评论区留言

关注我，分享更多大模型开发的干活文章