GitHub Copilot 一個月在平台上打出的訊息量，用夠長的時間軸來看是「以兆計」的等級。當量體大到這個程度，工程上的每一個小數點都會被放大成真金白銀。GitHub 的產品長 Mario Rodriguez 跟 Anthropic 的 Brad Adams 在「Code with Claude」這場演講 Caching, harnesses, and advisors: Building on Claude at GitHub scale，把 Copilot 在這個規模下踩過的坑、學到的東西攤開來講。小編覺得這場特別值得看的地方在於: 它不談空泛的概念，而是談一家每天打數十億次推論的公司，到底盯著哪些數字、做了哪些取捨。

🎬 影片: Caching, harnesses, and advisors: Building on Claude at GitHub scale

以下是重點整理:

1. 三條主線: 快取、advisor、量測

Mario 把整場濃縮成三件事，剛好也是 Copilot 接平台時幾乎所有決策的底層。

第一是 prompt 快取。他講得很白: 沒有快取「我們不會死，但天啊，花的錢會多到嚇人」，所以光是 1% 的效率提升，對他們就是好幾百萬美金的差別。第二是跟 Anthropic 一起做的 advisor 機制，目標是讓使用者在「對的時間」拿到「對的智慧」，底下又分成 advisor 跟 critic 兩種玩法。第三是每次新模型一推出，怎麼有條理地把它接進產線。

這三條線背後都連回 GitHub 自己定的幾根柱子: 讓開發者保持在心流、讓團隊提速、用智慧跟信任在規模下把事情做成。Mario 說幾乎每一個產品決策都踩在這幾根柱子上，連談平台整合也一樣。

2. 為什麼 1% 的快取效率值好幾百萬

這個比喻很到位。Mario 把快取效率比成高頻交易: 單看一筆，1% 沒什麼感覺，但乘上每天數十億次呼叫，1% 就是好幾百萬。

所以對 Copilot 來說，快取根本不是「要不要做的最佳化」，而是這個規模的服務能不能活下去的前提。這也解釋了為什麼後面那麼多篇幅，都在講怎麼把快取命中率往上推、怎麼避免它被無端打掉。

3. 先有儀表板，再談最佳化

Mario 的第一個務實建議是: 先把快取命中率「儀表化」。沒有資料，要做決策真的非常非常難。

他特別提到 Anthropic 前陣子釋出了一個官方儀表板（Copilot 有先拿到預覽），可以看自己的快取命中比、對 Messages API 送了多少訊息。他直接喊話: 還沒去看的話，拜託去看一下，這是第一步。

不過 Copilot 真正盯的是自己那套，而且重點不是看單一數字，是看「模型之間的差異」。

這張就是他們其中一個儀表板的長相: 左邊是 Opus 4.6、中間是 4.7，旁邊那欄就是兩者的差值，還把 Sonnet 跟 Haiku 一起拉進來對照。新模型一進來（有時候在很早的測試階段就拿到），他們會跑一整套基準測試，像 Terminal Bench 2 這類，再加上自己內部的題庫，決定模型表現夠不夠格上線。上線後繼續盯資料，大概 30 天（有時更快）就能把那個模型的最佳化收尾。

這個差值還有一個很實際的用途: 要不要把預設模型從 4.6 換成 4.7，就看兩者的快取命中率差多少。Mario 說這個例子裡差了 1.3%——聽起來很小，但乘上每天數十億次呼叫，又是一大筆錢，所以這種決策一定要有資料撐著。

4. 健康的快取命中率是 94% 以上，掉到 70% 通常代表有 bug

這是小編覺得最有衝擊力的一個數字。要在規模下運營這個服務，Copilot 的快取命中率通常得跑在 94、95、96% 以上。

更狠的是反過來看: 如果命中率掉到 70%，那「八九不離十是有 bug」。意思是某個地方做錯了，可能是呼叫模型的方式、組 prompt 的方式、或整條流程出了問題，得回頭改。換句話說，他們不是把高命中率當「加分題」，而是當「健康指標」——低了就代表系統壞了。

他也補了一個常被忽略的成本算術: 從輸入端看，命中快取的 token 只算 10% 的成本，所以「命中」跟「沒命中」之間是 10 倍的差距。如果你一直讓快取失效，等於是用 10 倍的價錢在付那些 token。

5. 前綴要靜如止水: 別在前面塞會變動的東西

要把命中率從 50% 推到 70%、再推到 80%、90% 以上，Mario 強調這「不是運氣，是大量的硬功夫跟工程」。他點出三個關鍵，而且每一個都是踩過坑換來的教訓。

第一個是: 前綴（prefix）裡絕對不要放會變動的內容。快取的階層是 system prompt → 工具 → 對話歷史 → 最後送出的訊息，越前面越要穩。他舉了一個血淋淋的例子: 他們曾經在 system prompt 裡塞了一個 UUID，這東西每次都在變，等於每次都把整段快取打掉，命中率直接崩盤。所以 system prompt 要靜到不能再靜，一點會變的東西都別放。

