Open Interpreter 的 YOLO 模式：codex-rs 中"全自主执行"的提示词设计、判定逻辑与实现链路

YOLO 模式是 openinterpreter（codex-rs）TUI 交互会话中的一种最高放权运行形态：审批策略关闭、动作全部预批准，代理以完全自主方式执行多步任务。本文以 modes/yolo.md 这份模式提示词文件为主体，结合 deepseek_tui.rs、session.rs 等源码，讲清该提示词的逐句含义、它在系统提示词中的装配位置，以及"YOLO 模式"这一状态在 TUI 会话头部和请求路由中的判定与呈现方式。读完你可以掌握：这份 12 行提示词承载的行为约束、仓库中"YOLO"三个字从配置到渲染的完整调用链，以及全自主模式下的安全兜底设计。

一、yolo.md 原文与逐条解读

modes/yolo.md 全文如下（12 行，无任何外部链接或占位内容）：

## Mode: YOLO

You are running in YOLO mode — full autonomy, all actions pre-approved.

All actions auto-approved. Move fast, but think before you write. If you're about to delete files,
overwrite user work, or run destructive commands, pause and double-check. The undo button is the user's Git history.

Even with auto-approval, use `checklist_write` for work that has several concrete steps so progress is
visible and trackable in the sidebar. Keep simple commands and focused edits direct.
For multi-step initiatives, keep `checklist_write` current. Add `update_plan` only when a high-level strategy
would help and do not duplicate the checklist there.

这段提示词定义了 YOLO 模式下代理必须遵守的三条核心纪律：

• 全自主、全预批准（"full autonomy, all actions pre-approved" / "All actions auto-approved"）：这是 YOLO 模式与默认交互模式的根本区别——不存在逐个审批的提示，动作直接执行。它同时声明了节奏基调："Move fast, but think before you write"（快，但落笔前先想）。
• 破坏性操作前的强制停顿：文件删除、覆盖用户工作、执行破坏性命令之前必须"pause and double-check"。这里有一句值得玩味的设计——"The undo button is the user's Git history"（撤销按钮就是用户的 Git 历史）。它把可回滚性作为 YOLO 模式的安全边界：全自主不等于不可挽回，代理被要求以 Git 历史为最后防线来约束自己。
• 可见性纪律：即便动作已自动批准，多步骤工作仍必须用 checklist_write 工具把具体步骤写出来，让进度在侧边栏可见、可跟踪；简单命令和聚焦式编辑则保持直接执行，不为用工具而用工具。对多步工程要保持清单实时更新，update_plan 只在需要高层策略时才补充，且不得与 checklist 内容重复。这两个工具在 base.md 的 "Toolbox (fast reference)" 一节中也被列为 "Planning / tracking" 类别的首选工具，说明 yolo.md 的约束与基础提示词的工具约定是自洽的。

二、yolo.md 如何被装配进系统提示词

yolo.md 不是运行时动态加载的文件，而是在编译期通过 include_str! 内联进二进制的。deepseek_tui.rs 顶部集中声明了 CodeWhale TUI 提示词的全部组成部分：

const DEEPSEEK_TUI_DEFAULT_MAX_TOKENS: u32 = 64_000;
const CODEWHALE_BASE_PROMPT: &str = include_str!("deepseek_tui_prompts/base.md");
const CODEWHALE_CALM_PERSONALITY: &str = include_str!("deepseek_tui_prompts/personalities/calm.md");
const CODEWHALE_YOLO_MODE: &str = include_str!("deepseek_tui_prompts/modes/yolo.md");
const CODEWHALE_AUTO_APPROVAL: &str = include_str!("deepseek_tui_prompts/approvals/auto.md");
const CODEWHALE_COMPACT_TEMPLATE: &str = include_str!("deepseek_tui_prompts/compact.md");

在 build_system_prompt 中，系统提示词按固定顺序拼接：

