更充分運用 Claude Platform（第 2/2 段）

🧑‍🏫 這是 Claude 官方影片的後半段，主題是怎麼讓 agent（會自己連續做很多步驟的 AI）更省錢、也更聰明。影片先示範三種控制 AI 讀取內容的方法，再介紹一種做法：讓便宜的模型做事，遇到難題才請貴的模型幫忙判斷。就算你不寫程式，理解這些做法，也更知道怎麼餵資料給 AI、怎麼挑模型。

• 14:08 Programmatic tool calling：模型自己決定要把哪些資料放進 context，只放需要的一小段（一個 byte、幾個字）
  ↳ Programmatic tool calling（讓模型寫程式去呼叫工具）的重點是：工具回傳的大量資料先不給模型看，由模型自己挑，只把需要的一小段放進 context（模型當下能看到的全部內容）。
• 14:08 案例：Quora 用這個技巧省下很多成本，做 Python 和大量 HTML parsing 時也變得更聰明
  ↳ Quora 用了這招，成本明顯下降。在寫 Python、解析大量 HTML（網頁原始碼）這類工作上，模型沒有被一堆雜訊淹沒，表現反而更好。
• 14:38 Compaction 被稱為「大鐵鎚」技巧：tool 宣告和 tool 結果就算管得再好，agent 跑得夠久還是會撞到 context window 上限
  ↳ Compaction（壓縮對話）是最後一道保險：就算工具說明和回傳結果都已經很精簡，agent 跑久了，累積的內容還是會塞爆 context window（模型一次能裝的容量上限）。
• 14:38 Compaction 會把對話中不再需要的回合壓縮成一段簡短摘要
  ↳ 做法是把前面已經用不到的來回過程，濃縮成一小段摘要來取代原文。就像開完長會只留會議紀錄，騰出空間繼續工作。
• 15:09 這段摘要很重要，產生時下了很多功夫，讓模型不會斷掉思路、知道接下來該做什麼；Hex 已經在正式環境使用 compaction
  ↳ 關鍵在摘要的品質：寫不好，模型會忘了做到哪、下一步要幹嘛。官方在這上面下了很多功夫，Hex 這家公司已經在正式產品裡使用。
• 15:39 Demo：在 HeroCorp agent 一次加上 tool search tool、programmatic tool calling、compaction 三種技巧
  ↳ Demo 用的是一個虛構公司 HeroCorp 的 agent，一次打開 tool search tool、programmatic tool calling、compaction 三招，比較前後差多少。
• 15:39 加上之後 context 條上升得慢很多；之前光是第一個目標就用到一百萬 tokens，現在呼叫的是完全相同的工具、拿到相同的資料
  ↳ 畫面上的 context 用量條漲得慢很多。原本光是第一個目標就吃掉一百萬 tokens（模型計算文字量的單位）；現在呼叫的工具、拿到的資料都一樣，只是放進去的東西變少了。
• 16:10 靠 context engineering 控制放進 context 的內容，用少很多的 context 就把整個頁面載完，成本也大幅下降
  ↳ 這就是 context engineering（刻意管理哪些東西要放進 context）：資料一樣齊全，只是不讓沒用的東西佔位子，所以用少很多的量就把整頁載完，花費也大降。
• 16:41 Tool search tool：模型判斷需要某種工具（例如 hero retention metrics），系統從好幾百個工具裡挑出三、四個回傳，context 裡不用放 100 個
  ↳ Tool search tool（幫模型找工具的工具）：模型說「我要查英雄留任數據」，系統就從幾百個工具裡挑三、四個相關的給它，不用一開始就把上百個工具說明全塞進去。
• 17:12 工具是即時（just in time）動態加入的，加入後模型馬上呼叫它，並拿到完整資料
  ↳ 工具是在要用的那一刻才加進來（just in time，即時），加進來模型馬上就用，拿到的資料一樣完整，不會因為比較晚加入而少拿資料。
• 17:43 Programmatic tool calling 在介面上標成 code execution，看得到模型寫的程式碼，可以了解實際發生什麼事
  ↳ 這個功能在介面上顯示為 code execution（執行程式碼）。你可以直接看到模型寫了什麼程式、怎麼拿資料、挑了哪些，不是黑箱。
