如果学校不能在课堂中给予学生更多成功的体验，他们就会以既在学校内也在学校外都完全拒绝学习而告终。——林格伦

https://github.com/openinterpreter/openinterpreter

Open Interpreter：把低成本模型推上台前的编码代理

有些项目一上来就把野心写在脸上，Open Interpreter 就是这样一个存在。它并不试图用夸张的口号吸引注意力，而是很直接地告诉你：它是一款为低成本模型优化的编码代理。这句话很短，却很有分量。因为它点出的，不只是一个工具的定位，更像是在回应当下开发者最现实的需求——既想要智能代理带来的效率，又不想被高昂成本拴住手脚。

项目地址：https://github.com/openinterpreter/openinterpreter

它首先是一位“终端里的代理”

Open Interpreter 的形态很明确：它运行在终端中。安装完成后，只需要在终端里输入 i 或 interpreter，就可以启动一个会话。这个启动方式非常克制，没有多余动作，也没有复杂铺垫，像是把一扇门直接推开，让人立刻进入工作状态。

在安装方式上，它分别给出了 macOS、Linux 和 Windows 的入口。

macOS 和 Linux：

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

Windows：

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

安装之后，进入会话的动作同样干脆：

1
i

或者：

1
interpreter

这种体验很像一位已经站在终端里等你的助手：不喧闹，不绕路，随时准备开始协作。

一个围绕低成本模型打磨出来的方向

Open Interpreter 的 description 很直白：A coding agent for low-cost models。README 进一步补充了它的思路：它是 OpenAI Codex 的一个 fork，并且重点放在模拟能够让低成本模型发挥出更好表现的 agent harness 上。

这里最有意思的地方，不在于“fork”这个动作本身，而在于它的取舍。它并没有把重心放在宏大叙事上，而是集中火力去做一件非常具体的事情：让低成本模型也能在代理式编码场景里更好地工作。这意味着它关注的不是抽象的模型能力展示，而是更实际的运行方式、交互方式和执行方式。

/harness：它不只是在跑模型，也在切换工作方式

README 里有一个非常关键的部分，叫 Harness Emulation。Open Interpreter 允许你通过 /harness 来切换当前使用的 harness。项目给出的可选项包括：

1
2
3
4
5
6
7
8
9
10
11
> /harness

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

这份列表本身就很有画面感。它不是只给你一个固定姿势，而像是准备了多套不同风格的工作服，让同一个代理可以用不同方式进入任务。对于一个强调低成本模型表现的项目来说，这种“可切换的工作外壳”显然是核心设计之一。

也正因为如此，Open Interpreter 给人的感觉并不是一个死板的命令行程序，而更像一个会根据场景调整工作形态的执行者。你可以把它理解为：模型是一部分，harness 也是一部分；真正的使用体验，往往来自二者的配合。

它还把“Computer Use”带进了自己的能力边界里

如果说 harness 决定了它怎样工作，那么 Computer Use 展示的就是它能把手伸到哪里。

README 中写得很清楚：Open Interpreter 自带一个 QA skill，可以让任意模型去操作并测试界面。它既可以在真实浏览器中驱动 Web 应用，也可以操作本地应用。这一点让它的角色一下子从“会写命令的终端助手”扩展成了“能动手验证界面的执行者”。

这是一种很鲜明的气质变化。很多工具停留在“生成内容”这一步，而 Open Interpreter 在 README 里强调的是“operate and test interfaces”。也就是说，它不仅仅在说，更在做；不仅仅给出建议，还能参与验证过程。

功能列表不长，但很有骨架

Open Interpreter 在 README 里的 Features 部分列得并不冗长，但每一条都像一根结构梁，把这个项目的轮廓搭得很清楚。

1. 原生沙箱中的命令执行

它可以在 macOS、Linux 和 Windows 上，在原生沙箱机制中运行命令。这意味着它并不是简单把命令一丢了之，而是把执行环境本身当作产品能力的一部分。

2. 在 TUI 中切换 provider 和 model

它支持通过 /model 在 TUI 中切换 providers 和 models。这让交互方式更像是在和一个可调度的系统打交道，而不是对着一条固定流水线发号施令。

3. 查看或切换 Rust 原生 harness

它支持通过 /harness 检查或切换 Rust-native model harnesses。这和前面的 Harness Emulation 一起，构成了项目的关键主轴。

4. 通过内置 QA skill 测试 Web 和本地应用

README 明确提到，它可以通过内置的 QA skill测试 Web 应用与原生应用。这让它的能力边界不只停留在文本和终端，而是进一步延伸到界面层。

5. 作为 Agent Client Protocol 代理运行

它可以通过 interpreter acp 的形式，作为 Agent Client Protocol 代理，为编辑器工作。这让它不仅仅属于终端，也能进入更广的编辑器协作场景。

1
interpreter acp

6. 本地保存配置和会话状态

它会把配置和 session state 保存在本地的 ~/.openinterpreter 目录下。这个细节虽然安静，却很重要：它说明项目把本地状态管理作为默认路径，而不是让使用者在每次启动时都从零开始。

7. 支持 exec、MCP、skills、hooks、permissions 和 AGENTS.md

