上下文窗口管理

了解 Bob 的 270,000 token 上下文窗口的工作原理、每个类别对 token 使用量的贡献,以及保持会话专注和高效的最佳实践。

上下文窗口概述

Bob Shell 中的每个会话都有一个上下文窗口——该对话的 token 预算。上限为 270,000 token。Bob 加载的所有内容都会计入其中。

窗口的填充内容

类别包含内容
系统提示Bob 本次会话的核心指令
工具定义内置工具 schema 和已连接 MCP 工具的定义
MCP 工具已连接 MCP 服务器提供的工具的指令和描述
规则来自项目和模式规则文件的自定义指令(例如 AGENTS.md.bob/rules-*
技能Bob 为本次对话加载的技能指令
消息你的提示词、Bob 的回复以及对话中的工具活动。这是计为 token 的记录

命令输出和工具结果计入消息。文件内容没有单独的行。

token 报告包含两个汇总字段:

  • 为模型响应保留:为 Bob 的下一次回复预留的 token(通常为 20.0k)。
  • 可用空间:剩余的空闲 token。

基础开销

固定类别在你开始使用 Bob 之前就会占用上下文。即使是简单的 "快速打个招呼。" 也会消耗约 8.5k token。其中大部分是工具定义5.1k)、系统提示1.5k)、规则830)和技能454)。只有 590消息中。

Bob 每次提示都会重新发送完整的开销栈。更多的 MCP 服务器或已加载的技能会在你输入之前增加 MCP 工具工具定义技能

监控 token 使用情况

Bob Shell 在每次交流结束时报告 token 使用情况。下表显示了影响每个类别的因素:

类别增长原因
系统提示会话启动时加载。正常工作期间保持不变。
工具定义内置工具 schema。会话启动时设定。正常工作期间保持不变。
MCP 工具已连接的 MCP 服务器和已启用的工具。添加服务器或工具时增长,发送提示词时不增长。
规则项目和模式规则文件(例如 AGENTS.md)。会话打开时设定。
技能Bob 为会话加载的技能。如果 Bob 在对话中激活技能,可能会增加。
消息你的提示词、Bob 的回复、文件读取、工具输出和命令输出。每次交流和代码库探索都会增长。

在短时交流中,固定类别通常占用了大部分总量。当你要求 Bob 读取文件或运行工具时,消息通常会成为最大类别。注意这个变化。

可用空间随任意类别的增长而缩小。为模型响应保留是为 Bob 下一次回复预留的,不包含在上方的已用总量中。

Token 限制

每次会话的硬性上限为 270,000 token。Bob 在达到限制之前就会开始压缩。压缩通常在总使用量达到约 190,000 token 时开始。

自动上下文压缩

在压缩阈值处,Bob 会:

  1. 保留最近和最相关的上下文。
  2. 汇总或删除较旧的对话片段。
  3. 维护关键系统指令、工具定义、规则和技能。
  4. 使用压缩后的上下文继续工作。

压缩是有损的。消息早期的细节可能无法保留。当你更换话题或消息大到影响质量时,开始新会话。

对 Bobcoins 的影响

Bobcoins 追踪 token 使用量。输入和输出 token 都计入其中。

  • 每条消息都会再次发送完整的活跃上下文,包括固定开销。
  • Bob 每次发送时都会重新处理已加载的内容。
  • 消息量大的长会话,后期每次提示的费用会更高。

最佳实践

注意:

上下文窗口不是存储空间。它是工作内存——Bob 在每个步骤中可以使用的内容。控制放入其中的内容。当会话被过时输出填满时重置。用测试而非 Bob 的回复来验证结果。

确定会话和对话的范围

每个工作目标使用一个会话,从简明的提示词开始。在要求 Bob 探索代码库之前,陈述目标、预期结果和约束条件。明确指定文件和函数名称。避免"读取整个代码库"或"检查后端"等模糊请求。话题变化时开始新会话——消息中的不相关内容会增加费用并可能让 Bob 混淆。

保持常驻上下文精简

固定类别在你输入任何内容之前就会消耗 token。要降低开销:

  • 保持自定义规则AGENTS.md 简短——只放设置、测试和样式命令(例如 pnpm testmvn verify)。
  • 只连接当前工作所需的 MCP 服务器、工具和技能。断开未使用的连接,优先使用项目级 MCP 配置而非全局配置。
  • 消息保留给本次会话特有的情境证据——bug、日志和相关文件。不要在每次提示词中重复常驻规则。

在需要时添加上下文

让 Bob 搜索和读取目标文件,而不是将大段内容粘贴到聊天提示词中。在提示词中引用特定文件路径和行范围,避免宽泛的目录引用:

✓ 修复 src/utils/validation.ts 第 45-67 行中的邮件验证逻辑
✗ 查看 src/、tests/ 和 docs/ 中的所有内容并提出改进建议

分阶段工作——找到可能的文件、检查相关文件、规划、修改并验证。对于大范围代码库读取,使用子智能体,使会话收到压缩结果,而不是每个 read_file 调用都落入消息。当来源冲突时,相信运行中的代码和测试,而非过时的注释或旧的 README 说明。

有关大型项目的更多策略,请参阅处理大型项目

当消息填满时重置

经过长时间会话,消息会积累重复的文件内容、废弃的计划和过时的工具输出。当工作目标改变或对话大到影响质量时,开始新会话。保留约束条件、证据和未解决的问题——删除其余内容。

Bob 也可以自动压缩旧的片段,但压缩是有损的,消息早期的细节可能无法保留。相比一次大型自主运行,优先选择小型、经过审核的变更,以保持 diff 可审查,让 Bob 保持专注。

这个主题怎么样?