6. 工具只在必要時才動，而且要有回歸測試護體

第二個教訓是工具。如果你動態載入工具、讓那段工具前綴一直變，那後面整段對話又會被連帶失效一次。

Mario 說他們在工具這塊吃過不少虧，所以建議是: 一定要有大量的回歸測試。因為你之後一定會大量實驗 skills 跟工具，整條流程裡得有測試守著，確保你在動工具的時候，沒有不小心把快取打爛。這點正好呼應投影片那段程式碼結構——左邊三行標語寫的就是「不放動態內容、只在必要時改工具、維持快取親和性」，把這三條規矩直接寫死在程式裡。

7. 多模型 harness 下的「快取親和性」最難搞

第三個、也是最硬的一個: 快取親和性（cache affinity）。Mario 直言，當你跑的是一個「多模型 harness」時，這件事真的很難。

拿 Copilot 當例子: 一個使用者可能先呼叫 Opus，接著叫一個 GPT 模型，再叫一個開源模型，然後又繞回 Opus。在這一連串切換裡，他得保證下一次的 Opus 呼叫——也就是接著上一次 Opus 留下來的那段——還能對到正確的快取。光是要在多模型 harness 裡守住這件事，他們就投入了非常多工。

這段對任何在做「多模型路由」的人都是提醒: 模型一換來換去，快取就容易斷，而把它接好，是真正的工程難題。

8. 破除迷思: 長上下文不等於更貴

Mario 說他常被客戶問: 用長上下文是不是就比較貴? 他的答案很乾脆: 不是。

他們做了一個快速實驗來佐證，投影片標語直接寫「長上下文 = 更多 token，但不等於更貴」。同一個模型、模擬不同行為: 較小的上下文視窗，平均壓縮次數是較大視窗的三倍。

關鍵在這裡: 輸出 token 比輸入貴很多（以 Opus 為例大約是 5 比 25），而每做一次壓縮，光是要把訊息摘要起來就得吐出大約 4,000 個輸出 token。所以你越常壓縮，輸出 token 就越爆，連帶快取也被嚴重打掉。結論是: 長上下文視窗本身不會讓你花更多錢，真正要懂的是「壓縮是怎麼被觸發的」，並依場景幫使用者把它管好。

9. 快取這塊的收尾心法

Mario 把快取這段收在幾句務實的話上。

先把命中率儀表化、做一個你真的會去看的儀表板，把時間投進去——官方已經幫你出一個了，至少先用那個，然後再進一步去看模型之間的差異、看上線前跟上線後的變化。他甚至講了一句很重的話: 在你把命中率看清楚之前，其他效率都不重要。把它從 50 推到 70、推到 90，會花掉大量工程時間，但這就是優先級最高的事。

另一個重點是「分介面量測」。Copilot 不只有 VS Code，還有 Copilot CLI、雲端的 coding agent、IntelliJ、行動版。介面這麼多，你得決定要「跨介面共用同一套 harness」還是「個別微調」，而且每次出版本都要清楚知道: 這次是進步了還是退步了。

10. advisor 策略: 小模型卡關才呼叫大模型

接著 Anthropic 的 Brad Adams 上場，講另一條從 Copilot 來的回饋: 團隊想要「Opus 等級的智慧，但 Haiku 等級的價格」。做法叫 advisor 策略，靈感來自資淺工程師配個資深導師。同理，你拿 Haiku 當執行者，給它一個能呼叫 Opus 的工具; 大部分時候 Haiku 自己處理，只有遇到它自己搞不定的關鍵點，才去問 Opus。因為動用 Opus 的時機壓得很保守，他們的評測顯示這樣能拿到接近 Opus 的智慧，成本卻低很多。Brad 還現場 demo 了一道刁鑽題目（要印出 Hello World!、但程式碼不能用到某些字母）: 純 Haiku 一直瞎試兜不出來，加了 advisor 那邊則問 Opus 一句、拿到提示就收工。

編按: 這種「小模型卡關才呼叫大模型當顧問」的做法，小編是持保留態度的。它本質上就是一種跨模型的 multi-agent 拆分，而這類架構的代價（token 成本常見 3–10 倍、context 污染、協調開銷）在實戰裡很容易被低估。之前那篇 Multi-Agent 反模式與模式 整理過不少證據，包括 Cognition/Devin 的實戰心得——很多時候把單一 agent 的 prompt 跟 harness 調好，效果不輸甚至勝過硬拆出一個顧問模型。demo 很漂亮，但要不要真上 advisor，建議先拿自己的場景做對照實驗再說。

11. rubber duck: 把 critic 插在「會複利」的時間點

Mario 回到台上又補了一招，叫 rubber duck（橡皮鴨）。他說「我們是 GitHub，命名上總有點怪」，但這招的核心是: 在對的時間點插入一個「批評者」(critic)。

