Open Interpreter 交互模式（TUI）完全指南：Composer、文件与图片上下文、审批、斜杠命令与会话管理

Open Interpreter 的终端 UI（TUI）是它在日常仓库中完成真实编码任务的主战场：底部 Composer 负责输入与指令下发，@//mention 负责把文件与图片挂进上下文，/permissions、/model、/plan、/review 等斜杠命令则分别管控审批、模型切换、规划与代码评审。本文以仓库文档 docs/interactive.md 为核心骨架，结合 codex-rs/tui、codex-rs/cli 中的真实实现，完整梳理 TUI 的启动方式、全部快捷键与斜杠命令，以及会话状态在本地的持久化机制。读完你可以在终端中流畅地完成“启动 → 提需求 → 授权审批 → 后台任务 → 会话管理”的完整闭环。

快速上手：在项目目录启动终端 UI

交互模式的入口非常直接：进入任意项目目录并运行 interpreter，即可拉起终端 UI，并在底部 Composer 中输入你的第一条指令：

cd my-project
interpreter

Open Interpreter 的产品定位是面向“可信仓库的日常开发工作”，因此启动后即为交互态。你也可以把首个提示直接作为命令行参数传入，跳过手动输入：

interpreter "find the auth middleware and explain how it works"

此时该字符串会被当作第一条用户消息直接送进会话。从源码看，这套 CLI 由 codex-rs/cli/src/main.rs 的 MultitoolCli 结构体承载，同一个二进制会根据发布形态使用不同的产品名：相关注释明确写着“when this binary ships as Open Interpreter”，二进制名会通过 product_command_name() 动态解析为 interpreter，help 文案与版本号也随产品身份切换。这意味着 Codex 与 Open Interpreter 共享同一套 TUI 与命令体系，仅是产品外壳不同。

Composer：TUI 底部的指令输入框

Composer 是位于 TUI 底部的提示框，所有消息、命令、文件提及都在这里完成。下表是官方文档给出的完整操作映射：

操作	键或命令
发送消息	Enter
添加换行	Shift+Enter
打开斜杠命令	/
提及文件	@ 或 /mention
在 $VISUAL 或 $EDITOR 中编辑提示	Ctrl+G
搜索提示历史	Ctrl+R
在工作运行时排队后续操作	Tab
取消或退出	Esc
退出	/exit 或按两次 Ctrl+C

几个值得展开的细节：

• Enter 发送、Shift+Enter 换行是绝大多数聊天式 TUI 的肌肉记忆，长 Prompt 可以通过后者自由排版。
• Ctrl+G 外接编辑器：当提示过长或需要精细修改时，会唤起 $VISUAL/$EDITOR 指定的编辑器，适合粘贴大段需求文本。
• Ctrl+R 历史搜索：与 shell 的历史搜索心智一致，可以回溯此前输入过的指令。
• Tab 排队：当 Agent 正在工作时，你仍可输入下一条指令并排队，不必干等任务结束。
• 退出双保险：既可以用 /exit 斜杠命令，也可以连续按两次 Ctrl+C。

在实现上，Composer 位于 codex-rs/tui/src/bottom_pane/chat_composer.rs，其输入体验还支持可选的 Vim 模式（通过 /vim 命令开关）。所有快捷键并非硬编码，而是在 codex-rs/tui/src/keymap.rs 与 keymap_setup 中集中管理，并可通过 /keymap 命令交互式重映射，这一点远超普通聊天工具。

文件与图片：把上下文精准挂进对话

用 @ 模糊搜索文件

在 Composer 中输入 @（或 /mention 命令）即可对工作区文件做模糊搜索，命中后将文件内容作为上下文加入会话。SlashCommand 枚举中 Mention 的说明就是 “mention a file”（见 codex-rs/tui/src/slash_command.rs）。模糊匹配并非简单子串匹配，底层复用 codex-rs/utils/fuzzy-match 这一独立 crate 实现。

用 -i 附加图片到首个提示

如果你希望 Agent 基于截图工作，可以把图片直接附加到首个提示中，路径间用英文逗号分隔，支持一次附加多张：

interpreter -i screenshot.png "explain what is wrong in this UI"
interpreter -i before.png,after.png "compare these states"

-i 即 --image，对应源码 codex-rs/cli/src/main.rs 中的定义：

#[arg(long = "image", short = 'i', value_name = "FILE", value_delimiter = ',', num_args = 1..)]
images: Vec<PathBuf>,

其中 value_delimiter = ',' 决定了 before.png,after.png 会被自动拆成两张图片，num_args = 1.. 允许后续跟随任意数量文件路径。因此“多图对比”类任务（如前后端状态对比、设计稿还原度检查）非常适合用交互模式开场。

