有請 Claude 平台產品管理負責人 Brad Abrams,以及 Anthropic 技術成員 Rod Howarth 上台。

Prompt caching:本場最重要的一個帶回家重點

午安,謝謝大家前來。你們差不多撐到 Code with Claude 的尾聲了,謝謝各位的努力堅持。這個場次絕對值回票價,因為我們要談的不只是打造 agent,而是如何部署安全、可靠、高效能、而且最重要的——成本划算的 agent,讓你真的能在規模下做這件事。我知道很多人已經開始做 agent 了,少數人也許已經有 agent 進了生產環境,但真正對自己 agent 的效能、可靠性與成本滿意的,非常少。這場演講就是要鑽進這個問題——所以絕對值得你的時間。那我們開始鑽。

在談今天其他的技巧與工具之前,我想先講 prompt caching。這是本場最重要的一個帶回家重點:你怎麼做 prompt caching。

你看,在長時間運行的 agentic 應用裡,有很多工具呼叫、很多使用者輪次,逐字稿會變得很長。而每一次 API 請求,都會重複這些很長的 prompt 片段。

如果每次都得重新計算這些片段,既貴又慢。所以我們提供 prompt caching,讓我們能預先計算 context 中共享的部分。我們把那些存成一種中間值——我們叫它 KV 值——把 prompt 預先計算好的部分存放在我們的伺服器上。下一個請求進來時,我們只需要處理與上一個請求之間的小增量。這省下大量運算,而我們把省下的回饋給你。所以 prompt caching 最重要的好處是:打一折——用了 prompt caching,你只付 10% 的費用。此外,你會得到更快的回應時間,而且 prompt caching 不影響你的速率限制(rate limit):任何被快取的 token,在 API 的速率限制裡都不計入。

有些客戶把 prompt caching 做得非常好。看看 Perplexity、Cursor、Replit——這些客戶都投入了可觀的工程心力,把快取命中率拉到非常高。事實上,如果這些客戶沒有這麼高的命中率,我們根本撐不起他們的工作負載——沒有 prompt caching,算力就是不夠。所以它非常重要。

但好消息是:你可以用小得多的力氣,拿到差不多高的命中率。

有兩個技巧。第一個在投影片上:進到我們的 developer console——我們的 Claude console——你可以看到這個新儀表板,回報你的快取命中率。我展示的這個 agent 命中率只有 56%,還有進步空間。我邀請大家一回家就去看看你的 agent 的命中率。如果還沒到 80 幾,我會建議那就是你第一件該做的事,因為許多長時間運行的 agent,命中率是可以拉到那麼高的。

第二個大技巧:用我們的 Claude API skill。這是一個新的 skill,Claude Code 預設就裝好了。只要你有 Claude Code——或其他開發工具也行,因為它就只是個 skill——它非常懂 prompt caching。你只要進 Claude Code、打開你的專案,說「improve my caching rate 改善我的快取命中率」,它就會跟你一起改 prompt、加 cache control 標頭等等,把你的命中率拉上去。

Demo:Hero Corp 的 CEO 儀表板

好。為了看看實際的樣子,我想請 Rod 出場。Rod 做了一個 demo。

Rod,要不要出來?好。Rod 其實是 API 團隊的首席工程師之一。如果你用 API 做過東西,你跑的大概就是他的程式碼。我們切到 demo 機,看看 Rod 準備了什麼。

我們要做的是一個給 CEO 的儀表板。CEO 有一組目標(objectives),我們寫了一個 agent,它會出去——等等,Rod,這是對的 UI 嗎?我們可是 Code with Claude Tokyo,你端出這個 90 年代 SharePoint 風的 UI?我不知道欸。但我覺得我們可以做得更好。你覺得呢?來看看能不能更好。Rod,那台機器上有 Claude Code 嗎?好,Rod 有 Claude Code。Rod,看你能不能給我們一個更好的主題。呃——想想什麼比較適合東京的觀眾。對,Brad 覺得——對,就是那樣。記住,現在是一天的尾聲,我們得讓它刺激一點。所以——好,Rod 要做一個超級英雄主題的 demo,我覺得合適多了。再說一次,我們是在用 Claude Code 就地修改 demo 的原始碼,然後切回來。啊,好多了吧?

好,我們不再是某家無聊公司的 CEO 了。這是 Hero Corp 的 CEO 儀表板。Hero Corp 做的是出租超級英雄:保衛你的城市、打倒反派、出席小孩的生日派對——什麼都行。但我們仍有一組目標,而我們是靠掃遍這家公司所有的資料,來回報這些目標的狀態。所以我們有一堆把資料接進來的工具。為了感受一下這個網站的樣子,Rod 還做了一個漂亮的開發者主控台。我們看看這個網站的開發者視角。你要不要叫出來?這是我們的 dev view。可以看到有幾個工具——Outlook 搜尋,這個我們等下會講。然後可以看到 Rod 對 prompt caching 的投入——等等,Rod,0% 的快取命中率?老兄,我們不是說好了——我整段都在講 prompt caching 有多重要,0%?好,Rod,要不你現場把 prompt caching 實作一下。

