它 Fork 了 OpenAI Codex，却让 DeepSeek 和 Kimi 跑得更顺

有个朋友上周问我，说想跑个 coding Agent 帮他写脚本，但 Claude Code 太贵了，OpenAI 的 API 账单也扛不住，问我有没有便宜的选择。

我第一反应是让他试试 Open Interpreter。

坦白讲，我知道 Open Interpreter 是因为它 64K 的 Star 数——这项目在 GitHub 上太显眼了。但真正读进去之后，我发现它跟我之前想的完全不是一回事。

它不是那个 Python 项目了

如果你两年前听说过 Open Interpreter，印象大概停留在「一个让 GPT-4 写代码的 Python 工具」。那个版本确实存在，但现在它已经是一个社区维护的分支了（endolith/open-interpreter）。

2024 年 10 月，Open Interpreter 团队做了一个激进的决定：用 Rust 重写整个项目。而且不只是重写——他们 Fork 了 OpenAI 的 Codex（就是那个给编辑器写代码的 Agent 框架），把整套 Rust 代码库接过来作为新基础。

说真的，这个决定挺有意思的。Codex 是 OpenAI 的产品，但 Open Interpreter 的定位却是「为低成本模型优化的 coding agent」。Fork 了 OpenAI 的东西，然后用来跑 DeepSeek、GLM、Kimi 和 Qwen——这画面多少有点戏剧性。

Harness 才是真正的内核

我花了不少时间读它的源码，发现最核心的机制不是代码生成，而是 Harness 仿真系统。

打开 codex-rs/core/src/harness/routing.rs，你会看到一个枚举类型，定义了 10 多种 harness 路由：

pub(crate) enum ChatHarnessRoute {
    DeepSeekTui,
    KimiCode,
    KimiCli,
    LittleCoder,
    MiniSweAgent,
    Minimal,
    OpenCode,
    Pi,
    QwenCode,
    SweAgent,
    Terminus2,
}

每个枚举值对应一个完整的 harness 实现。codex-rs/core/src/harness/mod.rs 列出了 15 个模块，每个模块都是一个独立的「Agent 协议适配器」：

• claude_code.rs + claude_code_prompt.rs — 模拟 Claude Code 的交互协议
• deepseek_tui.rs + deepseek_tui_prompts/ — 模拟 DeepSeek TUI 的 prompt 体系
• kimi_cli.rs + kimi_cli_prompt.md — 模拟 Kimi CLI 的交互
• qwen_code.rs + qwen_code_prompt.md — 模拟 Qwen Code
• zcode.rs + zcode_tools.json — 甚至支持 ZCode 的工具格式
• swe_agent.rs — SWE-Agent 的协议
• minimal.rs — 最简协议，适合调试

每个 harness 做的事情本质上是一样的：把 Codex 的底层能力（文件操作、命令执行、沙箱）包装成对应 Agent 的交互协议。用户用 /harness 命令切换，TUI 里会列出所有选项。

这就引出了一个关键问题：为什么需要仿真？

为什么不做自己的协议

我一开始也有这个疑问。既然你 Fork 了 Codex，为什么不直接用 Codex 的协议，然后让用户自己选模型？

答案藏在 routing.rs 的另一个函数里：

pub(crate) fn resolve_stream_transport_route(
    wire_api: WireApi,
    harness: &Harness,
) -> Result<StreamTransportRoute, CodexErr> {
    match (wire_api, harness) {
        (WireApi::Responses, Harness::ClaudeCode | Harness::ClaudeCodeBare) => Ok(
            StreamTransportRoute::ClaudeCodeResponses(claude_code_profile_route(harness)),
        ),
        (WireApi::Chat, Harness::KimiCli) => {
            Ok(StreamTransportRoute::ChatHarness(ChatHarnessRoute::KimiCli))
        }
        // ...
    }
}

不同 Agent 使用不同的 API 线路——有的用 Responses API，有的用 Chat Completions，有的用 WebSocket。Harness 系统做的就是协议适配：把 Codex 的底层能力映射到目标 Agent 的通信协议上。

