上下文管理
模型每次只能接收有限数量的信息，这个容量叫“上下文窗口”。长对话、代码、Tool 定义和输出都会占用窗口，因此 Agent 需要决定下一次请求应该带上什么。
上下文里不只有聊天文字
一次模型请求通常包含：
- 应用提供的系统规则；
- 当前可用 Tool 的结构说明；
- 对话中仍需保留的历史或历史摘要；
- 当前 Run 已产生的 Tool 结果；
- 本次附件、任务说明和临时工作信息；
- 为模型回答预留的输出空间。
所以，聊天界面看起来只有几段话时，也可能已经占用大量上下文。反过来，界面显示的完整历史也不一定逐字进入每次模型请求。
Token 是什么
Token 是模型处理文字的计量单位，不等同于字符或汉字。代码、JSON、长路径和 Tool schema 也会消耗 Token。设置模型时填写的上下文窗口会用于发送前估算；兼容服务商的实际计量可能略有差异。
界面中的上下文指示器用于帮助判断剩余空间，它是安全估算，不是服务商账单。
压缩怎样工作
当旧历史接近容量上限时，系统会选择一个完整、稳定的早期片段，请模型生成更短的语义摘要，再用摘要替代这段历史的“模型视图”。压缩边界不会切开一个 Tool 调用和它的结果，也不会覆盖尚未被模型观察的当前 Run 内容。
压缩的目标是保留：任务目标、已确认决定、完成证据、失败与审批、未完成工作和下一步。摘要生成失败、没有真正变短或与最新历史冲突时，旧摘要不会被强行替换。
压缩不等于删除聊天
压缩改变的是后续模型看到的表示，不是把界面中的早期消息直接删除。已提交的消息和受支持的执行轨迹仍保存在本地历史中。不过，不是所有第三方原始结果都会永久完整归档；MCP 大结果、浏览器结果等可能只保留安全投影或 Artifact。
为什么 Agent 仍可能“忘记”
- 摘要为了缩短内容，必然丢失部分细节；
- 系统保留的精确历史入口数量有限，并不是完整目录；
- 当前模型可能没有配置正确的上下文窗口；
- 尚未提交的流式片段在崩溃后可能丢失；
- 分叉或新建对话有各自的历史边界。
让长任务更稳定
- 在开头写清目标、约束和完成条件；
- 每完成一个里程碑，让 Agent 总结已确认事实和剩余工作；
- 重要规范放进项目文件或 Skill，不要只依赖很早的聊天消息；
- 大文件按范围读取，不把整份日志一次塞入；
- 发现上下文紧张时，先收口当前阶段，再开启聚焦的新任务。
大型任务方法见管理大型项目。