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

🧑‍🏫 這支影片是 Anthropic 在倫敦 Code with Claude 開發者活動上的一場演講，主題是讓 AI agent 更省錢、更快、做得更好。AI agent 是會自己分好幾步做事、還會呼叫各種工具的 AI 助理。演講主要教兩招：讓 AI 重複使用已經讀過的內容，以及精挑細選要給 AI 看的資料。如果你在做或在用 AI 工具，這兩招直接影響花費和效果。

• 00:18 講者 Puneet Shah 是 Anthropic platform 團隊的 product manager，這是倫敦場 Code with Claude 的最後一場 session
  ↳ 講者 Puneet Shah 是 Anthropic 平台團隊的 product manager，也就是產品經理，負責決定產品要做什麼。這是倫敦場 Code with Claude 開發者大會的最後一場。
• 00:48 講者參與推出的功能包括 one million context window、fast mode，以及多項 prompt caching 改進
  ↳ 他參與推出的有：百萬規模的 context window（AI 一次能讀進的內容量）、fast mode（讓回應更快的模式），還有 prompt caching 的多項改進，下一點起會解釋。
• 00:48 模型之上的 platform 層不只提供智慧，還要幫你做出真的能服務使用者的產品與事業
  ↳ 這裡的 platform 指模型外面那一層服務和工具。他的意思是：模型聰明還不夠，平台要幫你把 AI 變成真的能服務客戶、能賺錢的產品。
• 02:21 講者說：這場如果只記得一件事，就記 prompt caching
  ↳ 整場最重要的一句：如果只記得一件事，就記 prompt caching。後面講的省錢、提升速度，大多是靠它。
• 02:21 Prompt caching 原理：處理完 input tokens 後，在產生 output 前先存進 cache；對話有新訊息時只處理新增的 tokens，其餘從 cache 取
  ↳ token 是 AI 計算文字量的單位。AI 處理完你的輸入（input tokens）、還沒寫回答（output tokens）之前，先把內容存進 cache（暫存區）。下一輪只處理新加的部分，舊的直接拿來用。
• 02:52 好處一：cached tokens 不必重新處理，這部分省下的費用回饋給使用者，享 90% 折扣
  ↳ 存在 cache 裡的 tokens（cached tokens）不用重新處理，省下的成本回饋給你：這部分打一折，只要付一成的價錢。
• 02:52 好處二：rate limit 不計入 cached tokens。cache hit rate 80% 時，實際上等於 rate limit 放大 5 倍
  ↳ rate limit 是平台限制你單位時間內能用多少量。cached tokens 不算進額度。cache hit rate（從 cache 取用的比例）80% 時，只有兩成算額度，等於額度放大 5 倍。
• 03:25 好處三：latency 降低。cache 得越多、對話越長，time to first token 會下降
  ↳ latency 是等回應的延遲。time to first token 是送出問題後，到 AI 吐出第一個字的時間。cache 越多、對話越長，要重新處理的越少，等待就越短。
• 03:25 做 agentic 應用時，cache hit rate 以 80% 以上為目標
  ↳ agentic 應用就是讓 AI 當 agent，自己分多步完成任務的應用。講者建議這類應用的 cache hit rate 要做到 80% 以上。
• 03:56 Replit、Cursor、Perplexity、Claude Code 的 cache hit rate 都在 90% 以上，他們在 prompt caching 上投入了大量心力
  ↳ Replit、Cursor 是 AI 寫程式工具，Perplexity 是 AI 搜尋，Claude Code 是 Anthropic 的寫程式 agent。它們的 cache hit rate 都超過 90%，是花大功夫調出來的。
• 03:56 第一步是先搞清楚自己的 prompt cache hit rate 是多少
  ↳ 先量再改：不知道自己的 cache hit rate，就不知道到底省了多少，也不知道要從哪裡改起。
• 04:27 在 console.anthropic.com 的 cost 與 usage 頁面旁邊，現在可以看到 prompt caching 的 analytics
  ↳ console.anthropic.com 是 Anthropic 給開發者的管理後台。在費用和用量頁面旁邊，現在多了 prompt caching 的 analytics（分析數據），可以看命中率。
