更充分運用 Claude Platform（第 1/2 段） ☕ Buy me a coffee

🧑‍🏫 這支是 Anthropic 的 Claude Platform 產品負責人在講：AI agent 做出來不難，難的是正式上線後要夠便宜、夠快、夠穩。這一段講兩招：prompt caching，讓重複的內容不用每次重算；context engineering，決定 AI 每次該讀什麼。如果你有在用 Claude 的 API 或 agent，這兩招都能直接幫你省錢、提速。

• 00:55 講者是 Anthropic 的 Claude Platform 產品管理負責人 Brad Abrams，這場講的是把 agent 真正放到正式環境（production），而不是做 demo 或 proof of concept
  ↳ 講者 Brad Abrams 負責 Claude Platform 的產品管理。agent 是會自己一步步動手完成任務的 AI 程式。這場講的是讓 agent 真的上線給人用（production），不是只做展示或概念驗證。
• 01:27 現場調查：已經有 agent 上線、而且對成本、可靠度、延遲都滿意的人很少。這場要介紹幾個管理成本、延遲和可靠度的技巧
  ↳ 他現場問了一下，agent 已上線、又對花費、穩定度、速度都滿意的人很少。可見難的不是做出來，而是長期跑得划算又穩。這場就是在教這幾招。
• 01:57 講者認為最重要的技巧是 prompt caching。他從數據看得出來，還有人沒在用
  ↳ 他認為最該先做的是 prompt caching：把每次都一樣的 prompt 內容先存起來重複用。他從使用數據看得出來，還有不少人沒開，等於一直多付錢。
• 02:28 長時間執行的 agent 每做一次 tool call，就會把 tool call 和 tool result 接到 prompt 後面，context 越來越長。沒用 caching 的話，重複的部分每次都要重新處理
  ↳ tool call 是 agent 去叫外部工具（查資料、跑程式），tool result 是工具回傳的內容。每叫一次都接在後面，AI 要讀的內容（context）越堆越長，沒快取就每次整段重讀。
• 02:28 只要標出 prompt 裡共用的區段，系統就能先算好並存下 KV values，跳過 inference 的前段，省下延遲和運算時間
  ↳ 你只要標出「這段每次都一樣」，系統就把這段的計算結果（KV values）存起來。下次模型推算答案（inference）時直接沿用，不用從頭算，所以更快也更省。
• 02:58 Prompt caching 可以讓 input tokens 打 1 折（90% discount）。對多數客戶來說，input tokens 是費用的最大宗
  ↳ token 是模型的計費單位，大約是字詞的片段；input tokens 就是你送進去的文字量。被快取的部分只收一成價錢，而這塊正是多數人帳單的最大宗，所以省很多。
• 03:29 另一個好處是回應更快，尤其是 time to first token 會縮短
  ↳ 除了便宜也會變快。time to first token 是送出請求後，等 AI 吐出第一個字的時間。前面那段不用重算，這段等待就明顯縮短。
• 03:29 比較少人知道的是：快取的 tokens 不會算進 API rate limit。講者說目前 rate limit 已經提高將近 10 倍，想再省著用還是可以靠 caching
  ↳ rate limit 是平台限制你一段時間內能用多少量，超過會被擋。快取的 tokens 不算額度，同樣額度能跑更多工作。雖然上限已提高近 10 倍，caching 還是能讓你更寬裕。
• 04:00 Cursor、Replit、Perplexity 的 prompt caching 都做到 90% 以上，但它們投入了大量工程心力才達到
  ↳ Cursor、Replit、Perplexity 這些知名 AI 產品，快取命中都做到九成以上。但講者強調，它們是花了大量工程人力才調到這個程度，不是一開就有。
• 04:32 工具一：到 Claude Console 的 Analytics，打開新的 prompt cache dashboard，就能看到正式環境 agent 的 caching 狀況。沒到 90% 以上就還有要改的地方
  ↳ Claude Console 是 Claude 的開發者後台。到 Analytics（使用分析）打開新的 prompt cache 儀表板，就能看到上線 agent 的快取命中比例。低於九成就還有可以改的地方。
