我常在 AI 開發社群裡面潛水，常看到這個萬年問題：怎麼樣才能少花一點 token？通常的解法就是用一些工具來避免 AI 產生不需要的工作，或是用快取的方式來減少請求，我自己也有用 Headroom 這一套來處理這問題，但老實說可能是因為我的用量不大，我無法感受到差異，
但在我看完一場 Github 的研討會之後有全新的視野：真正該做的不是少用 token，而是把 agent 品質做好，token 自然就會省下來，至於品質要怎麼做好，核心技能就是上下文工程（context engineering）。
這篇是我整理聽完這場線上研討會的心得。雖然講的是 Github Copilot 的計費改制，但底下的觀念其實跟工具無關，不管你用的是 Claude Code、Cursor 還是哪一個 agent，都適用。
為什麼省 token 的出發點錯了
想像 NASA 要登陸月球，如果射火箭非常便宜，那最省事的做法是什麼？一次射 20 枚，中一枚就算成功，沒中下個月再射 20 枚。聽起來很蠢，但這就是現在大多數人用 agent 的方式——token 以前很便宜，所以上下文隨便給、prompt 不太花心思，agent 直接派出去，成功就好、失敗就再來一個。
一天用兩三個 agent 的時候，這樣燒沒問題，但現在的趨勢是一個開發者一天可能派出十幾個、上百個 agent，每個還跑得越來越遠，這種燒法一下燒完了。
那正解是什麼？把每一枚射出去的火箭打得更準。換句話說，在 agent 派出去之前先把品質拉上來，命中率自然就高了。這裡有個很簡單的 ROI 角度可以看清楚：如果一個 agent 的產出價值是零，你再怎麼省它的成本都是白搭。價值雖然不好算，但並不代表這個邏輯不成立。
一個 99% 的小誤差，跑 50 步剩多少
真正讓我把「品質」當一回事的，是誤差累積這件事。
大模型本身沒有確定性，同樣的輸入跑兩次結果可能不一樣，所以它天生就帶誤差，永遠不會百分之百準確。問題在於 agent 是多步驟工作，每一步的小誤差會一路疊上去。
假設每一步的準確率是 99%，已經很樂觀了，但 50 步之後整體正確率只剩大約 61%。如果每一步準確率掉到 95%，50 步之後就剩 8%。
數字攤開來看很嚇人。這不是說每個 agent 都會失敗，而是只要把單步準確率往上拉一點點，整條鏈的成功率就會大幅改善。再加上失敗的代價——每個跑壞的 agent 都浪費了 token，你還要花時間修 bug、重新 review、再跑一次，更慘的是低品質的輸出可能直接引發線上事故。
這其實就是傳統軟體開發講的 shift left，把品質、測試、安全儘量往前挪。同樣的思路，放到 agent 系統裡一樣成立。
上下文要剛剛好，不是越多越好
要理解為什麼品質這麼吃上下文，得先回到 LLM 的本質：它就是一台文字機率機，你的輸入加上它學過的資料，它預測下一個最可能出現的字，一個接一個拼出完整的回答，寫程式也是同樣原理，只是預測的是下一行程式碼。
把這個原理對應到品質，核心只有一句話：上下文要剛剛好。
給太多，不相關的資訊會把模型帶偏，因為 LLM 自己分不清哪些相關、哪些不相關，全部丟進去一起算機率，給的雜訊越多，算對的機率就越低。給太少更糟，缺了關鍵資訊，模型會自己編內容來補空缺，而你很多時候根本看不出來它在缺資訊——這時候幻覺跟事實看起來沒什麼兩樣。
這裡還有一個容易被忽略的點：agent 跟 LLM 的對話是沒有狀態的。LLM 不會幫你存對話，所以 agent 每跟它聊一輪，都是把之前所有的輸入和輸出整包再送一次。也就是說，token 跟上下文是一直往上堆的，時間拉長會滾得越來越大。一個小模型的上下文上限大概五萬到二十萬 token，大模型可以衝到一百萬——差不多是一整部《紅樓夢》的份量。
上下文視窗的兩個陷阱
知道上下文會一直堆，就要認識兩個常見的失準狀況。這兩個不是絕對會發生，但放在心裡當判斷的參考點很有用。
第一個是「迷失在中間」（lost in the middle）。 通常發生在 token 用量低於 50% 的時候，模型天然更關注上下文的開頭和結尾，中間那段容易被忽略。大多數情況沒問題，因為開頭放的是你的指令目標、結尾是當前在做的事，本來就該被優先重視，但在切換任務的時候會出事——你本來叫 agent 修 bug，聊著聊著說「我們換個新功能吧」，視窗越滾越大，模型可能又跑回去繼續修 bug，因為它把最開頭那句話看得比你最新的指令還重。解法很簡單：每個獨立任務就開一個新的上下文視窗。
第二個是「記憶衰退」。 發生在用量超過 50% 之後，模型開始只盯著對話結尾看，系統指令、自訂指令、你一開始的 prompt 都慢慢被忘掉，於是它開始飄移，做一些你摸不著頭緒的事。解法是儘量不讓上下文超過 60%，把任務拆細、中途適時開新對話。
五個真正能上手的做法
原理講完，剩下的是實際可以動手調的地方。先說一個前提：你的規模決定值不值得。如果你一天只派十個 agent、一個月花 50 美元，這些最佳化幫你省一半也才省 20 美元，不一定值得折騰。但如果你是一天排程上百個 agent 的人，每省 1%、每提升 1% 品質都會被放大，非常值得投入。
第一，選對模型。 最常見的浪費，是不管做什麼都預設開最強的那顆模型，連修個錯字都用旗艦模型。不同模型的價差可能到二十幾倍，而且更貴不一定更好。規劃、架構設計、處理複雜 bug 的時候適合用推理模型；規劃做完、進入一行一行實作的階段，反而適合用一般模型——因為推理模型可能會回頭質疑你的計畫、自己 free style 重寫，執行階段你不需要它這樣。預設用自動選模型，真的有需要再手動挑。
第二，只給相關的上下文。 不要把可能用到的資訊全部塞進 prompt，讓 agent 自己去找它需要的；也不要為了一個小改動就把整個專案丟給它。這就是上下文工程的核心，後面的技巧本質上都是它在不同場景的應用。
第三，prompt 要精確，而且分階段。 不要說「修一下這個 bug」，要寫清楚在哪個 issue、什麼場景下會出現、修好後先跑測試、測試過了就停——這樣可以防止 agent 自作主張去做沒必要的事。你已經知道的資訊就直接給它，別讓它自己翻檔案，那很燒 token。工作流程則拆成研究、規劃、實作三段，每一階段用不同的上下文，不相關的東西就不會一路被拖著走。
第四，用測試當護欄。 這一條嚴格說不算上下文最佳化，就是寫測試。有測試的話，讓 agent 在交出結果前先用測試驗證自己。分享裡提到一個數字讓我印象很深：某個內部團隊一週有 500 個 PR，他們程式碼庫裡有 53% 是測試程式碼。測試是一種確定性控制，要嘛過、要嘛不過，沒有模糊地帶。
一個 agent 跑了十步準確率已經掉一半的時候，測試可以及早把它拉回軌道，而不是等它跑到最後才發現結果是錯的。這也是為什麼我一直強調要幫 AI 開發的程式補上自動化測試。
第五，把 agent 指令寫得精簡，而且自己寫。 那份每次對話都會被塞進上下文的指令檔，寫得好不好直接影響每個 agent 的起跑點。它不是給人看的知識庫，是給 agent 的行動規則，所以要精簡——字越多每次越貴。最有感的是用它來控制輸出，因為輸出 token 是最貴的。光是寫一句「輸出保持簡潔」，就可能把原本 50 行的回覆壓到 5 到 10 行。還有，別用 AI 生成這份指令，要自己寫，因為你寫的是基於你真正觀察到 agent 犯過的錯，而不是憑空想像。
配置之外，更值得長期投資的事
上面五個之外，agent 還有不少配置可以調：自訂 agent、Skills、MCP、subagent。簡單區分一下——自訂 agent 是你手動調出來、固定某種工作方式的角色；Skills 是你提供給 agent 的能力，需要時才被塞進上下文；MCP 則是讓 agent 能呼叫外部 API，像讀 GitHub issue、抓 Figma 設計。但 MCP 不要全部一直開著，沒用到的會白白佔上下文、燒 token，最好放進特定的自訂 agent 裡，用完關掉。
不過講到最後，我自己最認同的是這段：在 agent 時代，最值得長期投資的不是寫程式本身，而是三件事。一是分析能力——快速摸清業務、搞懂客戶真正要什麼、翻譯成可實作的技術方案，這是 agent 做不到的，它會執行但不會做戰略。二是架構，好的架構能減少 agent 失誤、告訴它程式該放哪、維持整體品質。三是把配置 agent 當成一份持續的工程工作，用工程師的思維去帶它。
這也呼應我一直在做的事——把跟 AI 協作的流程當成一套會持續迭代的工作流，而不是一次性的 prompt。
回到最開始那個問題
所以省 token 到底該怎麼做？我的結論是：別把出發點放在省錢。
減少 token 當然要做，但它應該是「追求品質」的副產品，而不是目標本身。真正要做的是少派一點 agent、但讓每一個 agent 的正確率都更高。把模型選對、上下文給準、分階段規劃、測試當護欄、指令寫精簡這五件事疊在一起，agent 品質上去了，token 消耗自然就降下來了。
說到底，這就是上下文工程——重點是替 agent 設計好它需要的工作環境，而不是把它當成隨口聊天的對象。把這件事做好，省錢只是順帶的結果。