Open Interpreter 的 deepseek-tui Harness：Auto 审批策略（Tier 2 成文法）如何设计无人值守 Agent 的责任边界

Auto 审批策略（Auto Approval Policy）是 Open Interpreter 中 deepseek-tui harness（CodeWhale 系统提示）的一条 Tier 2 成文法：它宣布"所有工具调用预先批准、不再出现审批弹窗"，同时用五条行为约束和两条宪法条款（Article IV 行动义务、Article V 验证纪律）为完全自主执行的 Agent 划出责任边界。读完本文，你将理解该策略的完整规则文本、它在系统提示装配链中的确切位置与调用链、它和 YOLO 模式/宪法体系的协作关系，以及 checklist_write 等配套工具在源码中的实现证据——足以让你在自己的 Agent 系统中参考这套"授权即责任"的提示工程范式。

策略原文：全文继承与逐条解读

策略文件 approvals/auto.md 的完整内容如下（标题 + 正文，未删节）：

Approval Policy: Auto — Tier 2 (Statute)

All tool calls are pre-approved. You will not see approval prompts — your actions execute immediately.

This means you carry more responsibility:

• Pause before destructive operations (deletes, force-pushes, rm -rf).
• Use checklist_write for multi-step work so progress stays visible even though no one is watching.
• If you're uncertain about a course of action, state your reasoning before proceeding.
• The user can interrupt you at any time.

This approval policy is a Tier 2 Statute. It grants full execution authority within Constitutional bounds. Article IV (Duty of Action) applies fully — you are expected to execute, not narrate. Article V (Discipline of Verification) still applies — verify your work even when no one prompts you to.

从规则设计角度看，这段提示做了三件事：

1. 授权声明："All tool calls are pre-approved" 直接取消人类在环（human-in-the-loop）的审批门禁。注意措辞是"You will not see approval prompts"——它明确告诉模型不要期待审批 UI，避免模型把"等批准"写进自己的执行计划里。
2. 责任补偿清单（四条 bullet）：授权越大、监督越弱，模型自身就要承担越多的"自我监督"义务——破坏性操作前暂停（删除、强推、rm -rf）、用 checklist_write 让进度在无人旁观时依然可见、不确定时先陈述推理再行动、承认用户随时可以中断。
3. 法律定位：声明自己是 Tier 2 成文法（Statute），执行权在"宪法边界内"完全授予，并点名两条宪法条款继续生效——Article IV 要求"执行而非叙述"，Article V 要求"无人督促也要验证"。这正好对应无审批场景下的两个典型失败模式：只描述不行动（narrator 问题）、以及不验证就宣称成功。

提示装配链：auto.md 在系统提示中的确切位置

auto.md 不是独立生效的，它通过 include_str! 被编译进 Rust 二进制，再按固定顺序拼进最终 system prompt。

在 deepseek_tui.rs 中，所有 CodeWhale 提示段落都以常量形式内嵌：

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（deepseek_tui.rs），顺序是：

1. base.md（CodeWhale 宪法 + 成文法 + 法规，{model_id} 占位符被替换为实际模型 slug）
2. calm.md（Tier 8 人格：仅控制语气，不得阻止任何工具调用）
3. yolo.md（Tier 2 模式：全自主、所有动作自动批准）
4. auto.md（本文主角：审批策略）
5. 项目指令块（.codewhale/instructions.md / .deepseek/instructions.md / AGENTS.md / CLAUDE.md，向上递归查找，都没有则自动生成一份项目结构说明）
6. 项目上下文包（目录结构、README 摘录、关键源文件列表）
7. ## Environment 块（平台、shell、工作目录、lang 等）
8. Context Management 块（/compact 与提示缓存经济学说明）
9. compact.md 模板与 Authority Recap 结尾块

这个"最静态在前"的排列并非随意：deepseek_tui.rs 中的 Context Management 段落明确解释，DeepSeek 对请求中最长字节稳定前缀做缓存（128 token 粒度、约 90% 成本折扣），所以稳定的宪法/法律文本放最前，易变的 <turn_meta> 工作集信息则被 add_turn_metadata_to_latest_user_message 追加到最新的 user 消息里而不是系统提示里，以保住前缀缓存命中率。Auto 审批策略作为不随会话变化的法律文本，天然适合放在这个稳定前缀中。

装配结果会进入最终的 Chat Completions 请求体（max_tokens: 64000、stream: true、tool_choice: "auto"），请求构造入口见 build_request。

上下文佐证：宪法层级、YOLO 模式与人格文件的分工

要准确理解 auto.md 的语义，需要看它的三个邻居文件，因为 CodeWhale 提示采用"立法体系"式的分层设计：

法律层级（Article VII） 定义在 base.md：Tier 1 宪法（真理、用户主权、行动义务、验证纪律、协调遗产）> 用户当前指令 > Tier 2 成文法（模式权限、审批策略、输出格式规则、工具选择纪律） > 法规 > 项目本地规则（AGENTS.md 等）> 证据 > 记忆 > 人格 > 先例。auto.md 自我声明为 Tier 2，意味着它高于项目规则和人格，但低于宪法和用户当前消息——"在宪法边界内授予完全执行权"正是这个层级的准确表述。

YOLO 模式（modes/yolo.md）是 auto.md 的姊妹条款，两者共同构成"全自主"面：