• 17:43 程式用 async gather 以相同參數呼叫同一批工具，但這次結果沒有全部載入 context
  ↳ 程式用 async gather（一次同時發出好幾個呼叫的寫法）去叫同一批工具、參數也一樣。差別在於這次的結果先留在程式裡，沒有全部倒進 context。
• 18:13 模型把結果存進 JSON 物件，只 print 出需要的那一小段（例如 contact、pipeline、gong 來源，以及 :2,500），只有 print 出來的內容會進 context
  ↳ 模型把結果存進 JSON（一種整理資料的格式），只 print 出需要的部分，例如 contact、pipeline、Gong 這幾個來源，再截一段（:2,500）。只有印出來的內容模型才讀得到。
• 18:43 Demo 中把 compaction threshold 設得很小（大約 500k），這是常見的做法
  ↳ Demo 把 compaction threshold（觸發壓縮的門檻）設得偏低，大約 500k tokens 就壓縮。影片說這是常見的做法。
• 19:14 不一定要用滿一百萬 tokens 的 context；門檻設低一點可能省成本、降低延遲，甚至讓模型更聰明
  ↳ 模型能裝一百萬 tokens，不代表要裝滿。門檻設低一點，每次處理的內容就少，可能更省錢、回應更快，甚至讓模型表現更好。
• 19:14 context 長到門檻時會暫停執行，把整份 transcript 交給另一次模型呼叫做摘要
  ↳ 用量一碰到門檻，agent 會先暫停，把整份 transcript（到目前為止的完整執行紀錄）交給另一次模型呼叫，專門來寫摘要。
• 19:47 摘要把幾百次 tool call 和結果壓縮成「繼續做下去需要知道的幾件事」，讓模型可以接著跑
  ↳ 摘要把幾百次工具呼叫和結果，濃縮成「要繼續做下去就必須知道的幾件事」，模型拿著這份重點就能接著跑。
• 19:47 但每跑一次還是要花 $10
  ↳ 不過就算用了這三招，這個 agent 每跑一次還是要花 10 美元。如果是要天天跑的東西，這筆錢不算小。
• 20:21 原因是用的模型是 Opus 4.7：很棒的模型，但很貴
  ↳ 貴的原因是用了 Opus 4.7。Opus 是 Claude 能力最強、也最貴的等級，模型很好，但每一步都用它，帳單自然就高。
• 20:51 Sonnet 這類小模型 tool calling 和寫程式一樣好，只有少數幾件事做得沒那麼好
  ↳ 其實 Sonnet 這類比較小、比較便宜的模型，在呼叫工具、寫程式上跟 Opus 一樣好，只有少數幾件事做得沒那麼好。
• 21:22 Advisor strategy 的目標：用 Haiku 或 Sonnet 等級的成本，拿到 Opus 等級的智慧
  ↳ Advisor strategy（顧問策略）就是要解決這個問題：花 Haiku（最小最便宜的等級）或 Sonnet 等級的錢，拿到接近 Opus 的判斷力。
• 21:22 靈感來自工程團隊：資深工程師帶資淺工程師，不替他動手寫，而是做 code review、看設計文件、給指導
  ↳ 這個點子來自工程團隊：資深工程師不會替新人把程式全寫完，而是幫忙審程式、看設計文件、給方向，實際動手的還是新人自己。
• 21:53 模型也一樣：讓 Haiku 能呼叫 Opus 求助，Opus 看過 transcript 了解狀況後給 Haiku 建議，效果好很多
  ↳ 換到模型身上：讓 Haiku 做事，卡住時可以呼叫 Opus。Opus 讀過執行紀錄、搞懂狀況後給建議，Haiku 照著做，結果好很多。
• 22:25 動畫比喻：executor（Haiku）知道每個形狀怎麼處理，只有奇怪的那個要問 advisor，advisor 再告訴它怎麼做
  ↳ 動畫裡，executor（實際做事的模型，例如 Haiku）一般的形狀都自己處理，只有遇到奇怪的那個才去問 advisor（顧問模型），問完再照指示處理。
