03 — 工具审批策略引擎：YOLO 模式与审批缓存

工具审批策略引擎：YOLO 模式与审批缓存

学习目标

理解 CodeWhale 的工具审批策略引擎：三层操作模式、审批缓存机制、多平台沙箱集成与 MCP 工具审批流。

前置知识

• 安全沙箱设计 — 多层防御架构与平台沙箱技术栈
• 工具调用协议 — Function Calling 协议与工具系统架构

下文假设你已理解上述概念，直接聚焦 CodeWhale 的具体实现。

项目实践

三层操作模式

模式	写入权限	审批门	沙箱	切换方式
Plan	只读	不适用	只读策略	/mode plan 或 Tab 循环
Agent	可写入	破坏性操作需确认	平台沙箱	默认模式
YOLO	可写入	自动批准	平台沙箱	--yolo 或 /mode yolo

审批流程

审批缓存（Remembered Approvals）

当用户在审批对话框勾选 “remember”：

• 同类操作后续自动批准，无需等待下一轮
• 立即翻转当前 turn 的 auto_approve 标志
• 缓存持久化到配置文件

多平台沙箱集成

平台	沙箱技术	状态
macOS	Seatbelt（sandbox-exec）	活跃执行
Linux	Landlock（内核 5.13+）+ seccomp + bwrap	检测，未正式执行
Windows	Job Object（计划中）	未正式支持
Linux 进程加固	PR_SET_DUMPABLE=0 / NO_NEW_PRIVS / RLIMIT_CORE=0	v0.8.46+ 活跃

MCP 工具审批

MCP 发现的工具同样走审批框架：

• 只读 MCP 助手（资源/提示列表和读取）在 suggestive 模式下可跳过审批
• 有副作用的 MCP 工具需要审批
• MCP 工具配置被视为等同于在机器上运行代码

环境变量控制

DEEPSEEK_YOLO=1    # 启动时启用 YOLO 模式

v0.8.46 修复了 DEEPSEEK_YOLO 环境变量在启动时被 honoured 的问题（之前 --yolo 标志和环境变量未正确合并）。

问题与规避

陷阱：YOLO 模式下误批准危险操作

YOLO 自动批准所有工具，包括 rm -rf 等危险命令。

规避：

• YOLO 只应在可信工作区使用
• macOS Seatbelt 沙箱在 YOLO 模式下仍然活跃——操作系统级的安全网
• Linux 进程加固（NO_NEW_PRIVS 等）提供额外防护

陷阱：审批缓存过期后误批准

用户之前记住了对某个工具的批准，但工作区环境已变化。

规避：审批缓存按工具类型和参数缓存，工作区切换后应手动清理缓存。

陷阱：Plan 模式下的只读限制

Plan 模式下模型应该只读调查，但如果需要记录发现（如 checklist_write），写操作是否允许？

规避：Plan 模式下允许最小写入（checklist、plan 更新），但不允许修改项目文件。

设计取舍

审批与沙箱分离

CodeWhale 将 execpolicy（审批决策）和 sandbox（资源限制）设计为两个正交的 crate：

维度	execpolicy	sandbox
职责	决策：是否批准	约束：限制资源访问
层级	应用层	系统层
平台依赖	无	有（macOS/Linux/Windows 不同）
用户交互	有（审批对话框）	无（静默执行）

优势：

• 可以在不同平台上使用相同的审批策略
• 沙箱增强是独立于审批的额外防护层
• 新平台只需要实现 sandbox crate，不需要改动审批逻辑

为什么 YOLO 不是”关闭沙箱”

YOLO 只关闭审批门，不关闭沙箱。即使在 YOLO 模式下：

• macOS Seatbelt 仍然活跃
• Linux 进程加固仍然生效
• 工具执行仍然被限制在工作区内

这是”合作模式下的错误捕捉”——即使信任模型的意图，仍然有操作系统级的安全网。

参考来源

• crates/execpolicy/ — 审批策略引擎源码
• crates/tui/src/sandbox/ — 多平台沙箱实现
• README: “Three modes control the action space”
• docs/SANDBOX.md — 沙箱文档