OpenHands Agent Canvas：把多个编码代理收进一个自托管控制台

它解决的是多代理时代的碎片化问题

OpenHands 这个仓库的 README 现在主推的不是单个编码代理，而是一个叫 Agent Canvas 的控制中心。它解决的问题很具体：当你的日常开发同时涉及 OpenHands、Claude Code、Codex、Gemini 这些代理时，每个代理都有自己的启动方式、会话界面和后端配置，切换起来很割裂。Agent Canvas 把这些代理统一到一个自托管的界面里，你可以从同一个前端连接本地、Docker、虚拟机或公司内部网络的多个代理后端。它默认在你自己的机器上运行，数据不出你的控制范围，这点对在意代码隐私的团队有吸引力。文档明确说它面向的是“把编码代理变成一支永远在线的工程团队”这种使用方式，所以它的目标用户不是偶尔跑一次脚本的人，而是把代理当日常生产力工具、并且愿意自己维护基础设施的开发者。

架构：前端、后端与可插拔的 ACP 代理

从 README 的架构描述看，Agent Canvas 由前端和 agent-server 后端组成，前端负责会话和自动化配置，后端负责实际执行代理。它通过 Agent-Client Protocol（ACP）与第三方代理通信，这意味着只要代理实现了 ACP，就能接入，不限于 OpenHands 自家的代理。这种设计把代理执行和界面控制解耦了。你可以让团队共享一个跑在服务器上的 agent-server 做代码审查和依赖更新，同时自己笔记本上跑个人代理，两者从同一个 Canvas 前端切换。文档强调“可以在多个不同环境运行后端”，这背后是一个关键取舍：统一入口不意味着统一运行时，每个后端仍然有独立的资源限制、网络访问和文件系统权限。好处是灵活，坏处是你得自己管理这些后端的生命周期，Canvas 本身不负责编排它们。

三种安装路径，权限边界完全不同

README 提供了三种安装方式，它们的权限模型差异很大。第一种是全局 npm 安装，命令是 npm install -g @openhands/agent-canvas 然后运行 agent-canvas，文档明确警告这种模式“代理会完全访问你的文件系统”，因为它直接跑在你安装的机器上。第二种是 Docker 沙箱，通过 docker run 挂载两个卷：一个是 $HOME/.openhands 存配置，另一个是 $PROJECTS_PATH 作为代理能访问的项目目录。这种方式把代理限制在指定目录里，比无沙箱模式安全得多，但前提是你提前建好 PROJECTS_PATH 并理解挂载语义。第三种是从源码跑，git clone 后 npm install && npm run dev，同样有完整文件系统访问的警告。三种方式最终都访问 localhost:8000，Docker 镜像的路径是 /canvas，npm 和源码是根路径。选哪种不光是便利性问题，直接决定了代理的权限边界在哪里。

自动化：把 Slack、GitHub 接进代理工作流

Agent Canvas 不只是会话界面，它内置了自动化能力。文档提到可以创建 automations 和 workflows，集成 Slack、GitHub、Linear 等工具，按计划触发或响应 webhook 事件。一个给出的例子是自动生成报告并发布到 Slack，另一个是自动把 GitHub issue 分解成任务。这意味着你可以让代理在后台持续运行，而不是等人打开界面。这种设计把代理从交互式工具变成了后台服务，适合处理重复性工作，比如依赖更新、定期代码扫描。但要注意，自动化依赖 webhook 和外部服务，这意味着你的 Canvas 实例必须能被那些服务访问到，要么部署在公网服务器，要么用内网穿透。README 提到在云端服务器上运行能让代理在笔记本关闭后继续工作，也更容易被 Slack、GitHub、Datadog 触发，这实际上是在说：自动化能力的前提是你要有一个常驻的、可达的部署环境。

模型与代理的开放性：自带模型，自带代理

