核心用法
openclaw-new-agent 是 OpenClaw 生态的多账号管理 Skill，专门用于在现有 OpenClaw 实例上部署独立的飞书机器人 Agent。其核心价值在于实现"一平台多机器人"的架构：每个 Agent 拥有独立的工作空间、角色定义（SOUL.md）和用户权限（allowFrom），互不干扰。
标准流程：
1. 场景确认 — 收集新 Agent 用途、工作区命名（如 workspace-codewriter）、飞书凭证
2. 强制备份 — 使用带日期标签的 .bak 备份策略，防止配置污染
3. 工作区创建 — 与主 workspace 平级目录 新建文件夹，含 SOUL.md、USER.md、AGENTS.md 等标准结构
4. 配置注入 — 通过 gateway config.patch 局部更新 openclaw.json，新增 channels.feishu.accounts.{agentId} 和 agents.list 条目
5. 白名单获取 — 独特机制：allowFrom 初始留空，用户发送测试消息后从日志自动提取 open_id
6. 验证闭环 — openclaw doctor 检测配置 + 日志追踪 + 真实消息测试
显著优点
- 工作区隔离：每个 Agent 独立文件系统，避免记忆污染和权限串扰
- 动态白名单：无需用户提前提供 open_id，降低配置门槛
- 零覆盖更新：
config.patch局部修改，保护现有配置 - 一键模板支持：内置飞书开放平台快速创建链接，自动预配置 WebSocket 事件订阅
潜在局限
- 依赖 OpenClaw 生态：非独立工具，必须基于运行中的 OpenClaw 实例
- 手动重启要求：配置更新后需等待 Gateway 重载（约2-3秒），无热更新机制
- 日志依赖取证：白名单自动获取依赖日志解析，若日志轮转或权限不足会失败
- 单飞书渠道：仅支持飞书（Lark），未覆盖 Discord、Slack 等其他 IM
适合人群
- 多角色需求者：需要区分工作/个人、不同项目、不同客户的 OpenClaw 用户
- 团队管理员：为成员部署专属 Agent 且需隔离数据的企业场景
- 自动化进阶用户：已熟悉 OpenClaw 基础配置，追求架构扩展性的开发者
常规风险
- 配置回滚风险：未严格备份时，错误的 JSON 注入可能导致主配置损坏（已内置强制备份步骤缓解）
- allowFrom 遗漏：若用户有多个飞书账号，遗漏任一 open_id 会导致消息静默丢弃
- WebSocket 连接失败：飞书开放平台侧权限配置错误（如未开启
im:chat:readonly）会导致 Gateway 无法建立连接
来源说明
该 Skill 由 OpenClaw 社区作者 Zhou Quan 维护，MIT 开源协议，版本迭代至 v1.2.1，具备社区技术背书但非官方核心组件。