Open Interpreter

面向 Kimi K3、GLM 5.3 等开放模型的终端编码代理开源

Open Interpreter 现在是一个终端里的编码代理，GitHub 仓库简介写的是“面向 Kimi K3、GLM 5.3 等开放模型的编码代理”。它从 OpenAI 的 Codex CLI 分叉而来，主打为不同模型复刻各家推荐的“驾驭层”（harness），并保留 Codex 的操作系统级沙箱。名字沿用 2023 年走红的 Python 项目，但主分支在 2026 年 7 月以 Codex 为基底重建，许可证随之换成 Apache-2.0。截至 2026-10-26，最新版本是 0.0.56，终端代理免费，模型费用由用户自己的账号或本地模型承担。

编辑部更新于 2026 年 10 月 26 日阅读约 11 分钟

它是什么

Open Interpreter 是一个命令行编码代理。在项目目录里输入 interpreter，或者简写 i，就进入一个对话界面：它会读仓库里的文件、提出修改、直接改代码、运行命令、查看差异，之后还能用 interpreter resume --last 接着上次的会话继续做。快速上手文档对它的描述是“基于 Codex CLI 界面构建、为不绑定服务商的本地使用而改造的终端编码代理”。README 开篇一句话是“为低成本模型优化的编码代理”，GitHub 仓库简介则写成“面向 Kimi K3、GLM 5.3 等开放模型的编码代理”，这两句都是官方自述。

技术上它是 OpenAI Codex 的分叉。README 原话是“Open Interpreter 是 OpenAI Codex 的分叉，重点在于模拟能让低成本模型发挥最好表现的代理驾驭层”。仓库里的 FORK_BRANDING.md 说明，内部的 crate、协议字段以及 codex-package.json 这类文件名都保持 Codex 原样，只在一个集中的品牌模块里换上 Open Interpreter 的产品名和命令名。根目录 NOTICE 文件的第一行仍然是“OpenAI Codex, Copyright 2025 OpenAI”。按 GitHub 的语言统计（截至 2026-10-26），仓库里 Rust 代码约 69.6 MB，Python 约 1.78 MB，主体是 Rust。

和 Codex 原版相比，它新增的东西主要有三类。第一是 harness 模拟：用 /harness 可以在 native、claude-code、claude-code-bare、zcode、kimi-code、kimi-cli、qwen-code、deepseek-tui、swe-agent、minimal 之间切换，每一种都按对应代理产品的提示词、工具定义和消息格式来组织请求。第二是按脚本生成的服务商与模型目录：OpenAI、Amazon Bedrock、Ollama、LM Studio 是内置的运行时服务商，Kimi、DeepSeek、Z.AI 与智谱、Google AI Studio 等托管服务商来自生成的目录。第三是 Agent Client Protocol（ACP）支持，编辑器只要配置为启动 interpreter acp，就能把它当作代理接进来。

同一家公司 Open Interpreter Inc. 还做了一个面向非开发者的桌面应用 Interpreter，开源仓库名为 interpreter-workstation，官方博客称它建立在新的 Open Interpreter 运行时之上，可以操作浏览器、Office 文档和其他本地应用。终端代理与桌面应用是两个产品。

关于名字：2023 年那个让模型在本机写并执行 Python 代码的旧版，README 说明已交给社区分叉 endolith/open-interpreter 维护，那个仓库仍用 AGPL-3.0，截至 2026-10-26 最近一次推送在 10 月 25 日。旧版在 PyPI 上的 open-interpreter 包最新版本仍是 0.4.3（2024-10-26 上传），新版的安装方式是官网脚本，不经过 PyPI。

为低成本模型优化的编码代理。
Open Interpreter README 开篇（译文）

核心能力

