mcpField
O
Open Computer Use

Open Computer Use

本地服务
github.comAI 与智能体1263 周前更新

关于 Open Computer Use

Open Computer Use 是一个 MCP 服务,为任意 LLM 提供基于 Docker 沙箱的独立计算环境,包含终端、浏览器、文档技能和子 Agent。它可自托管,适合多用户部署,但项目已归档,不再维护。

主要功能

  1. 01每个会话独立的 Docker 容器
  2. 02实时 CDP 浏览器画面与交互
  3. 03内置 13 项技能,涵盖文档与网页测试
  4. 04可调用 Claude Code、Codex 或 OpenCode 的子 Agent
  5. 05通过 Streamable HTTP 接入 MCP 客户端

适用场景

  1. 01在聊天界面中为模型提供代码执行与文档生成环境
  2. 02用 Playwright 技能进行网页测试与抓取
  3. 03在自托管环境中试验 LLM 的计算机使用能力

MCP 相关

该服务通过 Streamable HTTP 的 /mcp 端点对外提供沙箱能力,供 Open WebUI、Claude Desktop、n8n 等 MCP 客户端调用。

配置

本地服务的配置在各客户端中通用,复制后粘贴到客户端的 MCP 配置文件即可。

暂未收录安装方式

我们还没有获取到这个服务的安装包或远程地址,请按项目 README 中的说明安装。

代码仓库

工具

还没有获取到工具列表

本地服务需要在你的电脑上运行后才能读取工具,维护者暂未提供工具列表。

详细介绍

开放式计算机使用

构建 CodeQL 发布 许可证 星标 问题

为任意大模型提供专属计算机的 MCP 服务——采用受管理的 Docker 工作空间,配备实时浏览器、终端、代码执行、文档技能和自主子 Agent。可自托管、开源,并可接入任意模型。

已归档。 此代码库不再开发或维护,不会收到修复、安全更新或依赖项更新,问题和拉取请求也已关闭。请勿在生产环境中运行。

Open Computer Use 是一项概念验证,旨在为大模型提供一台真正的计算机。其继任项目是 Wide Moat:Open WebUI 搭配 Open Terminal、浏览器,以及通过 gVisor 隔离的 Kubernetes 沙箱,并配备入口 sidecar 和通过 MITM 代理的出口流量。已知限制中列出的隔离和凭据处理问题,在该架构中得到了解决,而非在此代码库中。欢迎在 ai.lab.widemoat.ai 体验。

代码继续以 FSL-1.1-Apache-2.0 许可证提供:可使用、分叉并自行托管。每个版本发布两年后都会转为 Apache-2.0 许可证。

演示:Qwen 3.6 Plus 抓取 GitHub Trending,制作 Excel 图表,并生成编辑风格的 Web 仪表板——全部在一次聊天中完成

这是什么?

一个 MCP 服务,为任意大模型提供配备齐全的 Ubuntu 沙箱,并使用相互隔离的 Docker 容器。可以把它看作 AI 的计算机——它能完成开发者能做的一切:

  • 执行代码——在隔离容器中运行 bash、Python、Node.js、Java
  • 创建文档——借助技能,以专业样式创建 Word、Excel、PowerPoint 和 PDF 文档
  • 浏览网页——Playwright + 实时 CDP 浏览器串流(你可以实时看到 AI 所见)
  • 运行 Claude Code——配备交互式终端的自主子 Agent,自动配置 MCP 服务
  • 使用 13+ 项技能——经过实战验证的工作流,适用于文档创建、网页测试、设计等

专为生产级多用户部署打造。 已通过 1,000+ MAU 测试。每个聊天会话都在独立的 Docker 容器中运行——AI 可以安装软件包、创建文件、运行服务,用户之间互不影响。可在各种 MCP 客户端之间无缝切换:今天使用 Open WebUI,明天切换到 Claude Desktop 或 n8n——后端不变,无需迁移。

