更充分發揮 Claude Platform 的效益（第 2/2 段）

🧑‍🏫 這是 Claude 官方講座的後半段，講怎麼讓 agent（能自己規劃、連續執行任務的 AI）長時間工作，又不會花太多錢。context 指模型當下能記住、參考的所有內容，放得越多，就越貴、越慢。講者用一個實際案例示範：先做快取，再精簡餵給模型的資訊，最後讓便宜模型去請教貴模型，把成本壓下來，判斷品質也沒有掉。

• 13:24 現在的 agent 可自主工作數小時，終究會碰到百萬 context 上限；compaction 讓對話在 context 滿了之後能繼續，不會被迫中斷
  ↳ 現在的 agent 可以自己連續做事好幾個小時，但記憶容量總有滿的一天。compaction（壓縮）就是在容量滿了之後先整理、再接著做，工作不會因此中斷。
• 13:24 compaction 的運作：依你的 prompt 摘要 context、降到較低的 context 量、移除已不相關的回合，然後繼續對話，並反覆這個過程
  ↳ 做法有點像整理會議紀錄：照你給的 prompt（給 AI 的指示）寫摘要，把已經用不到的來回對話刪掉，空出位置繼續做；下次又滿了，就再整理一次。
• 13:54 compaction 讓人有種 context 幾乎無限的感覺，也能讓模型維持在正軌上
  ↳ 因為會一直自動整理，用起來就像記憶用不完。摘要會留下關鍵資訊，所以模型比較不會做到後來忘了原本的目標而跑偏。
• 13:54 案例：Hex 使用 compaction 後簡化了程式碼，模型也能持續表現良好
  ↳ Hex 這家公司導入以後，不用再自己寫一大堆管理記憶的程式，程式碼變簡單了，模型在長時間的任務裡表現也沒有變差。
• 14:24 Demo：左側 context window 長條上升得慢很多，因為每個回合放進的 context 變少了
  ↳ Demo 左邊的 context window（顯示記憶空間用掉多少的長條）爬得慢很多，因為每一輪只放進真正需要的東西。
• 14:24 Demo：context 到約 400k 時掉回來，原因是設定了 400k 門檻並觸發 compaction 壓縮
  ↳ 長條到 40 萬左右突然掉下來，不是故障。他們設定到 40 萬就觸發 compaction，整理完空間就空出來了。
• 14:55 tool search 範例：要取得 hero retention metrics，模型先詢問哪些工具能幫上忙，找到 hero retention metrics 工具
  ↳ tool search（工具搜尋）：模型不會一開始就把所有工具的說明都讀進來，而是先問「哪個工具幫得上忙」，找到查 hero retention metrics 的那個工具，才只載入它。
• 14:55 工具 schema 很大：一個 14,000 tokens、hero list 6,100、下一個 9,300；講者說這對很多 agent 來說很正常
  ↳ schema（工具的說明書，教模型這個工具怎麼用）很佔空間：一份就要 14,000 個 token（AI 計算文字量的單位），其他幾份也有 6,100、9,300。講者說很多 agent 都是這樣。
• 15:26 用不到的工具沒有放進 context，佔用的空間就少很多；transcript 裡只出現需要的那個工具的定義，其他工具都沒有
  ↳ 只放用得到的說明書，其他的不帶，空間就省下很多。從 transcript（完整的對話紀錄）也看得到，裡面只有那一個工具的定義。
• 15:56 Gong 是一種記錄業務團隊對話的工具，可以分析資料，了解第一線對新產品的反應
  ↳ Gong 是一種把業務和客戶的通話錄下來並做分析的工具，公司可以從中看出第一線客戶對新產品的反應。
• 16:27 通話常長達 30 分鐘甚至 60 分鐘，做 dashboard 不需要全部內容，只需要整體情緒
  ↳ 一通電話常常長達半小時到一小時，但做 dashboard（彙整數據的儀表板）只需要知道客戶整體是正面還是負面，不需要讀完整份逐字稿。
• 16:27 programmatic tool calling：模型寫了一段小 script，先看前 2,500 個 tokens／字元來理解資料結構
  ↳ programmatic tool calling（用程式呼叫工具）：模型不直接讀全部資料，而是先寫一段小程式（script），看開頭大約 2,500 個字，搞懂資料長什麼樣子。
• 16:57 script 接著逐一處理各通通話、取得整體情緒後串流到 dashboard；原本龐大的結果只留下真正需要的部分，讓 context 保持精簡
  ↳ 接著讓程式一通一通處理，算出整體情緒，再把結果送到儀表板。就像請助理讀完一疊報告、只回報結論，模型的記憶就不會被塞爆。
