星期二
Kubernetes 節點 Swap、Copilot 動態工作流｜10/6
3 則新聞，長度 3 分 35 秒
0:00 / 3:35
本集重點
Kubernetes 團隊以新實測展示 NVMe swap 可提高閒置型 Agent 沙箱與 CI 工作負載的節點密度，但過度依賴 swap 會拖慢活躍記憶體。GitHub Copilot 的動態工作流與 code review API，則讓多階段代理流程更可重用，也更容易接進既有審查自動化。
本集新聞
-
Kubernetes 節點 swap 實測：Python 沙箱密度提高至 3 倍
Kubernetes 官方部落格於 10 月 5 日發表 NVMe Local SSD 節點 swap 的工程實測，涵蓋 CI 編譯、headless browser 與 Python 沙箱。作者在其 gVisor Python 測試中，將單節點容量由 80 個提高至 240 個；該數據限於文章所述環境與工作負載。
閱讀原文：Kubernetes Blog對工程師的影響
對間歇執行的 Agent 沙箱、瀏覽器測試及 CI 批次工作，swap 可換出閒置記憶體並提高單節點密度。這不是 RAM 的替代品：文章觀察到工作集被換出時編譯時間會增加超過 40%。平台團隊應在自家節點量測延遲、OOM 和磁碟用量，再調整 kubelet swap 設定與工作負載記憶體界線。
-
GitHub Copilot 動態工作流進入 public preview
GitHub Copilot 的動態工作流已提供給 Copilot CLI、Copilot app 與 Copilot SDK。開發者可用程式碼定義 Agent 流程，包含循序或平行任務、結構化結果傳遞、子 Agent 驗證與人工檢查點；功能仍處於 public preview，CLI 需開啟 experimental features。
閱讀原文：GitHub Changelog對工程師的影響
常見的發布檢查、跨檔案掃描與多階段調查可以重複執行，並把固定控制步驟和 Agent 判斷分開。團隊要維護 extension 及流程定義，且預覽行為可能變更；短小任務通常不值得增加編排層。
-
GitHub Copilot code review API 正式可用
GitHub 於 10 月 2 日宣布，Copilot code review 可透過支援的 REST 與 GraphQL API 要求，並可在每次請求指定 review effort。功能正式提供給 Copilot Pro、Pro+、Max、Business 與 Enterprise 方案。
閱讀原文：GitHub Changelog對工程師的影響
CI、發布機器人或內部開發入口可從既有系統啟動 Copilot 審查，並依工作需要設定 effort。接入時應明確定義觸發條件、重複審查與人工核准流程；API 自動化審查不會取代合併責任與人工判斷。
逐字稿
早安，今天整理 3 個和 AI 開發流程及執行環境有關的消息。Kubernetes 的新實測談如何用 NVMe swap 增加節點承載量；GitHub 則把可重用的 Agent 流程帶進 Copilot，並開放程式化要求 code review。
先看 Kubernetes。Kubernetes 官方部落格在 10 月 5 日刊出一篇新工程分析，測試已在 Kubernetes 1.34 達到正式支援的節點 swap，並把 swap 放在 NVMe Local SSD。作者測了 CI 編譯、瀏覽器沙箱和隔離的 Python 工作階段；其中 gVisor Python 沙箱從單節點 80 個提高到 240 個。這是作者在特定 GKE 與工作負載上的測量，不代表所有叢集都會得到相同比例。文章也指出，若把容器記憶體壓得太低，讓活躍工作集也被換出，核心編譯時間會增加超過 40%。編輯觀察，這對執行間歇性工作、等待使用者輸入的 Agent 沙箱，以及 CI 批次工作特別有參考價值，因為閒置記憶體可能被移到磁碟，讓節點容納更多 Pod。它不能取代 RAM；平台團隊應先用自家節點與工作負載測量延遲、OOM 和磁碟使用，再設定 swap 上限與工作負載的 memory request、limit。
再來看 GitHub Copilot 的動態工作流。GitHub 在 10 月 1 日宣布，Copilot CLI、Copilot app 和 Copilot SDK 都能使用以程式碼定義的流程，把一般自動步驟和一個或多個 Agent 串在一起。流程可依序或平行執行、傳遞結構化結果、安排子 Agent 互相檢查，也能在檢查點暫停，等人確認後再繼續。Copilot app 不需額外設定；CLI 目前要開啟實驗功能。這項能力仍是 public preview。編輯觀察，常做的發布檢查、跨目錄掃描，或先蒐集事故資料再整理分析結果的團隊，可以把順序、驗證和人工核准點固定下來；Agent 負責需要判斷的部分。相較每次只靠一段 prompt，流程程式本身更容易重跑和觀察，但團隊也要維護 extension 與工作流定義，而且預覽功能仍可能變動。簡單問題不需要多一層編排。
第三則是 Copilot code review API。GitHub 在 10 月 2 日將透過 REST 和 GraphQL API 要求 Copilot 審查程式碼列為正式可用，也允許每次要求指定 review effort。這項功能適用於 Copilot Pro、Pro+、Max、Business 和 Enterprise。編輯觀察，維護 CI、發布機器人或內部開發入口的團隊，現在可以從既有系統啟動審查，而不用依賴人工到 Pull Request 頁面操作。較實際的起點是挑一個低風險儲存庫，把 API 審查結果接到現有檢查流程，並確認觸發條件、重複審查和人工核准規則；API 能自動提出審查，不等於它能取代合併前的責任審核。
今天這幾項更新都在把 Agent 工作拆成可重跑、可觀察的步驟，同時提醒我們量測資源代價，並把人工檢查放在真正需要的位置。以上是今天的技術新聞摘要。