按模型切换驾驭层。官方博客的论点是：每个编码模型在训练时都熟悉某一套工具名称、参数、系统提示和上下文压缩方式，用一套通用工具去驱动所有模型会损失表现，所以 Open Interpreter 为不同模型复刻服务商推荐的那一套。博客给出的对照来自 Terminal-Bench 2.1 的 89 道题：Kimi-K2.5 在 Open Interpreter 里解出 50 道，在 OpenCode 1.15.7 里解出 39 道；DeepSeek V4 Flash 分别解出 53 道和 42 道，这组数字均为官方自述，测试由厂商自己完成。按 Harness 文档，没有手动指定时，它会根据服务商和模型自动挑选：Kimi 与 Moonshot 默认用 kimi-code，Qwen 系列默认用 qwen-code，Anthropic 和 Claude 模型默认用 claude-code，DeepSeek 默认用 claude-code-bare。文档写明，这些模式都在 Open Interpreter 自己的 Rust 运行时里执行工具调用，并不去调用外部的 Kimi Code 或 Claude Code 程序。

原生沙箱与审批。沙箱继承自 Codex，分成两层控制：沙箱模式决定技术边界，有 read-only、workspace-write、danger-full-access 三档，其中 workspace-write 只允许写当前工作区，网络默认关闭；审批策略决定什么时候停下来询问用户，有 untrusted、on-request、never 三种。执行层面，macOS 用 Seatbelt 配置，Linux 与 WSL 用 Bubblewrap 和 seccomp 等内核机制，Windows 用系统原生沙箱。文档写明，策略无法落实时应当直接拒绝运行，而不是悄悄在沙箱外执行。博客把这一点当作它和其他面向开放模型的代理之间的主要差别。

沿用 Codex 生态。它说同一套 Codex exec 协议。README 举的例子是：已经在用 Codex SDK 的项目，只要把 codexPathOverride 指向 interpreter 就能切换。exec、MCP、技能、hooks、权限和 AGENTS.md 的用法与 Codex 一致。README 把“默认可移植”列为产品目标：项目说明放在仓库的 AGENTS.md，技能放在共享的 .agents/skills 目录，只有暂时没有通用标准的配置和运行状态才放进 ~/.openinterpreter。

服务商不设限。在界面里用 /model 切换服务商和模型；任何兼容 OpenAI 的服务都可以通过 --chat-completions 走 Chat Completions 接口。Kimi K3 文档写明，Kimi Code 订阅用户在浏览器里完成 Kimi 登录后即可使用 K3，也可以用 Moonshot 平台的 API key。Z.AI 文档区分了国际版 Z.AI 和国内的智谱 AI 两套服务商，并提供按 GLM 编码工作流复刻的 zcode 驾驭层。

内置界面测试技能。README 写明，仓库自带一个 QA 技能，可以借 agent-browser 在真实浏览器里操作网页应用，或借 trycua 操作和测试原生应用。

适合谁 / 不适合谁

适合谁

已经在用 Codex、想把一部分任务交给 Kimi、DeepSeek、Qwen、GLM 等更便宜的模型，又不想换掉 AGENTS.md、技能和 MCP 配置的开发者。README 和博客都把这类迁移列为主要场景。

在 CI 里跑 codex exec、想按任务换服务商的团队。按 Sandbox 文档，隔离的 CI 运行器可以配 workspace-write 加 never 审批，不需要人盯着。

想在 Zed、JetBrains、VS Code 等支持 ACP 的编辑器里接入一个带沙箱的代理的人，以及想研究不同驾驭层对模型表现有多大影响的人。

习惯终端工作流、愿意自己管理 API key 和服务商账单、能接受版本号仍是 0.0.x 的用户。

不适合谁

要找 2023 年那个 Python 版、想在 Python 代码里 import interpreter 调用的人。新版是 Rust 写的终端程序，和旧版没有代码上的延续。

不写代码、主要处理文档和表格的用户。同一家公司的桌面应用 Interpreter 更对口。

需要长期稳定接口的生产集成。新版持续合并 Codex 上游的改动，配置项和命令可能随之变化。只用 GPT 系列模型的人，直接用 Codex 原版少一层转手。

和同类比

与 Codex、Claude Code、OpenCode 的对照说法出自 Open Interpreter 的 README、文档和博客，均为官方自述。

和 Codex CLI 比。Codex 是它的上游，同样是 Apache-2.0。博客的说法是，Codex 围绕 GPT 打造，Open Interpreter 继承了它成熟的终端界面、app-server 协议和跨平台沙箱，再把多家服务商和驾驭层模拟做成一等功能。上游的新功能要合并进来后才能在 Open Interpreter 中使用。

