亚马逊开源了 Kiro Crew（Apache 2.0）——一个能跑多编码 Agent 的持久化异步工作区：你在里面派活，Agent 在你离开后继续干，跨天、跨仓库、跨工具。它在亚马逊内部代号 MeshClaw，半年被 3.9 万名开发者使用、约 500 名贡献者提交了 597 次更新。这篇教程带你理解它的定位、装起来，并跑通第一个「无人值守」任务——同时说清楚它的坑（token 烧得快、推理引擎仍绑 AWS）。
🧰 本教程适合：想给团队上「异步编码 Agent」的工程师与团队负责人。需要会装命令行工具、能看懂基本概念，不要求写过 Agent 框架。
Step 1：先理解 Kiro Crew 解决什么问题
1 从「盯一个提示词」到「跑一队 Agent」
传统编码 Agent 的局限：
· 对话结束就失忆，跨会话要重新解释
· 一次只能陪一个任务，人得全程盯着
· 长任务（迁移、排查）没人守就停摆
Kiro Crew 的思路：
· 工作单元是「跨天的会话链」，不是一次对话
· 知识图谱 + 共享记忆：项目上下文跨会话保留
· 派活即走：Agent 后台持续跑，回来验收
· 可并跑多个 Agent、可派生子代理
典型场景（亚马逊内部真实用法）：
· 事故排查：跨多个仓库追根因
· 工单分拣（ticket triage）
· 代码迁移：几小时的活，人不在也跑完
· PR 监控：早上自动检查未合并 PR
· 定时维护：修 flaky 测试
设计单位：Session Chain（会话链），
不是 Chat（聊天）——这是它和普通
AI 助手最本质的区别。💡 为什么值得关注：3.9 万人在无强制的情况下自发使用，约「每 78 个用户就出 1 个贡献者」——这个采纳密度说明它解决的是真实痛点，不是 demo。参考《Codex 持久模式》里「跨会话自主」的趋势，Kiro Crew 是把这事工程化的又一个标本。
Step 2：核心组件——记忆、调度、工具面
2 四样东西撑起异步工作区
| 组件 | 作用 | 说明 |
|---|---|---|
| 知识图谱 + 共享记忆 | 跨会话保留项目上下文 | 向量嵌入 + 全文检索，存架构决策与编码偏好 |
| Skills / Lessons | 沉淀可复用经验 | Skill 是可编辑的 Markdown 能力包；Lesson 是持续纠错记录（可限定单个工作区） |
| 调度器 | 定时 / 事件触发 | 时区感知 cron、webhook（外部事件）、heartbeat（盯 PR 状态变化） |
| Apps + MCP | 连接外部工具 | DevFleets / Task Runner / Issue Radar 等官方 App，或自建 MCP 服务 |
一个细节很有价值：不需要推理的任务直接跑普通脚本/命令，不走模型——长期无人值守运行里，这能同时压住成本和失败率，也是 Agent 系统最容易失控的两个点。
Step 3：安装——三条路任选
3 一行脚本 / Docker / 桌面应用
前置：Kiro CLI（推理引擎依赖 Kiro 账号 + Bedrock）
方式一：一行安装脚本（本地跑）
curl -fsSL <官方安装脚本> | sh
· 适合个人尝试
方式二：Docker（常驻服务器跑）
· 适合团队 / 无人值守环境
· 跑在你自己控制的服务器上
方式三：桌面应用
· macOS / Linux / Windows 都有
· 与 CLI 同源，带图形界面
连接编辑器（可选）：
在 JetBrains / Zed 里通过 ACP 协议接入
kiro-cli acp
kiro-cli acp --agent my-agent
复用现有配置：
· 直接读 .kiro 配置（steering files / skills / agents）
· 可复用其他标准平台写的 skills（不改即用）
· Slack / Telegram / WeCom 集成，任务结果推群里开源的是「编排层」，不是「推理引擎」：Crew 的编排代码是 Apache 2.0，但 Agent 的推理仍走 Kiro CLI + AWS Bedrock 的计费模式——典型「open harness, closed engine」。预算敏感团队先算好账再上车。
Step 4：跑通第一个异步任务
4 派活 → 走人 → 回来验收
实操四步：
1. 初始化工作区
kiro crew init --name my-project
2. 派一个异步任务（示例：PR 监控）
「每天早上 9 点检查 open PR，
有超过 3 天没更新的就列出来，
附上最后活动时间」
· 用 cron 调度：写进时区感知的定时任务
· 或绑 webhook：PR 状态变化自动触发
3. 走人
· Agent 按计划在后台跑
· 每个 Agent 的推理和工具调用在
Activity 视图实时可见（计划/工具调用/审批点/结果）
4. 回来验收
· 检查结果、批注修正
· 修正会沉淀成 Lesson，影响后续行为
· 高频模式可固化成 Skill
小技巧：
· 先跑「纯脚本」类任务（不需要模型）
——便宜、稳定、适合试水
· 再用并发子代理：父 Agent 把「查代码库」
「写测试」拆给子 Agent 并行🚀 建议第一个任务选「低风险 + 明确产出」的：比如定时汇总未合并 PR。先建立信任，再逐步放权给「改代码」类任务。
Step 5：安全——七层防御是默认配置
5 给 Agent 真实仓库权限之前的防线
Kiro Crew 出厂自带七层防御：
1. OS 级沙箱：Agent 跑在系统级隔离里
2. deny-by-default：命令默认禁止，逐条放行
3. 可疑模式阻断：识别危险命令序列
4. 输入校验：外部输入先过校验再进 Agent
5. 敏感路径阻断：禁止访问凭证/私钥等路径
6. 凭证脱敏：日志里自动打码
7. 签名审计日志：每次行动都有可验真的记录
另外：
· 本地 Dashboard 默认只绑本机
· 工具请求可要求人工审批
两条最重的：
· deny-by-default：默认什么都干不了，
比你事后追责强一万倍
· 签名审计日志：出事之后有据可查
——对照《五眼联盟 23 条风险清单》，
这七层几乎逐条命中真实成本警示：已有用户报告 Crew 比 Kiro CLI 烧 token 快得多——并发子代理 + 跨会话上下文叠加，token 消耗是线性放大。上线前先设好预算上限，参考《Agent 预算护栏》里的「先限流再放权」。
Step 6：选型判断——什么时候该用 Kiro Crew
6 适合什么团队、不适合什么团队
| 场景 | 适合？ | 原因 |
|---|---|---|
| 长任务（迁移/排查/工单） | ✅ 很合适 | 异步 + 持久上下文正是为此设计 |
| 定时/事件驱动维护 | ✅ 合适 | cron/webhook/heartbeat 原生支持 |
| 多仓库多 Agent 并行 | ✅ 合适 | 并发子代理 + Activity 视图 |
| 完全本地、不依赖云推理 | ⚠️ 受限 | 推理仍依赖 Kiro + Bedrock |
| 预算极敏感的小团队 | ⚠️ 谨慎 | token 消耗比 CLI 快，需设上限 |
一句话：如果你有「人不在也得跑」的开发任务，Kiro Crew 值得一试；如果只是偶尔用 AI 写段代码，它对你过重。开源版本刚起步，评测数据和成本数字都还薄——先小规模验证再决定是否推广。