Kilo CLI Coding Agent

核心用法

Kilo CLI Coding Agent 是一种后台优先的编程代理技能，通过 bash background 模式实现非交互式代码任务自动化。

基础模式：workdir + background

• 在隔离目录中启动代理（workdir:$SCRATCH），避免读取无关文件
• 返回 sessionId 用于全程跟踪：日志查看、状态轮询、输入写入、强制终止
• 适合自动化构建、批量 PR 评审等无人值守场景

主要功能场景

1. 自主构建（--auto 模式）

kilo run --auto "Build a snake game with dark theme"

2. PR 评审（三种安全策略）

• 在实际项目目录评审（禁止在 OpenClaw 自身目录操作）
• 克隆到临时目录安全隔离
• 使用 git worktree 保持主分支完整

3. 批量并行评审
预取所有 PR refs，为每个 PR 启动独立 Kilo CLI 进程，通过 process:list 统一管理，最后批量回写 GitHub 评论

4. 多 Issue 并行修复
结合 git worktree（隔离分支）+ tmux（持久 TTY 会话），可同时推进 5+ 个修复任务

关键设计原则

• --full-auto 用于构建（自动批准变更）
• vanilla 模式用于评审（无特殊标志）
• 严禁在 ~/openclaw/ 启动（防止代理读取系统文档产生异常行为）
• 严禁在 OpenClaw 实时仓库切换分支（使用克隆或 worktree）

显著优点

• 真正的后台并行：多进程并发处理 PR/issue，显著提升批量任务效率
• 工作目录隔离：workdir 参数限制文件访问范围，减少上下文污染
• 多重安全机制：临时目录、git worktree、明确的分支保护规则
• 标准化输出：提供 PR 模板（The Razor Standard），强制包含人工描述、功能意图、测试验证、实现细节，降低"AI slop"风险

潜在局限

• 环境依赖重：需预装 Node.js、Kilo CLI、GitHub CLI、tmux，且必须配置 GITHUB_TOKEN
• 状态管理复杂：sessionId 跟踪、多进程监控、结果聚合需要额外编排
• 交互场景受限：复杂交互开发仍需 tmux，后台模式仅适合明确指令的任务
• 网络与 API 依赖：GitHub CLI 操作、npm 安装均依赖外部服务
• 安全风险点：虽然禁止在自身目录运行，但自动化代理仍有权限执行 git 操作、推送代码、创建 PR

适合人群

• 需要批量处理开源项目 PR 的维护者
• 希望自动化代码审查流程的工程团队
• 有多 Issue 并行开发需求的全栈开发者
• 已熟悉 tmux 和 GitHub CLI 的高级 CLI 用户

常规风险

| 风险类型 | 说明 |

|---------|------|

| 权限滥用 | `GITHUB_TOKEN` 需合理配置 scope，避免过度授权 |

| 代码污染 | 并行进程若配置不当可能交叉污染工作目录 |

| 分支破坏 | 违反规则在 OpenClaw 目录切换分支可导致实时实例崩溃 |

| 信息泄露 | 禁止将 soul.md 等系统文档暴露给代理读取 |

| 自动化失控 | `--auto` 模式自动批准变更，需配合代码审查机制 |

| 资源耗尽 | 大规模并行（如同时评审 20+ PR）可能耗尽本地资源 |

核心用法

本 Skill 提供 Kilo CLI 的完整调用指南，核心模式为 bash background 后台执行 + workdir 目录隔离。用户通过 bash workdir:<目录> background:true command:"kilo run <任务>" 启动非交互式编码代理，返回 sessionId 用于进程监控（process action:log/poll/kill）。支持三大场景：

1. 自主构建（--auto 模式）：kilo run --auto "Build a snake game" —— 自动审批变更
2. PR 审查（vanilla 模式）：通过 git fetch origin '+refs/pull/*/head:refs/remotes/origin/pr/*' 批量获取 PR，并行启动多个 Kilo CLI 实例审查，结果用 gh pr comment 回写
3. 交互式会话：复杂任务使用 tmux 技能，利用 git worktree 创建隔离分支，实现多 Issue 并行修复

关键安全规则：绝对禁止在 ~/Projects/openclaw（OpenClaw 运行目录）内执行 Kilo CLI 或 git checkout，必须使用 /tmp 临时目录或 git worktree 隔离。

显著优点

• 真正的并行能力：通过 background 进程 + tmux 会话，可同时运行 5+ 个 Kilo CLI 实例处理批量 PR 或 Issue
• 目录隔离设计：workdir 参数确保 Agent 仅访问相关文件，避免读取敏感配置；git worktree 实现分支级隔离
• GitHub 原生集成：深度整合 gh CLI，支持 PR checkout、评论、创建，形成完整 DevOps 闭环
• 模式化工作流：明确区分 --auto（构建）与 vanilla（审查）模式，减少误用

潜在缺点与局限性

• 外部依赖重：必须预装 kilo（npm）、git、gh、tmux 四个 CLI 工具，且需正确配置 GitHub 认证
• 无交互容错：background 模式下 Agent 若提问会阻塞，需手动 process action:write 回复，不适合高度不确定的任务
• Token 权限风险：依赖 GITHUB_TOKEN，若使用过度权限的 token 可能导致仓库篡改
• 环境敏感：Kilo CLI 版本兼容性、Node.js 环境、tmux 配置差异可能导致行为不一致

适合人群

• 维护者/Reviewer：需要批量审查 PR、自动化代码评审流程的工程师
• 多任务开发者：需同时处理多个 Issue 或功能分支的高级用户
• CI/CD 集成者：希望将 Kilo CLI 纳入自动化工作流的技术团队
• 不适用的场景：初学者（外部工具链复杂）、单文件简单编辑（ overhead 过高）、无 GitHub 访问环境

常规风险

| 风险类型 | 等级 | 说明 |

|---------|------|------|

| 命令注入 | 低 | 示例中 `rm -rf $REVIEW_DIR` 使用变量控制，已标注用途，但用户需确保变量非空 |

| Token 泄露 | 中 | `GITHUB_TOKEN` 是敏感凭证，需遵循最小权限原则 |

| 工作目录冲突 | 中 | 在运行中的 OpenClaw 目录执行 git 操作可能破坏实例，文档已明确禁止 |

| 外部工具漏洞 | 低 | 依赖 Kilo CLI、gh 等工具的安全更新，需持续关注 |