讓 AI agent 接手效能除錯

088Rajat Shah（Netflix）33:382026-07-28

AI Agents for Performance: Ship Faster, Pay Less — Rajat Shah, Netflix

Netflix 工程師分享如何用 AI agent 讀效能剖析資料、揪出壞的程式碼模式，做到自動生成修復用的程式碼審查。

重點摘要

程式碼比效能長得快：coding agent 讓寫程式碼的速度衝到 10 倍快，但省資源的環節顧不到，運算成本也跟著往上衝；agent 也摸不清公司內部框架與慣用寫法，容易套用別的程式碼庫看過的模式。
人工抓效能瓶頸很痛苦：一般工程師得先觸發 profiling、下載資料、開視覺化工具，在呼叫堆疊裡大海撈針找瓶頸，動輒二十分鐘起跳，通常只在半夜出包才會做。
剖析資料的格式很好認：不管服務是用什麼語言、什麼執行環境寫的，profiler 吐出來的呼叫堆疊與 CPU 用量資料結構都很類似，agent 本來就看過大量常見的壞模式，例如 O(n²) 迴圈、重複配置物件等，抓起來自然快。
從抓一個問題到掃全公司：Netflix 實測讓 agent 讀 profiling 資料、自己找到程式碼庫裡對應的方法、送出修復用的程式碼審查，全程不到五分鐘；同一個壞模式甚至一次在七個服務裡都被抓出來，修完後 CPU 省下 0.5% 到 4.6%。
靠 pattern catalog 養出長期記憶：把發現的模式與反模式寫進一個集中的 Git repo 當 catalog，讓沒有記憶的 LLM 也能重複利用之前的發現，愈多服務跑過 profiling，catalog 就愈準。
人仍是最後一道關卡：不管是靠單元測試、整合測試，或用 canary 部署比較新舊版的 CPU 與延遲，最後要不要合併那份修復用的程式碼審查，還是得工程師點頭，因為改動正式環境的程式碼風險很高。

時間軸13 段

00:00	開場自介	Rajat Shah 說明他是 Netflix AI platform 團隊的 staff software engineer，這場要分享怎麼靠導入 AI agent 提升效能工程的產出。
00:46	問題的起點	coding agent 讓寫程式碼的速度衝到 10 倍快，但運算成本也跟著往上衝，因為 agent 不見得寫得出最省資源的程式碼。
02:12	人工調校的痛點	一般工程師得觸發 profiling、下載資料、開視覺化工具，在呼叫堆疊裡大海撈針找瓶頸，通常只在半夜出包才會做。
05:11	兩個核心假設	不同語言寫的服務，profiler 吐出的呼叫堆疊資料結構其實很像；agent 本來就看過大量常見的壞模式，像 O(n²) 迴圈、重複配置物件。
07:23	第一次驗證成功	把 profiling 資料餵給 coding agent，它不用看原始碼，就能從呼叫堆疊認出某個方法被用在 quadratic 演算法裡。
10:38	端到端流程跑通	agent 抓到問題後自己 clone 對應 commit 的 repo、找到程式碼、送出修復用的程式碼審查，全程不到五分鐘。
12:30	一次掃出全公司	同一個壞的 counter 物件迭代模式，一次在七個不同服務裡都被揪出來，修完後 CPU 省下 0.5% 到 4.6%。
15:20	導入長期記憶	為了讓沒有記憶的 LLM 也能重複利用發現，講者提出把模式與反模式寫進集中的 Git repo 當 catalog。
20:47	送審前先驗證	送出程式碼審查前，agent 要先跑過單元測試與整合測試，再靠 canary 比較新舊版 CPU 與延遲，錯誤率升高就視為警訊。
23:36	人仍要拍板	profiler 只能給估計值，真正要不要合併還是工程師說了算，因為改動正式環境的程式碼風險很高。
24:16	從被動走向主動	一開始的做法是等問題出現才救火；catalog 養大之後，可以往前移，讓 reviewer agent 在程式碼審查階段就提醒。
30:48	自動化程度分級	這場主要在講「工具與整合」這一級的自動化；要再往上讓 agent 自己規劃決策，得先做好評測、沙箱與資安防護。
33:16	收尾致謝	講者感謝聽眾，提到之後可能把內容寫成更詳細的部落格文章放在個人網站。

值得記的話5 句

In this talk, I'm here to share how we did improve our performance engineering throughput by introducing AI agents into the mix.這場要分享的是，我們怎麼靠導入 AI agent 提升效能工程的產出00:00
it knows that this is consuming 8.8% of the CPU time during that period of profiling.它抓得出這段程式碼在那次剖析裡吃掉了 8.8% 的 CPU 時間11:00
And if fixed across all of those different code repos, it could have savings between 0.5% to 4.6% of CPU cycles.把這些不同的程式碼庫都修好，CPU 週期可以省下 0.5% 到 4.6%13:42
That's the reactive path that I just covered so far, which means you have the code already running in production, and now you're trying to improve it.這就是目前講的被動路徑：程式碼已經在正式環境跑，你才回頭想辦法優化它24:16
And if you shift left all the way, like why even wait until a code review?如果把這件事一路往前移，何必等到程式碼審查才處理25:29

名詞與人物6 個

Netflix AI platform: 講者所屬團隊，負責機器學習模型代管用的大規模分散式系統。
profiler: 用來剖析正式環境服務、抓出呼叫堆疊與 CPU 用量的工具，是這整套流程的資料來源。
pattern catalog: 講者提出的核心機制：把發現的效能模式與反模式集中寫進一個 Git repo，讓沒有記憶的 LLM agent 也能重複利用先前的發現。
canary deployment: 讓新舊兩個版本的程式同時跑一段時間、比較 CPU 與延遲差異，作為要不要送出程式碼審查的判斷依據。
O(n²): 這場第一個被 agent 揪出來的效能反模式，指迴圈裡藏著平方級複雜度的計算。
TorchFix: PyTorch 官方的公開 repo，收錄可用來優化 kernel 與模型圖的反模式清單。

提到但沒有展開

講者提到之後可能把這場內容寫成更詳細的部落格文章放在個人網站，但沒有進一步說明時間或連結。
講者提到如果要走到讓 agent 自己規劃與決策的自動化程度，需要投入更多評測、沙箱與資安防護（例如防止 prompt injection），但這場沒有展開細節。
講者提到 C++ 與 PyTorch 生態圈已經有公開的優化撇步來源，可以當作 catalog 的起點，但沒有列出具體清單。

Agent開發工具評估

在 YouTube 看原片 ↗