核心差异
功能Open Computer UseClaude.ai(Claude Code web)open-terminalOpenAI Operator
可自托管是否是否
支持任意大模型是(兼容 OpenAI)仅 Claude任意模型(通过 Open WebUI)仅 GPT
代码执行完整的 Linux 沙箱沙箱(Claude Code web)沙箱 / 裸机否
实时浏览器CDP 流式传输(共享、可交互)基于截图否基于截图
终端 + Claude Codettyd + tmux + Claude Code CLIClaude Code web(内置)PTY + WebSocket不适用
技能系统13 个内置技能(自动注入)+ 自定义技能内置技能 + 自定义指令Open WebUI 原生(仅文本)不适用
容器隔离Docker(runc),每个聊天独立Docker(gVisor)共享容器(操作系统级用户)不适用

可与任何兼容 MCP 的客户端配合使用:Open WebUI、Claude Desktop、LiteLLM、n8n 或你自己的集成。请参阅 docs/COMPARISON.md,了解与其他方案的详细比较。

实时浏览器流式传输

浏览器查看器

使用技能预览文件

文件预览

前端设计 — 在浏览器标签页中实时呈现的落地页

由 frontend-design 技能生成的 Roasthaus 落地页,在聊天窗口旁实时呈现

演示文稿 — 定制设计系统,而非默认的白色模板

BrewLoop 投资人演示文稿中的幻灯片,采用咖啡主题配色,包含数据卡片和柱状图

创建自己的技能 — 将重复性工作封装为可复用函数

invoice-builder 技能的演示:左侧是用法代码,右侧是生成的 PDF

数据 → 图表与分析

SaaS 用户增长图表,标注了拐点并附有文字分析

Claude Code — 云端交互式终端

Claude Code 终端

子 Agent 控制面板 — 监控与控制

子 Agent 控制面板

请参阅 docs/FEATURES.md 了解架构详情,并参阅 docs/SCREENSHOTS.md 查看所有截图。

实用建议:在终端中使用 Claude Code 创建技能,然后在聊天中搭配任意模型使用。技能与模型无关——编写一次,随处使用。

多 CLI 子 Agent 运行时(v0.9.2.1+):子 Agent 调度支持 Claude Code(默认)、OpenAI Codex 和 OpenCode(支持 OpenRouter / qwen / DeepSeek / 75+ 个提供商)。在 .env 中切换 SUBAGENT_CLI=claude|codex|opencode——请参阅 docs/multi-cli.md,了解 OpenCode + qwen3-coder + OpenRouter 的完整配置示例。

架构

架构

docs/future-architecture/ 中包含有关 Kubernetes 架构的设计说明,该架构未在此仓库中构建。本项目代码仅支持 Docker Compose。

试用方式

方式URL所需条件适用场景
免费在线演示 — Open WebUI + Computer Use,已包含模型ai.lab.widemoat.ai使用 GitHub 或 Google 登录30 秒内端到端体验
自托管下方的 快速入门Docker,首次构建约需 15 分钟完全掌控、隔离网络环境、高强度使用

仅支持 OAuth 登录——不支持邮箱/密码或短信登录。在 ai.lab.widemoat.ai 上,模型作为免费便利服务提供。托管的 MCP 端点目前不可用;请参阅 docs/CLOUD.md。

快速开始

git clone https://github.com/Wide-Moat/open-computer-use.git
cd open-computer-use
cp .env.example .env
# Edit .env — set OPENAI_API_KEY (or any OpenAI-compatible provider)

# 1. Start Computer Use Server (builds workspace image on first run, ~15 min)
docker compose up --build

# 2. Start Open WebUI (in another terminal)
docker compose -f docker-compose.webui.yml up --build

打开 http://localhost:3000,即可使用已配置好 Computer Use 的 Open WebUI。

注意: 使用两个独立的 docker-compose 文件:docker-compose.yml(Computer Use Server)和 docker-compose.webui.yml(Open WebUI)。它们通过 localhost:8081 通信。这模拟了实际部署场景:服务和 UI 运行在不同的主机上。

模型设置(重要!)

在 Open WebUI 中添加模型后,前往 Model Settings 并设置:

设置值原因
Function CallingNativeComputer Use 工具正常工作所必需
Stream Chat ResponseOn启用实时输出流

