核心用法
Canvas OS 是一套基于 OpenClaw Canvas 面板的本地应用平台方案，允许开发者构建、存储和运行富视觉交互应用。其核心架构遵循"Agent 即操作系统、Canvas 即窗口、应用本地构建运行"的哲学。
主要工作流程：
1. 应用开发 — 在 ~/.openclaw/workspace/apps/[app-name]/ 目录下创建自包含的 HTML/CSS/JS 文件
2. 本地服务 — 通过 python3 -m http.server 启动 localhost 服务（推荐端口 9876-9880）
3. Canvas 导航 — 使用 openclaw nodes canvas navigate 将 Canvas 面板指向本地服务
4. 数据注入 — 通过 canvas eval 执行 JavaScript 实现 Agent 到 UI 的实时数据更新
5. 双向通信 — 应用通过 openclaw://agent 深度链接向 Agent 发送指令
三种内容加载方式：
| 方式 | 场景 | 限制 |
|------|------|------|
| Localhost Server | 复杂应用、外部资源依赖 | 需端口管理 |
| Direct HTML Injection | 快速展示、演示 | 无外部资源、大小受限 |
| Data URLs | 小型内容 | 部分系统不稳定 |
关键限制： Canvas 安全沙箱完全阻止 file:/// 协议访问，必须使用上述三种替代方案。
显著优点
- 富交互体验：突破纯文本限制，支持动画、实时数据、复杂布局
- 本地化优先：数据与应用存储于本地文件系统，隐私可控
- Agent 原生集成：深度绑定 OpenClaw 生态，命令即操作（"Open dashboard"、"Update revenue"）
- 自包含架构：单 HTML 文件即可运行，便于版本管理与迁移
- 双向通信机制：JavaScript eval 注入 + deep link 回调形成完整闭环
- 预设模板：Dashboard、Tracker、Timer 等开箱即用模板
潜在缺点与局限性
| 问题 | 说明 |
|------|------|
| **安全沙箱约束** | Canvas 的 `file:///` 封锁是硬性限制，增加架构复杂度 |
| **端口管理负担** | 多应用需协调端口分配，存在冲突风险 |
| **URL 协议缺陷** | `openclaw-canvas://` 方案在部分版本不可用 |
| **调试困难** | Canvas 内无 DevTools，需依赖 console.log 或外部调试 |
| **平台绑定** | 深度依赖 OpenClaw 生态，迁移成本较高 |
| **状态持久化** | 需自行实现 data.json 读写，无内置 ORM/存储层 |
| **CSS 隔离缺失** | 多应用共享 Canvas 环境，样式可能冲突 |
适合人群
- OpenClaw 深度用户，希望突破文本界面限制
- 个人开发者构建私有化数据看板、习惯追踪器等工具
- 需要离线优先、数据自主可控场景（非敏感业务数据）
- 快速原型验证：利用模板 5 分钟搭建可交互 MVP
常规风险
1. XSS 风险：canvas eval 执行任意 JavaScript，恶意应用可窃取 Agent 上下文
2. CSRF 通过 Deep Link：openclaw://agent 回调可能被伪造，需校验消息来源
3. 本地服务暴露：http.server 默认绑定 0.0.0.0，同网络设备可访问
4. 端口占用冲突：自动化脚本若未妥善清理，可能导致服务异常或信息泄露
5. 依赖版本漂移：OpenClaw Canvas 协议未稳定，openclaw-canvas:// 已标记为不可用
缓解建议：
- 绑定
127.0.0.1替代默认0.0.0.0 - eval 前校验
window.app对象签名 - 敏感操作增加用户确认层
- 定期审计
~/.openclaw/workspace/apps/目录内容