和 Claude Code 比。博客把 Claude Code 归为“围绕单一模型打造”的代理。Open Interpreter 里的 claude-code 驾驭层是对它请求形态和工具面的模拟，按 Harness 文档，可以跑在 Anthropic Messages、Responses 或 Chat 任一种接口上，但它不是 Anthropic 的官方客户端。

和 OpenCode 比。博客把 OpenCode 称为“使用通用驾驭层的热门编码代理”，并以它为对照做了博客里那组 Terminal-Bench 测试，测试方是 Open Interpreter 自己。博客认为，此前面向开放模型的热门代理大多缺少内置沙箱，开发者只能盯着权限提示、在隔离机器上工作，或者用 Docker 这类重量级虚拟化。

和各家模型自己的代理比。Kimi Code、Qwen Code、DeepSeek TUI 都是服务商推荐的工具，Open Interpreter 的做法是在一个界面里复刻它们的驾驭层。Kimi K3 文档明确写着不需要另装 Kimi Code CLI。

三者的定位不同：Codex 围绕 GPT 打造；Claude Code 是 Anthropic 的官方客户端；Open Interpreter 保留 Codex 的终端界面，同时接入多家服务商的模型。

上手路径

安装。macOS 和 Linux 运行 curl -fsSL https://www.openinterpreter.com/install | sh；Windows 在 PowerShell 运行 irm https://www.openinterpreter.com/install.ps1 | iex。重启终端后用 interpreter --version 确认安装成功。按 Install 文档，Linux 发布包用 musl 构建，Windows 也支持在 WSL 里按 Linux 方式使用，Git 是推荐安装项。之后可以用 interpreter update 升级；卸载脚本会保留 ~/.openinterpreter 里的配置、会话、日志和凭据。

服务商与认证。第一次启动会引导用户选择认证方式：用 ChatGPT 账号登录，填 API key，接 Ollama 或 LM Studio 这样的本地模型，或者配置其他兼容服务。Authentication 文档建议 CI 和无界面机器用 API key，例如 OPENAI_API_KEY、ANTHROPIC_API_KEY；本机运行 Ollama 时，interpreter --oss 的模型流量不出本机。凭据可以存进系统钥匙串或 ~/.openinterpreter/auth.json，文档提醒后者要当作密码保管。

第一次会话。进入项目目录输入 i，提一个具体需求，比如“加一个返回构建版本号的 /health 接口”。它会读项目、提出方案、改文件、在当前沙箱和审批设置下运行命令。常用命令包括：/model 换模型，/harness 看当前驾驭层，/permissions 调整权限，/review 检查当前改动，interpreter exec 跑一次性任务。

权限档位。Sandbox 文档建议：看陌生代码用 read-only 加 on-request，日常可信仓库用 workspace-write 加 on-request。文档写明，--yolo 会同时关掉审批和沙箱，只应在一次性虚拟机或隔离容器这类外部沙箱里使用。

从 Codex 迁移。已有的 AGENTS.md 和 .agents/skills 目录可以直接沿用；用 Codex SDK 的代码把可执行文件指向 interpreter；CI 里的 codex exec 换成 interpreter exec，再用 -c 指定 model_provider 和 harness。

/harness 可以在会话中切换驾驭层，服务商和模型另行配置，同一个仓库里可以分别对比不同模型与驾驭层的组合。

定价与许可证

终端代理本身不收费，代码以 Apache-2.0 发布。花钱的地方是模型：自带 API key 时按服务商的账单付费，用 ChatGPT 登录时走用户自己的订阅额度，用本地模型则不产生调用费。按 Z.AI 文档，GLM 编码套餐只有在使用对应的 Coding Plan 服务商时才消耗套餐额度，走通用接口不计入套餐。

官方博客对桌面应用 Interpreter 的说法是“可以免费试用”，企业用户可联系团队。按它的隐私政策，桌面应用若使用官方托管的模型，请求会经过 Open Interpreter 的服务器，完整的请求和响应会保留最多 30 天后删除；用自己的 API key 时内容从设备直接发给服务商，不经过它的服务器。

