上一篇《Harness 怎么扩展：skill、配置目录与 hook》聚焦于“往 harness 里加东西”——将可复用工作流打包成 skill，将约束写入配置目录，将监控逻辑挂接到 hook。本篇换个角度：当 agent 已装配好各类工具后，如何有效管控它的行为？ 两个核心问题浮出水面：第一，agent 在修改文件、执行命令、发起网络请求时，如何界定哪些操作需征求用户意见、哪些可自动放行；第二，针对同一模型，怎样依据不同场景灵活调节其“推理深度”，既避免浪费 token，又不让复杂任务因思考不足而打折。 CC 和 Codex 对这两个课题均给出了各自解法。与系列前几篇一致，差异不在于“谁有谁没有”，而是面对相同的控制难题，两家在工程实现上选择了截然不同的路径。 ## 一、权限管控 首先聚焦第一个问题：权限控制。Agent 在运行过程中会涉及文件修改、命令执行、网络请求发起等操作。完全放开存在安全隐患，而每次都询问则会严重拖累效率。核心矛盾在于：如何在“最小化打断”与“确保可控性”之间找到一个可调节的平衡点，并让这个平衡点能够按“个人/项目/企业”等层级分层固化下来。 Codex 的解法是将授权拆解为两个正交维度，组合成一张授权矩阵。 **维度一：沙箱策略**，用于定义 agent 的操作边界。其枚举类型 `SandboxPolicy` 包含 4 个变体： - `DangerFullAccess`——无任何限制 - `ReadOnly`——仅允许只读操作，网络默认关闭 - `ExternalSandbox`——已在外部沙箱中运行，放开磁盘访问但遵循传入的网络设置 - `WorkspaceWrite`——在 ReadOnly 基础上额外允许写入当前工作区及列表中的 `writable_roots` **维度二：审批策略**，用于决定何时暂停操作并询问用户。枚举类型 `AskForApproval` 包含 5 个变体： - `UnlessTrusted`——仅对“已知安全且只读”的命令自动批准，其余均需询问 - `OnFailure`（已标记为 DEPRECATED）——沙箱内全自动批准，仅在失败时升级给用户处理 - `OnRequest`（默认档）——由模型自行判断何时需要询问 - `Granular`——按类别提供细粒度开关，某类设为 `true` 则放行，`false` 则直接自动拒绝 - `Never`——从不询问，失败直接返回给模型 `Granular` 变体内部包含 5 个类别字段：shell 命令审批、execpolicy 规则触发的提示、skill 脚本执行、`request_permissions` 工具触发、MCP elicitation 提示。 两个维度的分工十分清晰：沙箱策略负责“边界管控”（文件读写范围 + 网络开关），审批策略负责“节奏控制”（何时暂停询问）。两者彼此独立，可任意组合使用。 CC 则选择了另一条路径：将授权构建为三层叠加结构——模式（baseline）+ 规则（allow/ask/deny）+ 分类器（auto mode 实时审查）。 6 种权限模式，通过 Shift+Tab 在 `default→acceptEdits→plan` 之间循环切换： - `default`——仅只读操作无需询问 - `acceptEdits`——读操作 + 文件编辑 + 工作目录内的 `mkdir`/`touch`/`mv`/`cp`/`rm`/`rmdir`/`sed` 无需询问 - `plan`——仅只读，用于研究并给出方案，不修改源码 - `auto`——几乎全部无需询问，但有独立分类器模型在动作执行前进行实时审查；标注为 research preview - `dontAsk`——仅运行预批准的工具，其余一律自动拒绝；适用于锁定的 CI 或脚本场景 - `bypassPermissions`——跳过所有检查，全部不询问，等价于 `--dangerously-skip-permissions`，仅用于隔离容器/VM；`rm -rf /` 和 `rm -rf ~` 仍会触发熔断提示 除 `bypassPermissions` 外，对 protected paths（`.git`/`.claude`/`.vscode`/`.idea` 等）的写入操作永不自动批准。 规则分为三类：`allow`（不询问直接使用）、`ask`（每次需确认）、`deny`（禁止执行）。评估顺序为 deny → ask → allow，首条匹配即生效，deny 始终拥有最高优先级。有一个细节值得特别记录：bare 工具名 deny（如 `Bash`）会将该工具从上下文中整体移除；scoped deny（如 `Bash(rm *)`）则保留工具，仅拦截匹配的调用。 settings 拥有 5 级优先级：Managed（企业 IT 推送，优先级最高，不可被任何层覆盖）> 命令行参数 > Local（`.claude/settings.local.json`）> Project（`.claude/settings.json`）> User（`~/.claude/settings.json`）。任意一层设为 deny，其它层均无法将其覆盖为 allow。 auto mode 分类器包含以下几个关键细节：独立分类器模型会在动作执行前进行审查，拦截三类场景——超出请求范围的升级操作、指向不熟悉的基础设施、被读取到的敌意内容所驱动的动作。决策顺序为：先走 allow/deny 规则，只读操作及工作目录内编辑直接放行，其余交由分类器处理，拦截时会将理由回传给模型。 进入 auto mode 时会丢弃宽泛的 allow 规则（`Bash(*)`、通配解释器、包管理 run、`Agent` 规则），退出时恢复。分类器仅查看 user 消息、工具调用、CLAUDE.md，工具结果被剥离（防止注入）。回退阈值：连续 3 次或累计 20 次被拦截，auto mode 暂停，转为逐条提问模式（该阈值不可配置）。 会话中以口头方式声明的边界（例如“先别 push”）会被当作 block 信号，但不会持久化，compaction 删除了那条消息后就可能失效；如需确保生效，必须写入 deny 规则。 从对比角度来看，两家的核心模型存在本质差异： | 维度 | Codex | CC | |------|-------|-----| | 核心模型 | 两个正交维度：沙箱策略 × 审批策略 | 三层叠加：模式 + 规则 + 分类器 | | 档位粒度 | 4 沙箱 × 5 审批，组合矩阵 | 6 种模式（含 dontAsk 全预批） | | 最细粒度收口 | `Granular`：5 个类别字段独立开关 | scoped deny：`Bash(rm *)` 级别 | | 语义审查 | 无（确定性规则组合） | auto mode 分类器，语义把关 | | 企业策略锁定 | 沙箱策略 + 审批策略约束组合 | Managed settings，5 级优先级最高 | 简单概括：Codex 偏向“策略把关”——两个确定性维度正交组合，开源可验证，行为可预测。CC 偏向“模型把关 + 策略兜底”——auto mode 利用独立分类器进行语义判断，deny 规则层作为兜底保障。 **实操建议方面**：Codex 日常使用 `WorkspaceWrite` + `OnRequest`（默认组合）；无人值守批量运行时使用 `Never`，但务必配合收窄的沙箱（关闭网络、限制 `writable_roots`）；`Granular` 适合“放行 shell 但卡住 MCP/skill 脚本”这类精细场景。CC 复盘式编码使用 `acceptEdits`，配合编辑器或 `git diff` 事后审查；长任务减少打断使用 `auto`，但需注意它是 research preview，敏感操作仍需人工过目；CI 场景使用 `dontAsk` + 预批 allow 列表；`bypassPermissions` 仅在隔离容器中使用。通用原则：企业安全边界使用 Managed 或约束层锁定，不要试图通过项目层覆盖；硬边界务必写入 deny 规则，不能仅依赖对话中的口头声明。 ## 二、推理深度调节 说完权限，再来审视第二个问题：effort（推理深度）。同一个模型，既可以“少想快答”，也可以“多想深答”。简单任务思考过深既浪费 token，又可能导致 overthinking；复杂任务思考不足则难以产出高质量结果。因此，需要一个可调节“思考深度”的档位，并且能够按模型、按场景设定默认值。 Codex 的做法相当直接。`ReasoningEffort` 枚举包含 6 个档位：`None` / `Minimal` / `Low` / `Medium`（默认）/ `High` / `XHigh`。客户端只做一件事：透传。将 effort 组装进请求，最终转化为 OpenAI Responses API 请求体中的 `{"reasoning":{"effort":"high"}}`。客户端不修改 system prompt、不调整工具列表、不改变上下文窗口、不执行任何本地推理增强。 三层 fallback 机制：当前 turn 用户设定的值 → 模型默认档 → 模型不支持 reasoning 则整个 `reasoning` 字段不发送。切换模型时的档位平移，按 rank 差绝对值最小原则，映射到目标模型所支持的最近档位。Plan 模式拥有独立 effort，规划阶段可单独配置更高档位。 CC 的档位则依模型而定。Opus 4.8 / Opus 4.7 支持 `low` / `medium` / `high` / `xhigh` / `max`；Opus 4.6 / Sonnet 4.6 支持 `low` / `medium` / `high` / `max`。默认档位：Opus 4.8、Opus 4.6、Sonnet 4.6 均为 `high`；Opus 4.7 为 `xhigh`。若设置了当前模型不支持的档位，则回退到不超过该档的最高支持档位。 持久性差异：`low`/`medium`/`high`/`xhigh` 跨会话持久保留；`max` 仅当前会话生效（除非通过环境变量设置）。`max` 代表最深推理、token 不封顶的档位，官方文档原话为“prone to overthinking, test before adopting broadly”。 此外还有两样东西，并非模型原生的档位，而是 CC 自行添加的功能。`ultracode` 值得单独重点说明，因为它常被误认为“Opus 4.8 多出来的一个推理档”，实则不然。它是 CC 的会话级设置：启用后向模型发送 `xhigh`，同时让 Claude 为每个实质性任务自动编排一套 dynamic workflow——一段由 Claude 即时编写、在后台运行的 JavaScript 编排脚本，将工作拆解给数十到上百个 subagent 并行执行。 它与普通 subagent 编排的关键区别在于：脚本自身持有循环、分支和中间结果，Claude 的上下文中只保留最终答案。因此它特别适合“一个对话协调不过来”的大型任务——全仓 bug 扫描、数百文件迁移、多源交叉验证的调研；脚本还能固化质量保障流程，例如让多个 agent 互相对抗式复核彼此的结论后再汇报。 触发方式有两条路径：在 prompt 中直接要求，或通过 `/effort ultracode` 让 Claude 在整个会话中对每个实质性任务都自动规划一套工作流。它仅在支持 `xhigh` 的模型上出现在 `/effort` 菜单中（即 Opus 4.8 / 4.7），其余模型不提供此选项。仅当前会话生效，不属于 `effortLevel` 设置、`--effort` flag 或 `CLAUDE_CODE_EFFORT_LEVEL`。 `ultrathink` 关键词：在 prompt 的任意位置写入 `ultrathink`，可请求当前轮次进行更深层次的推理。它不会改变会话的 effort 设置，发送给 API 的 effort 值保持不变，仅在上下文中增加一条 in-context 指令。“think”/“think hard”等表述不会被识别为关键词。 设置入口丰富多样：`/effort`（无参数开启滑块 / `/effort <档名>` 直接设置 / `/effort auto` 恢复模型默认）；`/model` 中通过左右键调节滑块；`--effort` flag；`CLAUDE_CODE_EFFORT_LEVEL` 环境变量；`effortLevel` 设置（仅接受 low~xhigh，`max` 和 `ultracode` 不接受）；skill/subagent frontmatter 中的 `effort` 字段。优先级排序：环境变量 > 配置档 > 模型默认。 从对比角度来看： | 维度 | Codex | CC | |------|-------|-----| | 档位数量 | 6 档（None/Minimal/Low/Medium/High/XHigh） | 依模型而定，最多 5 档（low/medium/high/xhigh/max） | | 默认档 | `Medium` | 多数模型 `high`（Opus 4.7 为 `xhigh`） | | 客户端是否加工 | 不加工（纯透传，仅改 API 一个字段） | 有额外封装（ultracode 触发后台工作流编排） | | 单轮临时加深 | 无专用关键词 | `ultrathink` 关键词（不改变会话档位） | | max 持久性 | 不适用 | 仅当前会话（非环境变量设置时） | | 切模型档位映射 | `nearest_effort`：绝对值最近档（可能升档） | 取不超过目标档的最高支持档（只降不升） | | Plan 阶段独立 effort | 有（`plan_mode_reasoning_effort` 独立字段） | 无专用字段 | 两家共享 low/medium/high/xhigh 的中段命名方式，均拥有模型默认档和回退机制。差异在于：Codex 将 effort 视为一个仅向 API 传递、本地不加工的字段，源码可证；CC 在同样的档位之外又额外增加了几个自有功能——向上有 `max`（不封顶）、`ultracode`（effort 连带触发后台工作流编排）、`ultrathink`（单轮临时加深，不动会话档）。回退算法也有所不同：Codex 的 `nearest_effort` 按 rank 差绝对值最小映射，可能比目标档更高；CC 则取“不超过目标档的最高支持档”，只降不升。 **实操建议**：Codex 默认 `Medium` 适合大多数场景；需要深度推理时调至 `High`/`XHigh`；可为 Plan 模式单独配置更高档位（规划阶段值得多思考，执行阶段不必同等档位）；请记住调档仅改变一个传给服务端的字符串，本地不会因此“更努力”。CC 日常使用 `high`（Opus 4.8 默认）已足够；遇到难题时直接在 prompt 中写入 `ultrathink` 进行临时加深，无需改动会话设置；如需 Claude 自动拆解任务并并行编排，使用 `ultracode`；`max` 需谨慎使用，可能存在 overthinking 风险，建议先小范围试验。通用原则：effort 是按模型校准的，同一档名在不同模型上并不代表相同的算力投入，切换模型后请确认实际生效的档位。 ## 小结 两节内容下来，两家在控制面上的方向可以各用一句话来概括： **Codex**：权限是“策略矩阵”（两个确定性维度正交组合，开源可验证），effort 是“只传不改的档位”（拨到哪档就原样发出哪档，本地不加工）。可预测性优先，行为可检查。 **CC**：权限是“模型把关 + 策略兜底”（auto mode 分类器进行语义审查，deny 规则硬性兜底），effort 是“档位 + 几样加料”（max 不封顶、ultracode 连带后台编排、ultrathink 临时加深）。灵活度优先，将控制面做厚。 两套解法没有绝对的对错，各自适合不同场景。需要行为强可预测、安全边界机器可验证的，Codex 的组合矩阵更加直接；需要减少人工干预、靠语义判断处理复杂边界的，CC 的分类器路径更为省心。 --- **Harness Engineering 系列** 这个系列围绕 coding agent 的「平台层（harness）与业务工程」，逐篇拆解： - Harness 到底指什么 —— 平台层与业务工程的边界 - 复杂任务的 Spec 怎么写 —— 多 Agent、编排者入口、rules / docs / skills 组织 - Harness 怎么扩展：skill、配置目录与 hook —— CC 与 Codex 的两套扩展机制 - Harness 怎么拿捏 agent：权限与 effort —— 本篇 - Harness 怎么扛住长任务：compact、memory、goal —— 待更