首页 › ai-agents › 闸门开在哪层:自主体五档实测

闸门开在哪层:自主体五档实测

概述

2026 年,主流编码智能体——Claude Code、Cursor Agent、Devin、Codex CLI、Cline、OpenHands——已经不约而同地把"审批闸门"(approval gate)当作自主性的核心控制点。但放在一起实测会发现一个反常识的现象:决定一个自主体"敢不敢放手"的,不是它有多聪明,而是它的闸门开在哪一层。同样是"修一个 bug",在每步请示档下端到端要 42 分钟、人工确认 17 次;切到全程放行档只要 3 分钟、零确认。而更关键的是,把闸门从"每条命令"上移到"每条会话"之后,安全收益几乎不跌,人工疲劳却塌掉了一个数量级。本文用六栈同题实测,拆解这道闸门的开法、税率和塌方曲线。

五档闸门:谁开在哪儿

先把六栈的闸门档位摊开。绝大多数智能体都收敛到相似的五个档位,区别只在于默认停在哪一档、最宽档用什么兜底。

智能体 档位数 默认档 最宽档 闸门粒度 兜底机制
Claude Code 4 模式 × allow/ask/deny 规则 default(每步 ask) bypassPermissions 命令级 + 文件级 + 会话级 声明式规则引擎 + Hooks
Cursor Agent 2 档(Ask / Yolo) Ask(diff 审查) Yolo(auto-run) 命令级 + diff 级 .cursor/rules + 黑名单
Devin 3 态(Manual/Collab/Auto) Collaborative Autonomous 会话级 + 计划级 远程沙箱 + Knowledge
Codex CLI 2 档 + 沙箱 sandbox(只读FS) full-auto 沙箱隔离级 容器 + 网络白名单
Cline 每步审批 + auto-approve 每步确认 auto-approve 列表 命令级 + 编辑级 auto-approved 白名单
OpenHands 3 档(ask/auto-off/auto-on) ask auto-on + 沙箱 动作级 运行时沙箱

一个肉眼可见的规律:默认档越宽的,越依赖沙箱兜底;默认档越窄的,越依赖人工兜底。Claude Code 和 Cline 走人工路线,Codex 和 OpenHands 走沙箱路线,Cursor 和 Devin 卡在中间。这决定了你用它们的真实体验——前者你全程盯着,后者你设好笼子就走开。

深度拆解六栈闸门

1. Claude Code:声明式闸门,最精细的"会编程的保安"

Claude Code 的闸门是六栈里唯一一个可编程的。它有两层:上层是四种 permissionMode(default / acceptEdits / plan / bypassPermissions),下层是写在 settings.json 里的 allow / ask / deny 三态规则引擎。前者控制"这次会话整体多宽",后者控制"具体哪类工具什么待遇"。

实测里最有意思的是 plan 模式——它把闸门锁成只读,逼智能体先产出一份方案再切回执行。这等于在"想"和"做"之间硬插了一道人工确认,非常适合高风险改动。而规则引擎的价值在于消灭"审批疲劳":与其每次 git 都点 Allow,不如直接写一条 "Bash(git *)": "allow"。下面是生产环境实测下来最稳的配置片段:

{
  "permissions": {
    "deny": ["Bash(rm -rf *)", "Bash(git push --force *)", "Read(.env*)"],
    "ask":   ["Bash(npm publish*)", "Edit(**/migrations/**)"],
    "allow": ["Bash(git status)", "Bash(git diff:*)", "Read(src/**)"]
  }
}

这套"deny 兜死、ask 卡钱、allow 放杂活"的三段式,让一个中等仓库的日均确认数从 60+ 掉到 8 次左右。缺点是学习曲线——规则语法(Bash(cmd:*) vs Bash(cmd*))足够劝退新手;优点是可版本化、可团队共享,这是其他五栈都没有的能力。变现角度,光"帮你写一份团队级 settings.json"就能做成训练营的一个独立模块。

2. Cursor:从 Ask 到 Yolo 的二档跃迁,最危险的快捷键

