GitHub 於 2026 年 7 月 23 日把 agent automation controls 帶到 GitHub Issues 的 public preview。功能針對一個很實際的問題：當 agent 自動替 issue 加 label、改 type、assign 或 close 時，團隊怎樣知道它為甚麼這樣做，以及哪些變更應該即時執行、哪些要先交給人審核。
這次更新包含三個控制點。第一是 approvals：automation 可以先提出建議，變更會留在 issue 的 suggestions panel，使用者可逐項或一次全部接受、拒絕。第二是 confidence：agent 會為支援的動作標示 high、medium 或 low confidence，高信心動作可自動套用，中低信心動作則保留給人 review。第三是 rationale：每個動作都會記錄理由，無論已套用或仍在等待審批，都形成一條可追溯的 audit trail。
GitHub 也提供 `has:suggestions` 搜尋條件，讓團隊集中查看仍待處理的建議；repository admin 可以設定 automation level，調整信心門檻。這個設計把「agent 做得幾多」改成「agent 在甚麼信心水平下可以做甚麼」，較接近真正的工作流治理，而不是只有一個全開或全關的開關。
目前支援 GitHub Agentic Workflows 和 Copilot cloud agent automations，也可經 REST 和 GraphQL APIs 使用。初始動作涵蓋 labels、fields、issue type、close 和 assignees。對 GitHub Agentic Workflows，團隊可以在 frontmatter 以 `issue-intents: true` 要求 issue intent，亦可用 `issue-intents: false` 明確退出；支援的 safe output 包括設定 issue type、field、labels、close，以及 assign 給 agent 或 user。
使用場景包括自動 triage、補齊 issue metadata 和 spam detection。這幾類工作通常可以先把高信心、低風險變更自動化，再把不確定項目集中到 review queue。不過，GitHub 特別提醒 approvals 是 workflow convenience，不是 security control。如果 agent 已經擁有直接修改 issue 的權限，它仍然可以直接套用變更；審批流程不能取代最小權限、API scopes、組織政策和 audit。
另一個值得留意的細節，是 rationale 不等於可以完整重建模型的內部思考過程。它更適合作為「這次操作的可讀理由、信心和狀態」的治理 metadata。團隊仍應記錄原始輸入、工具呼叫、修改前後資料、操作者身份和錯誤處理，才足以在爭議或回溯時還原事件。
Agent automation 的成熟度，最後不只取決於 agent 能否成功改 issue，而是能否在正確的風險門檻下停止、請人決定和留下可核對的證據。GitHub 這次 public preview 把 confidence、rationale 和 approval 放到同一個操作面，為日後把 agent 接入更敏感的開發流程提供了一個可測試的治理模式。
