审批和沙箱是两层：为什么 on-request 也被拦

用 AI 编码智能体时有个高频困惑：审批模式明明设成了 on-request，智能体每次请求都点了同意，任务还是被拦下来。中文社区的高频误区清单里，这条单列成项：只改审批，不看沙箱。根子在于把两套机制当成了同一个开关——审批与沙箱各管一层，批准解决的是「要不要问你」，沙箱解决的是「批准之后动作在什么圈里执行」，点一百次同意也改不了圈的大小。这篇按误区文的惯例，先摆三种说法，再逐条对照，最后给一条「先看拦在哪层」的判断流程；两层各自的调法见审批模式详解与沙箱模式两篇。

说法一：我全点了同意，怎么还拦

第一种说法最常见：on-request 模式下，智能体要越圈就先请求，我每次都批，理论上畅通无阻。对照看，批准改变的是「这一步允许发起」，不改变「发起之后在哪个圈里执行」：你批准了一条联网命令，它照样在当前沙箱档位下跑，workspace-write 默认断网，命令发起得再名正言顺，网络层照样拦。这就是 on-request 也被拦的机制——审批层给了通行证，沙箱层没给路。两层不联动是刻意设计：如果批准一次就等于临时拆圈，圈的存在意义就没了。解法顺理成章：网络需求去开 network_access，路径需求去附加目录，让沙箱层的变化走沙箱层的配置，被拦后的逐层放开见PermissionError 排查一篇。

说法二：开成 full-access 就一劳永逸

第二种说法是拿全权当万能开关：既然两层烦人，干脆 full-access，圈没了还拦什么。对照看，全权确实能让报错消失，但消失的是报错，风险一点没少——文件系统与网络全放开后，误删、密钥外泄、来路不明的依赖安装都不再有闸门，而智能体是会自主执行的，错误发生在你看不见的步骤之间。更实际的问题是它掩盖了病因：被拦说明某个具体配置与任务不匹配，全权把这个问题糊住，下次换回正常档位立刻复发。全权的正确位置是明确知道任务要碰系统级资源、损失可承受的少数场景，常态任务用它是拿安全边际换省事，这笔账不划算。

说法三：审批越严，整体就越安全

第三种说法反着走：既然全权危险，我把审批拧到最严，每步都问，就安全了。对照看，这同样只动了一层。审批再严，批准之后的动作仍受沙箱约束，该断的网还是断；反过来，审批再松，沙箱还兜着底。两层的价值正交：审批管人的确认，防的是「不该做的被做了」；沙箱管执行的边界，防的是「做了的跑出圈」。只改一层就以为调好了整体，是这条误区的通用形态——社区把它单列成错，正因为太常见。通用的批准与隔离关系，批准等于放行一篇讲过同构的问题；插件类工具的权限层怎么看，见插件权限一篇。

先看拦在哪层：一条判断流程

合并起来，遇到「批了还拦」，按这条流程走。第一步看现象：任务停住、界面在等你确认，是审批层在工作，点不点、怎么设是审批模式的事；报错终止、上下文带路径或网络动作，是沙箱层在拦，去调档位与开关。第二步对配置：审批模式是不是你想要的那个，沙箱档位是不是与任务匹配，网络与附加目录有没有按需配置。第三步再动手，每次只改一层，改完重跑验证。想让这套流程在团队里跑顺，可以让 DeepSeek 把两层机制的判断差异整理成一页对照卡，再让豆包出几个「批了还拦」的模拟场景考新人，练的是先分层、再动手的反射。

两层机制速查

• 审批管「问不问你」，沙箱管「批准后在哪执行」，两层不联动
• on-request 被拦：审批给了通行证，沙箱没给路
• full-access 关掉的是报错，风险并未关掉，别当万能开关
• 等确认是审批层，报错带路径是沙箱层，先分层再动手
• 每次只改一层并重跑验证，别跳层调

关于审批与沙箱的三问三答

• on-request 模式的意义是什么，反正都要批？：意义在知情。它让你在动作发起前看到智能体要做什么，配合合理配置，多数日常动作不必人工介入；把每次批准当成一次审查而不是一次放行，这层才有价值。
• 批准一次之后，同类动作还用再批吗？：看配置。审批决定每次是否询问，没有「批一次管一类」的默认语义；想让某类动作免确认，改审批模式而不是连点同意，连点只会让审查形同虚设。
• 只调沙箱不动审批，行不行？：行，很多场景够用。档位配对之后，审批层可以维持较严的设置兜底；反过来只调审批不动沙箱，圈还是那个圈，这正是「只改审批不看沙箱」这条误区的由来。