Codex沙箱有三档文件系统模式（read-only / workspace-write / danger-full-access）和三档批准策略，默认workspace-write已经能读写工作区加常规本地命令，但很多人要么被频繁的批准请求烦到直接开full access，要么被卡住以为程序挂了——“卡住先看批准队列不是重启”这条纪律，在真实工作流里到底怎么养成？

1. 导语：一次“假死”事故的复盘

先还原一个在真实团队里反复出现的场景。某后端小组用 Codex 类编码智能体重构一个 Python 服务的配置加载层。任务进行到一半，终端输出停在一行 Running command... 上，光标不再滚动。工程师的第一反应是Ctrl+C 重启；第二次运行，又在同一位置停住；第三次，他直接把沙箱切到 danger-full-access，任务顺利跑完，于是得出结论：“默认模式有 bug，必须开全权限。”

这个结论几乎全错。真实原因是：智能体试图写入工作区之外的路径（例如用户级缓存目录或系统临时目录），在 workspace-write 模式下该操作被拦截，系统生成了一条批准请求并进入等待状态。等待期间进程并未崩溃，只是没有可继续执行的动作。工程师没有查看批准队列，而是把“等待人工决策”误读为“程序无响应”，于是用重启和提权两种方式绕过了本来应该被看见的安全信号。

本文的核心命题：“卡住先看批准队列，不是重启”不是一句运维口诀，而是对智能体运行时语义的正确理解——阻塞（blocked）与失败（failed）是两种不同状态，前者需要人工输入，后者需要修复。把阻塞当失败处理，等于系统性地拆除安全阀。

笔者认为，这条纪律之所以难以养成，根源不在工程师粗心，而在于权限状态的不可见性。传统命令行工具卡住时，用户会本能地怀疑网络或死锁；而智能体的阻塞原因藏在“批准队列”这个次级界面里，缺乏显式的状态提示。要养成纪律，仅靠培训不够，必须把状态外化到终端、日志和 CI 中。这也是本文后续所有章节的落脚点。

2. 背景与问题定义：智能体权限模型为何难用

2.1 从“工具调用”到“自主执行”的权限跃迁

早期的代码补全工具只做文本建议，权限问题几乎不存在：模型输出的是字符串，是否采纳由人类决定。编码智能体则不同，它具备工具调用能力——可以执行 shell 命令、读写文件、发起网络请求。一旦模型能够直接改变文件系统状态，权限模型就从“建议过滤”升级为“执行授权”，其复杂度与操作系统沙箱、容器安全处于同一量级。

这一跃迁带来一个结构性矛盾：任务完成度与权限开放度正相关，而安全风险也与权限开放度正相关。智能体要完成“重构配置加载层”，往往需要读取多个模块、写入若干文件、运行测试命令；权限收得越紧，越界操作越多，批准请求越频繁；权限放得越开，单次误操作（例如误删目录、误改全局配置）的破坏半径越大。权限设计本质上是在这条曲线上寻找工作点。

2.2 批准疲劳：安全机制被绕过的经典路径

安全领域对“告警疲劳”（alert fatigue）有长期研究：当告警数量超过人工处理能力时，操作者会倾向于批量忽略或直接关闭告警。批准请求面临同样的动力学。若一个任务触发数十次批准，且多数请求的内容是“写入工作区内某个明显无害的文件”，工程师很快会形成“批准请求都是噪音”的先验，进而选择永久放宽权限以消除摩擦。

本文评述：批准疲劳不是用户意志薄弱，而是信噪比设计失败。如果批准队列中 90% 的请求本可被策略自动放行，那么剩下 10% 真正需要人类判断的请求就会被淹没。治理方向不是要求用户“更有耐心”，而是提高批准请求的信息密度与自动分类能力。这一点在后文第 6 节和第 10 节会给出具体做法。

2.3 问题定义：三个可观测的失败模式

把模糊的“难用”拆成可观测的失败模式，是工程化的第一步。本文归纳为三类：

这三类失败模式共享一个底层缺陷：权限状态没有被当作一等可观测对象。操作系统有 ps、top、strace 来观察进程状态，而智能体的权限状态长期只存在于交互界面的一次性提示中。后文第 11 节将论证，把权限状态纳入可观测性体系，是这一代智能体工具走向成熟的必经之路。

3. 三档文件系统模式的机制解剖