README 最后一条功能描述非常紧凑，但信息密度很高。它支持 exec、MCP、skills、hooks、permissions 以及 AGENTS.md。项目没有在这段 README 里进一步铺开解释，但它们被明确列进能力清单，本身就说明 Open Interpreter 并不是一个单一命令工具，而是带着一套可组织、可扩展、可约束的代理结构在运行。

它的新身份也被说得很清楚

README 里有一条说明值得特别注意：这是 Open Interpreter 的新 Rust 版本，基于 Codex。 这句话其实帮整个项目完成了身份校准。

它不是在模糊自己的来历，也不是试图把历史版本轻轻带过，而是非常明确地告诉你：现在你看到的，是一个新的 Rust 版本。这个定位让人很容易理解项目当前的形态——它不只是名字的延续，也是一轮实现路径上的转向。

开发环境部分，同样透出一种“把运行条件认真对待”的态度

除了顶层 README，这个仓库里关于容器化开发的说明也透露出很强的工程气质。它提供了两条容器路径：

  • devcontainer.json
  • devcontainer.secure.json

前者用于现有的 Codex 贡献者开发流程，后者则提供一个更严格的运行配置。README 中对 secure profile 的描述相当具体，包括：

  • 安装 Codex CLI 和常用构建工具
  • 以 setuid 模式安装 bubblewrap，供 Linux 沙箱使用
  • 关闭 Docker 外层 seccomp 和 AppArmor 配置，以便 bubblewrap 构建内部沙箱
  • 启用基于 allowlist 的出站网络策略
  • 默认阻断 IPv6
  • 需要 NET_ADMIN 和 NET_RAW 能力以便启动时安装防火墙

这部分说明虽然面向开发与运行环境，但它也反过来说明了一个事实：这个项目很在意代理如何在约束环境中执行任务。它并不把“安全边界”和“运行控制”当成边角料，而是把这些内容摆到了清晰可见的位置。

如果要启动这个更严格的容器配置，README 给出的命令是：

1
devcontainer up --workspace-folder . --config .devcontainer/devcontainer.secure.json

而在 Docker 场景下，它也给出了本地构建和运行 contributor image 的方式：

1
2
3
CODEX_DOCKER_IMAGE_NAME=codex-linux-dev
docker build --platform=linux/amd64 -t "$CODEX_DOCKER_IMAGE_NAME" ./.devcontainer
docker run --platform=linux/amd64 --rm -it -e CARGO_TARGET_DIR=/workspace/codex-rs/target-amd64 -v "$PWD":/workspace -w /workspace/codex-rs "$CODEX_DOCKER_IMAGE_NAME"

对于 arm64，则将 docker build 和 docker run 中的 --platform=linux/amd64 改为 --platform=linux/arm64。

这种写法没有刻意煽情，却很容易让人感受到项目的气质：它不是只关心“看起来能不能跑”，而是很认真地处理“究竟怎么跑、在什么边界里跑”。

它的文档组织也很有秩序感

README 列出的文档入口包括：

  • Terminal docs
  • Quickstart
  • Install guide
  • Configuration
  • CLI reference
  • Harnesses
  • Model providers
  • Sandbox & approvals

这组目录传递出一种非常鲜明的结构意识。它把使用路径从安装、快速开始，到配置、CLI、harness、model provider，再到 sandbox 与 approvals，层层排开。哪怕不展开每一篇文档，仅从目录命名也能看出，这个项目并不是把所有能力揉成一团，而是在努力为终端代理这件事建立清晰的使用秩序。

一个名字背后的真正气质

“Open Interpreter” 这个名字本身就很有张力。它既带着解释器的技术感，也带着代理的行动力。而从 README 和 description 能看到，这个名字并没有停留在概念层，而是落实成了一整套具体能力：

  • 它从终端启动
  • 它关注低成本模型
  • 它强调 harness 的切换与模拟
  • 它支持界面操作与测试
  • 它提供原生沙箱中的命令执行
  • 它能以 ACP agent 的身份进入编辑器场景
  • 它把配置和会话状态保留在本地
  • 它支持一系列围绕代理运行组织起来的机制

这些点拼在一起，形成的不是一个单薄的 CLI 工具，而是一位有明确边界、有执行方式、也有运行规则的代理型角色。

为什么这个项目会让人记住

Open Interpreter 最容易被记住的地方，不是它列了多少功能，也不是它摆了多少术语，而是它把自己的定位说得异常清楚：为低成本模型优化的编码代理。

这句话之所以有力量，是因为它没有把自己包装成无所不能的神话，而是稳稳扎在一个很现实的问题上。它在终端中工作，允许切换模型与 harness，能够运行命令、测试界面、保存本地状态，也能作为 ACP agent 融入编辑器环境。它的能力不是飘在空中的概念，而是一项项被落实成可执行入口、可切换选项、可运行环境的具体设计。

如果把整个 README 读完，你会发现 Open Interpreter 的魅力并不来自喧哗，而来自一种非常清楚的方向感。它像一位已经想明白自己要做什么的工程型选手：不绕弯，不卖弄，把重点牢牢放在代理如何真正跑起来、如何在低成本模型上跑得更好、又如何在终端与受控环境中跑得更稳这几件事上。

这也正是它最耐人寻味的地方——它不是在空谈智能代理的未来，而是在很具体地搭建一种可以被使用、被切换、被约束、也被组织起来的当下形态。