Open Interpreter

Open Interpreter 是由 Killian Lucas 创建的一款免费、开源的命令行工具，它为大型语言模型提供了一个与本地计算机交互的自然语言接口。该工具于 2023 年 8 月在 AGPL-3.0 许可下发布，其工作原理是为你连接的任何 LLM 配备一个 exec() 函数：模型编写代码，提交给你审批，在你的机器上运行，接收输出结果，并不断迭代直至任务完成。没有云端中介，没有上传限制，也没有运行时间上限。

其核心工作流涵盖 Python、JavaScript 和 Shell 命令。你可以连接首选的 LLM 后端：OpenAI 的 GPT-4o（默认）、Anthropic Claude，或通过 Ollama 或 LiteLLM 运行的本地模型。v0.4.0 版本引入的 interpreter --os 模式增加了由 Anthropic 的 computer-use API 驱动的屏幕读取和鼠标/键盘控制功能，将智能体从脚本任务扩展到了全面的图形桌面自动化。只需一条 pip 命令即可完成安装；在终端中输入 interpreter 即可开始对话。

截至 2026 年 4 月，Open Interpreter 的实际功能

当前的稳定版本是 0.4.3，于 2024 年 10 月发布。该项目通过 pip install open-interpreter 或 uv tool install open-interpreter 安装，已累计获得超过 63,000 颗 GitHub stars，是获得星标最多的开源 AI 智能体项目之一。

其执行模型非常直观。你在终端提示符下输入自然语言请求。LLM 会生成代码来完成该请求。在运行任何内容之前，Open Interpreter 会打印出代码块并等待你的确认（按下 "y" 键）。你也可以传递 -y 参数来自动批准，尽管官方文档明确指出了这样做的风险。执行后，标准输出和错误信息会流回 LLM，然后由 LLM 决定是继续迭代、调试还是宣布任务成功。

开箱即用的受支持代码环境包括：Python、JavaScript、Shell（根据操作系统不同为 bash/PowerShell）和 HTML。LLM 会获知主机操作系统的信息，因此它会在 macOS 上编写 AppleScript，在 Windows 上编写 PowerShell，在 Linux 上编写 bash，无需用户进行任何配置。文件访问不受限制：智能体可以在你的用户账户权限范围内，读取、写入、移动和删除系统上任何位置的文件。

--os 计算机控制模式标志着自发布以来最重大的功能扩展。在此模式下，Open Interpreter 可以截取屏幕截图、移动鼠标、输入按键，并与屏幕上可见的任何应用程序进行交互。这使得无需脚本 API 即可实现类似语音控制的桌面软件自动化。

后端的灵活性是其真正的优势。处理隐私敏感工作负载的用户可以通过 Ollama 路由所有内容，将每一个 token 都保留在自己的硬件上。其他用户则使用 LiteLLM 连接到任何兼容 OpenAI 的端点。输出质量在很大程度上取决于模型的选择：GPT-4o 和 Claude 生成的代码可靠，调试周期短；而较小的本地模型通常需要更多的迭代和人工干预。

“它本质上是 OpenAI 的 Code Interpreter 的开源本地实现，但没有文件大小、运行超时或网络访问的限制。” - killianlucas (Killian Lucas)，Hacker News Show HN，2023 年 8 月 30 日

Open Interpreter 与 Cline 和 Aider 的定位对比

Open Interpreter、Cline 和 Aider 使用截然不同的执行模型来解决相邻的问题。从机制上理解它们的定位，决定了哪种工具适合哪种工作流。

Open Interpreter vs. Cline： Cline 作为扩展存在于 VS Code 中。它的主要循环是读取-差异-编辑-提交：它了解你项目的文件结构，以差异（diffs）的形式提出更改，并直接写入现有的源文件。Open Interpreter 没有 IDE 依赖，也没有项目级别的代码库感知能力。它可以在任何终端针对任何目录运行，其主要循环是编写代码-执行-观察。Cline 是一个代码编辑智能体。Open Interpreter 是一个代码执行智能体。Cline 在 2026 年 2 月发布了原生子智能体，具有用于多线程工作流的并行上下文窗口；而 Open Interpreter 是单线程运行的。如果你的任务是修改现有的代码库，Cline 在上下文方面胜出。如果你的任务是运行数据管道或自动化系统操作，Open Interpreter 则是最直接的工具。

Open Interpreter vs. Aider： Aider 也是一个终端 CLI，这使得两者在表面上更具可比性。区别在于架构重点。Aider 是围绕 git 构建的：它将每一次 AI 编辑视为一次提交，针对现有文件生成结构化的差异，并构建整个代码库的仓库映射（repo-map），为 LLM 提供深度的上下文。Open Interpreter 则不具备这些功能。它不映射仓库，不生成差异，也不进行提交。Aider 专为重构、在现有项目中实现功能以及 PR 级别的代码工作而构建。Open Interpreter 则专为一次性脚本、数据分析、文件自动化和系统脚本编写而构建，在这些场景中无需理解现有的代码库。

Open Interpreter vs. Devin： Cognition 的 Devin 在一个完全沙盒化的云环境中运行，拥有自己的浏览器、IDE 和终端。它在任务级别自主工作：分解、执行、验证，无需每步审批。Open Interpreter 在你的机器上运行，在每个代码块执行前需要你的批准，并且没有沙盒。Devin 的价格从 500 美元/月降至约 20 美元/月的基础费用加上计算单元费用，使其变得更易于获取，但仍属于专有的 SaaS。Open Interpreter 采用 AGPL 许可且免费。正确的选择取决于隔离需求：Devin 在设计上更安全；Open Interpreter 则更便宜、更透明。

