如何藉助 Agent 應用將軟體交付工作流引入 GitHub

軟體開發中，圍繞一個 Pull Request 往往要開啟多個工具頁面：確認產品決策、檢查依賴風險、配置釋出策略、判斷能否安全部署。GitHub Agent 應用嘗試把這些問題對應的工具直接帶到開發者所處的位置——GitHub 之內，從而減少上下文切換。

文章以“邀請隊友”步驟改為可選為例：產品團隊需要判斷這個改動是否合理。透過 Amplitude Agent，開發者在 Agents 標籤頁直接詢問這一步驟與後續漏斗成功的關係。得到的資料顯示，團隊使用者完成該步驟後留存更高，而個人使用者沒有這種關聯，因此將步驟改為僅對團隊保留、對個人使用者延遲。這樣，在產品資料不離開 GitHub 的情況下就完成了方案調整。

進入開發階段後，Pull Request 涉及依賴更新。開發者用 Endor Labs Agent 在評論中詢問變更依賴是否有風險。Agent 識別出被改動的依賴，檢查已知漏洞和包級風險，並直接在 PR 中回覆；這次沒有發現需要處理的問題。依賴審查因此從 CI 失敗後的補救，變成了開發過程中的主動確認。

功能實現時，由於“團隊”和“個人”在註冊階段即可區分，開發者請 LaunchDarkly Agent 建立功能開關：鍵名、型別、預設值、目標人群和釋出節奏都透過一條 PR 評論指定。Agent 會在 LaunchDarkly 中建立開關，並把程式碼實現作為一次提交交給開發者審查；如果目標環境需要審批，則會先生成審批請求，由人來決定是否放行。

合併之前，PagerDuty Agent 被用來評估部署風險。它把倉庫對映到 PagerDuty 中的服務，檢視當前是否有活躍事件，回看過去 90 天的事件歷史，並將 PR 涉及的檔案與歷史事件區域進行比較。評估結果是風險較低：沒有活躍事件，也與當前改動無明顯關聯，因而建議繼續部署。

整體來看，開發者仍然使用原有工具，但這些工具的能力不再分散在多個介面中。從想法到生產，每個服務都在其上下文或能力重要的時刻進入 GitHub。Agent Apps 已上架 GitHub Marketplace，使用者可為組織安裝後，在 Issue 中指派任務、在 PR 評論中 @ 提及，或在倉庫的 Agents 標籤頁選擇使用，從而把技術棧直接帶到已經工作的環境中。