GitHub 给 Issue Agent 加了置信度阈值:审批不是安全边界Chapters1×0:08开场与事件播报1:02机制拆解2:22这条循环补上了什么3:50工程落地建议5:22收尾0:006:030:08主播早上好,这里是 AI Loop Engineering 每日深度播客。本期覆盖七月二十日到七月二十七日,主事件是 GitHub 在七月二十三日发布的 Issues Agent automation controls,中文可以理解成给 Issue 自动化加上「理由、置信度和审批」。0:25主播GitHub 现在允许 Agent 自动给 Issue 加标签、设类型和字段、分配负责人,或者关闭 Issue。每个动作都要带一段理由,还要给出高、中、低三档置信度。管理员可以设一个自动化级别,超过阈值的动作直接生效,低于阈值的动作先放进审批面板。0:46主播听起来像是给 Agent 装了一个刹车。它真正做的,是把原来「Agent 判断完就写回」的一步,拆成「判断、解释、分级、应用」四步。这个拆分,正好落在 Agent 循环里最容易被忽略的执行边界上。1:02主播先看它怎么工作。GitHub 文档说,自动化会对每个受支持的 Issue 变更记录理由,并把动作标成高、中或低置信度。仓库的自动化级别决定阈值。默认是「谨慎」,只有高置信度变更自动应用,中、低置信度变成待审核建议。1:19主播仓库也可以选「完全控制」,所有动作都先审;选「平衡」,明确的日常分类自动做,有歧义的动作留下来;或者选「完全自动化」,尽量直接应用,只有被标成不确定的动作才暂停。这里的置信度不是模型分数排行榜,而是一个路由信号:它决定这次动作走自动通道,还是人审通道。1:40主播如果你想把某一次动作强制留给人看,也可以直接要求 Agent 只提出建议,即使它自己给出的置信度很高。建议会出现在 Issue 的审批面板里,工程师可以逐条接受或拒绝,也可以一次处理全部建议。搜索里还有 `has:suggestions` 这个限定词,可以把待审的 Issue 找出来。2:02主播GitHub 的文档还明确说,这套能力不只服务于 Copilot cloud agent automations,也适用于 GitHub Agentic Workflows,以及 REST 和 GraphQL API。覆盖的对象只限 Issue 的标签、字段、类型、关闭动作和负责人,不会替人审查 Agent 开 Pull Request 或推送代码的行为。2:22主播把它放回 Agent Loop 里看,原来的路径大概是:读取 Issue,判断它属于什么类别,然后直接写入标签、字段或负责人。现在中间多了一层动作意图。Agent 不只要说「我要加这个标签」,还要说「为什么加」,以及「我对这个判断有多确定」。系统再根据仓库策略决定是写入,还是交给人确认。2:44主播这层意图很有价值,因为 Issue 分类不是纯文本任务。加错一个标签,可能会把问题送进错误的队列;错误分配负责人,会改变团队的工作分工;直接关闭 Issue,甚至可能掩盖还没解决的故障。把理由和置信度保留下来,至少让下一步的人审有依据,不用重新从一段 Agent 对话里猜它当时看到了什么。3:07主播但这里也有一个容易被宣传语带偏的地方。GitHub 文档写得很清楚:审批是工作流便利功能,不是安全控制。它不构成服务器端边界。如果一个 Agent 已经拥有修改 Issue 的权限,它可以绕过建议流程,直接通过 REST 或 GraphQL API 写入。真正限制 Agent 能做什么的,仍然是仓库权限和 Agent 权限。3:30主播所以这不是「置信度高就安全,置信度低就危险」。置信度只回答一个问题:这次判断要不要让人再看一眼。权限回答另一个问题:这个 Agent 有没有资格做这件事。把两个问题混在一起,审批面板就会变成一种很漂亮、但挡不住越权动作的界面。3:50主播如果团队要试这套机制,我建议先从「谨慎」级别开始,不要一上来就全自动。先选一个低副作用的分类任务,例如根据 Issue 内容补标签和类型,把关闭 Issue、改负责人这类影响更大的动作留在人工审批里。观察一段时间后,再看哪些动作的低置信度比例高,哪些动作即使高置信度也经常被人拒绝。4:13主播第二步,把审批当成反馈数据,而不是最后一道装饰。每次接受、拒绝、修改建议,都可以进入评估集:是规则不清,还是 Issue 信息不完整?是 Agent 把相似标签混淆,还是仓库里的分类体系本来就重复?如果拒绝结果只停在面板里,下一次循环还会重复犯错。4:36主播第三步,真正的安全边界要放在权限和写入接口上。对 GitHub Agentic Workflows,管理文档支持通过 safe outputs 声明允许修改的属性,还可以把 issue intent 设为必须提供理由和置信度;如果 Agent 省略这些元数据,工作流就失败。这个设计比单纯展示一段解释更接近控制面,因为它把可写动作收窄到了工作流声明里。5:02主播但即使这样,也要把它当成最小权限的一部分,而不是完整安全方案。仓库权限、令牌范围、工作流来源、输入清理和人工审批仍然要单独检查。尤其是从 Issue 内容触发 Agent 时,不要因为它能解释自己的动作,就默认它理解了所有不可信输入。5:22主播今天带走一个判断:把 Agent 的动作分成「直接应用」和「等待审核」,是很实用的循环设计;但理由和置信度解决的是可解释和分流,权限才解决能不能做。下一次你看到一个 Issue Agent 声称自己有人工审批,可以追问一句:如果它绕过这个面板直接调用 API,服务器端还有什么东西能拦住它?5:45主播这个问题答不清,审批就只是界面;答得清,才算控制面。我们明天早上继续追踪 Agent 工程的新变化。