上下文管理

模型每次只能接收有限数量的信息，这个容量叫“上下文窗口”。长对话、代码、Tool 定义和输出都会占用窗口，因此 Agent 需要决定下一次请求应该带上什么。

上下文里不只有聊天文字

一次模型请求的输入通常包含：

应用提供的系统规则；
当前可用 Tool 的结构说明；
对话中仍需保留的历史或历史摘要；
当前 Run 已产生的 Tool 结果；
本次附件、任务说明和临时工作信息。

所以，聊天界面看起来只有几段话时，也可能已经占用大量上下文。反过来，界面显示的完整历史也不一定逐字进入每次模型请求。

系统还会为模型回答预留输出容量。这部分属于上下文预算，不是作为文字或消息发送给模型的内容。

模型请求怎样组装

理解下面的布局，先区分两个概念：

Run（一次任务执行）：Agent 从接收本次任务到结束执行的过程。一个 Run 可以多次请求模型、调用 Tool，也可以等待用户回答或审批后继续；它不等于一次模型请求。
World State（工作状态）：应用提供给模型的环境与能力状态。full 是完整快照，diff 只记录后来的变化。会话状态跨 Run 延续；Run 状态描述本次任务激活的 Skill、浏览器状态和附件等信息。

模型请求中的上下文主要分为独立的 tools 和 messages 两部分。tools 中的 Schema 是 Tool 名称、参数与结构定义；使用这些 Tool 的文字指导则放在相应消息段。下面是当前主模型请求的完整逻辑布局，可选内容不存在时省略：

text

模型请求
├─ tools：Tool 的 Schema，独立于 messages
│  ├─ 稳定工具：按名称排序
│  └─ 动态工具：按名称排序，接在稳定工具之后
└─ messages：按以下顺序组织
   │
   │  稳定与半稳定前缀
   │
   ├─ 1. 稳定 System Prompt（系统提示）
   │  ├─ 基础行为规则
   │  ├─ 稳定工具使用指导
   │  ├─ 文件事务固定规则
   │  └─ 用户自定义指令
   ├─ 2. 初始 Skill 简短目录
   ├─ 3. 初始协作说明与目录
   ├─ 4. 当前启用能力指南
   │  └─ 联网、人机交互、浏览器等；关闭后在后续请求中撤下
   ├─ 5. 会话 World State full
   │  └─ 工作区、权限、环境、模型选择及能力开关等
   ├─ 6. 压缩摘要（可选）
   │
   │  历史与当前任务
   │
   ├─ 7. 摘要之后尚未覆盖的统一历史（无摘要时为保留的历史）
   │  ├─ 过去的用户输入、助手消息、完整 Tool 调用与结果
   │  ├─ 当时的附件说明、已提取文本与图片引用
   │  ├─ 当时的 Skill 完整说明与 Run 状态
   │  └─ 关联的 World State diff、忽略交互等事实，保持原有因果顺序
   ├─ 8. 本次连续用户输入
   │  └─ 保留全部连续输入及其关联 diff、附件说明、文本与图片
   ├─ 9. Run 开始时预激活 Skill 的完整说明
   ├─ 10. 初始 Run World State
   │  └─ 本次激活的 Skill、本任务浏览器状态、附件等完整快照
   ├─ 11. 当前 Run 的因果时间线
   │  ├─ 助手消息、完整 Tool 调用与结果
   │  ├─ 用户回答与引导
   │  ├─ 运行中动态激活的 Skill 完整说明
   │  └─ World State diff、必要的恢复状态、忽略交互等事实
   │
   │  当前请求的即时尾部
   │
   ├─ 12. Todo 精简提醒
   │  └─ 提醒正文采用 500 Token 估算预算；完整计划独立保存
   ├─ 13. 单次修复提醒
   │  └─ 例如空响应修复、文件事务纯文字违规后的下一次请求提醒
   └─ 14. 未完成文件事务的最小快照
      ├─ 事务 ID（transactionId）、路径（filePath）
      ├─ 操作（operation）、策略（strategy）、状态（status）
      ├─ 草稿版本（expectedDraftRevision）、下一操作序号（nextIndex）
      └─ 允许的下一步（allowedNextActions）；无未完成事务则省略

图中的 14 个逻辑段不等于固定 14 条 message。同一段可能展开成多条消息，也可能因为没有对应内容而不出现；不同模型服务的具体消息格式还会经过适配。一次完整 Tool 交换中的调用与结果始终保持配对及先后关系。以上布局适用于主 Agent 的模型请求，生成压缩摘要使用单独的输入布局。

