写在前面如果你经常使用 Agent应该遇到过这种情况。同一个模型刚开始回答很快思路也很清晰但随着对话变的越来越长它开始回复的很慢可能会忘记前面讨论过的有时候可能还会理解错需求。很多人会觉的是模型不行了其实真正发生变化的是Context上下文。模型决定了 Agent 的能力上限而 Context 管理则会影响这个能力能否持续稳定地发挥出来。Context 不只是聊天记录很多人会以为 Context 就是聊天记录。其实聊天记录只是其中的一部分。每次 Agent 调用模型时真正发送过去的内容通常包括System Prompt当前 Prompt历史对话当前读取的代码Memory项目规则其他这些内容共同组成了模型当前能够看到的信息也就是 Context。所以Context 更像是 Agent 当前的工作环境而不是一份聊天记录。那 Context 为什么会越来越大呢因为每完成一次任务新的信息都会加入下一轮 Context。例如一次简单的需求修改Agent 可能会读取多个代码文件、调用终端和 Git 等工具、查询项目文档、再记录新的聊天内容。这些信息不会自动消失而是层层叠加。随着开发不断进行Context 会持续增长。最终一次请求发送给模型的内容可能已经变成System Prompt 历史对话 项目代码 Tool 返回结果 Memory 当前需求也就是说模型每回答一次都需要重新理解整个工作环境。就像你的助手每回答一个问题都要先把桌上所有东西重新看一遍。为什么 Context 越大效果反而可能变差很多人觉得Context 越大模型知道的信息越多效果应该越好。但真正影响效果的不是 Context 有多长而是有效信息有多少。举个例子一个会话里先讨论数据库又修改项目配置最后开始开发页面。当 Agent 修改一个组件时前面的大量内容其实已经和当前任务没有关系了。这些无关信息虽然不会让模型变笨但会增加理解成本常见的表现就是回复速度变慢更容易遗漏细节偶尔会把不同任务混在一起导致回答跑偏。因此Context 并不是越多越好而是越相关越好。Context Window 大就没有问题了吗现在很多模型都支持 128K、200K1M 上下文。但 Context Window 更像是容量而不是效率。就像一本两千页的书虽然所有内容都在但想快速找到某一页的信息依然需要时间。模型也是类似的。因此即使 Context Window 很大如果里面充满了历史任务、无关代码和重复信息回答质量依然可能受到影响。如何管理 Context一个功能一个对话尽量不要把不同的任务都放到同一个对话里。把任务拆开可以让每个对话都保持相对干净。定期整理上下文完成一个阶段后可以让 Agent 输出当前功能的总结。下一次直接基于总结继续而不是依赖几十轮历史聊天。把重复流程沉淀成 Skill这一点是我后来体会比较深的。很多流程其实每天都会重复。如果每次都重新描述一遍不仅浪费时间还会不断增加 Context。更好的方式是把这些固定流程整理成Skill或者沉淀到AGENTS.md、Rules等长期配置中。这样Agent 每次只需要知道按照这个 Skill 执行而不是重新理解整套流程。本质上这就是把稳定的信息从聊天记录中抽离出来需要的时候再加载而不是一直堆积在 Context 里。减少无关信息。尽量缩小 Agent 的工作范围。例如你已经确定问题出在某个模块就直接告诉 Agent 修改对应的文件或者提供相关代码片段而不是每次都让它重新扫描整个项目。给模型的信息越聚焦它就越容易理解你的真实需求也能减少无关信息对 Context 的干扰。很多时候一个干净、相关的 Context比一个冗长却充满噪音的 Context 更有价值。写在最后一个好的 Agent 工作流不是不断往聊天记录里堆信息而是把不同的信息放到合适的位置规则交给 Rules重复流程沉淀成 Skill项目知识交给 Memory 或 RAG当前 Session 只关注眼前的任务。模型决定了 Agent 的能力上限而 Context 管理决定了模型能否持续、高效地发挥这些能力。