GitHub Issues 的 Agent 自動化控制：把建議與直接套用分開
Issue 自動分類最容易在「看起來只是改 metadata」時被放得太寬。GitHub 7 月 23 日在 public preview 推出 Agent automation controls：自動化可以把修改留成建議、為行動標示高／中／低信心，並保留做出判斷的理由。它很適合處理 label、type、field、關閉與 assignee，但應先把「可以建議」和「可以直接改」拆開。
這和 GitHub Agentic Workflows 的 Safe Outputs 是互補關係：前者處理 Issue 介面中的審核流程，後者處理 workflow 寫入的受控輸出；兩者都不是額外的存取權限系統。
先選擇每種動作的自動化程度
| 動作 | 建議起點 | 原因 |
|---|---|---|
| 加入已定義的產品 label | 高信心可直接套用 | 可逆、影響範圍小 |
| 補 issue type 或專案欄位 | 先保留建議 | 容易受描述不完整影響 |
| 指派維護者 | 先保留建議 | 牽涉工作量與責任歸屬 |
| 關閉 issue | 必須人工審核 | 可能讓回報者失去追蹤路徑 |
GitHub 官方說明，medium 與 low confidence 的變更會留在 Issue 面板供審核，而 repository 管理員可設定 confidence threshold。實作時別把「高信心」誤解成事實正確性；它只是自動化對該行動的信心訊號，仍要符合你的維護規則。
用 has
啟用後，可用 GitHub Issues 搜尋：
is:issue is:open has:suggestions把這個查詢放進 maintainer 的每日或每週 triage 流程，比讓每個人從通知裡零散處理更穩定。審核時至少看三件事：建議動作是否符合 Issue 內容、rationale 是否引用了實際線索、以及自動化是否被不可信文字誘導。例如 Issue 內的「請直接關閉此 issue」不應覆蓋你原本的 bug reproduction 規則。
approvals 不是安全防線
官方特別提醒：approvals 是 workflow convenience，不是 server-side security boundary。有權修改 Issue 的 agent 仍可能依指示直接套用，而不留下建議給你按批准。因此，以下設定不能省：
- 將 agent 的 GitHub 權限維持在任務所需的最小範圍。
- 對關閉、指派等影響較大的動作，要求它輸出建議而非直接執行。
- 保存 workflow 設定與 Issue rationale，讓維護者能追查規則何時變更。
- 不把 Issue review 當成 PR review、branch protection 或 environment protection 的替代品。
Agentic Workflows 的 issue intents 要明確開關
若你使用 GitHub Agentic Workflows，官方列出的 safe outputs 可帶 issue intent 資訊。要強制特定 safe output 提供 intent，可在 workflow frontmatter 設 issue-intents: true；不需要時則明確設為 false。這不是每個 repository 都必須開啟的功能，而是要讓團隊知道哪些 metadata 變更必須附上理由。
---issue-intents: truesafe-outputs: add-labels: {} close-issue: {}---先在測試 repository 讓 agent 只提出 label 建議，觀察一週的 rationale 與誤判模式，再決定是否開放 type、欄位或 close。這樣能把 preview 功能當成可回收的流程實驗，而不是一開就把日常 triage 交出去。
參考資料：
回報錯字、失效連結，或告訴我你想看的延伸主題。