最近看幾個模型供應商的新功能說明，我注意到一個方向越來越明顯：大家不只在比模型多聰明、多會寫程式，也開始把 prompt caching、長推理、subagent 協作和成本模型講得更細。這些字看起來像平台規格表上的小項目，但從技術主管的角度，我覺得它們其實在提醒我們一件事：AI Agent 的成本治理，已經不能停留在「這次呼叫花了多少 token」。
很多團隊剛開始導入 AI 時，成本觀念很直覺：輸入越短越便宜、模型越小越便宜、能省就省。這在聊天或單次摘要場景還算夠用，因為任務邊界清楚，算完就結束。但 Agent 不一樣。Agent 會讀文件、查工具、跑測試、修正錯誤、再查一次，甚至把任務拆給子流程處理。這時候成本不再是一筆 API 帳單，而是整個工作流的形狀。
Prompt cache 在這裡就變得很有意思。表面上，它是把重複的上下文快取起來，避免每次都重新付費、重新處理。可是如果只把它當作省錢技巧，很容易低估它的架構意義。真正值得思考的是：哪些上下文應該穩定？哪些內容可以被任務覆蓋？哪些規則一旦變更，就應該讓 cache 失效？哪些資訊不該被長期放進共享上下文？
換句話說，prompt cache 不是單純的效能層，它開始像 Agent 的工作記憶設計。
人類團隊也有類似問題。一個資深工程師不會每次接任務都重新學公司規則，他腦中會保留一組穩定脈絡：系統架構、命名慣例、禁止踩的坑、部署流程、誰負責哪塊。但他也知道哪些資訊是這次任務特有的，不能混進長期判斷裡。Agent 如果沒有這種分層，長上下文只會變成一大包越塞越重、越來越難驗證的文字垃圾。
所以我會把 Agent 上下文分成幾層看。第一層是穩定規則，例如產品原則、權限邊界、程式碼風格、測試要求。這些適合被快取，因為它們反覆出現，而且變更應該可審查。第二層是任務上下文，例如這次 issue、相關檔案、錯誤訊息。它應該跟著任務生命週期走，任務結束就不要無限制殘留。第三層是暫態推理，例如某次嘗試的假設、失敗的路徑、工具輸出片段。這一層很有用，但最容易污染後續判斷，需要摘要、壓縮或丟棄。
如果供應商把 cache 命中率、長推理選項、子代理模式都變成明確的計價與能力邊界，產品團隊就不能再把 prompt 當作一串臨時文字。它比較像一份會影響成本、品質和安全的執行計畫。你放進去的每一段穩定上下文，都可能被反覆使用；你沒有切開的每一段私人資料，也可能被帶到不該出現的工作流裡。
Subagent 也是同一件事。把任務拆給多個 Agent，不只是「讓 AI 多開幾個工人」。如果沒有清楚的上下文邊界，它很快會變成多個昂貴的流程各自重讀同一堆資料、各自做重複推理、各自產生看似合理但彼此衝突的結論。好的 subagent 設計應該像分工，而不是分身。每個子任務要知道自己需要哪些上下文、能用哪些工具、輸出什麼格式、什麼情況要停下來交回主流程。
這也是為什麼我不太喜歡只用「token 用量」看 AI 成本。Token 是結果，不是原因。真正要管理的是上下文結構、工具呼叫次數、重試策略、cache 失效率、任務切分方式，以及人在什麼節點介入。只盯著 token，就像只看雲端帳單總額，卻不看哪個服務沒有 autoscaling、哪個排程在半夜重跑十次、哪個 log 永遠不清。
對企業系統來說，這件事還牽涉治理。穩定上下文裡通常會有流程規則、權限限制、資料定義與操作禁區；這些內容如果可以被快取，就應該被版本化、可回溯、可測試。不能今天 prompt 裡寫一套，明天某個 agent workflow 偷改一套，最後出了問題只剩「模型當時好像誤解」。當 Agent 開始真的執行任務，prompt 就不只是提示詞，而是半個 runtime 設定檔。
我現在會用幾個問題檢查一個 Agent 工作流是否成熟：穩定上下文有沒有集中管理？任務上下文有沒有生命週期？cache 失效規則清不清楚？子代理拿到的是最小必要資訊，還是整包丟過去？成本異常時能不能追到是哪一段上下文、哪一個工具或哪一次重試造成？如果答案都很模糊，那就算模型再強，也只是把不確定性包進更長的上下文裡。
AI 成本治理下一階段，重點不會只是找到更便宜的模型，而是把「記住什麼、重用什麼、忘掉什麼、交給誰做」設計清楚。Prompt cache 只是入口，它背後真正的題目是：當 Agent 變成日常工作流程的一部分，我們有沒有把它的工作記憶當成架構來管理，而不是把它當成一段每次臨時拼起來的文字。