Codex 沙箱提供三档文件系统模式，其命名已经暗示了能力梯度。要正确使用，必须先理解每一档允许什么、拦截什么、拦截后发生什么。以下分析基于公开文档与工程实践中的可复现行为，具体实现细节可能随版本演进，读者应以所用版本的官方文档为准。

3.1 read-only：纯读模式的边界

read-only 模式将文件系统挂载为只读视图。智能体可以读取工作区文件、遍历目录、执行不产生副作用的命令（如 ls、cat、grep），但任何写操作都会被拒绝。这一档的典型用途是代码审查、知识问答、依赖分析——任务本身不需要改变仓库状态。

值得注意的是，只读模式并不能完全消除风险。读取操作仍可能泄露敏感信息（例如读取 .env 文件），且某些命令表面只读、实际会写缓存。本文评述：只读模式的安全价值在于把“不可逆操作”从任务空间中移除，而不是提供信息隔离。若需要信息隔离，必须叠加网络策略与路径白名单，这属于另一层控制面。

3.2 workspace-write：默认档的能力与陷阱

workspace-write 是默认档，也是本文讨论的主战场。它允许智能体读写工作区目录内的文件，并执行常规本地命令；对工作区之外的写入则进行拦截，视策略配置决定是直接拒绝还是生成批准请求。

这一档的设计意图是“够用且可控”：绝大多数编码任务——修改源码、新增测试、更新文档、运行构建——都发生在工作区内，因此默认档能覆盖大部分场景。陷阱在于“工作区”的边界并不总是与工程师的心理模型一致。以下操作常被误认为在工作区内，实际越界：

• 写入用户级缓存目录（如 ~/.cache/）以加速依赖安装；
• 修改全局配置文件（如 ~/.gitconfig、~/.npmrc）；
• 在 /tmp 下创建临时构建产物；
• 通过包管理器安装系统级依赖。

当这些操作被拦截时，如果批准策略设置为需要人工确认，智能体就会进入等待。这正是第 1 节“假死”事故的机制来源。笔者认为，workspace-write 的真正难点不是权限太小，而是边界不可见。用户不知道哪些路径属于工作区，也就无法预判哪些操作会触发批准。解决方向有两个：一是在任务开始前显式声明工作区范围；二是让拦截事件在终端上以高可见度方式呈现。

3.3 danger-full-access：能力上限与风险上限

danger-full-access 解除文件系统限制，智能体可读写任意路径。命名中的 “danger” 并非修辞：在这一档下，一次错误的 rm -rf、一次误改系统配置、一次向全局路径写入冲突版本，都可能造成难以回滚的损害。

这一档的合理用途是受控的、一次性的、有快照保护的任务：例如在专用容器内做全仓库重构、在临时虚拟机中验证安装脚本。它不适合作为日常默认，也不适合在缺乏备份与审计的环境中使用。本文评述：把 full access 当作“解决批准疲劳的开关”，是用不可逆风险换取交互便利，在期望值上通常不划算——批准请求的成本是分钟级，误删的成本可能是小时级甚至不可恢复。

4. 三档批准策略与阻塞语义

文件系统模式决定“能不能做”，批准策略决定“做之前要不要问人”。两者是正交维度，但耦合极强。理解批准策略的关键，是理解阻塞语义：当策略要求人工确认时，智能体的执行流会暂停，等待外部输入，而不是报错退出。

4.1 三档策略的语义差异

按风险偏好从紧到松，批准策略大致可分为三档：逐项确认（每个敏感操作都请求批准）、按类确认（对特定类别操作请求批准，其余自动放行）、自动放行（不请求批准，直接执行）。不同工具的具体命名与默认值不同，但语义结构一致。

逐项确认的安全性最高，但批准请求数量也最多，最容易触发批准疲劳。自动放行的交互成本最低，但等于把安全判断完全交给策略配置。按类确认是折中方案，其效果高度依赖分类规则的准确性——分类过粗则漏报，分类过细则退化为逐项确认。

本文评述：三档策略不应被理解为“安全等级”，而应被理解为人机协作频率的调节旋钮。选择哪一档，取决于任务的可逆性、环境的重建成本、以及操作者的响应能力。一个可逆性强、快照完备的容器环境，可以承受更松的策略；一个直接操作生产配置的会话，则应采用更紧的策略。

4.2 阻塞状态机：为什么“卡住”不是“挂了”

