Context window 管理
了解 Bob 的 270,000 token context window 的工作原理、每个类别如何影响 token 用量，以及保持 task 专注并提升成本效率的最佳实践。
理解 context window
聊天面板中的每个 task 都有一个 context window — 该线程的 token 预算。上限为 270,000 个 token。Bob 加载的所有内容都会计入其中。
哪些内容会填满 window
将鼠标悬停在聊天面板右上角的 token usage indicator 上，可查看正在消耗 context window 的各项内容：
| 类别 | 包含内容 |
|---|---|
| System prompt | Bob 本次会话的核心指令 |
| Tool definitions | 内置工具 schema 及已连接 MCP 工具的定义 |
| MCP Tools | 已连接 MCP 服务器所提供工具的指令和说明 |
| Rules | 来自项目和模式 rule 文件的自定义指令（例如 AGENTS.md 或 .bob/rules-*） |
| Skills | Bob 为本次对话加载的 skills 中的指令 |
| Messages | 你的 prompt、Bob 的回复以及对话中的工具活动。这是以 token 计量的 transcript。 |
@ 提及、命令输出和工具结果均计入 Messages。文件内容没有单独的计量行。
Estimated breakdown 下方：
- Reserved for model response：为 Bob 下一次回复预留的 token（通常为 20.0k）。
- Available space：剩余空闲 token。
基础开销
在你开始与 Bob 协作之前，固定类别就已在消耗 context。在 Galaxium Travels 示例项目中，即使是 "Quickly say hi back." 也会合计约 8.5k 个 token。其中大部分来自 Tool definitions（5.1k）、System prompt（1.5k）、Rules（830）和 Skills（454），Messages 中仅有 590。
Bob 在每次 prompt 时都会重新发送完整的开销堆栈。连接更多 MCP 服务器或加载更多 skill 会在你开始输入前增大 MCP Tools、Tool definitions 和 Skills。
有关实际数字和重置演练，请参阅 Create a new context window。
监控 token 用量
Token usage indicator 会显示相对于 270,000 token 上限的使用百分比和已用/总量分数。点击它可打开 context window breakdown，查看哪个类别正在增长。
下表展示了各类别的增长因素：
| 类别 | 导致增长的因素 |
|---|---|
| System prompt | 在 task 启动时加载，正常工作期间保持不变。 |
| Tool definitions | 内置工具 schema，在 task 启动时设置，正常工作期间保持不变。 |
| MCP Tools | 已连接的 MCP 服务器和已启用的工具。添加服务器或工具时增长，发送 prompt 时不增长。 |
| Rules | 项目和模式 rule 文件（例如 AGENTS.md），在 task 打开时设置。 |
| Skills | Bob 为 task 加载的 skill。若 Bob 在线程中途激活某个 skill，可能增大。 |
| Messages | 你的 prompt、Bob 的回复、文件读取、工具输出和 @ 提及。每轮对话及仓库探索都会增长。 |
在简短的交流中，固定类别通常占据总量的大部分。当你要求 Bob 读取文件或运行工具时，Messages 通常会成为最大的类别。请留意这一变化。
任何类别增长都会使 Available space 缩小。Reserved for model response 为 Bob 的下一次回复预留，不包含在上方显示的已用总量中。
有关实际仓库的测量示例，请参阅 Create a new context window。
Token 限制
每个 task 的硬性上限为 270,000 个 token。Bob 会在达到上限前开始压缩。压缩通常在总用量约 190,000 个 token 时开始。
自动 context condensation
在压缩阈值处，Bob 会：
- 保留最近且最相关的 context。
- 总结或移除较旧的对话片段。
- 保留关键系统指令、tool definitions、rules 和 skills。
- 以压缩后的 context 继续工作。
Condensation 是有损的。Messages 早期的细节可能无法保留。当话题变更或 Messages 大到足以影响质量时，请点击 +（New task）开始新的 task。
对 Bobcoins 的影响
Bobcoins 追踪 token 用量，输入和输出 token 均计入其中。
- 每条消息都会重新发送全部活跃 context，包括固定开销。
- Bob 每次发送时都会重新处理已加载的内容。
- Messages 内容较多的长线程，后续每个 prompt 的费用更高。
最佳实践
Context window 不是存储空间，而是工作内存 — Bob 在每个步骤中可以使用的内容。控制好进入其中的内容。当线程充满过时输出时，及时重置或压缩。用测试而非仅凭 Bob 的回复来验证结果。
限定 task 和对话的范围
每个工作目标使用一个 task，从明确的 prompt 开始。在要求 Bob 探索仓库前，先说明目标、预期结果和约束条件。明确指出文件和函数名称。避免含糊的请求，例如"读整个仓库"或"检查后端"。话题变更时点击 +（New task）—— Messages 中无关的内容会增加费用并可能误导 Bob。
保持常驻 context 精简
固定类别在你输入任何内容前就已消耗 token。为了降低这部分开销：
- 保持 custom rules 和
AGENTS.md简短——只在其中放置构建、测试和风格命令（例如pnpm test、mvn verify）。 - 只连接当前工作所需的 MCP 服务器、工具和 skills。断开不使用的连接，并优先使用项目级 MCP 配置而非全局配置。
- 将 Messages 留给该 task 专属的情境证据——bug、日志和相关文件。不要在每个 prompt 中重复常驻 rules。
在需要时添加 context
让 Bob 搜索并读取目标文件，而不是将大块内容粘贴到线程中。使用 context mentions 引用特定文件或行范围，避免宽泛的目录提及：
✓ @/src/utils/validation.ts:45-67 Fix the email validation logic
✗ @/src @/tests @/docs Review everything and suggest improvements你也可以在编辑器中选中文本，使用 Cmd + L（Mac）或 Ctrl + L（Windows/Linux）将其直接添加到聊天中。
分阶段工作——找到可能涉及的文件，检查相关文件，制定计划，进行修改，然后验证。对于大范围的仓库读取，使用 subagents，让 task 接收压缩后的结果，而不是让每个 read_file 调用都落入 Messages。当来源相互矛盾时，信任正在运行的代码和测试，而非过时的注释或陈旧的 README 说明。
有关大型仓库的更多策略，请参阅 Working with large projects。
当 Messages 填满时重置或压缩
在长对话过程中，Messages 会积累重复的文件内容、废弃的计划和过时的工具输出。当工作目标变更或线程大到足以影响质量时，点击 +（New task）开始新的 task。保留约束条件、证据和待解决的问题——移除其余内容。
Bob 也可以自动 压缩 较旧的片段，但 condensation 是有损的，Messages 早期的细节可能无法保留。相比大型自主运行，优先选择小的、经过审批的变更，以保持 diff 可审查，并让 Bob 保持在正确的轨道上。
了解更多
请参阅 Create a new context window，在 Galaxium Travels 示例项目中打开分析视图并练习重置操作。