Rod 要進 Claude Code,幫我們把 prompt caching 做起來。我們應該會看到:prompt caching 做好之後重新載入網站,命中率會上升。好,你看,一開始它做了幾次快取寫入,現在開始有快取命中了。一個小小的改動,我們就拉到了 58% 的命中率。我邀請大家在這個 demo 的過程中持續觀察:隨著我們加更多功能,你會看到命中率再往上爬。

好,這個 demo 看起來不錯。我們有目標一。往下捲——其實還有四個目標。第一個目標是留住頂尖人才。目標二——看看目標二是什麼。它——等等,目標二根本沒載入。它說我們把 context 用完了,連目標二都還沒到。你可以看到這裡的 context window 指示器,對吧?給了你一百萬 token 的 context,四個目標我們只跑到一個就用掉一百萬 token。我想我們可以做得更好。你知道我們需要什麼嗎?一點 context 工程。我們切回投影片,讓我講一下 context 工程。

Context 工程:tool search tool、程式化工具呼叫、compaction

好。context 工程是「決定什麼東西屬於 Claude 的 context」的學門。

它真的是一門工程技術——等下會講——因為你希望 Claude 的 context 裡有足夠的東西讓它做出有理有據的好決策,但又不能多到讓它分心、變貴、變慢。所以你要深思熟慮,要確切知道並理解 context 裡有什麼。今天我會講三種你可以用來管理 agent context 的工具。

第一個是 tool search tool,它會把一大堆工具定義擋在你的 context 之外。

第二個是程式化工具呼叫(programmatic tool calling),它會把一大堆工具結果擋在 context 之外。

最後我會講 compaction。開始鑽。

先講 tool search tool。

它解決的核心問題是:許多 agent 為了做好工作,有 10 個、20 個、上百個工具。而我們希望 agent 有很多工具——我們要 agent 通用又高生產力,要用工具把事情合理地拆解。所以擁有 100 多個工具不瘋狂;瘋狂的是把 100 多個工具放進 context。就像上方「without」那條線顯示的:如果你有一百個工具,你會把大部分 context 耗在工具定義上,只剩一點點留給 agent 真正的運行。

這並不明智,因為你的 agent 大多數的軌跡、大多數的執行,可能只用到那些工具的 10%,你卻把全部都載進了 context——你在成本上付了錢,在延遲上也付了錢。而 tool search tool——看下面——我們只載入一個工具:tool search tool。當模型決定它需要某個工具時,它先問 tool search tool:嘿,你有做這件事的工具嗎?tool search tool 就在它的工具庫存裡搜尋,為那個查詢挑出對的工具,把它載入 context。結果你看到的是:你得到多得多的 agentic 空間。

你能更有效率地使用 context,因為每次執行只載入你真正需要的工具。所以你可以擁有大量工具,卻只用你需要的那些。

像 Lovable 這樣的客戶,真的從中看到了好處。光是這一個改動,他們的 token 用量就降了 10%——等於直接從帳面上省下 10%。但不只如此——對 Lovable 更重要的是,所有人的效能、智慧都變好了。因為當模型的 context 塞太多東西,判斷力有時就沒那麼好;減少進入 context 的東西,模型本身表現就更好。

好,這是 tool search tool。

接著談程式化工具呼叫。

我先說,我用 Fable 做這些動畫圖表做得很開心,希望大家欣賞我為此浪費的所有 token。程式化工具呼叫的目標,是把中間的工具結果擋在 context 之外。你看,很多工具——你其實會想把工具設計成回傳大量資料,因為你希望模型拿得到它可能需要的任何 context。所以你希望工具回傳很多資料。但如果你有一個工具,比如剛剛看到的 Outlook 工具,它回傳一百封 email——那會吃掉你一大塊 context,而你可能只需要其中一封的標頭。或者你有一個 HTML 頁面,你可能只需要裡面一個小小的 div 標籤,卻把整頁都載進了 context。

我們解決這個問題的方法,其實是依靠「我們的模型非常會寫程式」這個事實。與其單純用一次工具呼叫,我們的做法是:做工具呼叫、拿到完整結果,然後模型能檢視那個 schema,針對那塊任意資料的 schema 寫程式。它能即時寫程式,只抽出需要的那一點資訊——比如那份資料的 5%、2%——把那個結果放進 context。對任何回傳大量資料的工具,這都是巨大的好處。像 Quora 這樣的客戶就從中受益匪淺——Quora 的 agent 大量處理 HTML。他們會拉很多 HTML 進來,過去整頁整頁地拉,其實只需要頁面的一小部分。改用這個之後,他們的 agent 表現好了非常多。好,這是程式化工具呼叫。