• 05:02 工具二：Claude Code 新增了一個專門處理 prompt caching 的 skill，預設就已安裝。直接對 Claude Code 說「improve my cache hit rate」就行
  ↳ Claude Code 是 Anthropic 的 AI 寫程式工具，skill 是替它加上某類任務做法的擴充包。現在預設就裝好一個專管快取的 skill，直接跟它說「improve my cache hit rate」就行。
• 05:02 這個 skill 會一步步帶你加上 cache control markers，也可能重新整理 prompt 結構，幫你拿到很高的 cache hit rate
  ↳ cache control markers 是插在 prompt 裡的標記，告訴系統哪些段落要快取。這個 skill 會一步步帶你加上，必要時也會重整 prompt 的結構，讓命中率衝高。
• 05:32 Demo（和 Ben 一起）：一個 Executive Dashboard，先用 Claude Code 把老舊介面換成新 theme，變成虛構公司 HeroCorp AI 的 CEO 儀表板
  ↳ 接著和 Ben 現場示範。他們先用 Claude Code 把一個老舊的主管儀表板換上新外觀，改成虛構公司 HeroCorp AI 的執行長（CEO）儀表板，當作示範舞台。
• 06:34 Demo 情境：HeroCorp 派超級英雄對抗反派、保護 Metropolis 等。畫面有目標（objective 1 是留住超級英雄）、每位英雄的進度更新，以及 CEO 待辦事項
  ↳ 設定是 HeroCorp 派超級英雄打反派、守護城市 Metropolis。畫面上有公司目標（第一項是留住超級英雄）、每位英雄的進度，還有 CEO 待辦清單，就像一般公司的管理看板。
• 07:05 第一步是先知道自己的 cache hit rate。這個 demo 做了一個 dev console，可以看到 context 用量、tool calls 和 agentic transcript
  ↳ 要改善，得先量出現況。他們做了一個 dev console（給開發者看的檢視畫面），能看 context 用量、叫了哪些工具，以及 agentic transcript，也就是 agent 每一輪叫工具、拿結果的完整紀錄。
• 07:36 Dev console 顯示 cache hit rate 接近 0。Ben 在 Claude Code 裡要求改善 cache hit rate，然後重跑一次
  ↳ 一看命中率幾乎是 0，代表每一輪都在付全額重算。Ben 就在 Claude Code 裡要它改善命中率，改完再重跑一次同樣的任務來比較。
• 08:07 重跑時一樣是那些 tool calls，但 agentic transcript 裡開始出現 cache writes 和 cache hits
  ↳ 重跑時 agent 叫的工具完全一樣，差別是紀錄裡開始出現 cache write（寫入快取）和 cache hit（命中快取），代表重複的內容終於被重複利用了。
• 08:07 推論系統第一次看到某段 prompt 時會寫進快取，KV values 預設保存 5 分鐘，可以用選項延長。下一輪 loop 再遇到同一段，就是 cache hit
  ↳ 系統第一次看到某段 prompt 就把它存起來（cache write），預設保留 5 分鐘，可以設定延長。agent 在下一輪循環（loop）再碰到同一段，就直接取用（cache hit）。
• 08:40 Demo 中的模型是 Opus 4.7，有一百萬（1 million）tokens 的 context，但還是不夠用
  ↳ 示範用的模型是 Opus 4.7，context 上限有一百萬 tokens，空間已經非常大。但就算這麼大，這個 agent 還是不夠用。
• 09:13 原因是 tool calls 從 Slack、Gong 逐字稿、Salesforce 抓進大量資料，塞滿 context，連 objective 1 都還沒做完 context 就用光了
  ↳ 因為工具從 Slack（公司聊天軟體）、Gong（業務通話逐字稿）、Salesforce（客戶管理系統）抓回大量資料，全塞進 context，第一個目標還沒做完空間就滿了。
• 09:45 Context engineering 是一門專業：決定什麼東西應該放進 Claude 的 context
  ↳ 這就帶到 context engineering：刻意安排 Claude 每次該看到哪些資料。就像開會前幫主管整理資料，挑重點給，比整疊丟過去有效。
