跳到主要内容

Open Interpreter (Rust) — 这是什么 / 全景 / 阅读地图

30 秒导读: Open Interpreter 是 OpenAI Codex 的 Rust 分叉,一个终端里的编码 agent。 它和上游 Codex 几乎是同一套引擎,唯一的大改动是「harness 仿真」——在把请求发给模型前, 把它塑形成某个知名 CLI(Claude Code、Qwen Code、SWE-agent…)的系统提示和工具调用格式, 目的是从低价 / 开源模型里榨出最好的编码性能。本章只做导航:讲清它是什么、workspace 长什么样、 主线怎么走,然后把你送进四个深入章节。


1. 这是什么(零基础也能懂)

一句话定义: Open Interpreter(Rust 版)是一个装在终端里的 AI 编码 agent,它是 OpenAI Codex 的一个分叉(fork),专门针对「便宜的模型」做优化。

依据两条 README 原文:

  • 标语:『A coding agent optimized for low-cost models』(README.md:3)。
  • 定位:『Open Interpreter is a fork of OpenAI's Codex, with a focus on emulating the agent harness that gets the best performance out of low-cost models』(README.md:37)。

解决什么问题 / 给谁用。 想象你在终端里想让 AI 帮你改一个真实项目的代码,但你不想只用最贵的 旗舰模型——你想用便宜的、甚至本地开源的模型(DeepSeek、Qwen、Kimi、GLM/zcode…)。问题是: 这些模型往往在「别人家的提示词和工具格式」下才发挥得最好——比如某个模型是照着 Claude Code 的系统提示训出来的,你就该用 Claude Code 那套「壳」去喂它。Open Interpreter 就是来干这件事的。

它相对上游 Codex 的唯一大改动 = harness 仿真。 "harness"(壳 / 座架,指一个 agent 包在模型 外面的那层提示词 + 工具协议 + 回合循环)。Open Interpreter 继承了 Codex 的整套引擎(回合循环、 工具执行、沙箱、TUI…),但额外做了一件事:让你切换这层壳,把请求伪装成目标 CLI 的样子。

用起来就是在 TUI 里敲 /harness,弹出一个可选列表(README.md:39-53):

> /harness

native
claude-code
claude-code-bare
zcode
kimi-cli
qwen-code
deepseek-tui
swe-agent
minimal

注:上面是 README 展示的那一档。代码里的 harness 枚举比这更长——还有 little-codermini-swe-agentopencodepikimi-codeterminus-2,合计 15 个具名变体,外加一个 兜底的 Other(String)(codex-rs/tools/src/harness.rs:2enum Harness)。完整清单和它们 各自模仿谁,见 01 章

一句话直觉: 把模型想成一个演员,harness 就是给它换的戏服和台本。同一个引擎(Codex), 换上 Claude Code 的戏服,模型就按 Claude Code 的规矩演;换上 Qwen Code 的戏服,就按 Qwen 的规矩演。 native = 不化妆,用 Codex 自己的原生壳。


2. 顶层全景(它大概怎么转)

2.1 workspace 长什么样

代码在 codex-rs/ 下,是一个 Cargo workspace,129 个 crate(codex-rs/Cargo.tomlmembers 列表)。绝大多数是从 Codex 继承来的基础设施;真正体现「Open Interpreter 特色」的 是 core 里的 harness/ 子模块。下面这张图只点主力 crate(方框内第二行是它管什么):

codex-rs/ (Cargo workspace, 129 crates)

├── cli/ ──────────► 命令行入口(interpreter / i、子命令 exec、acp…)

├── tui/ ──────────► 终端 UI + 斜杠命令(/harness、/model、/permissions…)
│ SlashCommand::Harness → 让你换壳

├── core/ ═════════► ★引擎 + harness 仿真(全项目重心)
│ ├─ harness/ ──► 壳的定义、路由、请求塑形、各 CLI 的提示词
│ └─ client.rs ─► ModelClient.stream:按 (WireApi×Harness) 选路发请求

├── tools/ ────────► 工具定义 + Harness 枚举(enum Harness 在这)
├── model-provider-info/► 每个 provider 说哪种 wire(responses/chat/messages)
├── chat-wire-compat/ ► Responses ↔ Chat Completions 的格式互转
├── apply-patch/ ──► 把模型给的补丁精确打到代码文件上
├── exec/ + sandboxing/ + linux-sandbox/ ► 命令执行 + 原生沙箱护栏
└── codex-mcp/ + ext/mcp/ ► MCP(把外部工具接进来)

图怎么读: 从上到下大致是「入口 → UI → 引擎 → 手脚」。带 ★ 的 core 是重心,带 ═ 的 harness/ 子目录是 Open Interpreter 相对 Codex 的独有增量。

2.2 主力部件一句话职责