接下來是 compaction。

就算你把 tool search tool 和程式化工具呼叫都做得很好,你還是可能把 context 用完,因為它們終究佔 context。如果你的 agent 野心很大、要跑好幾個小時甚至好幾天,你就需要 compaction 這樣的東西。compaction 讓你這個開發者設定一個閾值。

你可以說:我的一百萬 token context window,我只想用 400 或 500k——只用其中一部分。當 context 用量接近那個點,我們會暫停 agent 的執行,拿另一個模型把整份逐字稿摘要起來,剝掉所有已經不需要的東西——那些中間工具結果、工具呼叫之類的;它們不需要了,因為需要它們的那個決策已經做完了,沒必要為歷史原因留著。然後我們把那些全部清出 context,只放進一份小而緊的「到目前為止發生了什麼」的摘要,接著重啟 agent。它就從停下的地方接著做。因為我們在「把摘要做好」上下了功夫,agent 有足夠的 context 直接接手繼續。對開發者來說感覺非常無縫。我們看到像 Hex 這樣的公司採用了它。原來 Hex 自己已經實作過一版,所以他們得以刪掉 300 行程式碼,擺脫那個維護負擔。讓 Rod 來扛維護負擔,總比你來扛好。好,這就是 compaction。

回到 demo:三招同時上

我們講了這三樣東西。我想該實際看看它們能不能改善我們的 Hero Corp app。切回 demo。好。上次我們離開 Hero Corp 時——對,就放著——上次離開時,記得嗎,四個目標只跑了一個,就耗掉一百萬 token 的 context。我們想看看能不能用這些技術讓它載入完。Rod,直接進 Claude Code,把這些全部啟用:tool search tool、程式化工具呼叫、compaction,一次到位,把這些策略全部設定好。

好,都上了。現在切回去重新載入——注意,發生的事多多了。你看 context window 在上升。活動串流裡有大量工具呼叫,因為我們正在填滿每一個目標。所以,真的只要多一點點工程,我們就拿到多得多的價值。對,所有目標都載入了,而且最終的 context 小得多。

我們一項一項走過,確保每個都看懂。

先從最上面的 tool search tool 開始。第一件發生的事是:模型決定呼叫 tool search tool,它搜尋的查詢你看得到,是「hero retention metrics(英雄留任指標)」。tool search tool 說:噢,我有一個那樣的工具,這是它的 schema——名字叫 hero_retention_metrics,帶底線的,你看「name」那裡。往下捲,看模型真的呼叫了那個工具。再捲一點——對,就在那裡。模型實際呼叫了那個工具,拿到了結果。

所以,我們不必把這 100 多個工具預先全部載入,可以一次載一個。

好,接下來是程式化工具呼叫。

這個很有意思。我們有這個 Gong 客戶摘要。不知道大家認不認識 Gong——它是會議逐字稿工具。它回傳一整份會議的逐字稿,有當然很好,但我們其實只想要這場會議的情緒(sentiment)。所以,與其吞下整份逐字稿——看「程式碼執行中」那段、程式化工具呼叫那一段,你會看到它真的寫了這段程式。它用 code executor 寫的。你可以看到對那些方法的呼叫,所有工具都在;然後它把 JSON 拉出來,只印出 JSON 的一小部分——只有這次執行真正需要的最小片段。這省下大量 context。

好,最後是 compaction。

你可以看到,這裡,compaction 觸發了。我們砍掉了 9 萬——降回 1 萬,然後你可以看到做出來的摘要。我們對接手的模型講得很清楚:這是目標、這是已蒐集的資料、這是你接下來要做的。是一份非常緊湊的摘要。其實,要不我們再跑一次,盯著 context window 那條線,看它一點一點長——因為我們在用 context 工程,而且閾值設在 400K。所以當它接近 400K,你會看到 compaction 發生,context 大幅下降,然後又開始累積。看我們能不能抓到那個瞬間——如果 demo 之神保佑的話。我錯過了嗎?發生了嗎?已經發生了。我錯過了。希望你們抓到了,我沒抓到。好,漂亮。我們的東西都看完了。切回去。哦,對——有件事沒人提,我不是日本人,但一次請求 1,600 日圓,很貴吧?貴嗎?一次請求這樣很貴吧。對,我想我們可以做得更好。切回投影片,談談怎麼把它優化一下。

Advisor 策略:小模型配一位資深顧問

