OpenHands 是 GitHub 上最火的自托管 AI 编程 agent 平台，没有之一。截至 2026 年 7 月底，82,338 颗星、10,545 个 fork、MIT 协议、主力 TypeScript，2024 年 3 月 13 日立项，最新 release 是 cloud-1.47.1。它干的事一句话能说明白：给你一个自托管的开发者控制中心，把 OpenHands、Claude Code、Codex、Gemini 这些 coding agent 集中到一个常驻的工程团队里--本地、Docker、VM、云端任选后端，agent 跑在哪台机器都行，再配上 Slack/GitHub/Linear 自动化，issue 来了自动拆任务、定时出报告发 Slack。控制台叫 Agent Canvas，是整个系统的前端入口，背后由 Agent Server（一个跑多 agent 的 REST API）和 Automation Server 两块驱动，整个项目目前处于 beta 阶段。
解决什么痛点
用过 coding agent 的人都撞过这几堵墙。一是 agent 散，Claude Code 在终端跑、Codex 在 IDE 里跑、OpenHands 在自家 UI 里跑，切换要换上下文、换模型 key、换项目目录，工程师脑子和窗口都在跳。二是 agent 不常驻，笔记本一关 agent 就停，长任务没法接，Slack 触发、GitHub webhook 触发更无从谈起，所谓「AI 工程团队」其实只是几把临时工具。三是数据合规，闭源 SaaS 把你的代码、issue、内部文档全传到对方服务器，企业、金融、医疗这类根本不能用。四是自动化断档，想让 agent 在 issue 创建时自动拆解、定时生成代码审查报告，SaaS 给你一个固定工作流，改不动也接不到自家 Linear/Notion。OpenHands 的解法是把 agent 后端拉回你自己的基础设施：本地、Docker、VM、企业机房、私有云都行，前端用同一个 Agent Canvas 统一调度，agent 在哪跑、数据留哪，全你说了算；自动化用 Agent Server 加 Automation Server 原生打通 Slack、GitHub、Linear、Notion，定时和 webhook 两种触发都支持。
一个 Canvas 通吃 OpenHands/Claude Code/Codex/Gemini
这是它和单一 agent 工具最大的分野。Agent Canvas 出厂跑开源 OpenHands agent，但通过 ACP（Agent-Client Protocol，agent 客户端协议）兼容任何第三方 agent：Claude Code、Codex、Gemini 都能挂进来，你不用为每个 agent 单独开一套 UI、单独管 key。实际用法是同一个面板里今天用 OpenHands agent 跑代码审查，明天切到 Claude Code 写新功能，后天用 Codex 改 bug，agent 之间切换不丢上下文--这在多 agent 对比、能力选型场景里特别值钱。架构上每个 Agent Server 跑在单个 host/port 上负责多 agent 调度，Agent Canvas 前端能同时连多个 Agent Server，团队共用一台做依赖升级和 code review，个人用本地那台做私密项目，一个面板切来切去。ACP 是个开放协议，README 明确写「any agent with ACP」，理论上任何实现 ACP 的 agent 都能接，不局限于官方列的这四种。
四种后端随切：本地、Docker、VM、云
后端层是 OpenHands 自托管的核心。它把「agent 跑在哪」和「你用哪个 agent」解耦，agent server 能装在四个地方：直接装在笔记本上（小心，agent 拿到文件系统全权限）、专用机比如 Mac Mini、云上 VM、或者 OpenHands Cloud/Enterprise 托管基础设施。这带来两个直接好处。一是数据不出域，敏感项目跑在本地或内网 VM，代码、issue、token 全程不离你家机器。二是「常驻」真正成立，把 agent 装在云上 VM 或 Mac Mini，笔记本一关 agent 照跑，Slack 触发、GitHub webhook 触发随时响应。官方在 README 里最推荐的就是「装在云上服务器」，因为这样 agent 能 7×24 在线，第三方服务才能稳定回调。前端的 Agent Canvas 是同一个，无论后端在哪，UI 体验一致，切换后端不丢会话。安全提醒官方也写在 README 里：直接装在裸机上 agent 拿到文件系统全权限，生产环境强烈建议上 Docker sandbox 隔离，把 PROJECTS_PATH 限定到你愿意暴露的项目目录。
自动化：Slack/GitHub/Linear 全链路
光能跑 agent 还不够，OpenHands 把「自动化」做成了系统级一等公民。Automation Server 和 Agent Server 配对，让你设定「agent 在什么时候、被什么事件触发」：定时 schedule 或 webhook 事件都支持。预置集成里 Slack、GitHub、Linear、Notion 是一等公民。典型链路是 GitHub issue 创建 -> 触发 OpenHands agent 自动拆解成任务 -> 拆完发 Slack 通知；或者定时跑 code review、依赖升级、报告生成，结果直接落到 Notion 或 Slack 频道。这把 coding agent 从「我打开它才干活」变成「事件来了它自己干」，是它和 Cursor、Cline 这类纯 IDE 内 agent 的本质区别--后两者没有常驻 server、没有自动化引擎、没有跨服务编排能力。Agent Canvas 官方截图里展示的就是 automation preview 界面，可见这块是主推场景。
三分钟上手
# 方式一：npm 直装（最快，但 agent 直接跑在本机，有文件系统全权限）
# 前置：Node.js 22.12.x+，uv
npm install -g @openhands/agent-canvas
agent-canvas
# 打开 http://localhost:8000
# 方式二：Docker sandbox（推荐，agent 隔离在容器里）
# 前置：Docker Desktop 或 Docker Engine
export PROJECTS_PATH="$HOME/projects" # 愿意让 agent 访问的项目目录
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.6.1
# 打开 http://localhost:8000/canvas
# 验证：UI 起来后加一个后端，填 LLM key，
# 跑一句「在当前目录建个 hello.txt 写入 hello」，看 agent 是否真动你的文件。要拆开跑也行：agent-canvas --frontend-only 只起静态前端加 ingress，--backend-only 只起 agent server 加自动化后端，分布式部署时用得上。源码安装走 git clone https://github.com/OpenHands/agent-canvas.git 然后 npm install && npm run dev。
适合谁 + 四个踩坑
适合：要自托管 coding agent 做日常自动化的开发团队（issue 拆解、依赖升级、报告生成）；有合规要求、数据必须留内网的企业；想在一个面板里对比 OpenHands/Claude Code/Codex/Gemini 能力的 AI agent 实验者；想要 7×24 常驻 agent 接 Slack/GitHub webhook 的小团队。
踩坑记四条。一是裸装等于给 agent 文件系统全权限，README 里官方用 WARNING 显式标红，生产千万别图省事 npm install -g 就上，老老实实走 Docker sandbox 把 PROJECTS_PATH 圈死。二是 Node 版本，必须 22.12.x 或更高，老 Node 直接跑不起来，先 node -v 确认。三是多后端切换的理解成本，Agent Canvas 能连多个 Agent Server，但每个 server 的模型 key、项目目录、隔离边界是分开的，别以为切后端就是切模型，其实是切了一整套环境，心里要有数。四是它还在 beta，README 顶部明确标 status-beta，npm 包是 @openhands/agent-canvas、README 里 Docker 镜像版本写的是 1.6.1，API 和配置项可能还会变，生产接入前盯着 changelog。另外 Cloud 和 Enterprise 是商业产品，和开源 MIT 的 agent-canvas 不是一回事，别混。
和竞品比
和 Devin 比，Devin 是闭源 SaaS，你的代码、任务、内部数据全上传到对方服务器，自动化工作流是它给的固定模板；OpenHands 是 MIT 开源自托管，后端装哪、数据留哪、自动化怎么编排全你定，合规和可控性是本质差距。和 Cursor、Cline 这类 IDE 内 agent 比，它们是「我打开 IDE 才干活」的工具，没有常驻 server、没有 webhook 触发、没有 Slack/GitHub/Linear 编排能力；OpenHands 是控制中心加自动化引擎，定位是「常驻工程团队」不是「编辑器插件」，能接的 agent 也包括 OpenHands/Claude Code/Codex/Gemini 全家桶，不局限于某一个。和纯 OpenHands agent 比，Agent Canvas 把它从「单一 agent」升级成「多 agent 编排加自动化平台」，加了 ACP 协议层，能挂任意第三方 agent。一句话：要在 IDE 里写代码用 Cursor/Cline，要 Devin 式自动化但要自托管和可控，选 OpenHands。
参考来源
- OpenHands GitHub 仓库（82,338 star，MIT，TypeScript）：https://github.com/All-Hands-AI/OpenHands
- Agent Canvas 官方文档（后端切换 / 自托管）：https://docs.openhands.dev/openhands/usage/agent-canvas/backends
- 预置自动化（Slack/GitHub/Linear/Notion 集成）：https://docs.openhands.dev/openhands/usage/agent-canvas/prebuilt-automations
- ACP 兼容 agent 接入说明：https://docs.openhands.dev/openhands/usage/agent-canvas/acp-agents
- npm 包 @openhands/agent-canvas：https://www.npmjs.com/package/@openhands/agent-canvas
- 社区 Slack 频道：https://go.openhands.dev/slack