• 04:27 演講前一天新推出的功能：可以查出 cache 為什麼失效。prompt 的排列順序影響很大
  ↳ 演講前一天新推出的功能，能查出 cache 為什麼失效、沒被重用。prompt 是你交給 AI 的指示和內容，裡面東西的排列順序對 cache 能不能重用影響很大。
• 04:27 常見錯誤：把 timestamp（今天日期）放進 system prompt，它一變動 cache 就失效，因為 tokens 必須完全相同
  ↳ system prompt 是每次都會先給 AI 的固定說明。如果在裡面放 timestamp（時間戳記，例如今天日期），日期一變，tokens 就跟之前不完全相同，cache 就失效了。
• 04:59 hit rate 還是 0% 的話，可以先用 auto caching，只要改一行程式就有基本的 prompt caching
  ↳ 如果命中率還是 0%，可以先用 auto caching（自動快取）：只要改一行程式，就有基本的 prompt caching，先拿到一部分省錢效果。
• 04:59 更好的做法：在 Claude Code 或其他 coding agent 裡使用內建的 Claude API skill，請它幫忙提升 cache hit rate、調整 prompt 的順序
  ↳ 更好的做法：在 Claude Code 或其他 coding agent（幫你寫程式的 AI）裡，用內建的 Claude API skill（懂 Claude 怎麼串接的技能包），請它幫你調整 prompt 順序、拉高命中率。
• 05:29 Demo 開始：講者扮演虛構公司 HeroCorp 的 CEO，由 CTO Ben 操作，先請 agent 把老舊的介面主題換新
  ↳ Demo（現場示範）開始：講者扮演虛構公司 HeroCorp 的 CEO（執行長），由 CTO（技術長）Ben 操作。第一件事是請 agent 把舊介面的主題換新。
• 06:30 HeroCorp 是一家出租超級英雄的公司，用 OKR 和 dashboard 追蹤績效，例如 90 天留任率
  ↳ HeroCorp 是出租超級英雄的公司。它用 OKR（設定目標並追蹤成果的方法）和 dashboard（數據儀表板）追蹤績效，例如 90 天留任率。
• 07:30 講者反覆強調：一定要看 agent 的 transcript，才能真正了解發生了什麼事
  ↳ transcript 是 agent 從頭到尾的完整紀錄。講者一再強調要看它，因為只看最後結果，不會知道 AI 實際讀到什麼、中間做了哪些事。
• 07:30 Demo 的 agent 從 web、Slack、Gong、Jira 等來源拉資料並彙整，用來掌握公司的整體狀況
  ↳ 這個 agent 會從網路、Slack（團隊聊天工具）、Gong（業務通話紀錄工具）、Jira（專案任務管理工具）抓資料來彙整，讓 CEO 掌握公司整體狀況。
• 08:01 Demo 一開始 prompt cache hit rate 是 0，成本約 31 英鎊，接著實作 prompt caching
  ↳ 一開始 cache hit rate 是 0，成本約 31 英鎊。接著現場把 prompt caching 加上去，看看有什麼差別。
• 08:01 Prompt caching 不影響模型的智慧，輸出結果完全一樣，只是預先處理過
  ↳ 不用擔心省錢會讓 AI 變笨。prompt caching 只是把處理過的部分先存起來，模型的能力和輸出結果都完全一樣。
• 08:31 畫面顯示 cache write 172 tokens，之後 cache hit 172 tokens，代表寫入的 tokens 在後續對話中被重複使用
  ↳ 畫面先顯示 cache write（寫進 cache）172 tokens，之後出現 cache hit（命中）172 tokens，代表同一段內容只存一次，後面的對話都直接重用。
• 09:01 cache hit rate 約 58%，agent 成本大約減半，算是好的第一步
  ↳ cache hit rate 來到約 58%，agent 的成本就砍了將近一半。還沒達到 80% 的目標，但已經是不錯的第一步。