You are running in YOLO mode — full autonomy, all actions pre-approved. ... 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.

值得注意的对照：auto.md 说 "all tool calls are pre-approved"（授权层），yolo.md 说 "move fast, but think before you write"（行为层），并且两者都强调同一件事——多步工作要用 checklist_write。这是提示工程中典型的"冗余强化"：同一关键约束在多个法律文件中重复出现，以提高模型遵守的可靠性。

Calm 人格（personalities/calm.md）则明确划界：人格是 Tier 8，"controls how you speak, never what you do"，末尾列出五条"永不"（不得阻止必要工具调用、不得屏蔽验证步骤等）。它和 auto.md 的分工关系是：auto.md 决定"可以做什么"，calm.md 决定"用什么语气报告"。

checklist_write：无人监督时让进度可见的工具实现

auto.md 第二条 bullet 指名的 checklist_write 是这套机制能自洽的关键——没有审批弹窗，就没有天然的"人在看着"时刻，于是工具层承担可视化职责。

在工具定义 deepseek_tui_tools.json 中，checklist_write 是一个独立工具（第 431 行），另有 todo_* 系列兼容别名，其描述为"Compatibility alias for checklist_write. Replace the active thread/task checklist; durable tasks are the real executable work object."；配套的 update_plan（第 2278 行附近）描述为"高层策略元数据……不要与 checklist 条目重复"，与 base.md 中"Composition Pattern for Multi-Step Work"法规一一对应（5 步以上任务先 checklist_write 叶子任务、执行中更新状态、必要时才加 update_plan）。

运行时还有一处佐证：deepseek_tui.rs 的 format_deepseek_tui_tool_outputs 会拦截 update_plan 的工具结果，把 "Plan updated" 重写为带 pending/in_progress/completed 计数与百分比的结构化 JSON 摘要（Plan updated: N pending, M in progress, K completed (P% done)），方便模型在后续轮次中低成本地回顾计划进度——这正是"progress stays visible"在实现侧的落点。

测试证据：请求形状与提示断言

该装配链有单元测试守护，deepseek_tui.rs 的 deepseek_tui_request_uses_expected_top_level_shape 验证：

• 请求顶层形状（max_tokens: 64000、stream: true、include_usage: true、tool_choice: "auto"）；
• 系统提示第一条消息必须包含 "CONSTITUTION OF CODEWHALE"（间接证明 base + 各法律段落确实被拼入 system 消息，而非 developer 或其他消息）。

另有 deepseek_tui_request_does_not_import_codex_session_skills 断言 Codex 的 skills 注入段不会泄漏进 CodeWhale 提示（断言 <skills_instructions> 出现次数为 0），deepseek_tui_compaction_request_uses_structured_state 则验证上下文压缩时切换到 deepseek-v4-flash、max_tokens: 4096、temperature 0.2 的结构化交接请求。这些测试合起来锁定了 auto.md 所在提示面的行为边界。

在 Open Interpreter 中的运行前提

结合 harness 文档 可确认使用前提：

• deepseek-tui harness 走 chat 路由（Chat Completions 兼容传输），需要 wire_api = "chat" 的 provider；responses 或 messages 路由与其不兼容（路由兼容表见 docs/harness.md "Route Compatibility" 一节）。
• 配置方式：harness = "deepseek-tui"（config.toml）或单次运行 interpreter -c harness='"deepseek-tui"' "task"。
• 文档同时说明：公开运行时不 shell out 到外部真实 Agent CLI——DeepSeek TUI 工具（shell、apply patch、read/write/edit、grep/file search、git status/diff、diagnostics、checklist、plan、tool search）全部由 Open Interpreter 的原生 Rust 运行时执行，auto.md 所描述的"立即执行"由此成立：工具调用没有额外进程层拦截。

需要说明的是，"DeepSeek 家族自动默认 harness" 在文档中写的是 claude-code-bare（见 "Automatic Harness Defaults" 表），deepseek-tui 需要显式配置；以上以当前仓库文档表述为准。

小结：一个可复用的"授权即责任"提示工程模式

auto.md 只有十几行，却是一个完整的自主 Agent 治理样本，其结构可以抽象为四个可迁移的设计决策：

1. 授权与责任在同一条法律中成对出现：宣布"免审批"的段落，紧接着就是"因此你要承担什么"的补偿清单——不给模型留下"既然不用审批就可以乱来"的解释空间。
2. 把法律分层显式化：Tier 1 宪法（不可协商的真理与验证义务）> Tier 2 成文法（审批策略）> 项目规则 > 记忆 > 人格，冲突解决顺序写明（Article VII），避免高层指令被低层配置悄悄覆盖。
3. 用工具弥补监督缺失：没有审批弹窗时，让 checklist_write/update_plan 这类"进度外化"工具成为模型的自律手段，并在运行时把计划结果重写为紧凑摘要供后续轮次读取。
4. 静态法律前置、动态状态后置：稳定文本放系统提示前缀以命中提示缓存，易变的每轮工作集放最新用户消息——授权策略这类不常变的规则正是前缀区的首选内容。

相关源文件索引：approvals/auto.md、modes/yolo.md、personalities/calm.md、base.md、deepseek_tui.rs、deepseek_tui_tools.json、harness 文档。