OpenClaw + Kiro CLI 实战：把聊天入口和代码执行层真正接起来

先给结论：OpenClaw 和 Kiro CLI 很适合搭配，但前提是你别把它理解成“两个 AI 工具叠加一下”。更准确的说法是，OpenClaw 负责做长期在线的入口、路由和自动化壳层，Kiro CLI 负责在具体代码仓库里完成分析、修改和持续会话。一个偏“总控台”，一个偏“落地执行层”。这两个东西分工清楚之后，组合价值才会出来。

这篇文章不讲空泛概念，直接讲一个真实可复用的做法：用 OpenClaw 接 Slack、Telegram 或本地聊天入口，把开发请求路由到一个专门的 coding agent，再由这个 agent 在项目工作区里调用 Kiro CLI 完成代码分析、改动建议和非交互式任务执行。

一、为什么这两个工具值得一起用

Kiro CLI 的强项，是它本来就是为终端里的开发任务设计的。它适合在具体仓库内工作，能保留会话、读取项目上下文、用 Steering 约束规则、用 Hooks 补自动化，还能接 MCP。OpenClaw 的强项则不一样：它更像一个自托管的 agent gateway，负责连接聊天入口、技能、工具、exec、配置、多 agent 工作区和长期在线的路由能力。

所以很自然的一种组合方式就是：

OpenClaw 负责“有人发来需求之后，怎么接住它”
Kiro CLI 负责“进入具体代码仓库之后，怎么把事情做下去”

这比直接把 OpenClaw 当代码 agent 用，或者把 Kiro CLI 硬塞进聊天入口，都更合理。前者容易把通道能力和仓库能力搅在一起，后者则缺少长期在线和多入口路由能力。

二、先把角色分工定清楚

我建议把这套组合拆成两层：

OpenClaw 层：负责接收消息、管理 agent、绑定通道、执行本地命令、加载 skills
Kiro CLI 层：负责进入具体项目目录，按项目规则完成代码理解、生成方案、修改文件和延续上下文

这一步很重要。很多人一上来就想“能不能让 OpenClaw 替我写代码”。当然可以，但那不是最稳的方式。更稳的方式是：OpenClaw 做编排，Kiro CLI 做代码执行。这样调试成本低，出了问题也容易定位。

三、环境准备：先分别装好 OpenClaw 和 Kiro CLI

先安装 OpenClaw：

curl -fsSL https://openclaw.ai/install.sh | bash

安装完之后，按向导完成基础 onboarding，至少让 Gateway 和默认 agent 跑起来。然后确认 CLI 正常：

openclaw doctor
openclaw health

再安装 Kiro CLI：

curl -fsSL https://cli.kiro.dev/install | bash

装好后，先确认 Kiro CLI 本身能在你的项目里启动：

cd ~/projects/my-app
kiro-cli doctor
kiro-cli chat --list-models

到这里为止，你做的还只是“两个工具都能跑”。真正的关键在下一步：把 OpenClaw 的 agent 工作区，和 Kiro CLI 的项目上下文，绑定到同一个真实仓库里。

四、创建一个专门的 coding agent，把工作区指向真实项目

最稳的做法，不是让所有消息都打到默认 agent，而是单独建一个 coding agent。OpenClaw 的多 agent 机制本来就适合这种分工：聊天归聊天，代码归代码。

openclaw agents add coding 
  --workspace ~/projects/my-app 
  --non-interactive

这样做有两个好处。第一，coding agent 直接绑定到项目目录，exec、文件读写和 skills 都围绕同一个仓库展开。第二，你后面给这个 agent 配的模型、技能、权限和通道，不会污染其他 agent。

接着看看 agent 是否已经建立：

openclaw agents list
openclaw agents bindings --agent coding

如果你希望从某个聊天入口直接把消息发给它，再把通道绑上去。比如绑定一个专门的 Telegram 或 Slack 入口给 coding agent，用来收开发请求。这样你在手机上发一句“帮我检查 billing 页面为什么报错”，消息就不会跑到别的 agent 上。

五、让 Kiro CLI 在这个仓库里真正变得可用：先写 Steering

如果你跳过这一步，后面集成出来的效果通常会很一般。因为 Kiro CLI 的代码能力不是凭空发生的，它要吃到项目规则，输出才会稳定。最起码，把 .kiro/steering/ 建起来。

cd ~/projects/my-app
mkdir -p .kiro/steering

建议至少放这三份文件：

product.md：这个产品做什么，关键用户是谁
tech.md：技术栈、依赖限制、测试要求
structure.md：目录结构、命名规范、组件放置规则

例如：

# Tech Stack
- Runtime: Node.js 20
- Framework: Next.js App Router
- ORM: Prisma
- UI: shadcn/ui
- Test: Vitest

# Constraints
- 复用现有 service 层，不新增平行数据访问层
- 页面必须补 loading 和 error 状态
- 新增接口优先走现有 auth 约束

你会发现，这一步其实不是在“配置 Kiro”，而是在给后续整个 agent 工作流补地基。没有它，OpenClaw 把请求转给 Kiro CLI 之后，得到的仍然可能是泛泛的输出。

六、最实用的接法：给 OpenClaw 写一个 skill，让它按固定格式调用 Kiro CLI

OpenClaw 的 skills 不是插件代码仓那一套重工程东西，它更像“教 agent 在什么场景下、用什么方式调用工具”。这正适合拿来做 Kiro CLI 的桥接层。

