上下文窗口管理
了解 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 会:
- 保留最近和最相关的上下文。
- 汇总或删除较旧的对话片段。
- 维护关键系统指令、工具定义、规则和技能。
- 使用压缩后的上下文继续工作。
压缩是有损的。消息早期的细节可能无法保留。当你更换话题或消息大到影响质量时,开始新会话。
对 Bobcoins 的影响
Bobcoins 追踪 token 使用量。输入和输出 token 都计入其中。
- 每条消息都会再次发送完整的活跃上下文,包括固定开销。
- Bob 每次发送时都会重新处理已加载的内容。
- 消息量大的长会话,后期每次提示的费用会更高。
最佳实践
上下文窗口不是存储空间。它是工作内存——Bob 在每个步骤中可以使用的内容。控制放入其中的内容。当会话被过时输出填满时重置。用测试而非 Bob 的回复来验证结果。
确定会话和对话的范围
每个工作目标使用一个会话,从简明的提示词开始。在要求 Bob 探索代码库之前,陈述目标、预期结果和约束条件。明确指定文件和函数名称。避免"读取整个代码库"或"检查后端"等模糊请求。话题变化时开始新会话——消息中的不相关内容会增加费用并可能让 Bob 混淆。
保持常驻上下文精简
固定类别在你输入任何内容之前就会消耗 token。要降低开销:
- 保持自定义规则和
AGENTS.md简短——只放设置、测试和样式命令(例如pnpm test、mvn verify)。 - 只连接当前工作所需的 MCP 服务器、工具和技能。断开未使用的连接,优先使用项目级 MCP 配置而非全局配置。
- 将消息保留给本次会话特有的情境证据——bug、日志和相关文件。不要在每次提示词中重复常驻规则。
在需要时添加上下文
让 Bob 搜索和读取目标文件,而不是将大段内容粘贴到聊天提示词中。在提示词中引用特定文件路径和行范围,避免宽泛的目录引用:
✓ 修复 src/utils/validation.ts 第 45-67 行中的邮件验证逻辑
✗ 查看 src/、tests/ 和 docs/ 中的所有内容并提出改进建议分阶段工作——找到可能的文件、检查相关文件、规划、修改并验证。对于大范围代码库读取,使用子智能体,使会话收到压缩结果,而不是每个 read_file 调用都落入消息。当来源冲突时,相信运行中的代码和测试,而非过时的注释或旧的 README 说明。
有关大型项目的更多策略,请参阅处理大型项目。
当消息填满时重置
经过长时间会话,消息会积累重复的文件内容、废弃的计划和过时的工具输出。当工作目标改变或对话大到影响质量时,开始新会话。保留约束条件、证据和未解决的问题——删除其余内容。
Bob 也可以自动压缩旧的片段,但压缩是有损的,消息早期的细节可能无法保留。相比一次大型自主运行,优先选择小型、经过审核的变更,以保持 diff 可审查,让 Bob 保持专注。