核心用法
agent-deploy 技能用于创建和管理独立的 OpenClaw Agent 实例，每个 Agent 拥有独立的 Telegram Bot、工作空间与会话存储。用户通过简单的自然语言指令（如 "deploy a new agent"）即可触发部署流程。
部署前必须获取两个关键参数：agentId（小写字母/数字/连字符）和 botToken（从 @BotFather 获取的 Telegram Bot Token）。系统会自动执行预检脚本 deploy.sh，完成以下操作：
- 创建隔离工作空间
~/.openclaw/workspace-<agentId>/ - 配置安全沙箱（
sandbox.mode: non-main，sandbox.scope: agent） - 添加路由绑定与 Telegram 账号
- 执行
openclaw doctor验证并支持失败自动回滚
显著优点
安全隔离设计：每个 Agent 运行在独立容器中，默认禁止访问主机工作空间（workspaceAccess: none），且无法修改核心网关配置（tools.deny: ["gateway"]）。
自动化运维：内置配置验证、热重载、API 密钥合并（全局配置 + 主 Agent 配置）、单 Bot 到多账号模式的自动迁移。
零手动干预：严禁直接编辑 openclaw.json，所有变更通过 openclaw config set 安全通道完成，避免配置漂移。
潜在缺点与局限性
依赖外部 Bot Token：用户必须自行从 Telegram @BotFather 获取 Token，流程存在外部依赖。
主 Agent 不可删除：remove.sh 脚本强制保护主 Agent，用户无法通过此技能清理初始实例。
日志诊断门槛：Bot 无响应时需手动检查 journalctl 日志，对非 Linux 用户不够友好。
适合人群
- 需要为不同业务场景（研究、客服、运维）隔离部署专用 Agent 的团队
- 追求多租户安全架构、担心 Agent 越权访问敏感数据的组织
- 希望快速扩展 Telegram Bot 矩阵而无需手动配置路由绑定的开发者
常规风险
- Token 泄露风险：Bot Token 以明文形式传递和存储，若日志级别配置不当可能残留敏感信息
- 权限提升漏洞：尽管沙箱默认隔离，但历史版本若存在容器逃逸漏洞仍可能导致主机被控
- 配置回滚失败：极端情况下自动回滚可能未能完全清理残留目录，需手动检查
workspace-<agentId>目录 - 网关服务中断：大规模并发部署或
systemctl restart操作不当可能影响现有 Agent 可用性