关键要点
- 许可证由AGPL 3.0变更为Apache 2.0——经GitHub API与仓库LICENSE文件确认
- 用Rust彻底重写，作为OpenAI开源Codex项目的分叉
- 当前GitHub描述："A coding agent for open models like Kimi K3"
- 明确列出的模型集成目标：Kimi K3、DeepSeek、Qwen、GLM/Z.AI
- 68,227星标，5,871分叉，仅10个未关闭issue，最后一次推送于2026-08-20
- 发布Kimi K3工具链后，一度成为GitHub上热度第一的Rust仓库
- 原本的Python/AGPL版"控制电脑"工具以社区分叉endolith/open-interpreter的形式延续
📍 简单一句话
Open Interpreter现在是一款基于Rust、采用Apache 2.0许可证的编码代理，分叉自OpenAI开源的Codex，专为运行Kimi K3等开源模型而构建，取代了原本Python/AGPL版"模型在你电脑上执行代码"的设计。
💬 简单来说
这款工具过去是把ChatGPT式的代码执行放到本地运行、而不是在OpenAI云端沙盒中运行的一种方式。它在精神上仍在做类似的事，但代码、许可证和目标用户——使用开源模型的人，而不是单一厂商API的用户——都已经变了。
📌注: 本评测覆盖的是当前Rust/Codex分叉版本的Open Interpreter。如果你要找的是2023年那款用自然语言指令浏览网页、编辑文件的原版Python工具，它保留在社区分叉中，而非主仓库。
2026年的Open Interpreter是什么
Open Interpreter（github.com/openinterpreter/openinterpreter，常被链接为github.com/OpenInterpreter/open-interpreter，会重定向到正式的小写组织名）是一款基于终端的编码代理。其当前的GitHub描述说得很直白："A coding agent for open models like Kimi K3"。这与2023年让这个名字广为人知的那款工具，语言不同、许可证不同，是一个不同的项目。
- Rust内核，完全取代了原来的Python代码库
- 分叉自OpenAI开源的Codex项目，兼容Agent Client Protocol（ACP）
- 用Rust重新实现了服务商推荐的"Kimi Code"工具链，专为从开源、低成本模型中获得更好表现而优化，而非围绕单一托管API
- GitHub上的仓库标签包括acp、coding-agent、deepseek、kimi、qwen和rust
- 官网：openinterpreter.com
- 由Killian Lucas创立，他以CEO兼首席开发者的身份领导Open Interpreter Inc.
从2023年AGPL个人项目到2026年Rust重写
Open Interpreter仓库创建于2023-07-14，2023年9月正式公开发布，正值人们对让语言模型直接访问终端这一想法兴趣高涨之时。创始人Killian Lucas——常驻华盛顿州贝灵厄姆——打造它的目的，是让人们获得与OpenAI托管版Code Interpreter同样"让模型直接执行代码"的能力，但可以在本地运行，或针对用户自选的远程模型运行，而不必受限于受限的云端沙盒：没有网络访问限制、没有文件大小上限、对执行环境拥有完全控制权。此后Lucas创立了Open Interpreter Inc.，担任CEO兼首席开发者。
这款原版工具以AGPL 3.0许可证发布，将自身定位为一种自然语言界面，让LLM可以从聊天式终端会话中编辑文件、浏览网页、分析数据集——更接近通用的电脑控制代理，而非专门面向编码的工具。
到2026年，该项目的方向已完全转变。团队用Rust从零重写了代码库，将其从OpenAI自家的开源Codex项目分叉而来，并将其重新定位为专为开源、低成本模型打造的编码代理，而非通用的"控制电脑"助手。许可证也在同一时期从AGPL 3.0变更为Apache 2.0。
2023年为何存在
OpenAI托管版Code Interpreter运行在受限的云端沙盒中——网络访问受限、文件大小有上限、对执行环境没有控制权。Open Interpreter的创立初衷，就是在没有这些限制的情况下，让人们在本地或对自选模型获得同样的能力。
到2026年发生了什么变化
该项目用Rust重写了内核，从OpenAI的Codex分叉而来，并将重心收窄为面向开源模型的编码代理——与最初通用的"控制电脑"工具范围不同。
Open Interpreter现在如何工作
Open Interpreter当前的架构，是用Rust重新实现服务商推荐的"Kimi Code"工具链，并包装在一个兼容Codex的终端界面中。它支持Agent Client Protocol（ACP），因此除了作为独立CLI运行外，还能接入兼容ACP的编辑器和工具。
- Rust内核负责代理循环和终端界面
- 分叉自OpenAI开源的Codex CLI，结构上与其兼容
- 兼容ACP（Agent Client Protocol），因此可以与其他支持ACP的工具集成，而不仅是独立运行
- 明确列出的集成目标：Kimi K3、DeepSeek、Qwen和GLM/Z.AI
- 在Rust内核之外仍提供Python SDK和运行时组件（见python-runtime-build.yml和python-sdk-release.yml工作流），因此并非从头到尾纯Rust项目
- 1macOS或Linux：在终端中运行
curl -fsSL https://www.openinterpreter.com/install | sh。 - 2Windows：在PowerShell中运行`irm www.openinterpreter.com/install.ps1 | iex`。
- 3在终端中运行
i或interpreter启动代理。 - 4按照相应服务商的配置说明，将其指向Kimi K3、DeepSeek、Qwen或GLM/Z.AI等开源模型——项目并未规定单一的必需后端。
- 5直接在终端中使用，或者如果你更喜欢在IDE中工作而非独立CLI，可通过兼容ACP的编辑器连接。
许可证变更：从AGPL 3.0到Apache 2.0
Open Interpreter的Python时代原始代码库以AGPL 3.0发布，这是一种著佐权许可证，要求任何修改代码并将其作为网络服务运行的人，公开其修改后的源代码。当前的Rust代码库则以Apache 2.0发布，这一点通过GitHub API的许可证字段和仓库根目录下原始的LICENSE文件均得到确认。
Apache 2.0允许、AGPL 3.0不允许的事
Apache 2.0是一种宽松许可证：你可以使用、修改和再分发代码——即使是在闭源商业产品中——而无需公开你自己的源代码，或基于它构建的服务的源代码。AGPL 3.0的著佐权"网络使用"条款，恰恰将这一义务强加给以托管服务形式运行修改版本的人。
保持不变的部分
Apache 2.0仍然要求保留版权和许可证声明，并说明对代码所做的重大修改。它还包含一项AGPL 3.0没有的明确专利授权。
Open Interpreter还在维护吗
仓库上能看到的每一项信号都表明这是一个活跃、持续维护中的项目，而非靠昔日热度吃老本的项目。最后一次推送发生在2026-08-20——距本次评测大约两周——在68,227星标、5,871分叉的规模下，未关闭issue仅有10个，对这种规模的仓库而言比例很低。
该项目还运行着相当完善的自动化CI体系，其.github/workflows/目录下的工作流文件即为证据：rust-ci.yml、rust-ci-full.yml和rust-ci-full-nextest-platform.yml通过cargo nextest在多个操作系统平台上运行Rust测试套件；cargo-ci.yml和cargo-deny.yml负责依赖和安全审计；blocking-ci.yml是阻止合并的必需检查；postmerge-ci.yml和public-ci.yml运行进一步验证；python-runtime-build.yml和python-sdk-release.yml负责构建和发布Python SDK组件；repo-checks.yml与codespell.yml负责仓库卫生检查。
仓库活跃度
- What it shows:
- 最后一次推送于2026-08-20，未被归档
星标与issue比例
- What it shows:
- 68,227星标对10个未关闭issue——积压很少
分叉数量
- What it shows:
- 5,871个分叉
CI覆盖
- What it shows:
- 9个以上的工作流文件，覆盖Rust测试、依赖审计和必需的合并检查
热门状态
- What it shows:
- Kimi K3工具链发布后，GitHub上热度第一的Rust仓库
📌注: 本次评测中，我们没有针对Open Interpreter运行自己的测试套件。上述维护信号均来自仓库公开的提交历史、issue数量，以及项目自身公开的CI工作流文件，而非PromptQuorum生成的基准测试。投入大量时间之前，请直接在仓库上核实当前状态。
谁适合使用Open Interpreter
正确的选择取决于你是具体想要一款针对开源模型优化的编码代理，还是原本那款通用的"控制电脑"工具。
以下情况适合使用Open Interpreter（当前的Rust版本）
- 你想要一款兼容Codex的终端编码代理，针对Kimi K3、DeepSeek、Qwen或GLM/Z.AI等开源或低成本模型优化
- 你已经在使用、或计划使用兼容ACP的编辑器，希望代理能支持该协议
- 你想要一款采用宽松许可证（Apache 2.0）的代理，可以在商业上构建产品而不承担著佐权义务
以下情况适合使用社区分叉endolith/open-interpreter
- 你具体想要2023年的原版Python工具，它能让模型从通用的聊天式终端会话中浏览网页、编辑文件、分析数据集，而非专门面向编码的代理
- 你出于与该特定许可证相关的原因，需要AGPL 3.0许可证的代码库
以下情况可以考虑完全不同的工具
- 你想要一款专有的、由厂商托管的编码代理——OpenAI Codex CLI或Anthropic Claude Code是与Open Interpreter当前架构所参照对象最接近的闭源选项
- 你想要一款IDE原生的自主代理，而非以终端为先——Cline或OpenHands是围绕这种工作流构建的
- 你想要Open Interpreter最初所处的那种不限范围的通用自主代理模式——AutoGPT和BabyAGI（均已在本站评测）是该类别中直接的历史同侪
Open Interpreter与替代方案对比
Open Interpreter当前的定位——面向开源模型、兼容Codex的终端编码代理——使它与多个类别的工具并列：其他终端编码代理、IDE原生代理、专有厂商代理，以及来自2023年"让LLM掌控你的电脑"这股浪潮中的历史同侪。
按使用场景的最佳选择
- 开源模型编码代理最佳之选：Open Interpreter——专为Kimi K3、DeepSeek、Qwen和GLM/Z.AI打造
- Git原生diff审查最佳之选：Aider——提交以可审查的git diff形式呈现
- 想留在VS Code内最佳之选：Cline——以扩展形式运行，而非独立终端工具
- 专有且有厂商支持选项最佳之选：OpenAI Codex CLI或Claude Code
- 重温最初不限范围代理模式最佳之选：AutoGPT（classic）或BabyAGI，均已在本站评测
工具 | 界面 | 许可证 | 最适合 |
|---|---|---|---|
| Open Interpreter | 终端，兼容ACP | Apache 2.0 | 面向开源模型的编码代理 |
| Aider | 终端 | Apache 2.0 | Git原生的diff式结对编程 |
| Cline | VS Code扩展 | Apache 2.0 | 自主IDE代理 |
| OpenHands | 沙盒化代理运行时 | MIT | 自主SWE代理任务 |
| Continue.dev | IDE扩展 | Apache 2.0 | 自动补全+聊天，限定于IDE |
| OpenAI Codex CLI | 终端 | 专有 | 厂商托管的终端编码代理 |
| Claude Code | 终端 | 专有 | 厂商托管的终端编码代理 |
| AutoGPT（classic） | CLI，自主循环 | MIT | 不限范围的自主代理实验 |
| BabyAGI | CLI，自主循环 | MIT | 最简自主任务循环实验 |
评估Open Interpreter时的常见误区
2026年围绕Open Interpreter的大部分困惑，源于人们期待的是2023年的那款工具，而不是当前的Rust重写版本。
误区1：以为它仍是AGPL 3.0许可证
AGPL 3.0许可证适用于原本Python时代的代码库。当前的Rust项目采用Apache 2.0许可证——经GitHub API和仓库LICENSE文件确认。在假定适用哪种许可证之前，请直接查看LICENSE文件。
误区2：期待原本的"控制电脑"工具
Open Interpreter当前的描述是"a coding agent for open models like Kimi K3"——比原本通用的文件编辑与网页浏览代理范围更窄、专注于编码。那款原版工具保留在社区分叉endolith/open-interpreter中，而非主仓库。
误区3：把它当作纯Rust项目
该仓库在Rust内核之外，仍在提供并发布Python SDK和运行时组件（见python-runtime-build.yml和python-sdk-release.yml）。它是一个以Rust为内核、同时保留Python组件的项目，而不是彻底放弃Python的纯重写。
误区4：以为必须使用某个特定的模型后端
项目将Kimi K3、DeepSeek、Qwen和GLM/Z.AI列为集成目标，但并未规定单一的必需后端。你指向哪个开源模型是一项配置选择，而不是固定依赖。
常见问题
Open Interpreter采用什么许可证？
Apache 2.0，经GitHub API的许可证字段和仓库LICENSE文件确认。这是相较于早期Python时代代码库所用的原始AGPL 3.0许可证的一次变更。
Open Interpreter还在维护吗？
是的。最后一次推送发生在2026-08-20，在68,227星标下未关闭issue仅有10个，并运行着涵盖Rust测试、依赖审计和必需合并检查的多工作流CI体系。
原版Open Interpreter怎么样了？
这款让本地或远程模型能从自然语言终端会话中编辑文件、浏览网页、执行代码的原版Python工具，已于2026年用Rust彻底重写，并从OpenAI开源的Codex项目分叉而来。原本的Python/AGPL版本以社区分叉的形式保留在github.com/endolith/open-interpreter。
Open Interpreter支持哪些模型？
该项目在仓库标签和描述中将Kimi K3、DeepSeek、Qwen和GLM/Z.AI列为集成目标，并用Rust重新实现了"Kimi Code"工具链。它并未规定单一的必需模型后端。
如何安装Open Interpreter？
在macOS或Linux上，运行curl -fsSL https://www.openinterpreter.com/install | sh。在Windows上，在PowerShell中运行irm https://www.openinterpreter.com/install.ps1 | iex。然后用i或interpreter启动代理。
Open Interpreter可以免费使用吗？
可以。它以Apache 2.0许可证发布，允许免费使用、修改和再分发，即便是在商业产品中，也无需公开你自己的源代码。
Open Interpreter与Codex或Claude Code兼容吗？
Open Interpreter是OpenAI开源Codex项目的分叉，构建目标是与Codex兼容，同时它也支持Agent Client Protocol（ACP），可与其他兼容ACP的工具集成。它是一个独立、由社区独立维护的项目，并非OpenAI Codex CLI或Anthropic Claude Code的官方扩展。
Open Interpreter现在还能让模型控制我的整台电脑吗？
当前的Rust项目被限定为编码代理，而非通用的"控制电脑"工具。范围更广的原版Python工具——文件编辑、网页浏览、数据集分析——以社区分叉endolith/open-interpreter的形式单独保留着。
Open Interpreter与Aider或Cline相比如何？
三者都是基于终端或IDE的编码代理。Aider是Git原生的，将输出结构化为可审查的diff；Cline以VS Code扩展形式运行；Open Interpreter是一款独立的、兼容Codex的终端代理，专门针对开源模型优化。哪一款更合适，取决于你更看重git diff审查、IDE集成，还是开源模型优先的调优。
Open Interpreter为什么从AGPL 3.0改为Apache 2.0？
该项目在README中并未就2026年重写伴随的这次具体许可证变更给出明确说明的理由。Apache 2.0比AGPL 3.0更为宽松：它取消了著佐权"网络使用"所附带的源代码披露义务，并新增了明确的专利授权，这使得在该代码基础上构建商业产品更容易。在依赖这一区别做决定之前，请直接阅读LICENSE文件以确认当前条款。