部件(crate/模块)干什么关键文件
coreagent 引擎 + harness 仿真,整个项目的心脏core/src/client.rscore/src/harness/
core/src/harness/routing.rs按「wire 协议 × 当前壳」决定这次请求走哪条塑形路线resolve_stream_transport_route
core/src/harness/request.rschat 类 harness 的唯一集成点:塑形请求 + 回译响应build_chat_harness_request
tools工具定义;Harness 枚举(所有壳的名字)住这tools/src/harness.rs enum Harness
tui终端界面 + 斜杠命令;/harness 让你换壳tui/src/slash_command.rs SlashCommand::Harness
model-provider-info每个模型 provider 声明它讲哪种 wiremodel-provider-info/src/lib.rs enum WireApi
chat-wire-compatResponses 与 Chat Completions 两种线格式互转chat-wire-compat/
apply-patch把模型产的补丁可靠地落到文件apply-patch/
exec / sandboxing跑命令、上沙箱护栏exec/sandboxing/linux-sandbox/
codex-mcp / ext/mcpMCP 客户端/服务端,接外部工具codex-mcp/ext/mcp/

2.3 主线走一遍(高层,不进代码)

一次回合(turn)从「用户输入」到「结果落地」,大致这么流(每一步指向真正负责的地方):

① 用户输入

② session/turn 组装:把历史 + 用户消息 + 可用工具 拼成一个 Prompt

③ ModelClient.stream(...) core/src/client.rs:2740 `stream`
│ 内部先问一句「这次该走哪条路?」
│ resolve_stream_transport_route(wire_api, harness)
│ core/src/harness/routing.rs:56
│ 输入 = (provider 的 WireApi) × (当前 Harness)
│ 输出 = 一条 StreamTransportRoute(见下)

④ 按路线塑形并发请求:
├─ 原生:ResponsesApi / ChatCompletionsCompat (Codex 老路)
├─ ChatHarness(qwen/kimi/swe-agent/…) → build_chat_harness_request
│ core/src/harness/request.rs:75
│ 把 Prompt 重写成目标 CLI 的系统提示 + 工具格式
├─ MessagesHarness(claude-code / zcode) → Anthropic Messages 线
└─ ClaudeCodeResponses / ClaudeCodeChat → claude-code 塑形套在别的线上

⑤ provider 返回(流式)

⑥ 部分 harness:把模型吐的**纯文本**回译成结构化工具调用
│ (如 swe-agent / terminus-2 的 inject_*_action_calls)

⑦ 执行工具 / 命令(过沙箱与权限)→ 结果写回历史 → 回到 ②,下一回合

这一步是全项目的枢纽: ③→④ 那个 (WireApi × Harness) → 路线 的选路,就是 Open Interpreter 的核心分叉点。三种 wire 协议(model-provider-info/src/lib.rs:65enum WireApi:Responses / Chat / Messages)乘上十几个 harness,落进 enum StreamTransportRoute(core/src/harness/routing.rs:37)的某一条。

  • Responses / Chat 且壳是 native → 走 Codex 原生老路,不塑形
  • 壳是 claude-code / claude-code-bare → 无论底下是哪种 wire,都套上 claude-code 的塑形。
  • Chat + 某个 CLI 壳(qwen-code、kimi-cli、swe-agent…)→ 走对应的 ChatHarness 塑形。
  • Messages(Anthropic 线)只允许 claude-code / zcode,其余壳直接报错拒绝 (routing.rs:108-151 那一串 InvalidRequest)。

完整的路由矩阵(哪个格子通、哪个格子报什么错)在 01 章; 「塑形具体改了哪几样」在 02 章;ModelClient.stream 底下的 回合循环细节在 03 章


3. 阅读地图(四章导引)

建议顺序:先 01 建立「壳」的心智模型,再 02 看一个壳到底改了什么,03 补底座引擎,04 看手脚护栏。

章节一句话讲什么什么时候读
01-harness-emulation.md为什么要仿真、有哪些 harness(15 具名 + Other 兜底)、(WireApi × Harness) 路由矩阵怎么选路想搞懂「换壳」到底是什么、有哪些壳
02-harness-shaping.md一个 harness 具体改了什么:系统提示替换、工具格式重写、把文本响应回译成工具调用想看塑形的真实机制
03-turn-loop-and-client.md底座引擎:一次回合怎么跑、ModelClient.stream 怎么发请求(继承自 Codex)想理解引擎主循环
04-tools-exec-sandbox.md手脚与护栏:工具、命令执行、原生沙箱、apply-patch 编辑、MCP/skills想看 agent 怎么真正动手、护栏在哪

4. 顶层代码地图(导航索引)

用符号名 grep 比行号抗漂移;下表是从本章跳进源码的入口。

主题文件路径符号名
项目定位 / harness 列表README.md(标语 :3 / fork 说明 :37 / /harness 列表 :39-53)
workspace 全景codex-rs/Cargo.tomlmembers(129 crate)
Harness 枚举(所有壳的名字)codex-rs/tools/src/harness.rsenum Harness / Harness::from_config_name
wire 协议枚举codex-rs/model-provider-info/src/lib.rsenum WireApi
选路:(wire × 壳) → 路线codex-rs/core/src/harness/routing.rsresolve_stream_transport_route / enum StreamTransportRoute
引擎发请求的总入口 + 分发codex-rs/core/src/client.rsModelClient::stream(:2740)/ stream_transport_route(:1036)
chat harness 塑形集成点codex-rs/core/src/harness/request.rsbuild_chat_harness_request
TUI 里的换壳命令codex-rs/tui/src/slash_command.rsSlashCommand::Harness
各 harness 的提示词/实现codex-rs/core/src/harness/claude_code.rs / qwen_code.rs / swe_agent.rs / zcode.rs