• 16:57 這場的重點不是炫目的 demo，而是真正上線：context 必須符合產品成功實際需要的內容
  ↳ 講者強調，這場的重點是真正能上線的產品，不是好看的展示。放進模型的資訊，應該剛好是產品成功真正需要的，不多也不少。
• 17:27 compaction 門檻選了 400K；講者喜歡百萬 context，但依你的情境，智慧、成本、延遲的最佳組合可能不是一百萬
  ↳ 他們把壓縮門檻設在 40 萬。上限雖然有 100 萬，但放越多就越貴、越慢，不一定比較聰明，要依自己的情況找平衡點。
• 17:57 門檻建議：可以從 500K 開始，400K 常是不錯的起點，但會因模型而異
  ↳ 門檻可以從 50 萬開始試，40 萬通常是不錯的起點；不過每個模型適合的數字不一樣，要自己實際測過。
• 17:57 設定門檻後會產生摘要，你可以寫自己的 prompt 來引導；摘要整理關鍵事實，讓對話不偏離、也不丟掉該留的 context
  ↳ 觸發壓縮時會產生一份摘要。你可以自己寫 prompt，指定一定要留下哪些重點（例如客戶名稱、已經做好的決定），避免重要資訊被整理掉。
• 18:27 做完 context engineering 後，每次載入成本降到約 11 英鎊，比先前少了大約三分之一
  ↳ 做完 context engineering（精簡餵給模型的資訊）之後，每次執行的成本降到大約 11 英鎊，比之前少了約三分之一。
• 18:57 業務毛利很薄，11 英鎊仍偏高；目前用 Opus 4.7，智慧高但成本也高，想改用 Sonnet 和 Haiku 並接近 Opus 的智慧
  ↳ 但這門生意利潤很薄，11 英鎊還是太貴。他們現在用的是 Opus 4.7（Claude 最強、也最貴的等級），想改用比較便宜的 Sonnet 和 Haiku，又希望聰明程度不要掉太多。
• 19:27 Advisor Strategy：agent 由 Sonnet 或 Haiku 擔任 executor，大多數情況自己處理，遇到奇怪的特殊狀況才呼叫 advisor 請教做法
  ↳ Advisor Strategy（顧問策略）：讓便宜的 Sonnet 或 Haiku 當 executor（實際動手做事的模型），平常自己處理，遇到奇怪的特殊狀況才去請教顧問 Opus。
• 19:57 類比：資深工程師帶資淺工程師，資淺工程師仍親手做事，但靠指導、code review、架構建議，產出可能接近資深工程師獨自完成的水準
  ↳ 就像資深工程師帶新人：新人自己動手寫，資深的負責指方向、做 code review（檢查別人寫的程式碼），最後成果可能接近資深工程師自己做的水準。
• 20:28 同樣邏輯也適用於模型：搭配 advisor 後，用 Sonnet／Haiku 的價格，有時能接近 Opus 的智慧
  ↳ 模型也是一樣：Sonnet 或 Haiku 負責做事，Opus 在旁邊指點。付的大多是便宜模型的價錢，有時候卻能拿到接近 Opus 的品質。
• 20:28 案例：Bolt 使用後架構決策變好，複雜任務的表現提升；簡單任務不會呼叫 advisor，因此沒有額外開銷
  ↳ Bolt 這家公司用了之後，架構這類大方向的決策變好了，難的任務表現也提升；簡單的任務根本不會去問顧問，所以不會多花錢。
• 20:58 講者形容這是改善成本與智慧表現的 Pareto optimal（帕雷托最適）做法
  ↳ Pareto optimal（帕雷托最適）指的是：已經找不到其他做法能更省、又同時更聰明。講者用它來形容顧問策略在成本和聰明度之間的取捨很划算。
• 21:28 Demo 改用 Sonnet 4.6 搭配 Opus 4.7 Advisor；成本變低是理所當然，真正的問題是智慧會不會因此下降
  ↳ Demo 改成由 Sonnet 4.6 做事、Opus 4.7 當顧問。變便宜是一定的，真正要看的是：這樣會不會變笨？
• 22:01 案例：關鍵客戶 Metropolis 的續約；Sonnet 看過通話紀錄後判斷續約進展順利，但因事關重大而去問 Opus
  ↳ 例子是重要客戶 Metropolis 的續約。Sonnet 看完通話紀錄，判斷一切順利；但因為這個案子很關鍵，它還是去問了 Opus。