智能体循环的实际体验

Open Interpreter 的日常使用是迭代式的，了解其节奏会让你受益匪浅。一个明确的请求（“加载 sales.csv，按月分组，计算平均订单价值，将条形图保存为 chart.png”）通常在两到四个代码块内完成。第一个代码块导入库并加载数据。如果出现导入错误，LLM 会发现它并编写一个纠正代码块。该循环持续进行，直到输出得到确认。对于大多数数据分析任务来说，这种体验令人印象深刻地直接。

在处理较长任务时会出现摩擦。因为默认情况下没有代码库映射，也没有跨会话的记忆，所以每次新对话都是从零开始。需要理解现有项目结构的任务需要手动粘贴文件内容或目录列表。如果没有明确的指令，LLM 无法自主浏览你的文件系统。

Token 成本是真实存在且可变的。一个简单的文件操作可能会消耗几百个 token。对失败脚本的迭代调试循环可能会激增到数万个 token，尤其是在使用冗长模型时。在复杂任务上运行 GPT-4o 的用户曾报告过因迭代调试而产生意外的 API 账单。该项目包含一个实验性的 %tokens 命令，用于在运行前估算成本。

本地模型路由改变了经济成本，但并非没有代价。在消费级 GPU 上通过 Ollama 进行路由消除了 API 成本，但引入了质量差异。较小的模型（7B-13B 参数）通常会生成语法正确但逻辑有缺陷的代码，导致调试周期变长，从而消耗用户更多的注意力。

“由于代码直接在你的机器上运行，如果你不仔细审查生成的代码，可能会出现各种各样的问题。” - Simon Willison，simonwillison.net，2024 年 11 月 24 日

安全模型是一个值得探讨的重点。默认的确认提示在大多数情况下保护了大多数用户。实验性的“安全模式”使用 semgrep 静态分析在执行前标记潜在的危险模式。Simon Willison 在 2024 年 11 月评测该工具时，对这种方法持怀疑态度，认为基于 Docker 的真正沙盒会更稳健。对于愿意信任拥有完全本地访问权限的 LLM 的用户来说，该工具运行流畅。对于需要经过验证的隔离环境的用户，Docker 模式作为一个实验性选项存在，但并非默认设置。

01 Light 硬件产品是一款由 Kickstarter 支持的 ESP32 语音设备，旨在作为物理 AI 控制器，于 2024 年初发布，代表了 Open Interpreter 成为硬件平台的尝试。2024 年 9 月 9 日，Killian Lucas 发表了《它本该是一个应用》（It should have been an app），宣布所有 01 Light 订单均已退款并取消制造。团队得出结论，智能手机应用在用户已有的硬件上能提供更好的性能。免费的 01 App 同时在 iOS 和 Android 上线，为桌面机器控制提供了相同的即按即说语音界面。这一转型既展示了项目的适应性，也凸显了一个小团队（当时仅五人）跨越软件和硬件领域的核心挑战。

Open Interpreter 适合哪些人

Open Interpreter 最适合特定类型的用户。对于能够快速阅读代码、希望用自然语言描述任务而不是从头编写脚本、并且看重完全在自己的硬件上工作的开发者和高级用户来说，它非常实用。希望以对话方式探索数据集而无需为每个问题启动 Jupyter notebook 的数据分析师，将获得真正的生产力提升。在许多小型一次性任务中进行探索性脚本编写、文件处理和格式转换工作的研究人员，也能从这种自然语言捷径中受益。

隐私优先的用户有充分的理由选择 Open Interpreter 而不是托管的替代方案。通过本地模型路由，任务描述、生成的代码和处理的数据永远不会离开用户的机器。这对于任何处理敏感文件、专有数据或在限制云传输的受监管行业中工作的人来说都至关重要。

希望在不手动编写 AppleScript 或 PowerShell 的情况下自动化桌面工作流的安全和系统爱好者，会发现操作系统控制模式特别有用。用自然语言描述自动化任务并在运行前审查生成的脚本，涵盖了以前需要专用自动化工具才能完成的工作流。

Open Interpreter 不是什么

Open Interpreter 不是一个具备代码库感知能力的编辑智能体。如果你需要重构现有项目、跨多个文件实现功能，或在定义的软件架构内工作，Aider 或 Cline 凭借更好的上下文机制能更好地满足这些需求。Open Interpreter 没有仓库映射，不生成差异，也没有自动的 git 集成。在现有的代码库上使用它需要手动将相关文件内容输入到对话中。

它不是一个安全或可审计的企业工具。默认情况下，没有基于角色的访问控制，没有审计日志，也没有沙盒执行环境。需要文档化、经过审查且隔离的代码执行管道的团队需要寻找其他解决方案。

它不太适合非技术用户。审批循环需要阅读并理解提议的代码。在不理解的情况下批准命令是可能的，但这会带来数据丢失或意外系统更改的真实风险。该工具专为能够评估其提议内容的用户而设计。

截至 2026 年 4 月，其维护轨迹是一个实际的隐患。上一个稳定的 PyPI 版本是在 2024 年 10 月发布的。2025 年 5 月开启的标题为“这个项目死了吗？”（IS THIS PROJECT DEAD?）的 GitHub Issue #1627 被以“未计划”（not planned）为由关闭，且没有公开回应。提交活动仍在继续，但发布节奏与 2023-2024 年的快速发展期相比已显著放缓。构建依赖于 Open Interpreter 的工作流的用户应考虑到，依赖项的维护可能需要自行打补丁。