CLI Worker Skill (Kimi CLI)

核心用法

cli-worker 是 OpenClaw 与 Kimi CLI 的桥接技能，允许主 Agent 将编码任务委托给 Kimi CLI，在独立的 git worktree 中并行执行，避免分支冲突与阻塞。

典型场景

• 并行开发：同时运行多个独立任务，互不干扰
• 隔离实验：在干净 worktree 中测试代码，失败可随时丢弃
• 无头执行：从 OpenClaw 非交互式触发 Kimi CLI，无需人工值守

关键指令

• cli-worker execute "任务描述" — 创建 worktree 并运行任务
• cli-worker execute "任务" --constraint "限制条件" --success "成功标准" — 带约束与验收条件
• cli-worker status <taskId> — 查询任务状态
• cli-worker worktree remove <taskId> — 清理 worktree
• git merge openclaw/<taskId> — 合并成果到主分支

与 sessions_spawn 的对比

文档明确建议：单任务优先用 CLI，避免 sessions_spawn。后者存在创建会话后无消息处理的已知缺陷（0 messages bug）。仅当需要持续多轮对话时才考虑 spawn。

显著优点

1. 真正的并行执行：利用 git worktree 机制，物理隔离环境，非伪并发
2. 失败安全：任务失败可直接删除 worktree，不影响主代码库
3. 灵活的输出格式：支持 --output-format text 获取完整原始输出，便于后续处理
4. 自动化友好：专为无头场景设计，适合 CI/CD 集成

潜在缺点与局限性

1. 手动认证门槛：必须用户手动运行 kimi /login 完成 OAuth，无法自动化
2. 安装依赖复杂：需 Node.js 构建、npm link、技能目录软链接等多步配置
3. 无持久会话：单次任务模式，不适合需要多轮交互的复杂场景
4. 状态查询延迟：需主动 poll status 或等待 Kimi 写入报告文件
5. Kimi CLI 专属：绑定特定供应商工具，迁移成本高

适合人群

• 需要并行处理多个独立编码任务的高级开发者
• 构建自动化工作流、寻求无头 CLI 集成的平台工程师
• 已在使用 Kimi CLI 且熟悉 git worktree 的现有用户

常规风险

• 认证失效风险：OAuth token 过期后需重新手动登录，可能中断自动化流程
• Worktree 堆积：未配置自动清理（--older-than）可能导致磁盘空间浪费
• 合并冲突：虽然 worktree 隔离执行，但最终合并到主分支仍可能产生冲突
• 环境差异：Agent 运行环境与本地 Kimi CLI 环境可能存在工具链版本差异
• 依赖网络：Kimi CLI 需连接 Kimi 服务，离线场景不可用