Context 是模型这一轮能看到的材料

context 可以先理解成：模型这一轮真正能看到的材料。

它不是“所有历史”，也不是“所有资料”，更不是“系统知道的一切”。它只是这一次调用模型时，被放进输入窗口里的那部分内容。

这个区分很重要。因为 LLM 本身可以先看成一个每次调用都只处理当前输入的语言引擎。它看起来记得过去，通常是因为外层系统把过去的对话、摘要、任务状态、用户偏好、检索结果或工具输出重新放进了这一轮 context 里。

所以 context 不是一个抽象玄学词。它非常具体：

- 当前用户的问题

- 系统指令

- 开发者指令

- 历史对话的原文或摘要

- 当前任务目标

- 已确认的约束

- 工具返回的结果

- 检索到的资料

- 从 memory 里取回来的偏好或经验

- 当前阶段的计划和未决问题

这些材料不一定都会进入当前轮。进入之前，系统要选择、排序、压缩、标注来源，也要过滤权限不允许看的内容。

这就是为什么 context 需要管理。

模型窗口不是无限的。即使某些信息塞得下，也不等于应该塞进去。无关历史、失败尝试、长日志、过时资料、重复内容都会和真正重要的信息竞争注意力。context 越大，也通常意味着成本更高、延迟更长，留给输出的空间更少。

所以 agent 系统里的一个核心问题不是“把资料都给模型”，而是：

这一轮最该让模型看到什么？

有时候它需要看到最近几轮对话，因为用户正在连续修正一个想法。

有时候它需要看到长期约束，因为当前动作不能违反之前确认过的边界。

有时候它需要看到原始证据，因为最后回答必须可追溯。

有时候它不应该再看到完整失败轨迹，只需要一条“之前尝试过 X，失败原因是 Y”的摘要。

context 管理做的就是这些事情：获取候选材料，决定哪些进入当前轮，把长材料改写成更适合模型使用的形态，并且隔离不该混在一起的信息。

这里容易有一个误解：context 管理不是简单的“压缩聊天记录”。压缩只是其中一种手段。更完整地看，它包括：

- 从哪里取材料

- 哪些材料有权限进入当前轮

- 哪些是指令，哪些只是外部资料

- 哪些原文必须保留

- 哪些可以摘要

- 哪些失败过程应该移出主上下文

- 哪些结论必须带来源

- 输出还需要预留多少空间

因此，agent 的表现经常不是单纯由模型能力决定的。一个很强的模型，如果当前 context 里缺少关键约束，也会做错。一个普通模型，如果当前 context 干净、相关、结构清楚，反而可能表现得更稳定。

这也能解释为什么 LLM 不是 Agent。LLM 负责基于当前输入生成下一步，而 agent 系统要负责构造这个“当前输入”。模型看到什么，往往决定了它能想到什么、会忽略什么、会不会把噪音当重点。

更具体地说，context 组装不是拼聊天记录。系统要构造的是当前工作视图，而不是把所有发生过的事都按时间顺序塞进去。

如果说 LLM 是语言引擎，那么 context 就是这一轮递给它的工作台。工作台上放什么、怎么摆、哪些东西收起来、哪些证据贴在旁边，这些都会影响下一步工作。