關於 Token 用量的建議，多半都在最佳化問題的另一端。你輸入的提示詞很少是開銷 的大宗。真正消耗 Token 的，是 Agent 代你讀進去的一切：檔案內容、命令輸出、 測試紀錄，以及不斷增長的歷史對話。

以下方法依實際節省成效排列，而非依技巧的巧妙程度。

每個檔案少讀一點

為了改一個函式而開啟 2000 行的檔案，Agent 大部分的預算都花在永遠用不到的 脈絡上。先搜尋，再只開啟需要的那一段。

這種節省會累積，因為 Agent 讀過的每個檔案都會留在之後的對話紀錄中。讀一次的 檔案只付一次費；但在第三輪讀進來的檔案，到第二十輪仍在被反覆攜帶。

讓輸出在進入模型前先經過過濾

建置紀錄、測試執行器與套件管理員的輸出，是寫給盯著終端機的人看的，不是寫給 按 Token 計費的模型看的。一次失敗的測試很容易產生數千 Token 的呼叫堆疊，而其中 真正有用的也許只有四十個 Token。

把雜訊多的命令接上過濾：

pytest -q 2>&1 | tail -30
npm run build 2>&1 | grep -E "error|warning" | head -20

這一步並不起眼，卻通常是能取得的最大單項節省。

控制任務範圍

長對話的單輪成本高於短對話，因為每一輪都會把整份紀錄重新送出。兩次專注的 工作階段比一次涵蓋同樣內容的冗長階段更省錢，效果通常也更好，因為模型不必再 權衡二十輪不相干的歷史。

當任務方向出現較大轉變時，重開一個工作階段既是品質決策，也是成本決策。

不要貼上 Agent 自己讀得到的內容

把檔案貼進提示詞等於重複計費：一次在你的訊息裡，另一次在 Agent 開啟該檔案 進行編輯時。直接給出路徑即可。

哪些做法成效有限

壓縮自己的提示詞基本上是做樣子。精心壓縮過的指令大約能省五十個 Token；而一次 多餘的檔案讀取要花掉兩千。把指令寫清楚，然後把注意力放在 Agent 讀了什麼， 而不是你寫了什麼。

對多數使用者而言，壓縮系統提示詞或工具定義同樣成效有限，而且是拿可靠性去換 一個與吵雜測試輸出相比可以忽略不計的節省。