原理：CI/CD 的「CI（持續整合）」假設是——變更是稀疏的、可預期的，所以用一條固定流水線一關一關跑很合理。這個假設在 agent 時代被打破：變更變成高頻、平行、機器產生。

給聽眾一個記憶錨點：把 CI/CD 想成銀行只開一個櫃台——客人一天來十個沒問題；現在一秒鐘湧進一千個，問題不是櫃台員手腳不夠快，而是「單櫃台 + 排隊」這個模型本身錯了。後面每一段都會回到這個比喻。

為什麼要花一頁講背景？因為「CI/CD 已死」這種話誰都能喊，關鍵是誰在喊。Hugo 是真的在 Google 維運過數百個內部團隊共用的開發平台——他講瓶頸是有傷疤的。

提醒聽眾一個立場：這同時是一家公司（Namespace）的產品論述，後面看到他們的解法時，要分清楚哪些是「行業趨勢」、哪些是「他們家賣的東西」。我們會兩者都標出來。

給聽眾一張地圖：我們不會只停在「CI/CD 死了」這種口號，而是一路走到「那我下週上班可以改什麼」。第五段是給大家帶走的東西。

互動提示：可以先問現場——「你們的 CI 跑一次平均幾分鐘？最近有沒有因為排隊等過 build？」把痛點先勾出來，後面講瓶頸時更有共鳴。

這頁是保險：團隊裡資深、資淺都有，先把六個詞講清楚，後面不會有人卡住。

特別強調 Runner 與 Premerge Queue，因為瓶頸與解法都圍著這兩個轉。Devbox 是 Namespace 的具體產品名，先點到，第三段會展開。

重點是讓聽眾「同意舊設計在當年是對的」。不要把 CI/CD 講成笨——它在人類節奏下是優雅的工程。問題出在前提變了，不是當初做錯。

舉例延伸：可問現場「你們 pipeline 是不是大多 push 才觸發、一步一步跑？」幾乎都會點頭——那就是 human-paced 的活證據。

原理：這是一個數量級（order of magnitude）問題，不是百分比問題。從 1–2 到數千，不是「忙一點」，是「換了一個物理世界」。

數字誠實聲明：演講用「一週一兩個 diff」對比「數千 agent 同時開 PR」來描述量級對比，這是定性的規模描述，不是某一家公司的精確統計，講的時候要這樣說，不要假裝是實測數據。

原理（給工程師的精確版）：這是排隊理論。當到達率逼近服務率，等待時間不是線性增加，而是趨近無限。runner 數固定（服務率固定），agent 把到達率推高，佇列就爆掉。

舉例：高速公路。車流量到某個臨界點，再多一台車不是慢一點，是整段直接堵死。CI 佇列也是同一條曲線。這也解釋了為什麼「加幾台 runner」常常只是把臨界點往後挪一點點。

原理：這頁把技術問題翻譯成財務問題。對工程師：你等 build 的時間是隱性成本；對主管：那是真金白銀的雲端帳單，而且成長最快、最沒人優化。

政府／資安場景的對應：把「成本」換成「可維運性與資源治理」。同樣的道理——當自動化產出暴增，支撐它的運算資源若不治理，會變成最大的隱性負債。措辭用「改善治理、提升可維運性」，不要誇大。

這是全場的轉折點，要停頓一下。原理：當你發現「再怎麼優化都會撞同一面牆」，代表問題出在抽象層（abstraction），不是參數。

舉例：當年從「手動部署腳本」跳到「CI/CD」也是換抽象層，不是把腳本寫快一點。現在輪到 CI/CD 自己被換。用這個歷史類比，聽眾比較不會覺得是在唱衰，而是看到一條演進線。

先給全景，再逐根拆。提醒聽眾抓一條主軸：每一根支柱都在做同一件事——把驗證從「流程後段、靠人推」往前移到「過程之中、自動發生」。

這四項是演講列出的 Continuous Compute 構成要素，接下來四頁每根都配一個工程師日常的例子。

原理：意圖／計畫是 agent 能平行探索的前提。沒有清楚的目標，機器只能照單改一行；有了目標，它可以同時試三種實作。這也呼應大家熟悉的「Research → Plan → Build」工作法。

舉例可換成你們團隊真實情境，例如「把這支 API 加上分頁，且回應格式維持一致」。重點讓聽眾感覺：我給的是意圖，不是逐行指令。

原理：這是「shift-left（左移）」的極致版。對 agent 特別重要——agent 速度快，如果回饋慢，它會在錯誤方向上跑很遠。短迴圈是讓 agent 不暴衝的韁繩。

連結回前面排隊理論：即時驗證等於降低進入佇列的到達率（壞東西不進來），從源頭緩解飽和，而不是事後加 runner。