第 2、3、9、10 段来自 Run 开始时的初始信息。后来新激活的 Skill、用户回答、状态变化和恢复信息留在第 11 段的实际发生位置，不会因内容类型相同而提前到初始说明中。本次任务包含多条连续输入时，第 8 段保留全部输入及其间的关联变化，不只取最后一条。

换轮时哪些内容会延续

上一 Run 的第 8–11 段会按原样和原顺序并入下一 Run 的第 7 段：用户输入、助手正文、Tool 交换以及关联材料继续作为统一历史。这里的“原样”包括原有消息角色、附件的已提取文本与图片引用、当时的 Skill 说明和状态。系统不会为重建旧历史重新提取附件，也不会重新读取已经变化的 Skill 文件来替换旧说明；之后发生压缩时，较早的历史仍可能被摘要替代。

历史中的状态说明的是“当时发生了什么”。过去启用过某项能力或 Skill，不表示现在仍有使用权限；当前权限由当前设置、任务状态和实际执行检查共同决定。会话 World State 的 full 在会话中延续，不会仅因开始新 Run 就生成一份新的 full；变化以 diff 留在对应位置。

第 12–14 段根据本次请求的即时状态重建，不会作为一组永久尾注逐轮累积。Todo 的 500 Token 预算只限制模型看到的精简提醒，不裁掉独立保存的完整计划。单次修复提醒只服务于相应的下一次请求。文件事务完成后，结果留在普通 Tool 历史中，不再占用未完成事务快照；固定操作规则仍在稳定 System Prompt 中。

能力开关与缓存

每次准备请求时，应用从同一份能力快照生成 Tool Schema、当前能力指南和 World State，避免出现定义、指导与状态彼此不一致。关闭能力后，下一次请求撤下对应 Schema 和指南，并在原有时间位置用 diff 记录不可用及原因；这个状态记录不会重新附带已撤下的指南。已发出的请求无法追溯撤回，实际 Tool 执行时仍会再次检查当前策略。

保持稳定内容靠前、旧历史顺序不变，可以增加相邻请求拥有相同前缀的机会。这里的前缀是两次请求开头完全相同的内容，模型服务可能利用它进行缓存。应用不保证缓存命中或命中率：能力与目录变化、压缩、模型服务切换和即时尾部提醒都可能改变可复用范围，服务商也有各自的缓存规则。复用旧附件引用也不意味着图片不再占用模型上下文容量。

Token 是什么

Token 是模型处理文字的计量单位，不等同于字符或汉字。代码、JSON、长路径和 Tool schema 也会消耗 Token。设置模型时填写的上下文窗口会用于发送前估算；兼容服务商的实际计量可能略有差异。

界面中的上下文指示器用于帮助判断剩余空间，它是安全估算，不是服务商账单。

压缩怎样工作

当旧历史接近容量上限时，系统会选择一个完整、稳定的早期片段，请模型生成更短的语义摘要，再用摘要替代这段历史的“模型视图”。压缩边界不会切开一个 Tool 调用和它的结果，也不会覆盖尚未被模型观察的当前 Run 内容。

压缩的目标是保留：任务目标、已确认决定、完成证据、失败与审批、未完成工作和下一步。摘要生成失败、没有真正变短或与最新历史冲突时，旧摘要不会被强行替换。

压缩不等于删除聊天

压缩改变的是后续模型看到的表示，不是把界面中的早期消息直接删除。已提交的消息和受支持的执行轨迹仍保存在本地历史中。不过，不是所有第三方原始结果都会永久完整归档；MCP 大结果、浏览器结果等可能只保留安全投影或 Artifact。

为什么 Agent 仍可能“忘记”

摘要为了缩短内容，必然丢失部分细节；
系统保留的精确历史入口数量有限，并不是完整目录；
当前模型可能没有配置正确的上下文窗口；
尚未提交的流式片段在崩溃后可能丢失；
分叉或新建对话有各自的历史边界。

让长任务更稳定

在开头写清目标、约束和完成条件；
每完成一个里程碑，让 Agent 总结已确认事实和剩余工作；
重要规范放进项目文件或 Skill，不要只依赖很早的聊天消息；
大文件按范围读取，不把整份日志一次塞入；
发现上下文紧张时，先收口当前阶段，再开启聚焦的新任务。

大型任务方法见管理大型项目。