• 09:01 Dashboard 只做到 5 個 OKR 就把 context window 塞滿了，所以需要 context engineering
  ↳ Dashboard 只做到第 5 個 OKR，context window 就塞滿了，agent 沒辦法繼續做。光省錢不夠，還得管好給 AI 看什麼，所以需要 context engineering。
• 09:38 Context engineering 是決定要把哪些 context 交給 Claude、讓 agent 表現最好的藝術與科學
  ↳ context 是 AI 當下看得到的所有資料。context engineering 就是決定要給 Claude 看什麼、不給什麼，讓 agent 表現最好；有方法可循，也需要經驗判斷。
• 09:38 看 transcript 可以發現：哪些東西其實不必傳給 Claude，哪些相關內容能讓它保持在正軌上
  ↳ 看 transcript 可以找出兩件事：哪些資料其實不必給 Claude，只是在佔空間；哪些相關資料能讓它不跑偏、專心做事。
• 10:11 三個主要技巧：一、精簡傳給模型的 tools；二、精簡 tool 結果；三、管理對話歷史，讓 context 感覺幾乎沒有上限
  ↳ 三個主要技巧：一、少給模型 tools（工具，例如查資料、發訊息這類功能）；二、把工具回傳的結果精簡；三、管理對話歷史，讓 context 用起來像沒有上限。
• 10:45 現在的 agent 常用到幾十甚至上百個 tools，Claude 模型特別擅長運用 tools
  ↳ 現在的 agent 常接幾十個、甚至上百個 tools。Claude 模型又特別擅長用工具，所以常會接上大量工具。
• 10:45 問題是：所有 tool 定義全傳給模型會佔掉大量 context，幾輪對話後 context 就滿了，實際工作的空間變少
  ↳ 問題是每個 tool 都要附上說明（定義）給模型看。全部塞進去會佔掉大量 context，聊幾輪就滿了，真正做事的空間就變少。
• 11:21 Tool search tool：所有 tools 照樣事先定義，但只給模型一個搜尋用的 tool，需要時才把特定 tool 的完整定義放進 context
  ↳ tool search tool：所有工具照樣先定義好，但只給模型一個「搜尋工具」的工具。需要用哪個工具時，才把它的完整說明放進 context。
• 11:21 Lovable 用 tool search 後，整體 token 用量減少了「10」（字幕原文為 by 10，沒說明單位）
  ↳ Lovable（用 AI 做網站和 App 的服務）用了 tool search 之後，整體 token 用量減少了「10」。影片原文只說 by 10，沒講是 10 倍還是 10%。
• 11:54 Lovable 的 tool 表現也提升了：context 裡的雜訊少、相關內容多，模型表現更好，因此已推廣給所有使用者
  ↳ Lovable 用工具的表現也變好了：context 裡雜訊少、有用的內容多，模型就做得更好，所以他們已經開放給所有使用者。
• 11:54 第二個技巧是 programmatic tool calling：把 tools 回傳的內容篩到只剩最相關的部分
  ↳ 第二個技巧是 programmatic tool calling（用程式來呼叫工具）：工具回傳一大包資料時，先篩到只剩最相關的部分，再交給模型。
• 12:26 做法是利用 Claude 很會寫程式的特性，讓 Claude 寫簡單的 Python script 呼叫同樣的 tools，先整理結果，再把最相關的內容交給模型
  ↳ 做法是利用 Claude 很會寫程式這點，讓它寫簡單的 Python（一種常用程式語言）script（小程式），去呼叫同樣的工具、先整理結果，只把重點交給模型。
• 13:03 Quora 用 programmatic tool calling 處理 HTML 內容，去掉無關部分、保留相關部分，模型表現因此提升
  ↳ Quora（問答網站）用這招處理 HTML（網頁的原始碼）：先刪掉不相關的部分、只留有用的內容，模型表現因此提升。

根據講者的說法，如果 prompt cache hit rate 是 80%，實際上 rate limit 會變成原本的幾倍？