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 接入更敏感的开发流程提供了一个可测试的治理模式。
