Agent 的人类确认点：哪些操作必须等人点头

Agent 的人类确认点：哪些操作必须等人点头

把权限和预算都收紧之后，还剩一个问题：有些动作即使技术上 Agent 做得了，也不该让它独自按下。删除、推远程、改权限、对外部发消息——这类事一旦做错，回滚成本不对称。

我把这类关卡叫做人类确认点（human gate）：Agent 可以准备好方案和命令，但执行前必须等人点头。原则很土：能撤销的可自跑，难撤销的先问人。

先画一条“撤销成本”轴

我不太用“重不重要”来划分，而用“做错了能否廉价撤销”。

• 易撤销： 改工作区文件、跑只读测试、本地格式化、生成草稿文档

• 中等： 本地 commit、加依赖但未推送、改本地配置

• 难撤销： force push、删数据、改生产配置、对客户发信、扩大公网权限、不可逆迁移

易撤销的，默认自动；难撤销的，默认闸门。中等的看仓库规范：有的团队允许 Agent 本地 commit，有的要求连 commit 也确认。

图：按撤销成本分级：易撤销、中等、难撤销（原创示意图）

这条轴比“敏感词列表”稳。敏感词会漏，撤销成本是因果。

我默认放进闸门的操作

不同产品形态不同，我个人默认名单是：

1. 任何生产 / 共享环境写入

2. git push（尤其 --force）以及改写历史

3. 删除或批量修改数据

4. 安装 / 升级依赖进入主工程（见前一篇查验）

5. 改变鉴权、CORS、防火墙、密钥与权限绑定

6. 对外通信： 发邮件、Slack、工单、评论到客户可见处

7. 花钱的动作： 下单、扩容、调用按量付费且预算外的 API

名单可以短，但要公开。Agent、同事、未来的自己，都该知道红线在哪。

闸门怎么设计才不形同虚设

只弹一个“确认吗？Yes/No”不够。好的确认点至少展示：

• 要做什么（人话 + 原始命令/请求摘要）

• 影响范围（哪些环境、哪些资源）

• 是否可回滚、怎么回滚

• Agent 为什么建议现在做

我见过最差的确认框只有一句“执行危险操作？”，人在疲劳时会下意识点通过。确认框的职责是帮人做判断，不是推卸责任到“你点过了”。

图：好的确认框要展示：做什么、范围、回滚、为何现在（原创示意图）

另外，确认应有时效：草稿搁太久，环境可能已变，过期应重摘要再问。以及：默认是否，不要默认是。

哪些可以安全地自动跑

闸门太多，Agent 会废掉，人也会烦。我愿意自动的通常是：

• 读代码、搜仓库、看日志（在授权范围内）

• 跑单元测试 / 类型检查 / lint（只读或对工作区可逆）

• 生成补丁但先不应用，或应用在独立分支且随时可丢

• 更新自己的 scratchpad / 计划文档

灰色地带用“自动准备、手动应用”：比如迁移 SQL 可以生成，执行必须确认；对外回复可以起草，发送必须确认。

和“停止按钮”的分工

停止按钮是人类随时打断；确认点是关键动作前的强制暂停。两者都要：

• 没有停止按钮，失控时你只能杀进程

• 没有确认点，危险动作可能在你去倒水时已经执行完

确认点偏策略，停止按钮偏应急。我不会用其中一个替代另一个。

团队里怎么落地上

个人玩具项目，靠自觉就行。团队里我更倾向于：

• 把闸门名单写进仓库说明（给人和 Agent 各一份）

• 运行时强制拦截，而不是只靠提示词“请你记得问我”

• 审计日志：谁在何时批准了什么

• 对高频且低风险的动作，用“信任提升”逐步放宽，而不是一上来全开

提示词里的“请先问我”只能算礼貌；真正的闸门要在工具层拒绝执行。Agent 一旦被提示词绕过，说明闸门不在该在的层。

图：纵深四层：最小权限、预算、确认点、停止按钮（原创示意图）

两个真实一点的取舍

取舍一：本地 commit 要不要闸门？
我的现状：允许自动本地 commit，但 message 要过我的规矩；push 必须确认。原因是本地 commit 易重置，push 影响他人。

取舍二：删文件要不要闸门？
工作区内单文件删除，若在 git 管理下，我有时允许；对 .git 外的数据目录、或匹配 * 的批量删除，必须确认。批量才是杀伤力来源。

取舍会变。变的时候更新名单，而不是靠当场感觉。

给 Agent 的确认话术模板

我会要求 Agent 在请求确认时固定结构，大致是：

1. 准备执行：……

2. 影响：……

3. 回滚：……

4. 不执行的后果：……

5. 请回复：允许 / 拒绝 / 修改后再来

结构固定后，人扫一眼就能决策，也减少 Agent 写成小作文。

收尾

人类确认点不是不信任模型，而是承认：软件世界里，有些键按下之后，道歉没用。 我的默认法则是：

• 按撤销成本分级，而不是按“AI 是否自信”

• 难撤销默认闸门，易撤销默认自动

• 确认框要带范围与回滚，默认否

• 闸门做在工具层，提示词只作补充

• 与停止按钮、预算上限一起用

能撤销的可自跑，难撤销的先问人。 自动化的目标不该是少麻烦人，而是少制造不可逆的麻烦。确认点让人出现在该出现的地方，而不是出现在事故复盘会。

确认疲劳：闸门太多也会坏

人点多了会麻木。若每个 lint 修复都要确认，最后真正危险的 push 也会被连点通过。所以名单要狠、要短、要稳定，不要把“我不放心”的一切都塞进闸门。

缓解确认疲劳的办法：

• 合并同类：一次确认覆盖“推送当前分支的 3 个 commit”，而不是每个 commit 弹一次

• 会话级授权：在明确范围内，短时间允许多次同类只读+低风险写，到期收回

• 预览替代空确认：先给 diff/命令，人看完再出现确认键

闸门的敌人不只是 Agent 越权，也是人类习惯性点头。

误批之后怎么办

再好的闸门也会遇到人批错。预案比羞耻重要：

1. 立刻停止后续自动链式动作（批准 push 不应自动部署，除非另有闸门）

2. 按确认框里写的回滚路径执行

3. 记一笔：是文案不清、默认值不对，还是名单分级错了

若发现某类操作误批率高，优先改交互，而不是训人“你们要点认真点”。

和权限系统的关系

确认点 ≠ 权限。权限决定“能不能做”，确认点决定“这次做不做”。即使 Agent 令牌没有生产写权限，开发环境里仍可能有难撤销动作（比如清掉共享开发库）。两边都要。

反过来，有确认点也不该滥发高权限令牌。纵深防御：最小权限 + 预算 + 确认点 + 停止按钮，叠在一起才像工程，而不是表演。

跨人批准

有的动作需要“另一个人”批准，而不是操作者自己点头——比如生产迁移。这时确认点要接到真正的审批流，而不是本机弹窗。Agent 可以准备材料，但批准人应是角色，不是碰巧在看屏幕的人。个人博客和小项目用不到这么重，公司环境要提前想。

我用来自检的五个问题

每次想放开一个自动动作，先问：

1. 做错了多久内能发现？

2. 发现后回滚要几分钟、谁有权限？

3. 影响是否可能越出本机？

4. 是否涉及外人可见的言论或数据？

5. 失败是否可能产生费用或合规记录？

任一题答案让我不舒服，就先留在闸门后。

收尾再压一句

能撤销的可自跑，难撤销的先问人。 Agent 越能干，确认点越要清楚——不是为了不信任它，是为了信任整个系统仍有人负责。自动化可以很快，责任不该跟着变模糊。