这跟「写一个通用的 Agent 协议」是两种不同的思路。通用协议需要一个所有人都接受的标准，而现实是每个 Agent 都有自己的协议。Harness 仿真的思路更务实——我不改变你的协议，我来适配你的协议。

你想想看，这种思路的好处是，只要有人写了一个新的 coding Agent，Open Interpreter 就可以通过写一个 harness 来支持它，不需要改底层框架。

100 多个 Crate 的工程规模

翻 codex-rs/Cargo.toml 的时候我数了一下，workspace 里有 100 多个 crate。这规模不像一个「开源工具」，更像一个商业产品。

关键 crate 的职责划分很清晰：

其中一个值得注意的细节是 codex-rs/cli/src/main.rs 里的 arg0_dispatch 机制——CLI 的入口会根据 argv[0] 的值自动路由到不同的子命令。这意味着如果你把二进制文件软链接成不同的名字，它会自动切换行为模式。老 Unix 黑客风格。

20 行命令搞定安装

安装体验倒是出奇地简单。macOS 和 Linux 上一行搞定：

curl -fsSL https://www.openinterpreter.com/install | sh

Windows 上用 PowerShell：

irm https://www.openinterpreter.com/install.ps1 | iex

装完后在终端输入 i 或 interpreter 就能启动会话。TUI 界面里用 /model 切换模型，用 /harness 切换协议适配器。

/harness 命令会列出所有可用的 harness：

> /harness

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

选 deepseek-tui，它就模拟 DeepSeek TUI 的交互方式；选 kimi-cli，它就模拟 Kimi CLI 的 prompt 体系。背后的模型可以自由切换，不受 harness 限制。

值得注意的能力边界

看了不少 issue 之后，我得说，这个项目虽然活跃（2026 年 7 月 6 号刚发了 0.0.21），但有几个地方需要留意。

Ollama 的兼容性是个痛点。 Issue #1220 和 #1371 都报告了使用 Ollama 本地模型时的问题——llama3:70b 和 llama-3.1 70B 在预置阶段（Preps）会卡住，无法正常完成初始化。如果你是想用本地模型跑 coding Agent，这一块目前还不够顺滑。

启动速度。 Issue #990 有人反映启动太慢，团队也承认了这个问题。毕竟 100 多个 crate 的 Rust 项目，编译出来就是个大二进制，启动时要加载的模块也不少。

30 个贡献者。 这是我从 GitHub API 拉到的数据。对于一个 64K Star 的项目来说，这个 contributor 基数不算大。核心团队对代码库的控制力很强，外部贡献者想切入可能不太容易。

它还是偏好 Cloud API。 虽然项目定位是「低成本模型」，但默认的安装和使用流程跟云 API 绑定得更紧。想完全离线跑本地模型，需要自己配置 Ollama 或 LM Studio 的接入，体验不如云 API 流畅。

从 Codex Fork 到 Harness 工程

写到最后，我想说一个观察。

Open Interpreter 最让我佩服的不是它的功能，而是它的工程策略：不重新发明轮子，而是 Fork 一个成熟框架（Codex），然后在上面加一层「协议适配层」（Harness）。这层适配层让它可以同时支持 10 多种 Agent 协议，而核心的代码执行、文件操作、沙箱隔离全部复用 Codex 的能力。

我把这个模式叫做 「协议桥接」模式——不建标准，只做转译。当你在一个碎片化的生态里（Agent 协议满天飞），与其试图统一标准，不如做最好的转译器。Open Interpreter 选择 Fork Codex 不是偷懒，而是把精力集中在最难的适配层上。

如果你想低成本跑 coding Agent，又不想被特定厂商锁定，Open Interpreter 是目前最值得关注的选择。只是要注意，如果你打算用 Ollama 跑本地模型，可能需要一点耐心等它完善。

64K Star 的项目，不会平白无故长这么大。