如果没有设置 Function Calling: Native,模型就不会调用 Computer Use 工具。

沙箱包含的内容

沙箱内容

类别工具
语言Python 3.12、Node.js 22、Java 21、Bun
文档LibreOffice、Pandoc、python-docx、python-pptx、openpyxl
PDFpypdf、pdf-lib、reportlab、tabula-py、ghostscript
图像Pillow、OpenCV、ImageMagick、sharp、librsvg
WebPlaywright(Chromium)、Mermaid CLI
AIClaude Code CLI、Playwright MCP
OCRTesseract(可配置语言)
媒体FFmpeg
图表Graphviz、Mermaid
开发TypeScript、tsx、git

技能

13 个内置公开技能 + 14 个示例:

技能描述
pptx使用 html2pptx 创建/编辑 PowerPoint 演示文稿
docx创建/编辑带修订记录的 Word 文档
xlsx使用公式创建/编辑 Excel 电子表格
pdf创建、填写表单、提取内容、合并 PDF
sub-agent将复杂任务委派给 Claude Code
playwright-cli浏览器自动化和网页抓取
describe-image使用视觉 API 分析图像
frontend-design构建可用于生产环境的 UI
webapp-testing使用 Playwright 测试 Web 应用
doc-coauthoring结构化文档协作工作流
test-driven-development强制执行 TDD 方法
skill-creator创建自定义技能
gitlab-explorer探索 GitLab 仓库

14 个示例技能:web-artifacts-builder、copy-editing、social-content、canvas-design、algorithmic-art、theme-factory、mcp-builder 等。

详情请参阅 docs/SKILLS.md。

MCP 集成

该服务使用标准的 Streamable HTTP 协议进行 MCP 通信。将任意 MCP 客户端指向你自己的部署即可。

  • 自托管:http://localhost:8081/mcp。快速检查:
    curl -X POST http://localhost:8081/mcp \
      -H "Content-Type: application/json" \
      -H "X-Chat-Id: test" \
      -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"test","version":"1.0"}}}'
    
    完整的自托管集成指南(LiteLLM、Claude Desktop、自定义客户端):docs/MCP.md。每个聊天的系统提示词通过 六种冗余的 MCP 原生渠道传递(工具描述、沙箱中的 /home/assistant/README.md、InitializeResult.instructions、用于已上传文件的 resources/list,以及供旧版集成使用的 HTTP /system-prompt 端点);完整说明见 docs/system-prompt.md。

配置

所有设置均通过 .env 配置:

变量默认值说明
OPENAI_API_KEY—大模型 API 密钥(兼容任何 OpenAI 的服务)
OPENAI_API_BASE_URL—自定义 API 基础 URL(OpenRouter 等)
MCP_API_KEY—MCP 端点的 Bearer 令牌
DOCKER_IMAGEopen-computer-use:latest沙箱容器镜像
COMMAND_TIMEOUT120Bash 工具超时时间(秒)
SUB_AGENT_TIMEOUT3600子 Agent 超时时间(秒)
SINGLE_USER_MODE—true = 使用单个容器,无需聊天 ID;false = 要求提供 X-Chat-Id;未设置 = 宽松模式
PUBLIC_BASE_URLhttp://computer-use-server:8081浏览器可访问的 Computer Use 服务 URL。该值会写入 /system-prompt,并通过 X-Public-Base-URL 响应标头返回给 Open WebUI 过滤器——作为公共 URL 的唯一真实来源。Open WebUI 过滤器 URL 要求。
CHAT_RESPONSE_MAX_TOOL_CALL_ITERATIONS、ORCHESTRATOR_URL、TOOL_RESULT_MAX_CHARS、TOOL_RESULT_PREVIEW_CHARS—open-webui 容器(而非 CU-server)中的设置。嵌入时必须配置——请参阅将 Open WebUI 嵌入自有堆栈时的必要设置。
POSTGRES_PASSWORDopenwebuiPostgreSQL 密码
VISION_API_KEY—视觉 API 密钥(用于 describe-image)
ANTHROPIC_AUTH_TOKEN—Anthropic 密钥(用于 Claude Code 子 Agent)
MCP_TOKENS_URL—Settings Wrapper URL(可选,见下文)
MCP_TOKENS_API_KEY—Settings Wrapper 身份验证密钥
自定义技能与令牌管理(可选)