• 09:45 常見錯誤是在平台上面再包一層抽象，遮住了 context 的內容。開發者不知道 Claude 實際看到什麼，就很難優化
  ↳ 常見錯誤是在平台上面再包一層自己的框架（抽象層），把細節藏起來。結果開發者看不到 Claude 實際收到什麼，就不知道哪裡浪費、該從哪裡改。
• 10:15 建議仔細看 Claude 能取用的完整 transcript，會很有收穫。Context engineering 就是由你主動決定哪些東西該放進去
  ↳ 建議直接打開完整紀錄，看 Claude 每一輪到底讀到什麼，會很有收穫。context engineering 的重點是：要放什麼由你主動決定，不是放它自己越堆越多。
• 10:47 目前已可在正式環境使用的三個工具：Tool Search Tool 減少 tool 宣告；programmatic tool calling 減少塞滿 context 的 tool 結果；compaction 清掉不再需要的舊回合
  ↳ 已能正式上線用的三招：Tool Search Tool，工具說明不用一次全載入；programmatic tool calling，工具回傳的大量資料不直接塞進去；compaction，清掉用不到的舊回合。
• 11:18 很多客戶載入數十、甚至上百個 tools。長時間執行的多用途 agent 本來就需要很多 tools，講者也鼓勵多用
  ↳ 很多客戶一次接幾十、甚至上百個工具。講者覺得這沒問題：要長時間跑、什麼都得會做的 agent 本來就需要很多工具，他也鼓勵大家多用。
• 11:18 但如果一開始就把所有 tools 放進 system prompt，真正做事的空間就所剩無幾
  ↳ 問題是每個工具都有一段說明。如果一開始就全寫進 system prompt（每次開頭給 AI 的固定指示），光放說明就占掉一大塊 context，真正做事的空間所剩無幾。
• 11:50 Tool Search Tool 的做法：tools 一樣先宣告，但延後載入（defer loading），等模型需要時才即時載入。某次執行從頭到尾沒用到的 tool 就不會載入
  ↳ Tool Search Tool 的做法是工具照樣登記，但先不載入（defer loading，延後載入），等模型要用時才即時載入。整趟任務都沒用到的工具，就一直不占空間。
• 11:50 例子：Lovable 用了之後 token 用量減少 10%
  ↳ 實例：Lovable（用對話就能做出網站或 App 的 AI 工具）導入之後，token 用量少了 10%。
• 12:20 Lovable 還發現，不只省錢、降延遲，更謹慎管理 context 反而讓模型表現更聰明
  ↳ Lovable 還發現一個額外好處：除了省錢、變快，把 context 管得更仔細，模型的表現反而更聰明。
• 12:50 Programmatic tool calling 解決 tool 回傳資料太多的問題。做 demo 時全塞進 prompt 還行，上正式環境就要更講究
  ↳ programmatic tool calling 是在處理工具一次回傳太多資料的問題。做 demo 時全丟進 prompt 還撐得住，真的上線就得更講究。
• 12:50 如果改 tools 讓它少回傳資料，常常會漏掉某些模型其實需要那筆資料的情況
  ↳ 直覺做法是改工具，讓它少回傳一點。但這樣常會漏掉某些情況下模型其實需要的資料，反而害它做不好。
• 13:21 核心想法是模型很會寫 Python。做法是告訴模型目前 context 裡有哪些 tools，讓它寫 Python code 來呼叫
  ↳ 關鍵是模型很會寫 Python（一種常見的程式語言）。所以改成告訴模型目前有哪些工具可用，讓它自己寫一小段程式去呼叫，而不是把結果直接倒進 context。
• 13:51 模型第一次會先寫 code 檢查回傳資料的 schema，第二次就知道 schema 了。Tool 的完整回傳資料留在記憶體裡，模型再寫 code 從中取出需要的部分（本段字幕到此中斷）
  ↳ schema 是資料的欄位結構。模型第一次先寫程式看回傳資料長什麼樣子，之後就知道了。完整資料留在記憶體裡，模型再寫程式只挑出需要的部分。（這段字幕到這裡中斷）

根據講者，長時間執行的 agent 使用 prompt caching，input tokens 可以打幾折？