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 範例專案中開啟分析檢視並練習重置操作。