默认情况下,所有 13 项内置技能均对所有人开放。若要按用户设置技能访问权限并添加自定义技能,请部署 Settings Wrapper——请参阅 settings-wrapper/README.md。

个人访问令牌(PAT): Settings Wrapper 还可以为外部服务(GitLab、Confluence、Jira 等)存储按用户加密的 PAT。服务端会根据用户邮箱获取这些令牌,并注入沙箱——因此每位用户的 AI 都可以访问自己的代码库和文档,而无需共享凭据。服务端的令牌注入代码已实现(docker_manager.py),但 Open WebUI 工具不会传递所需的标头,也不会对此进行修改。

MCP 客户端集成

Computer Use Server 使用标准的 MCP over Streamable HTTP 协议——任何兼容 MCP 的客户端都可以连接。Open WebUI 是主要经过测试的前端,但并非唯一选择。

客户端可自托管的 URL状态
Open WebUI已包含 Docker Compose 堆栈,并自动配置已在生产环境中测试
Claude Desktophttp://localhost:8081/mcp——请参阅 docs/MCP.md可用
n8nMCP Tool 节点 → http://computer-use-server:8081/mcp可用
LiteLLMMCP 代理配置——请参阅 docs/MCP.md可用
自定义客户端任何支持 MCP JSON-RPC 的 HTTP 客户端——请参阅 docs/MCP.md 中的 curl 示例可用

Open WebUI 集成

Open WebUI 是一个可扩展、可自托管的 AI 界面。我们将其用作主要前端,因为它支持工具调用、函数过滤器和 artifacts——这些都是 Computer Use 所需的功能。

**兼容性:**此构建版本专门针对 Open WebUI 0.11.0 构建并经过验证。我们构建版本号的前 3 段(v0.11.0.X)始终与其适用的 Open WebUI 基础版本一致。如果你运行的是其他 Open WebUI 版本,请选择前 3 段版本号与你的版本一致的 Open Computer Use 构建版本——例如,Open WebUI 0.8.12 对应 v0.8.12.Y 构建版本。

**为什么不使用分支?**Computer Use 本身不是分支:它通过官方插件 API(工具和函数)接入,因此安装工具和过滤器后,原版 Open WebUI 即可正常运行。(确实存在一个单独的分支,用于实现无法通过插件表达的改动,但此仓库不依赖它。)

通过企业网关(LiteLLM、Azure、Bedrock)运行 Claude Code?请参阅 docs/claude-code-gateway.md,了解三种路径的运维方案。

openwebui/ 目录包含:

  • tools/ — MCP 客户端工具(Computer Use Server 的轻量代理)。必需——这是 Open WebUI 与沙盒之间的桥梁。
  • functions/ — 系统提示词注入器 + 文件链接重写器 + 归档按钮。必需——没有它,模型就无法识别技能和文件 URL。
  • patches/ — 用于 artifacts、错误处理和文件预览的构建时修复。可选,但建议启用——可显著改善用户体验。
  • init.sh — 首次启动时自动安装工具和过滤器。可选——你也可以通过 Workspace UI 手动安装。
  • init.sh — 首次启动时安装工具和过滤器,并设置它们的阀门。
自动初始化的工作原理