我們優化的方法,是 advisor(顧問)策略。

advisor 策略的洞見,對帶過開發團隊的人不會陌生:你只要讓團隊裡的初級工程師接觸得到一位資深工程師,他就會變得更高產。讓資深工程師審他的程式碼、讓初級工程師每天問資深工程師幾個問題,那位初級工程師會進步飛快——而資深工程師只需付出一點點。模型也是一樣。你可以拿一個小而便宜的模型,給它一個能跟更大的模型對話的工具,讓它變強很多。如果你用的是 Sonnet 或 Haiku 這類模型,給它們一位 Opus 等級的顧問,就能讓它們聰明很多——或者,我們今天發布了 Fable,你也可以用 Fable 來當顧問。我也聽到一些關於 Fable 價格是 Opus 兩倍的議論。這正是一個好方法:用一小部分的成本,拿到 Fable 的部分推理能力。因為事實證明,Haiku 和 Sonnet 非常會寫程式、非常會做工具呼叫;它們比較不擅長的,是真正深刻、有洞察力的推理。那麼,何不讓 Haiku 和 Sonnet 用更少的錢做它們擅長的事,只在真正需要那種差異化推理的地方,才用 Opus 和 Fable 這樣的模型。我們看到像 Bolt 這樣的客戶就在這麼做。

切回 demo,看看實際跑起來的樣子。捲到活動串流最上面,你會看到我們在除錯視圖裡,現在用的模型是 Opus 4.8。進 Claude Code,把 advisor 模式打開。

現在我們可以做一件事——直接把模型換成 Sonnet,那會更便宜,對吧?但問題是:這是給 CEO 做商業決策的儀表板,我們錯不起,對吧?所以我們既要便宜,也要正確。兩者都重要。好,換好了。它又顯示了那行——我大概在頂端又錯過了。在活動串流裡。好,看這個。現在的情況是:我們用 Sonnet 呼叫所有這些工具——是 Sonnet 在呼叫——而過程中,Sonnet 會週期性地呼叫 advisor。在 Rod 幫我們找到的這個例子裡,Sonnet 呼叫了跑著 Opus 的 advisor,而 Opus 不同意 Sonnet 做的判斷。Sonnet 說:Metropolis 這筆交易——綠勾,進度正常。Opus 看了逐字稿,真的抓到一個問題,說:「Sonnet,你漏了這一條。」原來,在一份 Gong 逐字稿的最底下埋著:Metropolis 的市長說他非常希望 Cryophane——他非常希望 Cryophane 能出席開幕式。而客戶團隊漏掉了。所以這筆其實是紅的。看這筆交易,你會看到它是紅的,有一個紅色項目。而那要歸功於——對,我們找得到——歸功於 Opus advisor。所以我們不只是省錢——省了錢,還保住了這個層級的高階推理。接著點下去——砰——CEO 已重新安排了 Cryophane 的行程,我們會趕上的,这筆交易會成交。好。我想 Rod 在這個 demo 裡讓我們看到的是:用 advisor,我們可以用更便宜的模型,只在需要的地方用更貴的模型——加上三種不同的 context 管理、context 工程技巧,和 prompt caching。非常感謝,Rod。好,回到投影片。

收尾:2026 年我們發布了什麼

好,收個尾。我們講了 prompt caching——如果你在做 agent,你應該要在 80% 以上,務必去看看。我們講了 tool search tool,讓工具定義不把你的 context 塞爆;程式化工具呼叫,把工具結果擋在外面;然後是 compaction。最後講了 advisor:用更便宜的模型,拿到同等級的推理。

但 Claude 平台演進得非常快,而這是跟上最新能力的好方法。這只是我們 2026 年發布的東西——我不敢相信這張投影片上有這麼多項目。

基於時間,我只點名兩個。我個人超喜歡 workload identity federation,簡稱 WIF。WIF 做的事是移除對 API key 的需求。我知道很多客戶會把 API key 簽進原始碼、隨手亂放——那可能是洩漏風險;有人拿到你的 API key,就能用你的名義查詢。有了 WIF,這個問題被消除了。另一個我要提的是:就在今天我們發布了 Fable 模型,它是 Mythos 級的模型,所以我們得加上額外的安全分類器,這意味著那個模型的封鎖率(block rate)會比其他模型略高。因此我們推出了 fallback 功能:現在在 Messages API 上,你可以列出幾個其他模型,說:「噢,如果 Fable 因為分類器觸發等任何原因處理不了,請求就自動退回(fall back)。」這讓體驗更可靠、更穩健。這只是我們發布的眾多項目裡的兩個——而今年才過了一半。那麼,到此為止,非常感謝大家,祝大會接下來愉快。謝謝。