写在前面
如果你经常使用 Agent，应该遇到过这种情况。
同一个模型，刚开始回答很快，思路也很清晰；但随着对话变的越来越长，它开始回复的很慢，可能会忘记前面讨论过的，有时候可能还会理解错需求。
很多人会觉的是模型不行了，其实真正发生变化的是 Context（上下文） 。
模型决定了 Agent 的能力上限，而 Context 管理，则会影响这个能力能否持续稳定地发挥出来。
Context 不只是聊天记录
很多人会以为 Context 就是聊天记录。
其实聊天记录只是其中的一部分。
每次 Agent 调用模型时，真正发送过去的内容通常包括：
- System Prompt
- 当前 Prompt
- 历史对话
- 当前读取的代码
- Memory
- 项目规则
- 其他
这些内容共同组成了模型当前能够看到的信息，也就是 Context。
所以，Context 更像是 Agent 当前的工作环境，而不是一份聊天记录。
那 Context 为什么会越来越大呢？
因为每完成一次任务，新的信息都会加入下一轮 Context。
例如一次简单的需求修改，Agent 可能会读取多个代码文件、调用终端和 Git 等工具、查询项目文档、再记录新的聊天内容。这些信息不会自动消失，而是层层叠加。
随着开发不断进行，Context 会持续增长。最终，一次请求发送给模型的内容可能已经变成：
sql
System Prompt + 历史对话 + 项目代码 + Tool 返回结果 + Memory + 当前需求也就是说，模型每回答一次，都需要重新理解整个工作环境。就像你的助手每回答一个问题，都要先把桌上所有东西重新看一遍。
为什么 Context 越大，效果反而可能变差？
很多人觉得，Context 越大，模型知道的信息越多，效果应该越好。
但真正影响效果的，不是 Context 有多长，而是有效信息有多少。
举个例子，一个会话里先讨论数据库，又修改项目配置，最后开始开发页面。当 Agent 修改一个组件时，前面的大量内容其实已经和当前任务没有关系了。
这些无关信息虽然不会让模型"变笨"，但会增加理解成本，常见的表现就是：
- 回复速度变慢；
- 更容易遗漏细节；
- 偶尔会把不同任务混在一起，导致回答跑偏。
因此，Context 并不是越多越好，而是越相关越好。
Context Window 大，就没有问题了吗？
现在很多模型都支持 128K、200K，1M 上下文。
但 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 管理决定了模型能否持续、高效地发挥这些能力。