首次运行 docker compose up 时,初始化脚本会自动:

  1. 创建一个管理员用户([email protected] / admin)
  2. 通过 POST /api/v1/tools/create 安装 Computer Use 工具
  3. 通过 POST /api/v1/functions/create 安装 Computer Use 过滤器
  4. 配置工具和过滤器的阀门(ORCHESTRATOR_URL=http://computer-use-server:8081 — 用于服务端到服务端通信的内部 URL,并写入两者的 Valves)
  5. 将工具设为公开可读(为 group:* 和 user:* 通配符授予访问权限),这样非管理员用户也能在工作区中看到该工具
  6. 将过滤器设为已启用且全局生效(两个单独的开关:/toggle 和 /toggle/global)——仅启用而未设为全局生效的过滤器不会生效,这是手动设置时常见的错误
  7. 通过 POST /api/v1/configs/models 将 {function_calling: "native", stream_response: true} 合并到 DEFAULT_MODEL_PARAMS 中——这样所有模型都会获得正确的默认值,无需逐个点击模型的 Advanced Params

标记文件(.computer-use-initialized)可防止后续启动时重复运行初始化脚本。

**注意:**Open WebUI 不支持从文件系统预安装工具——必须通过 REST API 加载。初始化脚本会自动完成此操作,无需手动处理。

手动设置(如果不使用 docker-compose)

如果单独运行 Open WebUI,则需要手动执行以下操作:

  1. 前往 Workspace > Tools → 创建新工具 → 粘贴 openwebui/tools/computer_use_tools.py 的内容
  2. 将 Tool ID 设置为 ai_computer_use(过滤器正常工作所必需)
  3. 配置 Valves:将 ORCHESTRATOR_URL 设为 Computer Use Server 的内部 URL(Docker compose 下为 http://computer-use-server:8081)
  4. 打开工具的 ⋯ → Share 菜单,并将访问权限设为 Public(授予 group:* 和 user:* 通配符读取权限)——否则只有管理员账户能看到该工具,非管理员用户会看到空工具列表,且不会收到任何错误提示
  5. 前往 Workspace > Functions → 创建新函数 → 粘贴 openwebui/functions/computer_link_filter.py
  6. 启用过滤器:在 Functions 列表中同时切换 Active 和 Global——这是两个独立的开关;如果只启用 Active 而未启用 Global,过滤器会加载,但不会应用于聊天
  7. 在模型设置中,将 Function Calling 设为 Native,并将 Stream Chat Response 设为 On。也可以在 Admin → Settings → Models → Advanced Params 中一次性设置全局参数(function_calling: native、stream_response: true)——这会成为所有模型的 DEFAULT_MODEL_PARAMS。

docker-compose 堆栈会自动处理以上所有事项。

将 Open WebUI 嵌入自己的堆栈时的必要设置

如果在官方 docker-compose.webui.yml 之外运行 Open WebUI——例如使用自己的 compose、Kubernetes、Portainer 或下游仓库——有 四个陷阱会悄无声息地导致 Computer Use 无法工作。这四个问题都曾在我们的生产环境中出现。请按以下顺序检查。

第 1 步 — 本仓库只需要官方上游镜像

安装工具和过滤器后,Computer Use 即可在已发布的 ghcr.io/open-webui/open-webui 上正常工作,无需重新构建任何内容。

过去的情况恰恰相反:仓库中包含八个补丁脚本和一个 Dockerfile,用于将补丁应用到已构建的镜像上;拉取上游镜像时会悄无声息地跳过所有补丁。这些补丁现已移除。它们解决的问题中,有三个已在上游修复;其余问题则以源代码提交的形式存在于一个分叉仓库中,这与运行此集成是两回事。

预览 URL 检测也无需在构建时配置主机——iframe 来源会从模型写入的 URL 中读取,该 URL 来自服务端的 PUBLIC_BASE_URL。

第 3 步 — 两个 URL 设置,两种用途(公开与内部)

v4.0.0: 旧版“必须保持一致的三个 FILE_SERVER_URL 设置位置”这个易错点已消失。现在只有两个位置,分别对应两种不同用途——公开(浏览器可访问)与内部(Docker 本地)。COMPUTER_USE_SERVER_URL 构建参数已在 v0.9.2.0 中移除——fix_preview_url_detection 现在与主机无关(见第 2 步)。

位置用途读取方生产环境(配置域名)本地开发(Docker Desktop)
computer-use-server 容器上的 PUBLIC_BASE_URL 环境变量(docker-compose.yml / .env)公开——写入 /system-prompt 链接,并通过 X-Public-Base-URL 响应头返回给过滤器服务端(公开 URL 的唯一真实来源)https://cu.your-domain.comhttp://localhost:8081
过滤器和工具的阀门 ORCHESTRATOR_URL(由 init.sh 从 open-webui 容器上的 ORCHESTRATOR_URL 环境变量填充)内部——服务端之间获取 /system-prompt;转发 MCP tools/call过滤器和工具(Docker 网络)http://computer-use-server:8081http://computer-use-server:8081

⚠️ 不要将 ORCHESTRATOR_URL 指向你的公开域名。 虽然技术上可行,但这样每个 MCP 请求都会经过浏览器→CDN→Traefik→容器。链路中的任何故障都会导致流在工具调用过程中中断,用户会看到 MCP call failed: Session terminated。请留在 Docker 网络内。

过滤器已不再提供公开 URL 阀门——它会从服务端的 X-Public-Base-URL 响应头读取公开 URL,并将其与提示词一并缓存。一个公开设置,一个内部设置。

另请参阅 docs/openwebui-filter.md。

第 4 步 — open-webui 容器上的四个环境变量

将以下内容复制粘贴到下游 compose 的 environment: 区块中:

services:
  open-webui:
    environment:
      # --- Computer Use required env vars (read by build-time patches) ---
      - CHAT_RESPONSE_MAX_TOOL_CALL_ITERATIONS=200
      - TOOL_RESULT_MAX_CHARS=50000
      - TOOL_RESULT_PREVIEW_CHARS=2000
      # Internal URL of the Computer Use server — seeded by init.sh into both
      # Tool and Filter Valves, and read by the fix_large_tool_results patch.
      # Same Docker network: use the service DNS name.
      - ORCHESTRATOR_URL=http://computer-use-server:8081
变量未设置时的默认值正确设置后的效果
CHAT_RESPONSE_MAX_TOOL_CALL_ITERATIONS256(上游)每轮的工具调用上限;原始仓库设为 200,-1 表示禁用上限。Open WebUI 会将旧版(0.10 之前)的名称 CHAT_RESPONSE_MAX_TOOL_CALL_RETRIES 作为备用值读取。
TOOL_RESULT_MAX_CHARS50000(补丁内置)工具结果超过此截断阈值时,会被截断或上传。0 表示禁用。
TOOL_RESULT_PREVIEW_CHARS2000(补丁内置)截断或上传后,模型可见的预览大小。
ORCHESTRATOR_URL空由 init.sh 填入工具和过滤器的阀门,并由 fix_large_tool_results 补丁读取,作为上传目标。如果为空,超大结果会被静默截断——模型会丢失这些数据。

注意:如果使用的是上游 ghcr.io 镜像,最后三个变量不起作用——它们需要第 1 步中的 fix_large_tool_results。

步骤 5 — 筛选器必须设为全局,工具必须允许公开读取

Open WebUI 为每个函数提供了两个独立开关(is_active 和 is_global),为每个工具提供了两项必需授权(group:* + user:*)。自带的 init.sh 会为你完成这些设置;手动部署或自定义部署通常会漏掉其中一项,然后花上好几个小时纳闷“明明都装好了,为什么什么都不能用”。

资源要切换的设置UI 路径端点原因
筛选器 computer_use_filteris_active = true 且 is_global = trueAdmin → Functions → computer_use_filter → 切换 Active + 切换 GlobalPOST /api/v1/functions/id/computer_use_filter/toggle + .../toggle/globalis_active 只会加载函数;is_global 才会将其应用到每个聊天会话。已启用但非全局时会静默失效,且不会留下任何日志。
工具 ai_computer_use授予 group:* 和 user:* 的访问权限,permission: readWorkspace → Tools → ai_computer_use → ⋯ → Share → PublicPOST /api/v1/tools/id/ai_computer_use/access/update,参数为 {"access_grants":[{"principal_type":"group","principal_id":"*","permission":"read"},{"principal_type":"user","principal_id":"*","permission":"read"}]}没有授权时,只有创建该工具的管理员账号能看到它。非管理员用户会看到空工具列表,且不会收到错误提示。UI 中的“Public”开关会写入两个通配授权;只写入其中一个,会导致部分用户能看到工具、其他用户看不到,具体取决于 Open WebUI 版本。

对照数据库进行验证(自带堆栈使用 Postgres;参见 docker-compose.webui.yml:53):

# Filter flags — expect (t, t):
docker exec <postgres-container> psql -U openwebui -d openwebui -c \
  "SELECT is_active, is_global FROM function WHERE id='computer_use_filter';"

# Tool grants — expect TWO rows (group|* and user|*, both 'read'):
docker exec <postgres-container> psql -U openwebui -d openwebui -c \
  "SELECT principal_type, principal_id, permission FROM access_grant WHERE resource_id='ai_computer_use';"

对于使用 SQLite 的 Open WebUI 部署,将 psql 替换为 sqlite3 /app/backend/data/webui.db,并使用相同的 SQL。

步骤 6 — 一次性验证所有内容
# 1. Env vars reached the container:
docker exec open-webui env | grep -E 'CHAT_RESPONSE_MAX_TOOL_CALL_ITERATIONS|TOOL_RESULT_|ORCHESTRATOR_URL'

# 4. Tool+Filter Valve (Session-terminated trap) — Admin UI is simplest:
#    Workspace → Tools → ai_computer_use → Valves → ORCHESTRATOR_URL
#    Admin → Functions → computer_link_filter → Valves → ORCHESTRATOR_URL
#    → both must be http://computer-use-server:8081 (internal URL, Docker service DNS),
#      NOT your public domain.

# 5. Server env (baked into system prompt AND returned to filter via header):
docker exec computer-use-server env | grep ^PUBLIC_BASE_URL=
# → must be a URL your browser can reach (e.g. http://localhost:8081 for local dev).

# 7. Filter is ACTIVE *and* GLOBAL (see Step 5):
docker exec <postgres-container> psql -U openwebui -d openwebui -c \
  "SELECT is_active, is_global FROM function WHERE id='computer_use_filter';"
# → expect (t, t). Two 't's, not one.

# 8. Tool is public-read with both wildcards (see Step 5):
docker exec <postgres-container> psql -U openwebui -d openwebui -c \
  "SELECT principal_type, principal_id, permission FROM access_grant WHERE resource_id='ai_computer_use';"
# → expect TWO rows: (group, *, read) and (user, *, read).

重新构建镜像后,在浏览器中执行一次强制重新加载(Cmd+Shift+R / Ctrl+Shift+R)。否则浏览器会保留旧的缓存 JS 代码块,让你误以为修复没有生效。

症状 → 出错步骤
症状步骤
HTML 成品在聊天中显示为原始 <iframe ...> 文本1(上游镜像缺少 fix_artifacts_auto_show)
文件链接未自动插入预览 iframe1(缺少 fix_preview_url_detection),或浏览器无法访问 PUBLIC_BASE_URL
每次调用工具都出现 MCP call failed: Session terminated3(工具 Valve 指向公共域名)
工具循环提前中断;显示 “Model temporarily unavailable” 横幅4(未设置 CHAT_RESPONSE_MAX_TOOL_CALL_ITERATIONS)
大型工具输出静默显示为 ...(truncated);模型因此做出错误判断4(未设置 ORCHESTRATOR_URL 或无法访问),或 1(缺少 fix_large_tool_results)
工具循环错误显示原始 Python 异常1(缺少 fix_tool_loop_errors)
非管理员用户的工具列表为空(管理员可以看到)5(工具缺少 access_grant——未设为公开读取)
筛选器在 UI 中显示为“Active”,但预览 iframe / 归档按钮始终未出现5(筛选器 is_global=false——只切换了 is_active=true)
聊天中的文件链接跳转到 404 / 白屏服务器上的 PUBLIC_BASE_URL 与浏览器实际可访问的地址不一致——参见 docs/openwebui-filter.md
重新构建后仍未看到新行为浏览器缓存了旧 JS——执行强制重新加载

安全说明

在可自托管环境中的 Open WebUI 上,已使用 1000+ 用户进行生产环境测试。该项目已不再维护;未修复的问题列于下方。

当前模型
  • Docker socket:服务器需要访问 Docker socket 才能管理沙盒容器。这会授予对主机的重大访问权限——仅在可信环境中运行。
  • MCP_API_KEY:在生产环境中设置一个强随机密钥。若未设置,任何能访问网络端口 8081 的人都可以在容器中执行任意命令。
  • 沙盒隔离:每个聊天会话都在单独的容器中运行,并设有资源限制(2GB RAM、1 CPU)。在 Docker Compose 中,容器使用标准运行时(runc),并共享主机内核。Kubernetes Helm chart 默认使用无 root 权限的 Podman——用户命名空间加 AppArmor,且不使用特权容器;也可以选择使用 Kata Containers,以获得虚拟机监控程序级别的隔离边界。在 Compose 中,gVisor 从未接入。容器默认可访问网络。
  • POSTGRES_PASSWORD:在生产环境中更改 .env 中的默认密码。
已知限制
  • 未经身份验证的文件/预览端点:/files/{chat_id}/、/api/outputs/{chat_id}、/browser/{chat_id}/、/terminal/{chat_id}/——知道聊天 ID 的任何人都可以访问。聊天 ID 是 UUID(难以猜测,但不是真正的安全边界)。
  • 服务器不提供按用户身份验证:MCP 服务信任任何发送有效 MCP_API_KEY 的人。客户端会传递用户身份(X-User-Email),但服务器端不会进行验证。
  • HTTP 标头中包含凭据:API 密钥(GitLab、Anthropic、MCP 令牌)会通过 HTTP 标头从客户端传递到服务器。在 Docker 网络内是安全的,但若要对外开放,请使用 HTTPS。
  • 默认管理员凭据:[email protected] / admin——在多用户设置中请立即更改。
尚未修复的安全问题

本仓库不会处理以下问题:

  • 按会话签名的令牌,用于文件/预览/终端端点(取代作为身份验证凭据的聊天 ID)
  • 通过 Open WebUI JWT 验证进行服务器端用户验证
  • 提供自动 TLS 证书的 HTTPS 支持
  • 对所有工具调用和文件访问进行审计日志记录
  • 为沙盒容器设置网络策略(默认限制出站流量)
  • 密钥管理——将凭据从标头移至服务器端加密存储
  • gVisor(runsc)运行时——可选的容器沙盒功能,以增强隔离性(类似 Claude.ai)

开发

# Build workspace image locally
docker build --platform linux/amd64 -t open-computer-use:latest .

# Run tests
./tests/test-docker-image.sh open-computer-use:latest
./tests/test-no-corporate.sh
./tests/test-project-structure.sh

# Build and run full stack
docker compose up --build

贡献

本仓库已归档,不接受贡献。请参阅 CONTRIBUTING.md。

社区

许可证

本项目采用多许可证模式:

  • 核心部分(computer-use-server/、openwebui/、settings-wrapper/、Docker 配置):功能源许可证 1.1 版,未来采用 Apache 2.0 许可证(FSL-1.1-Apache-2.0)。可免费使用、修改、分叉、再分发,并在内部自托管。每个版本发布两年后会自动转换为 Apache 2.0。若要提供与我们的付费版本竞争的托管服务或嵌入式服务,则需要签订商业协议。
  • 我们的技能(skills/public/describe-image、skills/public/sub-agent):MIT
  • 第三方技能:请参阅各自的 LICENSE.txt 文件或原始来源。

必须注明出处:包含“Open Computer Use”以及指向本仓库的链接。

详情请参阅 NOTICE。关于第三方依赖项许可证(PyMuPDF AGPL、Anthropic Skill License、Apache 2.0 bundles 等),请参阅 THIRD-PARTY-LICENSES.md。

评论

支持 Markdown

第一次接触 MCP?

从协议是什么,到在客户端里装上第一个服务,这几条回答覆盖了大多数入门问题。

一个开放协议,规定了 AI 应用如何以统一方式连接外部工具与数据源。客户端负责与模型对话,MCP 服务负责提供工具、资源和提示模板,两者通过标准消息通信,同一个服务可以被不同客户端复用。