原理：瓶頸常常不是機器慢，是「等人觸發」。把觸發自動化，把人留在「需要決策」的節點。這對資安治理尤其重要——可追溯、可稽核的自動檢查，比靠人記得按按鈕可靠。

務必強調分寸（呼應 AI 治理原則）：自動跑檢查 ≠ 自動放行。最終是否合併、是否上線，仍應有人類監督。措辭用「強化監測、提升可驗證性」，避免講成「全自動、零人工」。

原理：這解的是「合併時的組合爆炸」。每個 PR 單獨綠不代表合起來綠；變更越多，互相干擾的組合越多。佇列負責用「合併後狀態」來驗證並排序。

舉例可用大家踩過的坑：「main 昨天好好的，今天兩個人各自 merge 完就壞了。」Premerge 佇列就是把這件事系統化、交給 agent 編排，而不是靠運氣與 rebase。

原理：Devbox 是「電腦」比喻的物理載體。可重現＋隔離＋秒級，三個特性缺一不可——可重現才不會「在我這台會過」、隔離才能平行、秒級才談得上 multiverse。

舉例給工程師最有感：「agent 跑測試時，你的筆電不會被吃滿、不用等它。」這是大家當下就痛的點。SSH/VNC 進去除錯也很關鍵——agent 環境不是黑盒，人可以進去看。

原理：快取與增量是「不重做重複工作」。在高頻變更下，重複的部分佔比極高（同一份依賴被 build 上千次），所以省掉它的效益被放大——又一次的「乘上 PR 數」效應，只是這次是往好的方向。

引述要誠實標來源：這是 Namespace 客戶的公開好評，屬於正面證言，不是中立 benchmark。講的時候說「客戶的說法是…」，把性質講清楚。

原理：你無法優化你看不見的東西。前面講「CI/CD 是最沒被優化的支出」，原因之一就是缺乏可觀測性。Analytics 把 duration／flakiness／resource 攤開，才談得上治理。

對資安／政府場景特別點題：可觀測 = 可稽核。私有登錄與存取控制是治理要求，不只是方便。這頁可以橋接到「治理」語彙。

原理：再好的新典範，如果要全員 re-platform，落地率就趨近零。能對接 GitHub Actions／k8s，意味著漸進採用——這也是給聽眾的安心點：不是叫你明天廢掉現有 CI。

策略提醒：對團隊而言，最務實的第一步往往是「在現有 pipeline 上加快取／加隔離環境」，而不是換平台。這頁替第五段的行動建議鋪路。

用途：證明這不只是 PPT 概念，已有真實採用。但要誠實——這些是客戶好評，不是獨立 benchmark。我刻意在來源行標註了性質。

對工程師有感的點：Zed、LiveKit、Framer 都是大家認得、CI 壓力很大的團隊。Hashimoto 用兩年這種「時間長度」比任何百分比都有說服力。

這頁是全場的「一圖總結」。建議放慢，逐列唸，每一列都對應前面講過的支柱／能力，幫聽眾把點連成線。

強調最後一列「擴展模型」：這才是分水嶺。前者是「固定容量＋排隊」，後者是「隨量擴展」。其餘差異都是從這一條長出來的。

這頁很重要——它讓你的分享有公信力。原理：「死」是行銷詞，工程上更準確的說法是「典範轉移／抽象層升級」。確定性檢查（你要的測試、資安掃描）不會消失，反而更該保留。

給結論定錨：不要二選一（全押 agent 或全守舊）。確定性自動化 + AI 編排 的混合，才是落地時的真實樣貌。這也呼應 AI 治理：保留可驗證、可追溯的關卡，由 AI 增強而非取代。

原理：每一條都對應前面一根支柱／能力，且都是「在現有體系內」就能做的小步，不需要 re-platform。鼓勵聽眾挑一條本週就試。

第 4 條最常被跳過卻最關鍵——沒有數據，所有優化都是猜。建議當作起手式：先量一週，再決定先動哪裡。

這是全場最「有感」的一頁，刻意放在收尾前。用大家天天遇到的場景——等 CI、本機被吃滿——讓抽象概念落到肌肉記憶。

收束金句：「差別不在 agent 更聰明，而在它有沒有一台能自己跑的電腦。」這句把標題「agent 需要的是電腦」收回來。可停頓，讓它沉下去。注意：左欄的「12 分鐘」是示意情境，不是統計值，講時說「假設」。

讓聽眾拍這一頁。五點剛好對應五段。唸的時候每點配一句前面的例子，幫記憶。

最後一點再次強調「保留人類監督」——這是把技術趨勢扣回治理原則的收尾，對工程與政府場景都成立。