从状态机视角看，智能体执行流至少包含以下状态：running（执行中）、awaiting-approval（等待批准）、blocked（被策略拒绝）、failed（执行失败）、done（完成）。

running ──敏感操作──▶ awaiting-approval ──批准──▶ running
                          │
                          ├──拒绝──▶ blocked ──调整策略/路径──▶ running
                          │
                          └──超时──▶ blocked（需人工介入）

running ──命令报错──▶ failed ──修复──▶ running

关键区别在于：awaiting-approval 是正常状态，系统在等待人类输入，没有异常发生；failed 才是异常状态，需要诊断。把前者当后者处理（重启），会丢失任务上下文；把后者当前者处理（干等），会浪费时间。纪律的核心就是先分辨状态，再决定动作。

4.3 超时与默认拒绝：被忽视的边界条件

批准请求通常有超时机制。超时后，系统可能默认拒绝该操作，也可能保持等待。默认拒绝是更安全的默认值，但它会制造一种隐蔽的失败：智能体在等待超时后收到拒绝，可能尝试替代路径，也可能直接放弃任务。如果用户此时不在终端前，回来看到的是“任务未完成”，却看不到“曾经有过一次批准请求”。

笔者认为，批准请求的完整生命周期必须可追溯：何时发起、请求内容是什么、等待了多久、结果如何。缺少这条审计链，事后复盘就只能靠猜。这一点在团队协作场景中尤为关键——批准可能由值班同学完成，而任务发起者需要知道发生了什么。

5. 二维权限矩阵：耦合与边界条件

把文件系统模式与批准策略放在同一张表里，可以得到一个 3×3 的权限矩阵。这个矩阵是本文的分析工具：它帮助我们把“权限配置”从模糊的偏好，转化为可讨论、可审计、可回滚的决策。

矩阵中值得展开的是 workspace-write × 按类确认 这一格。它之所以是推荐工作点，是因为它同时满足三个条件：工作区内的高频写操作不打扰人；越界写与高风险命令仍然触发确认；确认请求的数量被控制在可处理范围内。但这一格的稳定性依赖分类规则的质量，规则需要随项目演进持续维护。

本文评述：矩阵的另一个价值是揭示“提权”与“放宽策略”不是同一件事。从逐项确认切到按类确认，是在不扩大文件系统边界的前提下降低交互频率；从 workspace-write 切到 full access，是扩大边界。前者可逆、影响面小；后者不可逆风险高。工程实践中应优先调整策略粒度，而不是直接改模式。

6. “卡住先看批准队列”的纪律如何养成

纪律不能只靠自觉。行为改变需要触发条件、检查动作、反馈闭环三要素。本节给出一套可操作的养成路径，分为个人层、工具层、团队层三个层次。

6.1 个人层：建立“三秒诊断”反射

当输出停滞超过三秒，不要立即按 Ctrl+C，而是执行一个固定的诊断序列。这个序列应短到可以形成肌肉记忆：

1. 看最后一行输出：是否包含 “awaiting approval”“approval required”“pending” 等关键词；
2. 看是否有交互提示：部分实现会在终端内直接渲染批准界面，光标可能停在选项上；
3. 看进程状态：用 ps 确认进程是否存活、CPU 占用是否接近零（等待输入时通常如此）；
4. 查批准队列：若工具提供独立队列界面或日志，优先查看；
5. 确认无请求后再重启：重启前记录当前任务描述，避免上下文丢失。

这个序列的关键是第 4 步。很多工具把批准请求放在独立面板而非主输出流中，用户只看主输出就会误判。笔者认为，把“查队列”放在“重启”之前，本质上是在训练一种因果归因习惯：先找证据，再采取动作，而不是用动作掩盖不确定性。

6.2 工具层：让阻塞状态可见

个人习惯的养成速度，取决于工具是否配合。如果工具在等待批准时能输出高可见度提示，纪律的形成成本会大幅下降。以下是几种可落地的工程手段：

• 终端标题与状态栏：等待批准时把终端标题改为 [AWAITING APPROVAL]，切窗口回来一眼可见；
• 结构化日志：把批准事件写入 JSON Lines 日志，字段包括时间、操作类型、路径、决策、耗时；
• 桌面通知：等待超过阈值时触发系统通知，避免用户长时间离开；
• 心跳输出：等待期间周期性打印剩余等待时间或队列长度，明确表示“还活着”。