• 22:31 advisor tool 的一種用法：把 transcript 交給它檢查，它會回報可能漏掉的地方，或確認沒問題
  ↳ advisor tool（呼叫顧問的功能）有一種用法：把整份紀錄交給顧問檢查，它會指出可能漏看的地方，或確認沒有問題。
• 22:31 Opus 看得更深入，發現市長指定要 CryoThane，但他活動當天沒空，續約其實會失敗，應該是紅燈
  ↳ Opus 讀得更仔細，發現市長指定要 CryoThane，但他活動當天沒空。所以續約其實會失敗，應該亮紅燈，不是綠燈。
• 23:02 這是「watermelon」狀況（外綠內紅）；Opus 推翻了 Sonnet 的判斷，把問題抓出來，智慧因此補了回來
  ↳ 這就是「watermelon（西瓜）」狀況：外皮是綠的，裡面卻是紅的，看起來順利、其實有問題。Opus 推翻了 Sonnet 的判斷，便宜模型不足的判斷力就補回來了。
• 23:32 回顧：一開始成本是現在的十倍以上；先查 prompt cache 命中率（原本是零），再實作 prompt caching
  ↳ 回頭看，一開始的成本是現在的十倍以上。他們先查 prompt cache 命中率（重複的內容有多少被重複使用），結果是零，於是先做了 prompt caching（把重複內容暫存起來重用，比較省錢）。
• 23:32 講者說 Claude Code 裡的 Claude API skill 可以幫你處理很多 prompt caching 的邏輯（字幕轉錄寫作 Cloud API skill、Cloud Code）
  ↳ 講者說，Claude Code（Anthropic 出的寫程式助手）裡有個 Claude API skill（內建的技能包），可以幫你處理很多 prompt caching 的設定細節。
• 23:32 context engineering 第一步：減少傳給模型的工具
  ↳ context engineering 的第一步：不要把所有工具都塞給模型，只給這次用得到的，也就是前面 tool search 的做法。
• 24:03 context engineering 第二步是篩選工具結果中要回傳給模型的資料，第三步是用 compaction 做出近乎無限的 context
  ↳ 第二步：工具跑出來的結果先篩過，只把需要的部分回傳給模型，像前面的情緒分析；第三步：用 compaction 讓對話可以一直延續下去。
• 24:03 最後用 advisor tool 進一步降低成本，同時保留智慧
  ↳ 最後再加上顧問策略，讓便宜模型做事、Opus 把關，成本又降了一層，聰明程度也保得住。
• 24:33 重點一：就算其他都不做，也要做 prompt caching；先查出你的 prompt cache 命中率再實作
  ↳ 重點一：就算其他都不做，也一定要做 prompt caching。先查出自己的命中率，知道現況之後再動手。
• 25:03 重點二：context engineering，篩選送給模型的工具與工具結果，並在對話變長時做 compaction
  ↳ 重點二：做 context engineering，只給模型需要的工具、只回傳需要的結果；對話變長了，就用 compaction 整理。
• 25:03 重點三：advisor strategy，很多情況下是取得更好成本與智慧的 Pareto optimal 做法
  ↳ 重點三：顧問策略。在很多情況下，這是兼顧省錢和聰明最划算的做法。
• 25:03 講者說提到的部分功能是過去 24 小時內才推出的，平台演進很快
  ↳ 講者提到，有些功能是這場演講前 24 小時內才剛推出的，可見平台更新得非常快。
• 25:34 講者表示會持續幫助開發者打造真正上線的 agent，不只是 demo；投影片上只列了 2026 年已推出功能的一部分
  ↳ 講者說他們會繼續幫開發者做出真正能上線的 agent，而不只是展示用的 demo；投影片上列的，也只是 2026 年已推出功能的一部分。
• 26:06 講者特別推薦 automatic prompt caching：沒做過 prompt caching 的話，一行就能啟用
  ↳ 講者特別推薦 automatic prompt caching（自動快取）：如果還沒做過 prompt caching，加一行設定就能開啟。
• 26:06 講者也提到平台可在 AWS 上使用，這段談到的整個平台都在上面（字幕寫作 cloud platform on AWS）
  ↳ 講者也提到，整個 Claude 平台，包括這段講到的功能，都可以在 AWS（亞馬遜的雲端服務）上使用。

講者建議 compaction 門檻怎麼設定？