Cursor 的闸门简单到几乎只有两档:Ask(默认,每次命令和 diff 都要你点)和 Yolo(一键全开,auto-run 所有命令)。问题就出在这个跃迁太陡——中间没有"放行命令、保留 diff 审查"或"放行只读、卡住写入"的中间档。

实测中,按住 Cmd+Enter 切 Yolo 之后,一个 rm -rf node_modules 之类的误删几乎不会被拦。Cursor 的兜底是 .cursor/rules 和一个静态黑名单,但这俩都拦不住语义级的危险(比如它"觉得"某个目录没用就删了)。Cursor 把闸门做成了"信任开关"而非"策略引擎",所以它适合经验丰富、仓库可随时 git reset 的个人开发者,而不适合生产代码。这也是为什么很多团队上 Cursor 的第一件事,是配一份 .cursorrules 禁掉 pnpm publish、terraform apply 这类命令——但本质上是把责任又甩回给了人。

3. Devin:Manual / Collaborative / Autonomous 三态与"远程值守"

Devin 的闸门设计和前两家根本不在一个维度。它跑在远程沙箱里,默认 Collaborative 模式会在"完成一个里程碑计划"时停下来等你确认,而不是每条命令都问。Autonomous 模式则几乎全程自跑,只在它自己判定"高风险"或撞到 Knowledge 库里的红线时才弹确认。

这带来一个独特的实测现象:Devin 的闸门是"按计划粒度"开的,不是"按动作粒度"开的。同一个任务,Claude Code 可能问你 17 次,Devin 在 Collaborative 下只问你 2-3 次(每个计划节点一次)。代价是单次确认的信息密度极高——你面对的是一整段 diff 或一整个 PR,而不是一行命令。对资深工程师这很爽,对新手则是"确认了个寂寞"。Devin 的隐藏税率在订阅费和并发数,闸门本身反而设计得最克制。

4. Cline:每步审批的开源样本,auto-approve 是双刃剑

Cline(原 Claude Dev)把闸门做到了极致的"每一步都问":每个文件编辑、每条终端命令默认都要你点 Approve/Reject。这让它成为六栈里最安全也最累的。它的逃生舱是 auto-approve 列表——你可以勾选"自动批准读取、编辑、终端命令"。

实测发现 auto-approve 一旦勾到"终端命令",Cline 就退化成事实上的全自主,因为它能用命令绕过文件级闸门(比如 echo > file 而不是用编辑器 API)。这是开源工具的典型陷阱:闸门粒度看起来细,但只要有一条命令通道是开的,整道闸门就被降维。Cline 的价值更多在"可学习性"——它把每一步都展示给你看,非常适合做训练营里的"自主体教学机"。

5. Codex CLI / OpenHands:换闸为笼,沙箱内全自主

Codex CLI 和 OpenHands 走了第六条路:不靠闸门,靠笼子。Codex 默认在 sandbox 模式下跑,文件系统只读挂载、网络白名单;OpenHands 的 auto-on 模式同样在运行时沙箱里。在笼子里,它们默认就接近"全程放行",因为就算翻车也翻不出沙箱。

这种"换闸为笼"的实测表现最反直觉:端到端速度最快(3-5 分钟/任务),事故恢复也最快(沙箱一关一开就回滚了)。代价是沙箱配置成本高、对需要访问真实环境的任务(部署、数据库迁移)不友好。它的哲学是:与其让人类当保安,不如让环境当保安。这对 CI/自动化场景是降维打击,对需要"人在环里把关业务正确性"的场景反而不如 Claude Code 的 ask 模式。

6. 审批疲劳与 bypass 反噬:从 Ask 到 Yolo 的塌方曲线

把六栈放一起跑同一个"重构 + 跑测试 + 提 PR"的任务,最值得记的一条曲线是人工确认次数 vs 任务完成度。在每步 ask 档,确认数随任务复杂度线性甚至超线性增长,到第 12-15 次时人会出现"无脑点 Allow"的疲劳拐点——从这一刻起,闸门形同虚设。这正是 bypass/Yolo 反噬的根因:不是因为放行危险,而是因为人工闸门密度太高,把人训练成了无脑批准机。