这些手段的共同逻辑是把隐式状态显式化。本文评述：在智能体工具链中，可观测性建设长期偏重“模型输出质量”，而忽视“运行时状态”。批准队列的可见性属于后者，其工程价值不亚于日志与指标。

6.3 团队层：把纪律写进流程与模板

个人习惯容易在压力下退化，团队流程可以提供外部约束。可行的做法包括：

• 在项目 README 或 onboarding 文档中写明“卡住先查批准队列”的诊断步骤；
• 在任务模板中增加“预期越界操作”字段，提前声明可能触发批准的路径；
• 在代码评审中检查权限配置变更，要求说明升级理由与回收条件；
• 在事故复盘中区分“阻塞误判”与“真实故障”，分别制定改进项。

团队层的价值在于把隐性知识变成显性规则。当新成员加入时，他不需要经历一次“假死”事故才能学会这条纪律，而是从文档和模板中直接获得。

7. 从 workspace-write 起步的升级路径

本节给出本文的操作核心：一条从最小权限起步、按证据升级、带回收条件的路径。它把“权限配置”从一次性开关，改造为可审计的升级链。

7.1 阶段一：基线配置与观测

起步配置建议为 workspace-write + 按类确认。先跑一个中等复杂度的任务（例如为现有模块补测试），同时开启批准事件日志。这一阶段的目标不是完成任务，而是收集基线数据：批准请求的数量、类型分布、平均响应时间、被拒绝后的行为。

# 基线观测清单（示意）
- 任务类型：补测试 / 重构 / 修 bug
- 批准请求数：___
- 越界路径 Top3：___
- 平均等待时长：___ 秒
- 拒绝后是否自动改道：是 / 否
- 是否出现批准疲劳迹象：是 / 否

本文评述：基线数据的价值在于把主观感受转化为可比较的指标。用户说“太烦了”，无法指导改进；数据显示“每任务 23 次请求，其中 19 次是写入 ~/.cache”，改进方向就明确了。

7.2 阶段二：策略调优而非模式提权

根据基线数据，优先调整批准策略的分类规则，而不是直接切 full access。常见调优动作：

• 把高频、低风险的越界路径加入白名单（例如项目专用的缓存目录）；
• 把高风险命令（删除、权限修改、网络下载后执行）保持逐项确认；
• 对同一任务内的重复请求启用“记住本次会话的选择”，减少重复打扰；
• 为批准请求增加上下文摘要（例如 diff 预览），提高单次决策效率。

这一阶段的原则是在边界内优化体验。白名单是显式的、可审计的、可撤销的；而 full access 是隐式的、无边界的。前者即使出错，影响范围也可控。

7.3 阶段三：受控提权与回收

当任务确实需要越界写，且策略调优无法覆盖时，才考虑提权。提权必须附带三个要素：范围、时限、回收条件。例如：

提权记录示例：将沙箱切至 danger-full-access，仅用于在一次性容器内重建依赖缓存；时限 30 分钟；回收条件为任务结束或容器销毁；操作前已创建仓库快照；批准事件日志保持开启。

本文评述：提权记录的意义不在于形式，而在于强制操作者在提权前思考可逆性。如果无法写出回收条件，说明这次提权可能不该发生。这条规则与数据库变更管理中的“回滚预案”同构，属于成熟工程实践的迁移。

8. 关键数据与案例：批准疲劳的量化观察

本节的数据分为两类：一类来自公开研究与行业报告，标注真实来源；另一类为本文构造的模拟数据，用于说明分析方法，不构成实证结论。

8.1 公开研究中的告警疲劳证据

告警疲劳在安全运营中心（SOC）研究中已有较多积累。多项行业调查显示，SOC 分析师每天面对大量告警，其中相当比例最终未被有效处理。例如，Vectra AI 发布的年度报告曾指出，安全分析师普遍存在告警疲劳，且大量告警未被及时跟进（Vectra AI, 2023）。Palo Alto Networks 的 Unit 42 也在多份报告中讨论过告警过载对响应效率的影响（Unit 42, 2023）。

本文评述：把告警疲劳的研究迁移到批准疲劳，需要谨慎。两者结构相似（高频低价值信号淹没低频高价值信号），但决策成本不同——告警处理是“调查”，批准处理是“授权”，后者涉及不可逆操作，错误成本更高。因此，批准队列的信噪比要求应高于告警队列，不能简单照搬“降低告警量”的做法。

8.2 模拟数据：一个典型任务的批准分布