advisor 跟 critic 的差別在角色: advisor 比較像顧問，回答「這個我來幫你算」; critic 則更主動地說「我覺得你應該這樣做」。rubber duck 的流程是——模型在實作到一半時主動去要一份批評（跨模型家族，例如找 4.6 跟 4.5 Opus），拿到批評後，在真正動手前先修正計畫，再照修好的方向做下去。

他們把這個批評者插在三個核心位置: 第一是「擬好計畫之後」（很多使用者都是先做計畫再執行）; 第二是「複雜實作之後」，他形容這像一種「預先的程式碼審查」，先擋一輪，能省下拖到正式審查才被打槍的 token; 第三是「寫完測試、但還沒跑測試之前」，在 CI 測試很花時間的地方插一刀，能更快把開發者送回心流。

Mario 自己最有感的是計畫階段: 現在這些系統都越來越會規劃，如果你在這個點把錯誤抓出來，後面拿到的收益最大。投影片那句話講得很精準: 把智慧集中在「會複利的時刻」，而計畫階段就是槓桿最高的那個點。rubber duck 現在已經是 Copilot CLI 裡的實驗功能，下載開起來就能用，你可以直接說「幫我擬個計畫，並找 rubber duck 諮詢一下」，就會拿到一份跨模型家族的快速批評。

12. 新模型上線的方法論: 從 Cappy 端點到雙軌評測

第三大塊回到「新模型怎麼接」。Mario 開玩笑說，接平台的人都知道那種感覺: 週六早上五點接到電話，對方說「我們禮拜二要發新模型囉」。一開始他們做得很亂，但這兩年半下來，已經磨出一套很有方法的流程。

Anthropic 給一個待測模型，他們先把它接進內部叫 Cappy 的東西（也就是 Copilot API），開出一個端點。從端點往下要做三件事: 一是在 harness 跟 prompt 上動工，因為是多模型 harness，得更新各家的 system prompt（這塊跟 Anthropic 密切合作）; 二是把工具介面調對、調好; 三是微調 agent 迴圈（這部分他說現在已經不太需要動了），然後在上下文管理、壓縮、衝到正確的快取命中率上投入更多。

接著是兩條軌: 離線基準測試，跟內部試用（dogfooding，可以理解成線上基準測試）。大量微軟工程師、GitHub 工程師、還有一批密切合作的使用者會實際去用、給回饋。然後把發現整理成一份文件——現在不只寫文件，還會展開成更細的簡報——跟 Anthropic 來回循環，談 API 要改什麼、甚至模型本身或 checkpoint 要怎麼調，一路循環到模型正式發表。

13. 離線只是基準線，真功夫在線上

這一段是小編覺得對做 eval 的人最受用的判斷。Mario 說: 離線評測會給你一個指標沒錯，但它「不會是現實」。

你從線上評測、從上線後的線上實驗學到的，遠比離線多。離線只是設一條基準線——如果那條線穩定，你大致知道上線會長怎樣，能給個不錯的預期。但所有細節都不是靠離線磨出來的。實務上他們常常要花好幾天、甚至好幾週，靠線上實驗（大量 A/B 測試）才把一個模型整個調順，而且每週都有報告往上呈報給 Anthropic、也橫向同步給各團隊。

14. 最後的鐵律: 量「結果」，不要量「活動」

優化 harness 時，Mario 把它拆成四個環節: 組 prompt 跟上下文、呼叫模型、執行工具、把結果接回去再迴圈。

他花最多時間的地方，是「執行工具」跟「組 prompt 跟上下文」這兩塊。工具對他們非常重要，但他也警告: 工具越多，混亂越多、要調的越多。「上百個工具不是好事」——你應該分介面去調，針對精確的場景配上對的工具包。每要引入一個新工具，他們都會在模型層跟工具執行層兩邊，花大量時間去優化 harness。

收尾他丟出兩個高層次原則。第一，訊號要「三角驗證」: 公開基準測試、內部基準測試、內部試用、A/B 測試、線上遙測都要有，而且要能用統計顯著性去信任它們。第二、也是最關鍵的一句——量「結果」，不要量「活動」(measure outcomes, not activity)。他舉例: 程式碼的「採用率」還行，但「存活率」是更好的指標。因為如果你接受了一段程式碼、過一陣子又把它刪掉，那其實根本沒達成目的。採用率再漂亮，存活率很低，就代表你沒做對事。

這也是整場演講最值得帶走的一句話。在 AI 時代做產品，如果只盯著那些好看的單項指標，很容易為了拉高某個數字，反而把整個產品真正該量的東西搞砸了。Copilot 在兆級訊息量下學到的，說穿了不是什麼花俏的招式，而是一種紀律: 盯對的數字（快取命中率、存活率）、把智慧花在會複利的時刻，然後相信線上的現實，勝過離線的想像。