上下文視窗管理
了解 Bob 的 270,000 token 上下文視窗如何運作、每個類別如何影響 token 使用量，以及讓工作階段保持專注和節省成本的最佳實踐。
上下文視窗概述
Bob Shell 中的每個工作階段都有一個上下文視窗——該對話的 token 預算。上限為 270,000 個 token。Bob 載入的所有內容都會計入其中。
填滿視窗的內容
| 類別 | 包含內容 |
|---|---|
| 系統提示 | Bob 工作階段的核心指令 |
| 工具定義 | 內建工具結構描述和已連線的 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 使用量。下表顯示影響每個類別的因素：
| 類別 | 使其增長的因素 |
|---|---|
| 系統提示 | 工作階段啟動時載入。正常工作期間保持不變。 |
| 工具定義 | 內建工具結構描述。工作階段啟動時設定。正常工作期間保持不變。 |
| 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 設定而非全域設定。
- 將訊息保留給此工作階段特定的情境證據——錯誤、記錄和相關檔案。不要在每次提示中重複常備規則。
在需要時加入上下文
讓 Bob 搜尋和讀取目標檔案，而不是將大量內容貼入聊天提示。在提示中引用特定的檔案路徑和行範圍，並避免廣泛的目錄引用：
✓ 修復 src/utils/validation.ts 第 45-67 行的電子郵件驗證邏輯
✗ 審查 src/、tests/ 和 docs/ 中的所有內容並提出改進建議分階段工作——找到可能的檔案、檢查相關的檔案、計劃、更改和驗證。對於廣泛的儲存庫讀取，使用子代理，這樣工作階段接收的是壓縮結果，而不是每個 read_file 呼叫落入訊息。當來源衝突時，信任執行中的程式碼和測試，而非過時的注解或舊的 README 說明。
有關大型儲存庫的更多策略，請參閱處理大型專案。
當訊息填滿時重置
在長時間的工作階段中，訊息會積累重複的檔案內容、廢棄的計劃和過時的工具輸出。當工作目標改變或對話已足夠大而影響品質時，請開始新的工作階段。保留限制條件、證據和未解決的問題——其餘的可以移除。
Bob 也可以自動壓縮舊的片段，但壓縮是有損耗的，訊息早期的細節可能無法存活。相比一次大型自主執行，更應優先進行小型、已核准的更改，以使差異保持可審查且 Bob 保持在正軌上。