最简单的思路是：创建一个本地 skill，明确告诉 OpenClaw，遇到代码分析、代码修改建议、仓库总结这类请求时，优先通过 exec 工具进入项目目录，再用 Kiro CLI 的非交互命令执行。

先在 coding agent 的工作区里建 skill 目录：

mkdir -p ~/projects/my-app/skills/kiro-bridge

然后创建 SKILL.md：

---
name: kiro-bridge
description: Use Kiro CLI for repository-aware coding tasks in the current workspace.
---

When the user asks for code analysis, implementation planning, refactoring suggestions, bug diagnosis, or repository summaries:

1. Use exec in the current workspace.
2. Prefer Kiro CLI over ad-hoc shell reasoning when the task is repo-specific.
3. Start with read-only analysis before proposing write actions.
4. Use commands like:
   - kiro-cli chat --no-interactive "总结当前仓库结构并指出关键模块"
   - kiro-cli chat --no-interactive "分析 billing 页面报错的可能原因，先不要修改文件"
   - kiro-cli chat --no-interactive "给出实现方案，要求复用现有 Prisma 和 service 层模式"
5. If the user asks for file changes, ask Kiro for a plan first, then execute changes carefully.
6. After any suggested changes, run project validation commands if available.

这个 skill 的价值不在于“功能很多”，而在于它把调用习惯固化了。以后 OpenClaw 收到开发请求，不会每次都临场发挥，而是更有概率走你预期的路径：进仓库、调 Kiro、先分析再改。

七、实战流程：从聊天入口发需求，让 OpenClaw 调 Kiro CLI 完成仓库分析

假设现在你已经把某个聊天入口绑定到了 coding agent。接下来就可以直接发一个真实任务：

检查当前项目里 billing history 页面为什么没有正确显示数据。
先不要改代码，先总结可能原因，并告诉我你检查了哪些目录和文件。

在比较理想的路径里，OpenClaw 会加载你刚才的 skill，进入当前 workspace，用 exec 调 Kiro CLI，比如跑出类似这样的命令：

cd ~/projects/my-app && 
kiro-cli chat --no-interactive "检查当前项目里 billing history 页面为什么没有正确显示数据。先不要修改代码，先总结可能原因，并说明检查了哪些目录和文件。"

这个阶段的重点不是一步改完，而是把 OpenClaw 变成一个稳定入口，把 Kiro CLI 变成一个真正会读仓库的执行层。你先把分析跑顺，后面再加改代码、跑测试、回传结果，风险会小很多。

八、再往前一步：把“分析 → 修改 → 校验”做成固定工作流

这套组合真正有用的地方，不是问一句答一句，而是你可以把流程固化。一个比较稳的工作流通常长这样：

OpenClaw 接到请求后，先调用 Kiro CLI 做只读分析
Kiro CLI 输出计划和风险点
OpenClaw 再根据你的确认，调用第二次 Kiro CLI 或本地命令做修改
修改完成后，OpenClaw 用 exec 跑测试、lint 或构建命令
最后把摘要、改动范围和失败信息回传到聊天入口

这其实就是把 agent 从“会聊天”拉到“会交付可追踪步骤”。OpenClaw 的 exec、process、skills 和多 agent 结构适合管流程；Kiro CLI 的仓库上下文、持续会话和 Steering 适合做具体代码推理。两边各干擅长的事，组合才稳定。

九、一个可落地的最小工作流脚本

如果你不想一开始就把逻辑全塞给 agent，自定义一个脚本通常更稳。比如在项目目录里放一个 scripts/kiro-review.sh：

#!/usr/bin/env bash
set -euo pipefail

cd "$(dirname "$0")/.."
TASK="$*"

kiro-cli chat --no-interactive "$TASK"

然后在 OpenClaw skill 里要求优先执行：

Use exec to run:
./scripts/kiro-review.sh "用户的原始任务内容"

这样你把调用口收敛成一个脚本，后面想加日志、超时、预处理、后置校验，都有地方放。对个人开发者来说，这通常比一上来追求“全自动 agent 魔法”更靠谱。

十、这套组合适合谁，不适合谁

适合的人很明确：

已经习惯终端和仓库本地工作流的开发者
想把聊天入口、通知入口和代码执行入口打通的人
需要一个长期在线、可路由、可分 agent 的个人开发助手的人

不太适合的人也很明确：

还没形成基本项目规范，仓库本身就很乱的人
希望零配置就获得稳定自动改代码体验的人
没有明确安全边界，却想直接把高权限 exec 开满的人

说白了，这不是一个“装完立刻起飞”的组合，而是一套值得经营的开发者工作流。你需要先把 agent 的边界、仓库规则和调用路径想清楚，收益才会慢慢显现。

十一、我的判断：OpenClaw 负责入口，Kiro CLI 负责代码，这个分工是对的

我对这套组合的判断很明确：值得试，尤其适合个人开发者和小团队做自己的 AI 开发入口。它最有价值的地方，不是“两个热门工具拼一起”，而是它们的职责边界天然互补。OpenClaw 适合做长期在线的 agent gateway、技能载体和通道层；Kiro CLI 适合贴着代码仓库做持续、受约束的开发任务。

真正的实战建议也很简单：不要一开始就追求全自动改代码。先打通只读分析，再加计划，再加小范围修改，最后再接测试和回传。这样你得到的不是一个花哨 demo，而是一套真的能长期用下去的个人开发工作流。