审批与权限：谁来决定命令能否执行

当某个命令或工具需要授权时，TUI 会在它真正运行之前弹出审批请求，把决策权交还给你。官方文档明确了默认姿态的设计哲学：

默认姿态面向可信仓库的日常开发工作：工作区访问被允许，超出当前活动策略（policy）的行为会先询问。

也就是说：在你自己信任的项目目录里，日常读写操作不会频繁打断你；只有触及策略边界（例如修改工作区之外的文件、执行高风险命令）时才会请求批准。

需要调整策略时，在 Composer 中输入：

/permissions

/permissions 对应的 SlashCommand 描述为 “choose what Open Interpreter is allowed to do”（codex-rs/tui/src/slash_command.rs）。除此之外，SlashCommand 枚举中还有一组与沙箱权限强相关的命令，可视为文档所述“批准机制”的延伸：

• /elevate-sandbox（setup-default-sandbox）：配置提权的 Agent 沙箱；
• /sandbox-add-read-dir：放开沙箱对某个绝对路径目录的只读访问（仅在 Windows 构建下可见）；
• /test-approval：在 debug 构建中主动触发一次测试性审批请求。

完整的策略体系与沙箱细节不在本文范围内，可继续阅读仓库中的 沙箱与审批 与 权限 两篇文档，它们解释了策略文件的层次与审批的判定规则。

模型与提供商：/model 与一次性命令行覆盖

模型管理是交互模式的另一核心能力。在会话中输入：

/model

即可打开选择器，依次挑选提供商（provider）、模型（model）与推理力度（reasoning effort）。从实现看，Model 枚举项的描述是 “choose provider, model, reasoning effort, and harness”（codex-rs/tui/src/slash_command.rs），即它还顺带负责工具 harness 的选择。

Open Interpreter 支持的提供商覆盖面很广：OpenAI、Anthropic、本地提供商（如通过 Ollama、LM Studio 暴露的端点），以及来自生成模型目录的兼容自定义提供商。仓库中模型目录以 codex-rs/codex-api/src/model_compatibility_catalog.json 与 codex-rs/models-manager/src/models.json 等文件形态存在，可运行 /debug models（debug 构建）查看渲染后的完整模型目录。

除了会话内切换，官方还推荐两类一次性覆盖的启动方式，适合“这一次就跑特定模型”的场景：

interpreter -m gpt-5.1-codex "review this module"
interpreter --oss "try this with my local model"

• -m gpt-5.1-codex：临时指定模型而不改变持久配置；
• --oss：切换到开源模型优先的策略，配合本地推理服务使用。

规划与评审：编辑前多想一步，改完之后自查一遍

对于“先看看再说”的场景，Open Interpreter 提供了两种职责互补的模式：

/plan
/review

• /plan：当你希望 Agent 在动手编辑前先检查现状并提出方案时使用，相当于进入规划模式（“switch to Plan mode”），产出方案后再经你确认进入执行。这与 Plan 命令在 available_during_task 中返回 false 一致——它本就不该在任务执行中途被再次触发。
• /review：当你希望 Agent 对当前工作区改动做一轮代码评审时使用。Review 命令支持内联参数（supports_inline_args() 为真），例如 /review <范围>；其内置描述是 “review my current changes and find issues”。

官方对评审模式给出清晰定性：评审模式是“只读聚焦”的，它不会动你的代码，而是专注于在给出总结之前，先报告潜在的问题，包括：

• bug 与回归（regression）；
• 缺失的测试；
• 有风险的行为。

换句话说，/review 是 Agent 把“写代码”和“审代码”两种心智分开的体现。若你不需要进入 TUI，同样的评审能力也可以非交互方式触发——CLI 提供了独立的 review 子命令（见 codex-rs/cli/src/main.rs 的 Subcommand::Review），便于接入 CI 或脚本流程。

后台工作：长任务不阻塞对话

耗时命令不必卡住整个会话。TUI 支持把长任务放到底层后台终端中存活，同时 Agent 继续处理新指令。相关命令有两个：

命令	用途
/ps	列出后台终端
/stop	停止后台终端

从 SlashCommand 的实现看，Ps 描述为 “list background terminals”，而 Stop 则额外提供 clean 别名、描述为 “stop all background terminals”（codex-rs/tui/src/slash_command.rs）。这两个命令都属于任务进行中仍可用（available_during_task 为真）的指令，呼应了“后台并行 + 排队指令”的工作流：当编译、测试或长时间网络请求在前台告一段落，你可以边跑边继续推进其他任务。

