80.7k Star！OpenHands自托管Agent控制台：多Agent管理、自动化工作流与安全实践

你可能已经在用 Claude Code、Codex、Gemini CLI 这类编码 Agent 了。

单人、单项目、盯着一个终端跑，问题不大。麻烦通常出在后面：一个 Agent 在本机改代码，一个 Agent 想放到 VM 上长期跑，PR 审查、Issue 拆分、Slack 通知又希望自动触发，还要管 API Key、文件系统权限和团队共享。这时，普通 CLI 就开始吃力。

Image

今天要推荐的是 OpenHands（解放双手），一个自托管的编码 Agent 控制台。目前 OpenHands 主仓在 GitHub 上有 80.7k+ Star。

Image

和普通 CLI Agent 有什么不同

普通 CLI 更适合当前终端里的单次任务。OpenHands Agent Canvas 管的是一组运行位置和一组 Agent：本机、Docker、VM、公司内网机器、OpenHands Cloud / Enterprise，都可以作为 Backend。

Image

OpenHands 主要通过 Agent Canvas 来用：一个浏览器 UI 加后端服务。它默认可以跑 OpenHands 自家的 Agent，也可以通过 Agent Client Protocol，也就是 ACP，接入 Claude Code、Codex、Gemini CLI 或其他兼容 ACP 的 Agent。

Image

Backend 就是一个 Agent Server 加上它操作的 workspace。所有对话、设置、LLM 配置、MCP Server 和自动化，都跟当前选中的 Backend 绑定。切换 Backend 时，这些配置也一起切过去。

Image

所以，偶尔让 AI 改一个函数，CLI 足够了。OpenHands 更适合把 Agent 长期跑起来，比如自动 PR review、依赖更新、监听仓库事件、处理 Slack 触发、在远程机器上持续执行。

Agent Canvas：多个 Agent，一个控制面

你可以本机开一个 Backend 做日常小改动，在 VM 上开一个 Backend 跑耗时任务，再给团队共享一个后端处理 PR review。Canvas 前端负责连接和展示，Agent Server 负责会话、文件、命令和工具调用。

这里也有个限制：代码还在迁移，OpenHands Agent 和 Agent Server 的源码在 OpenHands/software-agent-sdk，Agent Canvas 的源码在 OpenHands/agent-canvas。看版本时要分清主仓 Release、Agent Canvas npm 包和 Agent Server 镜像。

Automations：让 Agent 接进工作流

Agent Canvas 支持 cron 定时任务，也支持 GitHub、Linear、Slack、自定义 Webhook 这类事件触发。预置工作流包括 GitHub PR Review Assistant、GitHub Repository Monitor、Slack Channel Monitor。

Image

以 GitHub PR Review Assistant 为例，你需要先给后端配置 GitHub 访问权限，再从 Automate里启动 PR review 工作流。PR 审查至少需要 Contents、Issues、Pull requests 相关权限；如果要看 CI，再补 Actions 或 Checks 只读权限。

Image

不过权限别给太大。GitHub token 优先选择 fine-grained personal access token，只给选定仓库授权，并设置过期时间。

ACP Agent：不被单一 Agent 绑定

ACP 是 Agent Client Protocol。

在 Agent Canvas 里，接入 ACP Agent 时，Agent Server 会启动外部 Agent 的 CLI 子进程，通过 stdio 上的 JSON-RPC 跟它通信。外部 Agent 自己管理模型、工具和执行逻辑，Canvas 负责发消息和展示结果。

默认命令包括：

npx -y @agentclientprotocol/claude-agent-acp  
npx -y @zed-industries/codex-acp  
npx -y @google/gemini-cli --acp

团队已经在用 Claude Code 或 Codex 的话，可以把它们接到 Canvas 里，用同一套界面、后端和自动化去管理。多人使用时，凭证、日志、运行位置都按 Agent 隔开，不用挤在一台机器上。

安装和自托管

最短路径是 npm。需要 Node.js 22.12 或更高版本、npm和 uv：

npm install -g @openhands/agent-canvas  
agent-canvas

默认会启动到 http://localhost:8000。如果想拆开前端和后端，可以用 agent-canvas --frontend-only和 agent-canvas --backend-only。

如果要放到 VM 或团队能访问的机器上，建议使用 public 模式，并设置强随机的 LOCAL_BACKEND_API_KEY：

export LOCAL_BACKEND_API_KEY="<choose-a-strong-secret>"  
agent-canvas --backend-only --public

Docker 也能跑。固定到 1.1.0可以这样：

mkdir -p ~/projects ~/.openhands  
docker run -it --rm -p 8000:8000 -v ~/.openhands:/home/openhands/.openhands -v ~/projects:/projects ghcr.io/openhands/agent-canvas:1.1.0

Agent 能访问什么，跟你挂进去的目录直接相关。不要为了省事把整个 home 目录、密钥目录、公司资料盘都挂进去。

权限风险别跳过

都说本地部署更安全，其实只对了一半。

本地部署确实能让代码和数据留在自己的机器或内网里。但 Agent Server 可以读写宿主机文件系统、执行 shell 命令、访问网络、存储 secrets。

工具调用安全风险分层：按风险等级匹配不同的控制策略

工具调用安全风险分层：按风险等级匹配不同的控制策略

如果你用无沙箱方式直接跑 agent-canvas，或者从源码跑 npm run dev，Agent Server 会直接跑在安装机器上，Agent 将拥有完整文件系统访问权限。

建议先卡几条硬规矩：

  • • 本机试用时，只在明确的项目目录里工作；
  • • Docker 方式只挂载需要处理的目录；
  • • VM 暴露到公网前必须使用 --public和强 LOCAL_BACKEND_API_KEY；
  • • 公网访问要加 TLS、反向代理、VPN、ngrok OAuth 或其他网络访问控制；
  • • 给 GitHub、Slack、Linear 这类集成配置最小权限 token，并设置过期时间；
  • • 把 .openhands、后端持久化目录、API Key 当成敏感资产看待。

Agent 能改代码，也能删文件、提交错误内容、把敏感信息写进日志或外部服务。自托管只是把控制权交回给你，风险还得自己兜住。

写在最后

如果你只是想让 AI 在当前项目里改几个文件，Claude Code、Codex CLI、Gemini CLI 直接用就行，路径短，心智负担也小。

如果你已经把编码 Agent 当成长期后台工人用，想在本机、VM、Docker、云后端之间切换，又想把 PR、Issue、Slack、Webhook 接进工作流，OpenHands 值得单独看一眼。

它现在还是 beta，版本线分散，源码位置还在迁移，这些都要心里有数。企业级权限、审计、团队治理也需要结合 Cloud / Enterprise 或自己的基础设施来做，不能指望开源版一键兜底。

对一个开源、自托管、能管多个 Agent 的工具来说，这个完成度已经值得试一下。

项目地址：https://github.com/OpenHands/OpenHands