From Blind Spots to Merged PRs: Continuous Agentic Performance Optimization - May Walter, Hud
三句話摘要
建立自動化 AI Agent 工作流程，持續發掘生產環境的性能優化機會並自動驗證修復。 自動化不只是讓現有的工作流更快，而是透過精確的運行時上下文和高信任度的驗證，發現工程師本來不會主動尋找的優化機會，但前提是定義清楚什麼才算值得做。 調查成本是隱形的決策障礙：團隊無法預估性能優化調查要花多久，導致即使已知有問題也傾向擱置。傳統的是個「漏桶」——問題被忽視直到必須緊急處理，然後回到忽視的循環。
重點整理
重點- 1
調查成本是隱形的決策障礙：團隊無法預估性能優化調查要花多久，導致即使已知有問題也傾向擱置。傳統的是個「漏桶」——問題被忽視直到必須緊急處理，然後回到忽視的循環。
- 2
Agent 加速暴露了交付與穩定性的差距：Google 的 DORA 2026 指標顯示，AI 提升了個人工程師效率，但團隊層級的軟件交付速度和穩定性未見改善，甚至軟件故障更頻繁。需要 Agent 不僅能快速開發，也能快速修復。
- 3
運行時上下文是 Agent 推理的基礎：Agent 在代碼級推理，但生產數據存在於服務與端點級，中間存在語言不匹配。方案是「Proud to Code」——將生產現象解釋為函數級的具體事實（特定查詢、調用頻率、端點時延對應的函數瓶頸），讓 Agent 有精確的推理基礎。
- 4
信任度是自動化的前提，需要三層驗證：Agent 必須驗證建議的修復在實際運行時有效果，評分要同時考量業務影響與風險。最後由人類審核，確保投入時間在真正值得做的事上，而非盲目信任 80 個 Agent 生成的 PR。
實用技巧與重點
乾貨- 技術棧
- 基礎設施：GitHub Agent Workflows（供應商中立）
- 代碼執行：Claude Code
- 上下文層：MCP（Motion Control Protocol）捕捉函數級運行時智能
- 數據庫：ClickHouse（列式數據庫，查詢效能不同於傳統 SQL）
- 查詢語言：HUD Query Language（基於 ClickHouse 查詢函數與端點的結構化資料）
- 觸發機制：定時運行（週度）+ Webhooks（SLO 告警時）
- 通知：Slack（可替換為 Teams、Email 等）
- 性能優化發掘對象
- 人工延遲：Timeouts、Sleeps
- N+1 查詢
- 缺失索引
- 順序操作（Sequential assignments）
- Distinct 語句未使用索引
- 評分維度（ROI 計算）
- 熱路徑（Hot path）：端點每週調用次數
- 業務影響：支付流程、註冊流程等關鍵路徑優先
- 時間節省：當前 P99 時延 vs 優化後預期時延
- 修復風險：是否涉及數據遷移、複雜邏輯變更
- 優選高 ROI 低風險的修復（而非最高影響、高風險的修復）
- 流程步驟
- 週度定時運行，分析生產追蹤資料與查詢時延
- Agent 查詢 HUD 語言，識別端點瓶頸
- 提出修復建議，重新運行測試
- 驗證修復的實際影響（對該端點時延的改善）
- 生成人類可讀報告（端點名稱、常規時延、異常情況、修復方案、預期效果）
- 優先級排序後逐個呈報
- 人類評估與決策是否創建工單或自行 PR
- 常見陷阱與解決方案
- 「合理但未驗證」(Plausible unverified)：要求在實際生產環境驗證修復效果
- 複雜查詢：建立專用技能集合，幫助 Agent 正確查詢 ClickHouse
- 「懶修復」：不只捕捉異常，要追溯根本原因
- 上下文過多或過少：只在 P99+ 請求時捕捉取証，減少信號雜音
結論
結論“自動化不只是讓現有的工作流更快，而是透過精確的運行時上下文和高信任度的驗證，發現工程師本來不會主動尋找的優化機會，但前提是定義清楚什麼才算值得做。”
完整解析
詳細性能優化一直是工程團隊的痛點。產品經理說某個頁面太慢，工程師無法預估調查需要多久，可能是一小時，也可能是一週。這種不確定性導致問題長期被擱置。等到真的影響業務了，團隊才進入危機模式，緊急投入資源修復，修完後又回到忽視的循環。這是經典的「漏桶問題」——根本不是故障本身，而是調查成本是隱形的，導致優先級判斷失真。
講者所在的公司 HUD 專注於為 AI 編碼 Agent 提供運行時智能層。他們發現，Google 2026 年的 DORA 指標揭示了 AI 革命的尷尬現實：AI 大幅提升了個人工程師的效率，但團隊層級的軟件交付速度反而停滯，穩定性還下降了。原因很簡單——開發變快了，但修復沒有相應加快，所以故障反而增多。突破口在於：如果既能用 AI 快速開發，也能用 AI 快速修復，就能實現期望中的 AI 紅利。
他們設計的方案是自動化性能優化的調查與驗證流程。系統每週運行一次，分析生產環境的函數級追蹤資料，用 Agent 提出優化建議，驗證修復在實際環境的效果，然後優先級排序後呈報給工程師。聽起來簡單，但細節藏著大量工程挑戰。首先是上下文匹配問題：Agent 在代碼級推理（函數、變數、邏輯），但生產指標存在於服務和端點層級（服務 CPU、端點 P99 時延）。這兩個層級之間缺少連接。他們的解決方案叫「Proud to Code」：將生產現象轉譯為函數級的具體事實，比如「這個端點在某次特定請求中花了 7 秒，時間分佈在這三個函數呼叫」。這樣 Agent 就有了精確的推理基礎。
其次是驗證的精確性。Agent 一開始會提出「合理但未驗證」的建議——聽起來對，邏輯清楚，但實際運行不工作。他們因此強制要求 Agent 在模擬環境中重新運行相同的查詢流程，量化修復的實際效果。第三是複雜查詢。他們使用 ClickHouse 數據庫，它是列式存儲，查詢模式與傳統 SQL 不同。他們為 Agent 構建了專用的「HUD 查詢語言」和技能集合，這樣 Agent 就能準確查詢而不是猜測。第四是「懶修復」的陷阱——Agent 有時會建議只捕捉異常而不根除根因，或者簡單地增加超時而不優化實際性能。
最後也最重要的是人類在循環中的位置。不是開 80 個 PR 讓工程師們埋頭苦幹，而是一次報告一個機會、按 ROI 排序。ROI 的計算涵蓋熱路徑（端點每週被調用多少次）、業務影響（支付流程優先於日誌記錄）、修復成本（是否需要數據遷移）。講者發現，生成人類友好的報告——用自然語言解釋問題、時延數據、修復方案和預期效果——比冷冰冰的程式碼建議有效得多。工程師看到「這個端點通常 200ms，有時跳到 45s，原因是沒用索引的 distinct 查詢」，比看 diff 容易理解得多，也更容易被說服。
關鍵時刻
Pipeline v2帶時間戳的重點，會在逐字稿層級分析上線後產生。目前請先透過原始影片觀看。
事實查核
Pipeline v2說法查證是下一次管線升級的一部分。KeyFrame 只會顯示它真正能驗證的內容。
