https://yennj12.js.org/yennj12_blog_V4/tags/context-cache/Recent content in Context Cache on YennJ12 Engineering BlogHugo -- gohugo.ioen-usThu, 04 Jun 2026 11:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part18-memory-cost-tuning-zh/Thu, 04 Jun 2026 11:00:00 +0800https://yennj12.js.org/yennj12_blog_V4/posts/fde-interview-guide-part18-memory-cost-tuning-zh/「把所有歷史對話塞進 Context 再問 LLM」 ——這個方案在 demo 時可以，在生產環境裡三個月後會讓你的帳單嚇一跳。 三層記憶體設計的核心不是「記更多」，而是「用最低的 token 成本，讓 Agent 感覺上記得一切」。 面試情境 面試官： 「這個 Agent 需要維護與大客戶長達三個月的商務對話。如果把所有歷史對話和工具調用結果全部當 Context 塞給 Gemini，Cost-per-request 會暴增，Tokens/sec 吞吐量大幅下滑。請設計一個三層記憶體架構平衡成本與延遲。」 一、核心問題：Context 成本為什麼會失控 先量化問題的規模： 典型企業客戶的對話規模估算： 每輪對話約 500 tokens（user + assistant + tool calls） 每天溝通 10 輪 三個月（90 天）= 900 輪 = 450,000 tokens 的歷史對話 如果全部塞入 Context： 每次請求的 input tokens： ├── System Prompt: 500 tokens ├── 三個月歷史對話: 450,000 tokens ├── 當次查詢: 100 tokens └── 總計: ~450,600 tokens 成本（Gemini 1.5 Pro，$1.