從「哪個 Model 最省錢？」到重新理解 Token、Context 與 AI 的注意力
最近陸續聽了公司幾位很優秀的同事分享 AI Agent、Context Engineering 和 Claude Code 的一些實務經驗，自己中間也花了一些時間問問 Claude Code、查資料，再一邊調整自己的做法，慢慢對 AI 成本這件事有了和當初不一樣的心得和觀點。
AI 的世界變化真的很快，很多現在覺得有效的方法，可能過一陣子又會有新的做法。也因為這樣，偶爾停下來整理一下這個階段自己學到什麼、想法怎麼改變，是一件蠻有趣的事情。
到底要用哪一個 Model，才最省錢？
畢竟現在 Model 這麼多，每個模型的 Input / Output Token 價格又不一樣。
一開始很自然會覺得：就選一個比較便宜的 Model，不就省錢了！
但研究了一小陣子之後，我才發現真正影響 AI 成本與效率的，很多時候不只是用了哪個 Model，而是：
你到底讓這個 Model 處理了多少東西，以及怎麼讓它工作。
先來理解AI 的成本到底是怎麼產生的？
AI 的成本，不只是 Model 的單價
AI 的成本，大致可以拆成三類：
1. Input：你丟了多少東西給 AI
程式碼、API Response、文件檔、logs、對話歷史等等，這些全部都會變成 Token。
而實際工作時，Input 的量往往遠大於我們想像。
我們看到 AI 最後可能只回答 500 個 Token，但在回答之前，它可能已經讀了幾萬個 Token。
2. Output：AI 最後產生多少內容
以 Claude 系列模型來說，Output Token 的單價通常明顯高於 Input，大約可以差到 5 倍。
所以叫 AI 幫我產生一份超級完整、鉅細靡遺的報告，這種 Output 成本是很直接的。
而且 Output 還有一個特性，不像 Input ，Output 無法靠 Prompt Caching 省下來。
每一次產生的Ouput ，就是付完整的 Token。
不過觀察實際運用上面，多數大部分 Coding 任務的 Output 量，還是比 Input 小不少。
3. 每個 Session 都可能固定付出的成本
這是我以前比較沒有注意到的地方。
例如，CLAUDE.md、Memory、Tool Schema、System Instructions、MCP Tool Definition等，這些東西有些會在每次 Session，甚至每一輪對話裡進入 Context。蠻像手續費，只要一開新的session 就要token。如果這一層很肥，累積起來要付不少token。在認知到這一點後，我馬上去瘦身一下我的 memory 和 Claude.md 那些的（笑）。
關於Prompt Caching
這也是一個很有趣的一件事，並不是所有 Input Token 每次都是原價。
如果某一大段 Input 重複出現、沒有改、又在 Cache 有效時間內，就有機會透過 Prompt Caching 降低成本。
像 CLAUDE.md、Memory 這類相對固定的內容，如果設計得好，其實很適合利用 Cache。
反過來看，AI 每次新產生的 Output，則沒有這個優勢。所「成本優化」開始變得比我原本想的複雜一點，不能只是看哪個 Model 每百萬 Token 最便宜，還需要一起看 Token 到底花在哪裡？
更大的發現：Context 不是越多越好
用了 Claude Code 一小陣子，有時候某些session 想叫 Claude Code 吃銀杏，記憶力不太好啊.......(雖然據說銀杏證實對記憶力也沒幫助就是了）。 但是這個疑問也只是飄過腦子一下，重要的就要它記錄到 memory，或寫出一個skill 之類的。一直到聽到同事提到 Lost in the Middle ，才讓我兩者對照連結起來。
Lost in the Middle是指：
大型語言模型（LLM）模型通常比較容易掌握 Context 開頭與結尾的資訊，中間大量資訊反而比較容易被忽略。
所以當 Context 越來越肥，Agent 有時候會開始出現一些很熟悉、令人翻白眼的症頭：
忘記一開始的驗收標準
繼續追著已經過時的假設跑
修 A，結果把 B 弄壞
重新調查前面其實已經確認過的事情
明明前面講過了，後面又像第一次看到
以前碰到這些情況，除了狂翻白眼想碎念 Claude 又變笨了之外，現在會深呼吸後先看看：
是不是我的 Context 已經太多太亂了？
實用 Tips：我現在怎麼看 Context、什麼時候清理？
在 Claude Code 裡，可以直接用內建的 /context 查看目前 Context 的使用量與分配情況，也可以從終端機底部的 Status Line 快速掌握目前用了多少。
我自己現在有一個很簡單的習慣：
Context 超過大約 70%，我就會開始考慮整理。
如果目前這件事情還要繼續做，我通常會先呼叫 /compact，把前面的對話紀錄壓縮、整理成比較精簡的 Context，再繼續往下。
如果我只是想試試看另一種解法、開一個分支任務，但又希望保留前面已經累積的修改歷史與 Context，我就會用 /fork，從目前狀態分出去探索。
至於完全不同的新主題，我現在就乾脆直接開新的 Session。
簡單來說，我自己的判斷大概是：
同一件事繼續做 → /compact
同一個脈絡，想分支試另一條路 → /fork
已經是另一件事 → New Session
這個習慣看起來很小，但實際用一陣子之後，我覺得蠻有幫助。
以前比較容易一直在同一個 Session 裡聊到底；現在會開始有意識地想：
這些 Context，我下一步真的還需要嗎？
而不是等到整個 Context 快塞滿、Claude 已經開始有點「忘東忘西」的時候，才想起來要整理。😂
Context Window 僅是容量，不代表品質
現在我比較不會只看：還剩多少 % Context？ 因為就算 Window 還沒有塞滿，也不代表目前 Context 的品質很好。
如果裡面充滿過時和不需要的資訊，它們一樣會跟真正重要的資訊競爭 AI 的注意力。
這讓我開始用另外一種方式理解 Context：
Context 的問題，不只是 Token 數量，而是訊號與雜訊的比例。
我們得把有限的注意力留給真正重要的東西。
Tool 本身，也在吃 Context
另一個以前我比較沒注意到的地方，是 Tool。我之前很容易有一個直覺：
MCP Server 越多，Agent 能力越強。
但 Tool Definition 本身也是 Context。
Anthropic 分享過一個案例：當 AI Agent 連接多個服務（如 GitHub、Slack、Sentry 等）累積到 58 個工具時，傳統的一次性載入會消耗約 55K Tokens；改成 On-demand Tool Search 之後，整體相關 Context 從約 77K 降到 8.7K，減少約 85%。
這個數字讓我印象蠻深。還沒有開始「工作」，光是在告訴 AI 你有哪些工具可以用就已經花掉不少錢。
而且工具太多還有另外一個問題：
Agent 選錯工具的機率也會增加。
所以更多 Tool，不一定等於更強的 Agent。
不要再只想著「省 Token」啦
哪個 Model 比較便宜？這個議題其實只是在最佳化整個 AI Workflow 裡的一小部分。
真正影響成本與效率的，還包括很多：
Context 放了什麼
每次固定load什麼
Tool 怎麼連結與設計
大量資料怎麼進來
對話歷史累積多久
任務有沒有被拆開
哪些事情應該交給 Script
哪些事情才真的需要 Agent
這些不只影響 Cost，也直接影響 AI 的工作品質。
省 Token 跟提高 AI 品質，有時候其實是同一件事情。拿掉的，往往就是那些不必要的雜訊。
從 WSCI 架構重新理解 Context Engineering
LangChain 在 2025 年談 Context Engineering for Agents 時，把 Agent 管理 Context 的策略整理成四個方向(簡稱為 WSCI)：
Write/Persist、Select/Retrieve、Compress、Isolate
在理解前面提到的 Token 成本、Context Rot 這些概念之後，再回頭看這四個方向，我更能了解它們為什麼實用。
Persist — 什麼值得留下？
哪些資訊是穩定、重要，而且未來還會一直用到的？
這些才值得放進 CLAUDE.md、Memory，或其他可以長期保存的地方。
Retrieve — 什麼需要時再拿？
不是什麼都先塞進 Context，而是等真正需要時，再去搜尋、讀取、取得相關資訊。
Compress — 什麼該整理、壓縮？
Context 累積到一定程度後，哪些歷史資訊已經不需要保留完整過程，只需要留下結論、決策與下一步？
Isolate — 什麼應該分出去做？
有些探索會讀大量檔案、產生大量中間資訊，但主 Agent 最後其實只需要結果。
這時候，把工作交給另一個 Agent 或獨立 Context，最後只帶回高訊號的摘要，反而更乾淨。
看了一圈資料，又拿自己的 Claude Code 實驗了一陣子之後，我發現很多原本看起來各自獨立的技巧，其實都可以放回這四個方向理解。
例如：
- 我開始重新整理自己的 CLAUDE.md 和 Memory，把不需要每個 Session 都載入的內容搬出去。
- 遇到很大的 Log、JSON 或 CI Output，不再習慣整包丟給 AI，而是先搜尋、過濾，只讓真正需要的資訊進入 Context。
- 探索範圍很大的工作，開始嘗試交給 Subagent，最後只把結論帶回主要對話。
- 重複出現的 Jira / Confluence / curl 工作，我也開始Script 化
甚至連 Coding Workflow 也慢慢從最初開始的 想到哪、問到哪、改到哪
變成：
Explore → Plan → Implement → Verify → Handoff
這些背後其實都在做同一件事情：
不要讓所有資訊、所有工作、所有歷史，同時擠在 AI 的 Context 裡。
研究到最後，我真正想優化的是什麼？
回頭看這段學習過程，我覺得最好玩的是，我問的問題其實一路在變。
從哪個 Model 最省錢？到 怎麼省 Token？後來是怎麼管理 Context？
到現在，我開始去思考 怎麼替 AI 設計一個好的工作環境？
因為 AI 並不是知道越多，就一定做得越好。
這點和跟人很像啊，如果今天桌上同時攤著 30 份文件、10 個待辦事項、昨天做到一半的工作，旁邊還擺著 58 個工具叫你自己挑……應該也很難專心。😂
真正需要管理的，不只是 Token，而是 AI 的注意力。
好的 Context Engineering，某種程度上就是在做這件事情：
讓對的資訊，在對的時間，出現在 AI 面前。
至於到底怎麼做？
下一篇再找時間整理、分享這陣子自己的實驗結果和實際調整，包括怎麼把 Persist / Retrieve / Compress / Isolate 用進 Claude Code，以及我在 CLAUDE.md、Memory、/compact、/fork、Subagent、Script 上做了哪些嘗試，還有這段時間慢慢調整出來的 Coding Workflow。
很多都還在持續實驗中，但也因為真的動手改過一輪，開始有一些蠻有趣的心得可以分享。
喜歡此篇文章的朋友，歡迎轉貼與留言。轉貼時請保持原內容與註明原文標題、連結以及作者即可，謝謝您。
沒有留言:
張貼留言