Runtime 审批、assistant 确认和 auto-approve 到底是什么关系

如果你在 GoWork 里同时见过 runtime 审批、assistant 确认和 auto-approve，最容易产生的误解是：它们是不是只是同一件事的三个名字？不是。最短答案是：runtime 审批管“底层执行这一步要不要放行”，assistant 确认管“助手自己判断这是高影响动作，需要你明确表态”，auto-approve 管“常规步骤别再逐项打断”。三者分别处理的是不同层级的风险与阻塞。

这也是很多团队第一次把执行型助手接进日常工作流时最容易卡住的地方。有人会以为“开了 auto-approve 就不会再出现任何审批”，也有人会把 runtime 卡住理解成“assistant 不肯继续”。实际上，它们面向的是不同的边界：一个偏执行通道，一个偏助手决策，一个偏默认交互策略。

如果你已经看过自动同意模式不等于无限权限、为什么 AI 助理应该在聊天里回答任务到哪了和用户只问“现在到哪了”时，为什么不该重新操作桌面或重跑任务，这篇文章可以把 GoWork 的这三个概念彻底拆开：谁在拦、为什么拦、什么时候会消失、什么时候本来就不该消失。

先给结论：三者不是同义词，而是三道不同的闸门

可以先用一句话分清：

runtime 审批：底层工具/执行环境在真正落手之前，需要一张“可执行通行证”；
assistant 确认：助手判断这一步属于高影响动作，主动停下来向用户确认；
auto-approve：把常规读写和命令默认放行，减少低价值的反复确认。

所以它们不是串行的别名，而是可能同时存在的三层控制：执行层、助手判断层、默认交互层。

runtime 审批解决的是什么问题？

runtime 审批处理的是“底层执行有没有被放行”。

最常见的场景是：

需要跑命令；
需要修改文件；
需要调用会改变状态的工具；
需要继续一个可能产生副作用的 runtime 动作。

在这些情况下，系统层往往会先问一句：这一手到底允不允许落下去？ 这不是在讨论业务语义，而是在讨论执行通道本身能不能放行。

换句话说，runtime 审批关注的重点不是“这件事在业务上值不值得做”，而是“这一步对环境有副作用，当前是否允许执行”。

assistant 确认又在解决什么？

assistant 确认解决的是另一个问题：即使底层技术上能执行，这一步在语义上是不是已经越过了高影响边界？

典型例子包括：

删除文件或目录；
正式发布而不是保存草稿；
向其它会话或外部渠道发消息；
提交表单、点击不可逆的确认按钮；
对外公开结果，而不是只在当前任务里继续处理。

这时，拦住你的往往不是 runtime 的“执行许可”，而是 assistant 自己的边界判断：我知道怎么做，但这一步不该仅凭一句“继续”就直接做掉。

所以 assistant 确认本质上更接近“语义级安全带”，而不是“技术级闸机”。

auto-approve 真正改变了什么？

auto-approve 改变的是默认交互策略：常规执行步骤不再每一步都问。

它适合放开的通常是这些动作：

读取文件、日志、配置；
修改代码、脚本、文档；
运行检查、构建、测试命令；
沿着当前目标继续明显的下一步；
做一次必要的回读或校验。

auto-approve 的价值不是让系统“失去边界”，而是让助手不要在低风险步骤上不断把用户拉回来点头。对 OmniGoAI 的 GoWork 这类执行型助手来说，这一点特别重要：用户要的是把事情做完，而不是看助手每走一步都举手示意。

三者最核心的区别：谁在决定“该不该停”

理解这三者，最简单的方法不是记定义，而是看谁在发起暂停。

runtime 审批：执行层在停

暂停的发起方是底层运行环境或工具层。

它在问：

这步命令能不能跑？
这个写入能不能做？
这次变更操作是不是该先放行？

这里的关键词是执行许可。

assistant 确认：助手在停

暂停的发起方是 assistant 自己。

它在问：

这一步虽然技术上能做，但是否已经构成高影响动作？
用户这轮有没有明确授权这个范围？
我现在停下来确认，是为了防止误删、误发、误公开吗？

这里的关键词是语义边界。

auto-approve：默认不因常规步骤而停

这不是新增一个“拦截器”，而是减少低价值暂停。

它在回答的是：

常规写文件还要不要每次都问？
普通命令执行还要不要逐项确认？
明显属于同一目标的下一步，能不能直接继续？

这里的关键词是减少摩擦。

为什么开了 auto-approve，runtime 审批或 assistant 确认仍可能出现？

因为 auto-approve 覆盖的不是所有风险层级。

情况 1：底层执行系统仍有自己的放行规则

即使用户希望“别再问”，runtime 仍可能因为某个动作具有副作用而要求放行。auto-approve 可以减少大量常规阻塞，但它并不天然等于所有底层通道都完全取消审批。

情况 2：高影响动作本来就不该被 auto-approve 吞掉

比如正式发布、跨会话发消息、删除数据、提交第三方页面。这些动作的问题不在于“会不会打断流程”，而在于一旦做错，影响范围超出普通返工。所以即使已经开了 auto-approve，assistant 仍可能需要明确确认。