许可证的沿革要分两段看。旧 Python 仓库的初始提交 31d4ffb（2023-07-14）用的是 MIT，提交 57f5695（2023-11-30）改成 AGPL-3.0。现在 main 分支上的 LICENSE 来自 Codex 仓库的初始提交 59a180d（2025-04-17），2026 年 7 月 16 日主分支以 Codex rust-v0.144.4 为基底重建（提交 e764363）之后，它成了 Open Interpreter 的许可证。NOTICE 文件保留 OpenAI 的版权声明，以及源自 Ratatui 的 MIT 代码声明。

Apache-2.0 允许商用和闭源再分发；许可证要求分发时保留 NOTICE 中的署名。

风险与局限

名字与历史。截至 2026-10-26，仓库有 68,670 个星标、5,909 个 forks，这些数字和 issue 编号都继承自 2023 年的 Python 项目，代码是新的 Rust 分叉。不少旧教程里“让模型在本机执行 Python 代码”的描述，说的是旧版。

贡献者。GitHub 贡献者接口（截至 2026-10-26）列出 473 个账号；主分支以 Codex 为基底重建，项目自身的工作集中在驾驭层、服务商目录和品牌层。

更新。按 GitHub API，main 分支最近一次提交在 10 月 11 日，内容是验证 Codex 0.159 的模型兼容配置。最新正式版 0.0.56 发布于 10 月 7 日 11:42 (UTC+8)，发布说明是加入 GPT-6.1 Sol 的模型信息并刷新服务商目录。截至 2026-10-26，开放 issue 15 个、开放 PR 8 个。

基准为厂商自测。Terminal-Bench 对照由 Open Interpreter 自己运行。博客的文字说测的是 DeepSeek V4 Flash，图表里同时给出 Kimi-K2.5 的数字。

驾驭层组合有约束。Harness 文档写明路由是严格的：服务商的 wire_api 必须和所选驾驭层匹配，比如 zcode 只能配 Anthropic Messages 接口。Z.AI 文档的排查提示是，/harness 显示 zcode 但行为看起来像通用模式时，要确认当前服务商的 wire_api 是 messages；文档也建议排查时把服务商、模型和驾驭层三层分开看。

安全设置。--yolo 或 danger-full-access 会取消本地沙箱边界；凭据如果存成文件，auth.json 就是明文密钥。

来龙去脉

Open Interpreter 的仓库创建于 2023-07-14，同一天提交了第一笔代码，许可证是 MIT。它让大模型在本机写代码并直接执行。2023-08-11 起在 GitHub 发布版本，2023-09-05 发布 0.1.0；2023-11-30，提交 57f5695 把许可证改成 AGPL-3.0。此后 Python 版陆续发布 0.2.0（2024-01-05）、0.3.0（2024-06-18）和 0.4.0（2024-10-24），PyPI 上最后一个版本 0.4.3 在 2024-10-26 上传。

另一条线来自 OpenAI：Codex CLI 的初始提交带着 Apache-2.0 许可证，时间是 2025-04-17。Open Interpreter 团队选择以它为底。发布页上第一个 rust-v 标签 0.0.16 出现在 2026-06-20；2026 年 7 月 16 日 00:35 (UTC+8)，提交 e764363 以 Codex rust-v0.144.4 为基底重建主分支，说明里只有一句“Rebase Open Interpreter onto Codex 0.144.4”。旧 Python 版本在发布页上现在都标成预发布。

官方博客《Introducing Open Interpreter》发布于 2026-07-13，开篇说“AI 有一个经济学问题”，要做“把开放权重模型当作一等公民的开放应用层”（官方自述），并宣布以 Apache-2.0 发布全新的 Open Interpreter。之后的版本主要在扩充服务商和模型：0.0.44 加入 GLM-5.3 的选项，0.0.45 加入 DeepSeek 的新模型选项，0.0.56 加入 GPT-6.1 Sol。README 顶部现在的公告是对 Kimi K3 的原生支持。