用 AI 编程 Agent 的人迟早会碰到同一个瓶颈：它跑在你笔记本上。

你把一个重构任务丢给它，它开始工作。这时候你要出门、要开会、要合上盖子——任务就断了。回来重新启动，上下文可能还得重新喂一遍。

如果想让 Agent 常驻干活，就得给它找个一直开着的地方。找台 Mac Mini，租个云服务器，然后你会发现：装好之后怎么管？多个 Agent 怎么调度？怎么让 Slack 里的消息触发它干活？

OpenHands Agent Canvas 就是回答这一层问题的：一个自托管的开发者控制台，用来跑编程 Agent 和自动化。

它解决什么

官方给它的定位

OpenHands Agent Canvas 把你的编程 Agent 变成一支自托管、常驻的工程团队。

它是启动对话、自动化日常任务的开发者控制中心——比如生成报告发布到 Slack，或者把 GitHub issue 自动拆解成任务。

默认跑在你自己机器上，但可以连接多种"Agent 后端"：Docker 容器、VM、或者公司内部基础设施。也可以选择跑在 OpenHands Cloud 或企业版基础设施上。

关键是最后一句：它开箱即用地跑开源 OpenHands Agent，但也能用 Claude Code、Codex 等任何第三方 Agent。

五个核心能力

能力 说明
自托管方式随你 本地、Docker、VM，或任何能跑 agent server 后端的地方
后端可切换 在本地、远程、云端 Agent 之间切换，不中断当前工作
创建自动化 建立与 Slack、GitHub、Linear 等集成的自动化流程，按时计划执行或响应 webhook
对接现有工具 与 Slack、GitHub、Notion 等第三方服务连接，自动化工作流
自带模型 可用任意 LLM

最后一条"可与任意 Agent 共用"值得单独说：支持 OpenHands、Claude Code、Codex、Gemini，或任何实现了 Agent-Client Protocol（ACP）的 Agent。

五个核心能力

一个挺有意思的架构选择

Agent Canvas 基于 OpenHands Agent Server ——一个 REST API，能在单台机器上跑多个 Agent。每个 Agent Server 跑在一个 host/port 上；Agent Canvas 可以连接多个 Agent Server，并在它们之间轻松切换。

这带来一种实际可行的用法，README 里举了例子：

你可以和团队共用一个 Agent Server，跑代码评审和依赖更新这类任务；同时把个人 Agent 跑在自己笔记本上。

这是"后端可切换"的真实价值——不是炫技，而是让团队协作和个人实验共存。

Agent Server 可以跑在：

  • 你的笔记本上（官方特别提醒：注意安全）
  • 一台专用机器，比如 Mac Mini
  • 云上的虚拟机
  • OpenHands Cloud 里

通常会配一个 Automation Server，用来设置按时计划运行或响应事件的 Agent。

三种部署路径

方式一：不用沙箱

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

前提是 Node.js 22.12.x 或以上，以及 uv。

README 里用 WARNING 标了一句必须留意的话：这种方式把 agent-server 直接跑在你安装的那台机器上——Agent 会拥有完整的文件系统访问权限。

也可以拆开跑：agent-canvas --frontend-only 只启静态前端和入口，agent-canvas --backend-only 只启 agent server、自动化后端和入口。

方式二：用 Docker 沙箱

需要 Docker，以及一个存放待访问项目文件夹的宿主机目录（PROJECTS_PATH），启动容器前先创建好。

export PROJECTS_PATH="$HOME/projects"
mkdir -p "$PROJECTS_PATH" "$HOME/.openhands"
docker run -it --rm \
  -p 8000:8000 \
  -v "$HOME/.openhands:/home/openhands/.openhands" \
  -v "${PROJECTS_PATH}:/projects" \
  ghcr.io/openhands/agent-canvas:1.22.0

Agent 只能访问 PROJECTS_PATH 下的项目。Windows 的等价命令在 README.windows.md 里。

方式三：从源码运行

git clone https://github.com/OpenHands/OpenHands.git
cd OpenHands
npm install
npm run dev

同样注意：这种方式 Agent 也能完整访问文件系统。

npm / 源码启动方式访问 http://localhost:8000，Docker 镜像访问 http://localhost:8000/canvas。可以在 UI 里直接添加更多后端。

三种部署路径

一个必须记住的安全提醒

完整沙箱 vs 直接跑在宿主机，这个选择不是小事。

Agent 能执行任意命令、读写任意文件。直接跑在宿主机上意味着——它能碰到的和你能碰到的一样多。ssh 密钥、云凭证、浏览器配置、其他项目，全在它的可达范围内。

如果只是先玩玩，用 Docker 沙箱。如果真要长期跑，官方建议放到云服务器上并做安全加固（SELF_HOSTING.md 里有细节）。

谁适合用它

适合：

  • 想让编程 Agent 常驻运行，不受本地机器开关机影响
  • 团队共用 Agent 做代码评审、依赖更新这类固定任务
  • 希望通过 Slack / GitHub / webhook 触发 Agent 干活
  • 已经用 Claude Code 或 Codex，想要一个统一的控制台管起来
  • 有闲置机器或愿意租一台云服务器

不太适合：

  • 只是偶尔让 AI 帮忙写几行代码
  • 完全没有服务器运维经验，也不想学
  • 对让 Agent 访问文件系统这件事感到不安（这个顾虑很合理）

说点实在的

这个项目的思路是把 Agent 从"一个工具"变成"一个基础设施组件"。既然 Agent 能持续干活，那它就该有个一直开着的地方、一套调度机制、和现有工具的对接方式——这听起来更像在描述部署一个服务，而不是装一个软件。

另外那个"自带模型 + 任意 Agent"的设计挺务实。它没打算把你锁在 OpenHands 自己的 Agent 上，而是做了一层控制面。在这个 Agent 种类快速分化的阶段，这种定位比"我全都有"更站得住。

安全隐患也值得认真对待。README 反复用 WARNING 标出来是有原因的——能执行命令的 Agent，权限边界就是你自己的权限边界。

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