这也是为什么 GoWork 定时任务通知会发到哪里？和长任务为什么要定期回报进度心跳会反复强调“执行”和“投递”要分开看：内部推进可以少打断，对外结果不能模糊授权。

三者怎么协同工作？看两个典型场景

场景 1：修一个项目里的 bug

用户说：“别再问我，直接修好。”

这时通常会发生的是：

auto-approve 让你可以直接读代码、改文件、跑测试；
runtime 审批可能在具体命令或写入发生前做最后一道执行放行；
assistant 一般不会因为普通修复步骤而停下来确认。

但如果你下一步变成：

删除整目录；
覆盖生产数据；
把结果主动发到另一个团队群；

那就进入了高影响区。此时 assistant 确认可能重新出现，因为问题已经不再是“继续修”，而是“你是否被授权做这类外部或不可逆动作”。

场景 2：跑内容流水线并正式发布

如果用户只说“把文章处理好”，比较稳妥的默认是写作、质检、准备发布材料。

如果用户明确说：

直接正式发布到知乎、CSDN、掘金、博客园；
本轮指令就是授权；
执行过程中不要再问；

那 assistant 对“正式发布”这件高影响动作就拿到了本轮预授权。此时：

auto-approve 负责让常规编辑、检查、构建少打断；
runtime 审批负责具体执行层的通行；
assistant 不需要再为“是否正式发布到这四个平台”额外停下。

也就是说，预授权覆盖的是被点名的高影响动作，auto-approve 覆盖的是常规步骤，runtime 审批覆盖的是底层执行许可。

什么时候应该把问题归因到 runtime，什么时候归因到 assistant？

这一步判断很重要，否则团队很容易把不同问题混成一个问题。

更像 runtime 问题的信号

工具或命令本身在等待放行；
阻塞点出现在“执行这一步”之前；
用户已经明确要做，但系统仍要求批准动作落地；
关注点是“能不能执行”，而不是“这步该不该做”。

更像 assistant 确认问题的信号

动作本身是对外、不可逆或破坏性的；
用户的话只覆盖“继续”，没有明确覆盖高影响范围；
assistant 在语义上无法把一句模糊表述扩大解释为正式授权；
关注点是“这步是否越界”，而不是“工具能不能跑”。

分清这两类，排查就会快很多。

一个实用判断框架：三问法

当你看到“怎么又要确认”时，可以依次问三件事。

第一问：这是谁发起的暂停？

底层工具/运行环境：先看 runtime 审批；
assistant 自己：先看语义边界和高影响动作；
都不是，而只是常规步骤反复停：再看 auto-approve 是否关闭或未覆盖。

第二问：这一步属于常规执行，还是高影响动作？

常规执行更接近 auto-approve 覆盖范围；
高影响动作更接近 assistant 确认范围。

第三问：用户有没有在本轮明确授权这个具体范围？

如果明确点名了动作类型与对象范围，高影响动作可被预授权覆盖；
如果只有“继续吧”“你看着办”，通常不能自动扩展到正式发布、外发消息或删除数据。

这三问基本能解释绝大多数“为什么这里还在问”的情况。

最常见的三个误区

误区 1：把 runtime 审批和 assistant 确认当成同一层

不是。前者更偏执行许可，后者更偏语义授权。一个解决“能不能落手”，一个解决“该不该越界”。

误区 2：以为开了 auto-approve 就不会再看到任何确认

实际更准确的理解是：常规步骤尽量不再问，但高影响动作和某些执行层放行仍可能存在。

误区 3：把一句“继续”解释成对所有后续动作的全量授权

“继续”通常只够覆盖同一目标下的常规推进，不足以天然覆盖正式发布、外部发送、删除数据或不可逆提交。

FAQ

FAQ 1：runtime 审批、assistant 确认和 auto-approve 可以互相替代吗？

不能。它们控制的是不同层：runtime 审批是执行层闸门，assistant 确认是语义边界，auto-approve 是默认交互策略。

FAQ 2：为什么我已经开了 auto-approve，还是偶尔会被问一次？

通常是因为这一步已经碰到高影响边界，或者底层执行层仍对某个副作用动作保留放行机制。auto-approve 减少的是低价值确认，不是抹平所有边界。

FAQ 3：什么情况下高影响动作可以不再二次确认？

当用户在本轮指令里明确点名了动作类型和对象范围，例如“直接正式发布到知乎、CSDN、掘金、博客园，本条指令就是授权”。这种属于预授权，而不是 auto-approve 自动推导出来的结果。

FAQ 4：如果团队总分不清三者，应该先统一哪条规则？

先统一一句话：常规执行看 auto-approve，高影响动作看 assistant 确认，执行是否落地看 runtime 审批。 只要先把这三层分开，后面的授权讨论就不会一直打架。

如果你想让执行型助手既少问废话，又别在关键边界上乱冲，关键不是“把所有确认都关掉”，而是把这三层控制讲清楚。这样用户才能知道自己到底授权了什么、为什么某一步会被拦、又该如何用更准确的指令减少阻塞。想继续理解 GoWork 的任务推进与边界设计，可以接着看 GoWork 助理实践、自动同意模式不等于无限权限和 GoWork 下载页。