🎯 什麼情境該想到我
當你的 agent 已經能用，但量一放大帳單就撐不住；你想省錢，又不想靠「換小模型」把品質換掉的時候。
⚙️ 怎麼用（步驟 / 公式）
0. 先量，再省：兩個數字一起看
- 先在強模型上做出能用的版本，再談省錢。做不出「一個」能用的 agent，就做不出便宜的。
- 建一個小 eval：幾個有標準答案的代表任務就夠。notebook 用 10 筆保險理賠、人工標好的判決。
- 每個設定都記兩個數：通過率、每任務成本（把每次回應的
usage加總後換算成美元）。 - 看「每任務」不看「每 token」：單價高的模型如果少走幾輪，整體可能更便宜。
- 品質門檻當限制，成本當要最小化的目標。 notebook 的門檻是 10/10。
成本換算（notebook 的 usage_cost）：
成本 = 一般輸入×P_in + 5分鐘快取寫入×1.25P_in + 1小時快取寫入×2P_in
+ 快取讀取×0.1P_in + 輸出×P_out （Batch 再 ×0.5）
倍率對官方價目查證 2026-11-02：寫入 1.25×／2×、讀取 0.1× 正確。但 Opus 5.5、Sonnet 5.5 的讀取是 0.05×，Fable 5.1、Mythos 5.1 是 0.025×。換新模型時要改這個常數。
1. Pareto 前緣：怎麼挑出「值得的」設定
- 每個設定跑多次，取平均通過率和平均每任務成本。
- 依成本由低到高排序，只保留「比所有更便宜的設定都更準」的點，這些點連成前緣。
- 不在前緣上的設定就是「比較貴，卻沒有比較準」，直接淘汰。
- 判斷一個新手法有沒有用，只看一件事：它有沒有把前緣往左推（同樣準確，但更便宜）。
- 同一設定兩次結果可能不同（Sonnet low 一次 9/10、一次 8/10）。上線前，notebook 建議約 50 個案例、每設定至少 5 次。
2. 清單（建議照這個順序檢查）
以下數字都是 notebook 的單次實驗結果：模型 Opus 5、Sonnet 5、Haiku 4.5，任務是假想保險公司的理賠 agent，固定前綴約 13K token（system prompt 內嵌一份約 11–12K token 的核保手冊，加上 12 個工具）。你的數字一定不同。
| # | 手法 | 做法 | notebook 單獨示範省多少 |
|---|---|---|---|
| 1 | 提示快取 | 頂層 cache_control 自動快取；不同對話共用前綴時，在 system 尾端加顯式斷點；兩次呼叫間隔超過 5 分鐘就用 1 小時 TTL | 2 次追問 −32%；時間戳移出 system −44%；穩定內容放前面 −54% |
| 2 | 輸入瘦身 | 少用的參考資料改成工具按需讀取；刪掉 system 裡重述工具清單的段落；工具多時用 tool search（defer_loading）；圖片先縮圖；大表格用 Files API ＋ code execution | 前綴 13,462 → 2,517 → 2,125 → 1,696 token；圖片 4,088 → 928 token；CSV 135K token 直接貼入 → 改跑程式 −79% |
| 3 | agent 迴圈控制 | 伺服器端的 context editing、compaction；用戶端在自然邊界一次修剪（jagged compaction）；自成一塊的子任務丟給 subagent | 3 筆理賠排隊、中間塞一份 135K 的帳本：−12%／−16%／−29%／−78% |
| 4 | 輸出控制 | 在 prompt 寫死輸出格式並附範例；max_tokens 只當防暴走的上限；無法處理時讓模型輸出哨兵字串，並設成 stop sequence | 備忘錄 4,096 → 61 output token，−63%；壞輸入 −56% |
| 5 | Batch API | 不急的工作送非同步佇列，24 小時內完成 | 同樣 token，−50% |
| 6 | effort 與模型 | 先降 effort，還能過門檻就降一級模型，effort 重設為 high 再往下掃 | 見下表 |
為什麼「換模型」排最後：前面幾項只改變「同樣的 token 付多少錢」或「送了哪些 token」，模型能力不變；換模型是直接拿能力換錢。
3. 掃模型與 effort（notebook 的 10 筆 eval，各跑 2 次）
| 設定 | 通過 | 每任務成本 |
|---|---|---|
| Opus high，無快取（基準） | 10/10 | $0.2906 |
| Opus high＋自動快取 | 10/10 ×2 | ~$0.150（−48%） |
| Opus low＋快取 | 10/10 ×2 | ~$0.121 |
| Sonnet medium＋快取 | 10/10 ×2 | ~$0.050 |
| Sonnet low＋快取 | 9/10、8/10 | ~$0.050 |
| Haiku＋快取 | 7/10、4/10 | ~$0.019 |
再把各手法逐一疊到 Sonnet medium 上：
| 疊加 | 通過 | 每任務成本 | 結果 |
|---|---|---|---|
| ＋system 顯式斷點 | 10/10 ×2 | ~$0.0225 | 唯一推動前緣的手法：比基準便宜約 13 倍 |
| ＋手冊改成工具讀取 | 9/10 ×2 | ~$0.021 | 省錢，但掉準確 |
| ＋tool search | 8/10、9/10 | ~$0.054 | 反而更貴 |
| ＋code execution | 10/10 ×2 | ~$0.0585 | 反而更貴 |
| ＋context editing／compaction | 10/10；10/10、9/10 | ~$0.050 | 沒效果（觸發門檻沒被碰到） |
| Haiku 子代理收集事實＋Sonnet 判決 | 9/10 ×2 | ~$0.019 | 最便宜，但差一題 |
| 改成一次性 Batch | 9/10 ×2 | 0.019 | 差一題，而且批次內快取命中不穩 |
顯式斷點為什麼有效：自動快取只在同一段對話內攤提前綴。每筆新理賠是新對話，第一輪都要重寫一次手冊；在 system 後面加一個斷點，之後每筆理賠都能直接讀快取。
快取何時回本可以自己算：同一前綴 P 被用 n 次，不快取付 nP，快取付 1.25P＋(n−1)×0.1P。n=2 時是 1.35P 對 2P，省 32.5%，與 notebook 實測的 32% 吻合。
🧪 我實際套用的紀錄
- 2026-11-02：（待填）
⚠️ 注意 / 什麼時候不適用
- 手冊改成工具讀取：模型只看得到它想到要查的段落，邊界案例會漏規則。整份文件大多數呼叫都會讀到時，留在快取裡反而便宜。
- tool search：工具 schema 要到約 10K token 以上才划算。notebook 只有幾百 token，搜尋這一步純粹是額外開銷。
- code execution：任務裡沒有數值運算就別加。另外它會額外收沙箱時間費。
- context editing、compaction、修剪：只對會長到很長的迴圈有用。每次編輯都會讓「編輯點之後」的快取失效，所以要讓它少發生。compaction 的預設觸發點是 150K、下限 50K。在有 preserved thinking 檢查的模型上，用戶端改寫早期回合，會讓後面的 thinking block 失效。
- subagent／拆解：子代理從零開始建前綴，不能共用父代理的快取。把手冊壓縮成規則卡會丟掉例外條款，notebook 就因此誤拒一筆該核准的理賠（被拒駕駛其實是同住的兒子）。
- advisor 工具（便宜模型當主力、Opus 待命）：要有便宜又明確的訊號（金額門檻、風險分數區間）決定何時諮詢才有用。叫弱模型自己判斷「這題難不難」，需要的正是它缺的判斷力。
- Batch：有人在等回應，或下一步要看上一步結果才知道要抓什麼，就不能攤平成單次請求。24 小時是「到期時間」，不是服務保證。
- effort 是渲染進 prompt 的：對話中途改 effort、換模型，快取都會失效。
- 和 服務棧選型與降本 的排序不同：那張卡（自架服務的角度）把模型路由排第 2，視為最大的一筆。這份 notebook 也證實換模型的跌幅最大（Opus→Sonnet 約 −67%），但仍排最後，因為它是唯一直接犧牲能力的手段。推論：兩者不矛盾。先拿走不傷品質的錢，再用 eval 決定能力能讓多少。
- 所有價格都是快照（查證 2026-11-02），新模型上市後，倍率和最小可快取長度都會變。
🔗 相關工具
- 工具-AI改動的AB對照評測 —— 為什麼一定要多跑幾次：雜訊底線要先量
- 工具-AI系統評估 —— 怎麼建這份 eval（本卡假設 eval 已經有了）
- 前綴快取 Prompt Caching —— 第 1 項的機制、失效條件與最小長度
- 服務棧選型與降本 —— 自架服務的降本槓桿，與本卡的 API 角度互補
- 工具-長對話的Token預算分配 —— 迴圈控制的另一面：上下文要怎麼分配