fn build_system_prompt(prompt: &Prompt, model: &str) -> (String, bool) {
    let cwd = prompt.cwd.as_deref();
    let base_prompt = CODEWHALE_BASE_PROMPT.replace("{model_id}", model);
    let mut sections = vec![
        base_prompt,
        CODEWHALE_CALM_PERSONALITY.to_string(),
        CODEWHALE_YOLO_MODE.to_string(),
        CODEWHALE_AUTO_APPROVAL.to_string(),
    ];
    // 其后按需追加项目指令（AGENTS.md 类）与项目上下文包

从源码结构看，YOLO 模式提示词（CODEWHALE_YOLO_MODE）与基础宪法 base.md、calm 人格 calm.md、自动审批法规 auto.md 一起构成该 TUI harness 系统提示词的固定主干；{model_id} 占位符在基础段中被替换为实际模型名。这与 base.md 第 VII 章 "The Hierarchy of Law" 的分层设计相呼应：base.md 自述 "Statutes (Tier 2)" 涵盖 "Mode permissions, approval policies, output format rules"，即模式（Mode）提示词在法律层级上属于第 3 层的运行期法规，低于宪法条款和当前用户指令，但高于人格与惯例——yolo.md 开头 "You are running in YOLO mode" 正是这样一种模式级法规声明。

与 yolo.md 搭配的 approvals/auto.md 从审批侧补齐了同一承诺："All tool calls are pre-approved. You will not see approval prompts — your actions execute immediately."，并显式引用宪法第四、五条（行动义务与验证纪律），强调"全自主执行权限"并不豁免验证责任。两者合起来构成 YOLO 语义的完整表述：yolo.md 管"怎么跑"，auto.md 管"审批如何消失"。

三、"YOLO 模式"在 TUI 中如何被判定与显示

提示词之外，"YOLO 模式"还是一个可被代码精确判定的会话状态。TUI 会话头部的渲染逻辑在 session.rs：

pub(crate) fn is_yolo_mode(config: &Config) -> bool {
    has_yolo_permissions(
        AskForApproval::from(config.permissions.approval_policy.value()),
        &config.permissions.effective_permission_profile(),
    )
}

pub(crate) fn has_yolo_permissions(
    approval_policy: AskForApproval,
    permission_profile: &PermissionProfile,
) -> bool {
    approval_policy == AskForApproval::Never
        && matches!(
            permission_profile,
            PermissionProfile::Disabled
                | PermissionProfile::Managed {
                    file_system: ManagedFileSystemPermissions::Unrestricted,
                    network: NetworkSandboxPolicy::Enabled,
                }
        )
}

由此可以确认 YOLO 模式的判定是"双条件"：审批策略为 AskForApproval::Never（从不询问用户），且权限档案要么被禁用（PermissionProfile::Disabled）、要么为无文件限制且网络放开的受管档案（file_system: Unrestricted + network: Enabled）。只有两个条件同时满足，会话头部才会追加一行渲染（同文件 L383-L389）：

if self.yolo_mode {
    let permissions_label = format!("{PERMISSIONS_LABEL:<label_width$}");
    lines.push(make_row(vec![
        Span::from(format!("{permissions_label} ")).dim(),
        "YOLO mode".magenta().bold(),
    ]));
}

即终端会话头部以紫红色加粗显示 permissions: YOLO mode，让用户在会话开始时就明确知晓当前处于全自主状态。相关的终端快照测试见 session_header_indicates_yolo_mode.snap。

四、请求路由侧的 YOLO 信号："Approval policy is currently never."

除了 UI 展示，YOLO 状态还会以文本信号的形式流入 harness 的请求构造。审批策略为 never 时，权限提示模板 approval_policy/never.md 会向模型注入一句固定声明：

Approval policy is currently never. Do not provide the `sandbox_permissions` for any reason, commands will be rejected.

harness 请求路由 request.rs 直接以这句话作为 YOLO 判据：

let yolo_mode = prompt
    .base_instructions
    .text
    .contains("Approval policy is currently never.");

该 yolo_mode 布尔值随后被传入各兼容路由的请求构造函数（如 build_kimi_cli_request、build_qwen_code_request），供下游协议适配使用。测试覆盖了这条链路：kimi_cli.rs 中的 kimi_yolo_mode_keeps_question_tool_without_prompt_reminder 用例验证了 YOLO 模式下询问类工具（AskUserQuestion）的保留行为；core/tests/suite/permissions_messages.rs 与 catalog_permission_messages.rs 则断言 never 策略下权限指令中必须出现 "Approval policy is currently never"。

五、相关审批旗标与使用注意

与 YOLO 相邻的审批控制项在 CLI 测试中可见：cli/src/main.rs 断言 --approve-for-me 与隐藏别名 --not-so-yolo 会将配置覆盖为交互式自动审批（auto_review + sandbox_mode="workspace-write"），且 --not-so-yolo 不出现在 --help 输出中。需要注意：从测试断言看，--approve-for-me 对应的是"workspace-write 沙箱 + 自动审批"的组合，与 has_yolo_permissions 要求的"Never + 无文件限制/禁用权限档案"并不相同——它是另一档放权，而非 YOLO 本身。因此实际使用中，"是否进入 YOLO 模式"应以 TUI 会话头部是否显示 permissions: YOLO mode 为准，权限体系的完整语义可进一步参阅 docs/permissions.md 与 docs/config-reference.md。

对使用 YOLO 模式的实践者，yolo.md 给出的安全契约可以归纳为三条可验证的行为预期：

• 可回滚优先：删除文件、覆盖工作、破坏性命令前必须复核，Git 历史是唯一"撤销按钮"——这意味着在受版本控制的工作区中运行 YOLO 会话，比在无版本控制的目录中更安全；
• 进度可见：多步任务必须有 checklist_write 清单且保持更新，update_plan 只做高层策略且不重复清单内容；
• 验证不豁免：与 auto.md 和 base.md 第五条款一致，"verify your work even when no one prompts you"——自动批准降低的是交互摩擦，不降低验证义务。

六、小结

modes/yolo.md 只有 12 行，但它是 YOLO 全自主模式的行为宪章：以"预批准"换取速度，以"破坏性操作前停顿 + Git 历史兜底"保留安全边界，以 checklist_write / update_plan 维持多步工作可见性。在实现层面，它经 deepseek_tui.rs 的 include_str! 编译期内联，在 build_system_prompt 中固定追加到 CodeWhale TUI 系统提示词主干；而"YOLO 模式"这一运行时状态则由 session.rs 中的 AskForApproval::Never + 无限制权限档案双条件判定，并在 TUI 头部以紫红色 permissions: YOLO mode 明示；请求路由侧则通过 "Approval policy is currently never." 模板文本（request.rs）向各兼容 harness 传递同一信号。提示词、判定逻辑与 UI 呈现三者共用同一套语义，使"全自主执行"在这套代码中成为一个可判定、可展示、可测试的明确状态，而非模糊的口号。