open-computer-use：用开源模型驱动一台云上 Linux 桌面

它要解决的问题：把模型从对话框里放出来

大多数 LLM 应用停留在文本输入输出。open-computer-use 想解决的是另一类任务：让模型去操作一台真正的图形化计算机，点按钮、敲键盘、开浏览器、执行 shell 命令。README 把它描述为“A secure cloud Linux computer powered by E2B Desktop Sandbox and controlled by open-source LLMs”，也就是一台跑在云端的 Ubuntu，由开源模型来操控。目标读者是愿意自己拼装模型链路的开发者，而不是想直接买一个 agent 产品的终端用户。项目主页和 README 都指向 E2B，说明这套东西从设计之初就假设沙箱由 E2B 提供。

三个模型各管一段：config.py 里的分工

这个项目最值得看的设计，是把一次操作拆成三个不同职责的模型，并且分别配置。README 给出的示例是：grounding_model = providers.OSAtlasProvider()，vision_model = providers.GroqProvider("llama3.2")，action_model = providers.GroqProvider("llama3.3")。grounding 负责把界面元素定位到坐标，vision 负责理解屏幕画面，action 负责决定下一步动作。这种拆法的好处是成本可控：定位和视觉可以用专门的模型，动作决策用更擅长推理的模型。代价是链路变长，任何一段出错都会让整次操作失败，而且三个模型之间的信息传递格式由项目自己定义，README 没有展开说明。providers.py 里已经收录了 Fireworks、OpenRouter、Llama API、Groq、DeepSeek、Google、OpenAI、Anthropic、HuggingFace Spaces、Moonshot、Mistral AI。README 对每个 provider 标注了能力范围，例如 Groq 的 Llama 3.2 同时支持 vision 和 action，而 Llama 3.3 只支持 action；DeepSeek 只支持 action。这些标注是选型时最直接的依据。

沙箱在云端，画面在本地：数据怎么流动

按 README 的描述，计算发生在 E2B 的 Desktop Sandbox 里，那台机器跑 Ubuntu，模型通过键盘、鼠标和 shell 命令去操作它。客户端这边做的是另一件事：实时串流沙箱的显示画面，README 说“Live streams the display of the sandbox on the client computer”，并且“The display stream should be visible a few seconds after the Python program starts”。也就是说，本地程序既是一个控制端，也是一个观看端。README 还提到用户可以随时暂停并给 agent 追加提示，这是把 agent 从全自动降级为可干预的半自动模式。架构图放在 assets/architecture.png 与 assets/architecture-light.png，README 指向一篇博客文章说明设计细节，仓库本身没有把数据流写成文字。如果你需要精确知道每一帧截图如何编码、动作如何回传，只能去读源码或那篇博客，README 层面给不出答案。

跑起来需要什么：从 poetry 到第一条提示词

前置条件是 Python 3.10 或更高版本、git、一个 E2B API key，以及至少一个 LLM provider 的 API key。README 给出的安装命令是 brew install poetry ffmpeg，然后 git clone https://github.com/e2b-dev/open-computer-use/，进入目录后创建 .env，写入 E2B_API_KEY="your-e2b-api-key"，再按 config.py 里选中的 provider 补上对应的 key，例如 GROQ_API_KEY、OPENAI_API_KEY、GEMINI_API_KEY、ANTHROPIC_API_KEY 等。README 特别写明 Hugging Face Spaces 不需要 API key，但 HF_TOKEN 是必需的，用来绕过 Gradio 的限流。启动方式是 poetry install 之后执行 poetry run start，agent 会打开并索要第一条指令；也可以带参数一次性给指令：poetry run start --prompt "use the web browser to get the current weather in sf"。这里有个容易踩的点：.env 里的 key 必须和 config.py 里实际启用的 provider 对得上，README 的注释写得很直白，“You only need the API key for the provider(s) selected in config.py”。

哪里会出问题：模型能力与沙箱边界的双重约束

第一个限制来自模型分工本身。README 的 provider 表里，DeepSeek 只标注 action only，Llama 3.3 也是 action only，Pixtral 用于 vision 而 Mistral Large 用于 actions。这意味着如果你选了一个不支持 vision 的模型去填 vision_model，链路就跑不通，而项目不会替你兜底。第二个限制是依赖面偏大：一次运行同时依赖 E2B 的沙箱服务和至少一个模型 API，任何一方限流或不可用都会中断任务。第三个限制是它对操作系统的假设。README 说“Uses Ubuntu, but designed to work with any operating system”，但实际验证过的环境只有 Ubuntu 沙箱，换操作系统属于设计意图而非已验证路径。第四个限制是项目没有发布 release，README 也鼓励使用者为新增 provider 提 PR，说明 provider 覆盖依赖社区补充，遇到冷门模型需要自己写适配。如果任务本身只是调用几个 HTTP 接口或做纯文本处理，用这套东西属于杀鸡用牛刀，直接写脚本更省事。

和闭源 computer use 的差别在哪

Anthropic 的 Claude computer use 是这条路上最直接的对照。它的做法是把视觉理解、坐标定位和动作决策放在同一个模型内部完成，使用者拿到的是一个端到端的能力，代价是模型不可换、行为不可拆。open-computer-use 走的是相反的路：它把这三个环节显式拆成 grounding_model、vision_model、action_model 三个配置项，允许你混搭 HuggingFace Spaces 上的 OS-Atlas、ShowUI 做定位，用 Groq 跑 Llama 3.2 做视觉，用另一个模型做动作。差别不在效果高低，而在可控性。闭源方案你只能调提示词，开源方案你可以换掉链路里的任何一环，但也要自己承担拼接带来的失败率。README 同时列了 Anthropic 作为 provider 之一，说明这两条路并不互斥：你完全可以用 Claude 填 vision 和 action，只在 grounding 上用 OS-Atlas。

维护成本与许可

项目采用 Apache-2.0 许可，允许商用与修改，具体条款以仓库中的 LICENSE 文件为准，这里不做法律层面的解读。维护成本主要来自两个方向。一是模型侧：README 里列的 provider 覆盖 Fireworks、OpenRouter、Llama API、Groq、DeepSeek、Google、OpenAI、Anthropic、Moonshot、Mistral AI，每一家的模型命名和可用性都会变，config.py 里的模型字符串需要跟着调整。二是依赖侧：poetry 管理 Python 依赖，ffmpeg 由系统包管理器安装，这两条路径的升级节奏由项目维护者决定。仓库没有 release，README 也没有版本号或兼容性矩阵，所以升级只能跟随 master 分支的提交，这对需要稳定基线的团队是一个现实约束。

编辑结论

适合已经在用 E2B、并且愿意自己维护模型组合与提示词的人：它把 grounding、vision、action 三个位置留成可替换的接口，config.py 里换一行 provider 就能换模型，这是它区别于闭源 computer use 产品的核心。不适合想要开箱即用、或者无法承担云端沙箱与多家模型 API 双重成本与依赖的团队。采用前先确认三件事：E2B_API_KEY 是否可用、providers.py 里是否已有你要用的模型、以及 HF_TOKEN 是否配置（README 明确写到 Hugging Face Spaces 需要它来绕过 Gradio 限流）。

官方来源

1. e2b-dev/open-computer-use on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README