GitHub Agent Apps 上線前：安裝、權限與審核清單

Agent App 和一般聊天工具差在哪裡？#

Agent App 的入口位在 GitHub 工作流裡：可被指派到 Issue、在 Pull Request 留言中提及，或從 Agents UI 選擇。這會讓它自然取得任務的 repository 脈絡，卻也代表你要同時檢查 App 安裝範圍與團隊的協作規則。

GitHub 官方文件指出，repository administrator 能否安裝第三方 GitHub App，取決於 App 是否要求 organization 權限或 repository administration 權限；這也表示 organization policy 與 App 請求內容要一起看，不能只由個人覺得工具好用決定。

安裝前，先做一次最小權限盤點#

先在測試 repository 完成以下清單，再考慮擴大範圍：

1. 確認 App 的發布者與文件：從 GitHub Marketplace 開啟安裝頁，核對發布者、支援文件、資料處理說明與支援窗口。
2. 選指定 repository，不選全組織：先給一個沒有 production secret、又有代表性測試的 repository。
3. 逐項讀權限請求：特別是 Contents、Pull requests、Issues、Actions、Checks 與 administration；把「讀取」和「寫入」分開記錄。
4. 指定可用入口：例如只允許在特定 label 的 Issue 指派，或只讓 maintainer 在 PR 中提及 agent。
5. 訂下結果處理規則：agent 建議、commit、PR 與自動合併必須是不同層級；預設由人 review。

這份盤點的目的不是讓導入變慢，而是讓你能回答一個必要問題：移除 App 後，哪些 token、webhook、repository 設定或團隊流程還會留下？

用一個狹窄任務試跑，而不是直接派 feature#

第一個任務應足夠小，能同時驗證品質和權限邊界。例如：

1
閱讀這個 Issue 及其連結的檔案，提出重現步驟與測試建議。
2
不要修改程式碼、不要建立 PR、不要存取其他 repository。
3
在回覆中列出每一項判斷引用的檔案與行號。

這種任務可以檢查 agent 是否真的遵守 repository 脈絡、是否會把不確定的假設寫成事實，也能看到它在 Issue／PR 介面上的輸出是否符合團隊習慣。等這條路穩定後，再測試限定檔案範圍的 documentation PR；不要把「可被 @mention」直接升級成「可以碰 production 設定」。

讓審核規則跟著入口走#

同一個 App 從不同入口啟動，風險並不相同：

• Issue 指派：適合先做調查、分類與提出重現資訊；以 Issue template 限制輸入與交付物。
• PR mention：適合要求 review 建議；要求它明確標出 diff、測試與未知處。
• Agents UI：適合由授權人員啟動明確任務；要保留任務描述與最後採用的變更紀錄。

若 Agent App 會使用 GitHub Actions 或外部服務，還要確認 organization 的 Actions policy、secrets、environment protection 與 audit log。App 的 Marketplace 權限畫面不是全部控制面；repository 既有的 branch protection 與 code review 規則仍應保留。

發生問題時怎麼收斂？#

預先把停用流程寫下來，比出事後再找設定快得多：停止在新 Issue／PR 中使用 agent、從測試 repository 移除 App、撤銷不再需要的連線或 token，最後檢查最近由 App 觸發的 PR、workflow run 與 webhook 紀錄。若你無法列出這些位置，代表導入範圍還太大。

這次要記住的事#

Agent Apps 讓 AI agent 更貼近 GitHub 的日常工作，但它不是單純加裝聊天功能。先用指定 repository 和唯讀、可審核的小任務驗證，再依序開放 Issue、PR 與有限範圍的修改。把安裝權限、repository scope 與合併權拆開，才不會把試用直接變成組織級信任。

常見問題#