OpenHands Agent Canvas

「自托管的 agent 控制中心」 —— 官方 README 现在给它起的名字是 Agent Canvas，

模型与开放条件

官方口径是「任何 LLM」，但这是特性表里的一句营销式表述，本站未取到完整 provider 清单。 已核验的部分：README 特性表有一行 "Bring your own model — Use with any LLM"， 指向官方文档 usage/settings/llm-settings#llm-profiles（LLM profiles，可配多套并存）。 ⚠ 未核验：具体支持哪些 provider（是否走 LiteLLM 一类的网关层）、 本地量化模型能否接、以及「any LLM」在工具调用与 structured output 上的对齐度。 这一项对本对象尤其重要，因为它同时是别人的调度层 —— 「Codex / Claude Code 跑在它上面」时，能用哪些模型由那个 agent 自己决定，不由Canvas 决定。

运行位置

四种官方部署形态并存，这是本对象最有实用价值的部分（README 四个Option 全核验）： Option 1 无沙箱本地跑：npm install -g @openhands/agent-canvas 然后 agent-canvas， 起完整本地栈，要 Node.js 24+ 与 uv；可用 --frontend-only / --backend-only 拆开跑。 Option 2 Docker 沙箱：docker run 官方镜像，需预先准备 PROJECTS_PATH 宿主目录， agent 可访问该目录下的项目。 Option 3 每会话独立容器：OH_CONVERSATION_RUNTIME=docker agent-canvas， 每次新会话起自己的容器与 Agent Server，适合并发跑多个 agent； 官方说明容器会挂载会话的 workspace 与持久化状态，容器替换后文件与对话历史仍在。 Option 4 从源码跑：clone + npm install + npm run dev。 入口统一在 http://localhost:8000（Docker 镜像是 /canvas）。 后端可远程切换：官方说 Agent Server 可跑在笔记本 / Mac Mini / 云上 VM / OpenHands Cloud，Canvas 前端可在多个 Server 间切换 —— 这条是它作为「调度层」的核心能力。

本地文件

本地文件访问范围由你选的部署形态决定，官方把这个变量讲得很清楚。 无沙箱形态：README 两次打 WARNING—— "This runs the agent-server directly on the machine you're installing on — the agent will have full access to your filesystem!" Docker 形态：访问范围收敛到 PROJECTS_PATH 挂载的目录。 每会话容器形态：官方提示共享同一宿主工作区的会话仍会共用同一批文件， 建议用独立目录或 worktree 避免冲突编辑。 ⚠ 后端远程时（云上 VM / Cloud），你的仓库要么在远端、要么靠工具从本地取 —— 具体同步机制本站未核验。

关机后的任务

这是本对象最突出的强项，也是它与其他 harness 站对象最大的差别。 官方 README 明确：把 agent 跑在云上服务器的最大好处是 "allows your agents to continue running even when your laptop is shut"， 且更容易通过 Slack / GitHub / Datadog 等第三方服务触发。 配套有独立仓 OpenHands/automation（核验2026-10-01：Python，MIT，32★，活跃） 提供定时（schedule）与 webhook 事件触发两种触发方式， 官方特性表列了可集成的第三方：Slack、GitHub、Linear、Notion。 对照本站其余对象：OpenAI Agents SDK、Deep Agents、Codex SDK 的 thread 状态都在 自己进程 / 自己机器上，关了就没了；这是唯一把「关掉笔记本后 agent 仍在跑」当卖点做的。

工具与扩展

工具面来自它所调度的那个 agent，而不是 Canvas 自己。 官方原文明确它能跑 "OpenHands, Claude Code, Codex, Gemini, or any ACP-compatible agent" —— 即通过 Agent Client Protocol（ACP）接入第三方 agent。 真正的工具/agent 定义在 OpenHands/software-agent-sdk （官方职责表：agents, tools, conversations, workspaces, events）。 ⚠ 本对象没有以 MCP 为接口（README 与仓库结构里未见 MCP 相关表述）—— 它用的是 ACP。这两个协议的定位差异本站未展开，标记为未核验。

上下文与记忆

⚠ 这一维度是本对象的重大信息缺口，本站明确记为未知。 已核验的只有持久化方向：automation 仓负责 run history， 每会话容器形态下官方说「workspace files and conversation history survive container replacement」。 但对话上下文长了之后如何压缩、摘要或落盘，README 与本文所引文档均未说明， software-agent-sdk 的具体上下文策略本站未核验。 按本站主张「状态 ≠ 上下文」：它把「状态」做得很完整（定时触发 + run 历史 + 容器可替换）， 但「上下文」这一侧本站拿不到证据，不能因为它有持久化就推断它有上下文管理。

权限与限制

这是本对象最需要认真读的部分，也是它官方做得最细的一块。 沙箱：见 local_files —— 官方提供 Docker 沙箱与每会话独立容器两种收敛手段， 但也明确提供了无沙箱形态并两次挂 WARNING。 认证：docs/SELF_HOSTING.md（核验 286行）给的是 API key 机制而非用户体系： 生成 key 用 openssl rand -base64 32 赋给 LOCAL_BACKEND_API_KEY； --public 模式下 key 不烘进前端，用户首次打开 UI 要手动粘贴 key 才能用， 之后每个 /api/* 请求都要带 X-Session-API-Key 头。 默认绑定是 loopback-only（127.0.0.1），官方说明这是为了让自动注入的 session key 不被局域网其他机器拿到；要监听 0.0.0.0 时 key 不再注入、改用同样的 API-key 输入界面。 官方还提醒用 export 而不是命令行参数传 key，避免出现在 ps aux 进程列表里。 暴露到公网时官方另有防火墙要求（Cloud Firewall / AWS Security Group / GCP firewall rule）。 ⚠ 未核验：多用户与权限分级（这是它作为团队级平台最可能被追问的点， SELF_HOSTING.md 里的证据集中在「怎么保护单个 key」，未见用户/角色体系）。

适合什么任务

适合：要把agent 放到自己服务器上 7×24 跑；需要定时或 webhook 触发（Slack / GitHub / Linear / Notion）； 想用一个界面统管多种agent（含Codex、Claude Code、Gemini 等 ACP 兼容的）； 需要 per-conversation 隔离容器；团队里前端/平台与 agent 运行时分离部署。 不适合：只想要一个轻量库把agent 嵌进自己的 Python 进程（用 software-agent-sdk 或 OpenAI Agents SDK）； 单机临时用一下（它是一整套栈，不是库）； 需要细粒度多用户权限与审计（本站未核验其能力）。

本页由 ai-coding-agent-atlas 数据层生成（CC BY 4.0）。 方法论与坐标系定义见仓库内 METHODOLOGY.md。