以下数据为模拟数据，用于演示分析方法，不代表任何真实产品统计。假设一个“为 Flask 服务补集成测试”的任务在 workspace-write + 逐项确认下运行，批准请求分布如下：

模拟数据显示，约 73% 的请求属于低风险类别，且集中在两类路径上。若把这两类路径加入白名单，批准请求总量可下降约七成，而真正需要人类判断的高风险请求（修改全局配置）仍然保留。这正是第 7.2 节“策略调优优先于模式提权”的量化依据。

8.3 案例：一次越界写引发的连锁反应

某团队在 workspace-write 下运行依赖升级任务，智能体尝试修改 ~/.npmrc 以切换镜像源。该操作触发批准请求，但用户当时在会议中，未及时响应。超时后请求被默认拒绝，智能体改道尝试在工作区内写入 .npmrc，部分生效，导致后续构建在不同目录下行为不一致。

这个案例的教训不是“应该开 full access”，而是批准请求的超时策略需要与工作流匹配。若任务可能在无人值守时运行，应配置通知机制或延长超时；若任务必须人工在场，应在任务描述中明确。本文评述：把超时当作“默认拒绝”的静默机制，会制造难以复现的环境差异，这比一次显式失败更难排查。

9. 对比与局限：full access 的真实代价

支持 full access 的常见理由是“效率”。这个理由在短期内成立，在长期需要拆解。本节从三个维度对比两种工作方式，并指出本文论证的局限。

9.1 效率对比：交互成本 vs 恢复成本

批准请求的成本是分钟级、可预期、可并行的：用户可以在等待期间做别的事，响应一次通常只需数秒。误操作的恢复成本则是小时级、不可预期、串行的：需要定位影响范围、恢复快照、重跑验证。用期望值衡量，只有当批准请求频率极高且误操作概率极低时，full access 才在数学上占优。而这两个条件在真实项目中很少同时成立。

本文评述：效率讨论常犯的错误是只计算显性成本。批准请求的等待是显性的，误操作的风险是隐性的、概率性的。行为经济学中的“概率忽视”（probability neglect）可以解释这种偏差：人们倾向于忽略低概率高损失事件，直到它发生。

9.2 安全对比：护栏的层次

full access 并非完全没有护栏——命令级策略、网络策略、容器隔离仍然可能生效。但它移除了文件系统这一层最直观的护栏。多层防御（defense in depth）的原则要求任何单层失效都不应导致系统性风险；移除一层，就要求其他层承担更多，而其他层往往并未为此设计。

笔者认为，更稳健的做法是保留文件系统护栏，同时降低其交互成本。白名单、按类确认、会话级记忆，都是在不移除护栏的前提下优化体验的手段。这与网络安全中“最小权限原则”（Saltzer & Schroeder, 1975）一脉相承：权限应恰好够用，不多不少。

9.3 本文论证的局限

必须承认三点局限。其一，不同工具对三档模式的具体实现存在差异，本文的描述以常见行为为基准，读者应以所用版本文档为准。其二，本文缺少大规模实证数据，模拟数据仅用于方法演示，不能作为统计结论。其三，权限设计涉及组织文化与合规要求，本文给出的路径是技术视角的建议，不构成合规意见。

10. 团队级治理：把纪律写进工程系统

个人纪律解决“知道该看队列”，团队治理解决“不看队列会被系统发现”。本节给出四个可落地的治理机制。

10.1 权限配置即代码

把沙箱模式、批准策略、白名单写入版本控制，随项目一起评审。配置变更走 Pull Request，要求填写变更理由与回收条件。这样，权限状态从“某个人的本地设置”变成“团队可见的工程资产”。

# 权限配置示例（示意，非真实 schema）
sandbox:
  filesystem: workspace-write
  approval: category-based
  allowlist:
    - "~/.cache/project-x/**"
  require_approval:
    - "**/.gitconfig"
    - "**/.npmrc"
    - "rm -rf *"
  audit_log: .agent/approvals.jsonl

10.2 批准事件纳入可观测性

把批准事件作为指标采集：请求数、批准率、拒绝率、平均等待时长、超时率。这些指标可以与任务成功率关联分析，回答“批准摩擦是否真的拖慢了交付”。若数据显示某类请求长期被快速批准，说明它可以进入白名单；若某类请求长期被拒绝，说明智能体的行为需要调整。

🔒 复制本站文章内容需登录并达到 L3。当前：未登录