May Walter - From Blind Spots to Merged PRs: Runtime Intelligence for Continuous Agentic Performance
三句話摘要
用 AI 代理自動化性能優化的調查與優先化，而非直接自動修復代碼。 少做但做對，用豐富的上下文和風險評估讓代理的提案可信，才能在人類工作流中真正發揮效用。 調查階段的自動化勝於修復自動化：公司往往因不知道修復成本（1 小時到 3 週）而延遲性能優化。自動化調查流程，讓工程師快速了解投資報酬率，才是優先化的關鍵。
重點整理
重點- 1
調查階段的自動化勝於修復自動化：公司往往因不知道修復成本（1 小時到 3 週）而延遲性能優化。自動化調查流程，讓工程師快速了解投資報酬率，才是優先化的關鍵。
- 2
運行時智慧是橋梁：生產環境說的是「端點 P99 耗時 6 秒」，代碼層說的是「函數內存洩漏」，兩者語言不同。需要感測器在函數層級記錄運行頻率、耗時、失敗與業務影響，才能讓代理準確推理。
- 3
信任需要高準確度：如果代理提議頻繁失效，工程師會忽視報告（如 DataDog 有 700 個未處理的告警）。寧可少做但做對，也不要大量低質量 PR。只提出風險低、影響大的改進。
- 4
上下文決定代理能力：代理不只缺少運行時上下文，也缺業務上下文。需明確定義「什麼是重要的」（如影響支付、身份驗證的路徑優先），代理才能做出正確決策。
實用技巧與重點
乾貨- 使用工具：Claude（代理引擎）、GitHub Actions（執行排程）、Slack（報告發送）、ClickHouse（查詢分析）、MCP 伺服器（Hook 生產數據）
- 架構層級：查詢語言層 → 技能層（HTTP 500 處理、內存洩漏診斷等）→ 自動化層（自動 PR、死代碼清除）
- 執行週期：每週或每兩週運行一次，自動生成性能報告
- 評分維度：性能提升百分比（如 30%）、風險等級、影響範圍（業務流程級別）
- 案例數據：某客戶 15 年老代碼庫找到 6 年前遺留的 N+1 查詢問題
- 成功標準：端點 P90 從 100 毫秒降至穩定（不再偶爾飆升到 45 秒）
結論
結論“少做但做對，用豐富的上下文和風險評估讓代理的提案可信，才能在人類工作流中真正發揮效用。”
完整解析
詳細Hood 創始人 Mila Wolter 分享了一個常見的企業困境：產品經理要求加快頁面加載，工程經理調查後發現「可能需要 1 小時到 3 週」才能確定具體瓶頸，於是問題被一再延期。根本原因是調查成本高、收益不確定，工程師無法有效優先化性能改進與新功能開發的競爭。
為了解決這個問題，Hood 開發了一套運行時智慧系統。核心思路是自動化調查階段，而非直接自動修復。具體做法是在生產環境部署感測器，主動記錄每個函數的運行頻率、耗時、故障率與業務影響。這些數據每週通過 GitHub Actions 流向 Claude 代理，代理基於代碼分析識別反模式（如 N+1 查詢、內存洩漏、人為延遲等），並按「性能提升 % × 影響範圍 ÷ 實施風險」計分，將最值得做的改進自動生成為 PR 草稿與 Slack 報告。
但實踐中發現了三個關鍵挑戰。首先，代理提議看似合理但未經驗證——聽起來正確的優化不一定是真正的瓶頸，測試環境的結論往往與生產不符。其次，生產環境和代碼層的語言不同——工程師說的是「端點 P99 6 秒」，代碼層說的是「函數內調用」，兩者的因果關係需要額外的上下文映射才能讓代理推理。最後，大量 PR 會引發信任崩潰——如果一次提交 80 個無人問津的 PR，工程師的反應和面對 DataDog 700 個未處理告警一樣：我乾脆不看。
解決方案是在代理層面引入業務上下文與風險評估。不追求最優化方案，只找影響最大、風險最低的改進。關鍵是明確定義「什麼值得投入」（如影響支付、身份驗證的熱點路徑優先），這樣代理才會向工程師呈現一個可信的、具體的提案：「你的端點 P90 是 100 毫秒，但偶爾飆到 45 秒。根因是 MongoDB distinct 查詢，換成搜索可提升 30%。預計 2 小時修復。」收到這樣清晰的提案，工程師會樂意優先化並驗證結果。整個流程形成閉環：自動化發現 → 人工審核合併 → 測量效果 → 不斷改進。
關鍵時刻
Pipeline v2帶時間戳的重點，會在逐字稿層級分析上線後產生。目前請先透過原始影片觀看。
事實查核
Pipeline v2說法查證是下一次管線升級的一部分。KeyFrame 只會顯示它真正能驗證的內容。