Agent Canvas 支持“bring your own model”，你可以用任何 LLM，不绑定 OpenHands 默认的模型提供商。这一点和它支持任意 ACP 代理是配套的：模型、代理、后端三者都是可替换的。文档里提到 LLM profiles 的设置，说明你可以在 Canvas 里配置多个模型配置，按需切换。这种开放性对团队有利，比如开发用便宜的模型跑批量任务，复杂推理用更强的模型。但代价是配置复杂度上升，你需要自己管理 API key、模型参数和不同代理对模型的要求。OpenHands 自家代理开箱即用，第三方代理可能需要额外的 ACP 适配配置。从文档看，Canvas 本身不限制你用谁，但它也不替你处理不同代理之间的行为差异。

一个真正的限制：安全责任全在你身上

最明显的限制是安全模型完全依赖部署者。无沙箱安装方式直接给代理文件系统的完整访问权，文档用了感叹号警告。即使 Docker 沙箱模式，也只是限制了卷挂载的目录，代理在容器内仍然有那个目录的读写权限。如果你把 PROJECTS_PATH 设成 $HOME，那和直接跑在宿主机上区别不大。另一个限制是，Agent Canvas 的设计假设你有能力维护多个后端，文档提到可以连接 Docker、VM 或公司基础设施，但没给出这些后端的资源隔离或安全加固的细节，只指向 SELF_HOSTING.md 说“特别注意安全加固”。这意味着对于不熟悉容器和网络配置的用户，很容易把代理暴露在过度宽松的权限下。如果你只是偶尔用代理改几个文件，这个控制中心的运维成本可能超过它带来的便利。

对比：它和直接跑 CLI 代理的差异

一个直接的替代方案是继续用各个代理自带的 CLI，比如 Claude Code 的命令行或 Codex 的终端界面。差别在于，CLI 是单代理、单会话、单机器，你手动启动、手动看输出。Agent Canvas 是把这些代理包在一个统一的前端里，加上自动化调度和 webhook 触发。CLI 方式没有控制中心，但也没有额外的 Node.js 运行时要求，不需要维护 Canvas 实例。另一个替代是 OpenHands 之前的单体应用形态，但当前仓库已经转向 Canvas 作为主推产品，说明项目方认为控制中心是更合适的方向。对用户来说，选择本质上是：你愿意付多少运维成本来换取统一管理和自动化。如果只是偶尔跑一次代理，CLI 更轻；如果你要多个代理协同、定时任务、团队共享，Canvas 的价值才体现出来。

维护与升级：版本节奏快，但依赖明确

仓库最近的发布记录显示 v1.14.0、v1.15.0、v1.16.0 分别在 2026 年 8 月 17 日、21 日、27 日发布，一周内三个版本，节奏相当快。这意味着你如果长期使用，需要跟上更新，否则可能错过 bug 修复或 ACP 协议兼容性调整。安装方式里 Docker 镜像标签是 ghcr.io/openhands/agent-canvas:1.16.0，说明你需要手动更新镜像版本。npm 全局安装的方式则用 npm update 来升级。许可证在仓库信息里是 unknown，README 没有提到 license 细节，这一点在采用前需要向项目方确认，特别是如果你打算在公司内部部署。依赖方面，npm 方式要求 Node.js 22.12.x 或更高，加上 uv 用于跑 agent server，这些是硬性前提。整体维护成本不算低，但也不算离谱，前提是你习惯用容器和包管理器。

编辑结论

OpenHands Agent Canvas 适合已经使用多个编码代理、希望统一入口和自动化日常任务的个人开发者或小团队，尤其是愿意自己维护 Node.js 和 Docker 环境的人。不适合只用一个代理、不想接触命令行、或者对代理访问文件系统权限极其敏感的用户，因为无沙箱安装方式会让代理直接读写你的文件。采用前先确认你的 Node.js 版本满足 22.12.x 或更高，准备好 uv，并仔细阅读 docs/SELF_HOSTING.md 中关于安全加固的部分。如果你打算在云端长期运行，务必先配置好 PROJECTS_PATH 的隔离目录和 Docker 沙箱，否则代理的权限边界会非常模糊。

官方来源

1. Official documentation
2. Official README
3. Project repository
4. Release notes