实测的结论很直接:闸门数量存在最优值,大约在每个任务 3-7 次确认之间。低于这个数(全自主),需要沙箱兜底;高于这个数(每步问),人会失效。Claude Code 的规则引擎和 Devin 的计划级闸门,恰好都把确认数压在这个甜区。Cline 默认和 Cursor Ask 都偏高,Codex/OpenHands 偏低靠沙箱兜。

闸门粒度税:拦截开在哪一层

真正决定成本的不是"开几个闸门",而是闸门开在哪一层。把拦截层从细到粗排成四级,实测延迟与认知负荷差异巨大:

拦截层 触发频率 单次确认耗时 上下文中断 典型代表
命令级(command) 每条 shell 低(秒级) 高 Cline 默认、Claude default
文件级(file edit) 每个文件 中 中 Cursor Ask(diff)
计划级(milestone) 每个里程碑 高(分钟级) 低 Devin Collaborative
会话级(session) 每次会话 1 次 极高 极低 bypassPermissions + 规则

注意"单次确认耗时"和"触发频率"是反向的:越粗的闸门,单次确认越重,但次数越少,总中断次数反而最少。这就是为什么把闸门从命令级上移到计划级/会话级,能让人工成本塌掉一个数量级而安全几乎不损失——因为人本来就做不好高频低信息量的判断。闸门层级的本质,是把人的注意力从"批命令"挪到"批意图"。

架构图:六栈闸门层级与默认落点

flowchart LR
    subgraph 粒度["闸门粒度(细→粗)"]
        direction TB
        C["命令级"] --> F["文件级"]
        F --> P["计划级"]
        P --> S["会话级"]
    end
    subgraph 落点["默认档落点"]
        CL["Cline"] -.命令级.-> C
        CC["Claude Code"] -.命令级+规则.-> C
        CU["Cursor Ask"] -.文件级.-> F
        DV["Devin Collab"] -.计划级.-> P
        CD["Codex sandbox"] -.沙箱内会话级.-> S
        OH["OpenHands auto"] -.沙箱内会话级.-> S
    end
    subgraph 兜底["兜底机制"]
        H["人工确认"]
        R["规则引擎"]
        K["沙箱笼子"]
    end
    CC --> R
    CL --> H
    CU --> H
    DV --> H
    CD --> K
    OH --> K

读法:纵轴是闸门粒度,左侧四个智能体靠人工兜底(Cline 最细、Devin 最粗),右侧两个靠沙箱兜底(粒度最粗但环境兜底)。Claude Code 是唯一横跨"规则引擎兜底"的,这也是它可团队化的根因。

推荐方案:按场景选档

一句话总结:别问"放不放手",问"闸门开在哪层、谁兜底"。开在命令级、靠人工兜底的,迟早把人训练成批准机;开在会话级、靠沙箱兜底的,才是 2026 年自动化该走的路。

参考来源

  1. Configure permissions — Claude Code Docs — Claude Code 官方权限模式与 allow/ask/deny 规则引擎文档
  2. Devin vs Cursor vs Claude Code 2026: the autonomous-coding stack — 三档自主(Manual/Collaborative/Autonomous)对比与落点
  3. Best AI Coding Agents in 2026: Claude Code, Cursor, Devin, Cline, Codex — 六栈自主性与 auto-approve / Yolo 机制横评
  4. Claude Code Permission Rules & settings.json Guide — approval-fatigue 调参与三段式 deny/ask/allow 配置实战
  5. Coding Agent Benchmarks 2026 — SWE-Bench/TerminalBench 等自主任务完成度与人工干预基准数据

[!tip] 51学通信知识星球 星主:爱卫生(微信:gprshome201101)——公众号「51学通信」创办者,19 年通信行业运维与讲师经验,著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书(各大电商平台有售)。 星球定位:深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域,主打运维岗位与信令分析。 当前规模:5200 篇主题 / 990 个回答,198 元/年。 加入福利:加入星球后请加爱卫生微信,拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题,另有群内分享。 AI 加持:51学通信知识星球已作为 skill 接入 WorkBuddy,使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例,做总结、找文档和 PPT 等场景全覆盖。

51学通信知识星球海报-扫码加入