• 22:25 Bolt 等客戶用這個方式控制成本
  ↳ Bolt 等客戶就是靠這種分工壓低成本：大部分工作交給便宜的模型，只在少數關鍵點動用貴的模型。
• 22:58 Demo 加上 Advisor 後，模型欄顯示 Sonnet 4.6 plus Opus as Advisor；tool calling 和 Python 程式都改由較便宜的 Sonnet 做，價格立刻大降
  ↳ Demo 改成 Sonnet 4.6 做事、Opus 當顧問後，所有工具呼叫和 Python 程式都交給比較便宜的 Sonnet 執行，每次的價格馬上大降。
• 23:28 接著驗證智慧有沒有打折：看最重要的目標「Metropolis renewal」續約，Sonnet 看過所有 Gong transcripts 和相關資料
  ↳ 接著要檢查便宜之後會不會變笨：挑最重要的目標「Metropolis 續約」，這時 Sonnet 已經讀完所有 Gong 通話逐字稿和相關資料。
• 24:00 Sonnet 判斷進度正常，但因為是影響重大的案子，主動呼叫 Advisor 確認
  ↳ Sonnet 判斷進度正常，但知道這個案子影響很大，所以主動找 Advisor 再確認一次，沒有自己直接下結論。
• 24:00 Opus 看同一份 transcript 後指出 Sonnet 漏掉的細節：藏在深處的資訊顯示市長其實想要 cryothane
  ↳ Opus 讀了同一份紀錄，抓到 Sonnet 漏看的細節：藏在資料深處的資訊顯示，市長其實想要的是 cryothane。
• 24:34 好處：平常用平價（inexpensive）的 Sonnet，需要時才隨選調用 Opus 的智慧，剛好用在需要的地方
  ↳ 好處是平常用平價的 Sonnet 跑，只在需要關鍵判斷時才叫 Opus 出場，把貴的智慧用在刀口上，不用每一步都付高價。
• 25:04 結果狀態改成紅色警示，下方列出 CEO 可採取的行動：lock in cryothane
  ↳ 結果這個目標的狀態改成紅色警示，下面列出 CEO 可以採取的行動：鎖定 cryothane。
• 25:35 Demo 點下按鈕鎖定 cryothane，保住合約（cryothane 是虛構名稱，因為法務不准用真的超級英雄名字）
  ↳ Demo 按下按鈕鎖定 cryothane，合約保住了。cryothane 是編出來的名字，因為法務不准用真的超級英雄名字。
• 26:05 總結：要注意 context engineering，清楚 context 裡有什麼，再針對真正需要的內容最佳化
  ↳ 總結一：做好 context engineering。先搞清楚 context 裡到底放了什麼，再只針對真正需要的內容去精簡、最佳化。
• 26:05 總結：advisor strategy 就是隨選調用的智慧（on-demand intelligence）
  ↳ 總結二：advisor strategy 的本質就是「隨叫隨到的智慧」（on-demand intelligence），平常不用，需要時才請高手出馬。
• 26:39 近幾個月的新功能：workload identity federation（WIF），可以解決資安團隊擔心 API key 外流的問題
  ↳ 新功能 workload identity federation（WIF）：API key 是讓程式使用服務的密鑰，外流就可能被別人盜用。WIF 就是用來解決資安團隊這個擔心的方案。
• 26:39 新功能 ANT CLI 命令列工具：console 上能做的事幾乎都能用命令列完成
  ↳ 另一個新功能是 ANT CLI（CLI 就是打指令操作的工具）。以前要在 console（Claude 平台的網頁管理後台）點選的事，現在幾乎都能用指令完成。
• 27:10 Claude 很擅長用命令列工具；透過 Claude Code 告訴它你要做什麼，它會幫你全部管理好
  ↳ Claude 很會用這類命令列工具，所以你不用自己學指令。在 Claude Code（在終端機裡使用的 Claude 助理）說你想做什麼，它會幫你處理好。
• 27:10 結論：押注這個平台，平台會持續變好，你的 agent 也會跟著新功能推出越來越好
  ↳ 結論：把 agent 建在這個平台上。平台會一直推出新功能，你的 agent 也會跟著變得越來越好。

在 Advisor 的 demo 裡，是誰發現 Metropolis renewal 案子其實需要 cryothane？