# 闸门开在哪层：自主体五档实测 ## 概述 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"`。下面是生产环境实测下来最稳的配置片段： ```json { "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 + 规则 | 注意"单次确认耗时"和"触发频率"是反向的：越粗的闸门，单次确认越重，但次数越少，**总中断次数反而最少**。这就是为什么把闸门从命令级上移到计划级/会话级，能让人工成本塌掉一个数量级而安全几乎不损失——因为人本来就做不好高频低信息量的判断。**闸门层级的本质，是把人的注意力从"批命令"挪到"批意图"**。 ## 架构图：六栈闸门层级与默认落点 ```mermaid 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 是唯一横跨"规则引擎兜底"的，这也是它可团队化的根因。 ## 推荐方案：按场景选档 - **个人玩具项目 / 单人脚本**：Cursor Yolo 或 Claude Code `bypassPermissions`。仓库随时能 `git reset`，速度第一，闸门是负资产。 - **生产代码库（团队协作）**：Claude Code `default` + 团队级 `settings.json` 规则引擎。把 deny 兜死（删库、强推、`.env`），ask 卡钱（publish、migration），allow 放杂活。确认数压在每任务 3-7 次。 - **CI / 夜间自动化**：Codex CLI sandbox 或 OpenHands auto-on + 沙箱。换闸为笼，环境兜底，全程无人值守，翻车靠沙箱回滚。 - **高风险一次性改动（迁移、重构）**：Claude Code `plan` 模式 + Devin Collaborative。先在只读里出方案，人工审完再执行，确认粒度压到计划级。 - **教学 / 训练营**：Cline 默认每步审批。把每一步都摊开给人看，是最好的"自主体解剖课"；配合 auto-approve 讲"闸门降维"陷阱。 一句话总结：**别问"放不放手"，问"闸门开在哪层、谁兜底"**。开在命令级、靠人工兜底的，迟早把人训练成批准机；开在会话级、靠沙箱兜底的，才是 2026 年自动化该走的路。 ## 参考来源 1. [Configure permissions — Claude Code Docs](https://code.claude.com/docs/en/permissions) — Claude Code 官方权限模式与 allow/ask/deny 规则引擎文档 2. [Devin vs Cursor vs Claude Code 2026: the autonomous-coding stack](https://aiagentrank.io/blog/devin-vs-cursor-vs-claude-code-2026) — 三档自主（Manual/Collaborative/Autonomous）对比与落点 3. [Best AI Coding Agents in 2026: Claude Code, Cursor, Devin, Cline, Codex](https://blink.new/blog/best-ai-coding-agents-2026) — 六栈自主性与 auto-approve / Yolo 机制横评 4. [Claude Code Permission Rules & settings.json Guide](https://www.developersdigest.tech/blog/claude-code-permissions-settings-guide) — approval-fatigue 调参与三段式 deny/ask/allow 配置实战 5. [Coding Agent Benchmarks 2026](https://presenc.ai/research/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 等场景全覆盖。