会话控制：开始、恢复、分叉、压缩与状态检查

交互模式对会话（session/thread）的管理覆盖了从创建到归档的完整生命周期，官方给出如下命令对照：

命令	用途
/new	开始一个新的会话
/resume	选择一个旧的会话
/fork	分叉当前会话
/compact	压缩旧的上下文
/clear	清除屏幕
/copy	复制最新的助手输出
/theme	更改语法高亮主题
/status	检查模型、沙盒、批准和令牌状态

逐个说明其定位与背后的实现要点：

• /new 与 /clear：都用于“重新开始”。区别在于 new 描述为 “start a new chat during a conversation”，更侧重会话层面；clear 则是 “clear the terminal and start a new chat”。二者在 available_during_task 中均为 false，说明系统会避免在执行中途强行打断任务上下文。
• /resume 与 /fork：/resume 让你从旧会话中挑选一个继续（“resume a saved chat”），/fork 则以当前会话为基线复制出新的分支（“fork the current chat”）。在 TUI 之外，CLI 同样暴露了 resume 与 fork 子命令，交互模式中按下 /resume 后出现的正是这类选择器 UI。
• /compact：用于把较早的上下文总结压缩，防止会话逼近上下文窗口上限（“summarize conversation to prevent hitting the context limit”）。
• /copy：把最近一条助手回复以 Markdown 形式复制到剪贴板（“copy last response as markdown”），方便把 Agent 产出贴到 PR、文档或 Issue。
• /theme：切换语法高亮主题，兼顾长时间阅读的舒适度。
• /status：一次性检视当前会话的“体检报告”，包括模型、沙箱状态、审批策略与令牌用量。其实现说明为 “show current session configuration and token usage”，对排查“为什么这个行为被允许/拒绝”“token 还剩多少”非常关键。

在底层，所有这些命令都来自统一的 SlashCommand 枚举（codex-rs/tui/src/slash_command.rs），并由 #[strum(serialize_all = "kebab-case")] 自动把枚举名映射为 /model、/new、/fork 这类命令串。有三条实现细节直接决定了你在 UI 中的体验：

1. 枚举顺序 = 弹窗展示顺序：源码注释明确要求“不要按字母排序”，因为弹窗（command popup）按枚举声明顺序排列，高频命令被刻意排在前面。
2. 特性门控（feature gating）：命令的可见性取决于运行环境。例如 Plan 仅在协作模式开启时可见，Apps/Plugins/Goal 等各有开关，Copy 在 Android 上隐藏，App（跳转桌面端）仅 macOS/Windows 可见（codex-rs/tui/src/bottom_pane/slash_commands.rs）。
3. 可用性分两种维度：available_during_task 决定命令能否在任务执行中触发；available_in_side_conversation 决定命令在“侧边会话”中是否保留。例如 /status、/copy 在侧边会话中依然可用，而 /new、/plan 则不行。

会话状态存储：~/.openinterpreter/

所有会话状态默认保存在本机的 ~/.openinterpreter/ 目录下，这也是 /resume 能够跨会话找回历史、/fork 能够复制旧分支的前提——它们读取的正是本地持久化数据。

仓库 codex-rs/utils/home-dir/src/lib.rs 的注释对此有精确说明：

对 interpreter 来说，唯一被认可的覆盖变量是 INTERPRETER_HOME，默认目录为 ~/.openinterpreter。

也就是说：

• 默认家目录为 ~/.openinterpreter/（.codex 仅在同二进制的 Codex 产品形态下使用）；
• 如需改变存储位置，可通过环境变量 INTERPRETER_HOME 指向自定义目录，而不会被 CODEX_HOME 等干扰。

这意味着不同项目、不同工作区可以由你自己决定是否共享同一份会话历史；若要为某个仓库隔离出独立的会话池，启动前设置 INTERPRETER_HOME 即可。

结语

Open Interpreter 的交互模式把“终端里的结对编程”拆解成几个正交的维度：Composer 统一承载输入与命令，@/-i 解决多模态上下文注入，/permissions 把安全策略的粒度交还用户，/plan 与 /review 区分了规划与评审两种心智，/ps//stop 支持后台并行，而 /new、/resume、/fork、/compact、/status 构成完整的会话生命周期管理。理解这些命令背后统一的 SlashCommand 调度机制（枚举、特性门控、任务中可用性），你就能推断出任意环境下哪些命令可用、何时可用。更多深入话题可以继续阅读同一文档树的 沙箱与审批、权限，以及 TUI 相关实现的入口 codex-rs/tui/src/slash_command.rs 与 codex-rs/tui/src/chatwidget/slash_dispatch.rs。