https://yennj12.js.org/yennj12_blog_V4/tags/tokenbudget/Recent content in TokenBudget on YennJ12 Engineering BlogHugo -- gohugo.ioen-usMon, 08 Jun 2026 10:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-core-concept-1-context-management-zh/Mon, 08 Jun 2026 10:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-core-concept-1-context-management-zh/Context Management 的本質是：在有限的 Token 預算內，決定哪些資訊值得保留、哪些必須壓縮或捨棄——這是所有長對話 AI 系統的核心資源排程問題。 一、為什麼面試官問這個 面試官測試的核心能力： 系統資源意識：你是否理解 LLM 的上下文視窗是有限的硬性限制，而非軟性建議？能否量化每個元件的 Token 消耗？Token waterfall 問題若不主動管理，100 輪對話後必然觸發截斷或 OOM。 Trade-off 判斷力：截斷策略的選擇（FIFO vs. 重要性加權 vs. 摘要壓縮）直接影響對話品質，面試官想看你能否說清楚「何時選哪種、代價是什麼」，而不是背誦一個萬用答案。 生產可操作性：理論上知道「要做 context trimming」很容易，但能否描述 LangGraph MemorySaver 的週期摘要節點、如何做 tenant-level 成本歸因，才是資深工程師的標誌。 弱答案長這樣：「我們用滑動視窗，把最舊的訊息刪掉就好。」——沒有量化 Token 預算、沒有解釋為什麼 FIFO 在長對話中會丟失關鍵系統指令。 強答案長這樣：「128K context 視窗中，system prompt 佔 8K、tools schema 佔 12K，剩餘 108K 給 history + answer。我們設 history ceiling 為 80K、answer reserve 為 28K。超過 history ceiling 時觸發階層式摘要：先壓縮最舊的 20 輪，~6K tokens 壓成 ~500 tokens，然後再做 FIFO。這樣能維持對話連貫性同時控制成本。壓縮比約 13:1，每次摘要呼叫用 Gemini Flash，成本不到主對話的 5%。」