Kiro Crew 0.13 on Ubuntu 24.04 云端部署指南

一、背景

1、Kiro Crew 是什么

Kiro Crew 最初是 Amazon 内部一个名为 MeshClaw 的项目。从它诞生之日起，在不到六个月的时间里，Kiro Crew 已经被超过 39,000 名 Amazon 开发者采用。接近 500 名贡献者共提交了 597 项更新，平均每周完成 143 次代码提交。由于 Kiro 已经是团队日常使用的开发工具，因此 Kiro Crew 选择了在 Kiro Agent 基础上构建。

Kiro Crew 的核心是 Kiro CLI，不同形式的客户端通过 ACP 协议调用 Kiro CLI。因此，使用 Kiro Crew 本身不需要额外配置模型 API，在已经安装并登录 Kiro CLI 的环境中即可使用。

2、Kiro Crew 的能力和适合的场景

与 AI Agent 的一次对话可完成边界明确的短任务，但软件迁移、故障分析、依赖升级、定期维护等工作经常持续数小时或数天。终端关闭、个人电脑休眠或会话上下文压缩后，任务进度、用户偏好和历史经验可能无法自然延续。Kiro Crew 针对这一问题，在 Kiro CLI 之上提供长期运行的 Gateway、持久会话、跨会话记忆、任务调度和子代理编排能力。

Kiro Crew 是采用 Apache License 2.0 发布的开源、自托管代理工作区。它不是新的基础模型，也不是离线推理服务。模型访问、工具执行和模型上下文协议（Model Context Protocol，MCP）仍由 Kiro CLI Agent 来承担；Kiro Crew 负责会话、记忆、审批、任务、日程和客户端接入等上层编排。

Kiro Crew 适合以下工作负载：

• 需要跨多个会话持续推进的迁移、重构和依赖升级；
• 需要保存用户偏好、项目事实、历史摘要和纠正经验的长期项目；
• 可拆分为独立子任务的并行分析、验证和分组件实现；
• 需要按小时、每日或事件触发的代码维护、报告和监控任务；
• 需要从浏览器、桌面应用或消息渠道访问同一持久工作区；
• 需要把会话数据和工作目录保留在自有主机，并能够自行控制备份、审计和网络边界。

以下场景通常不应优先采用 Kiro Crew：

• 不能访问 Kiro 模型服务的完全离线环境；
• 要求现成多可用区高可用、无状态水平扩展或明确服务等级协议的关键控制面；
• 尚未建立最小权限和人工审批制度，却计划授予生产系统写权限；
• 希望完全免除服务器、补丁、备份和监控运维。

3、如何向 Kiro Crew 下达任务

Kiro Crew 支持如下方式：

用户可以在 Dashboard 或桌面应用的聊天区域直接输入任务。Kiro Crew 基本执行链路如下：

Kiro Crew Web Dashboard（网页入口） / Kiro Crew 客户端（桌面应用） / Kiro Crew CLI
                    │
                    ▼
            Kiro Crew Gateway
会话、记忆、调度、审批、任务和子代理编排
                    │
                    ▼ ACP
            Kiro CLI 代理运行时
模型连接、工具调用、MCP 和上下文管理
                    │
                    ▼
          Kiro CLI 背后的模型服务

Kiro Crew Gateway 是编排和调度的核心组件。Gateway 通过 ACP（Agent Client Protocol）协议调用 Kiro CLI 执行任务，二者通过标准输入输出（STDIO）传输 JSON-RPC 2.0 消息。Kiro CLI 接收到任务后，即按照自身配置的提示词、MCP 工具等开始执行任务。

注意：Kiro Crew 桌面应用与 Kiro IDE 是不同产品。Kiro IDE 是基于 VS Code 构建的集成开发环境，Kiro Crew 则是独立产品。

4、本地部署与云端部署——Kiro Crew 的两种部署方式

Kiro Crew 可以考虑如下两种方式：

• 开发者本机安装：使用桌面版本安装包，安装后本机同时具备后台服务和桌面用户界面。此时，本机承担 Kiro Crew Gateway 的角色，用户通过本机桌面应用发起任务；任务提交给 Gateway 后，由 Gateway 调用本机的 Kiro CLI 执行任务。

• 云端虚拟机在线部署：在云端一台 Ubuntu 系统的虚拟机上完成部署，由云端虚拟机承担 Gateway 角色，管理端口监听在该虚拟机的 localhost:5476。接下来使用转发工具，将云端虚拟机的管理端口映射到开发者本机，随后使用浏览器访问该端口，通过网页进行交互。

如何选择二者：

• 希望获得充分的配置自由度，且开发者本机没有合规限制——本机部署。
• 企业有合规限制，开发者本机仅能使用特定应用，或者要求开发任务能够 7×24 小时运行——云端虚拟机部署。

5、Kiro Crew 与 Kiro Web 的差异

截至 2026 年 8 月，Kiro Web 产品仍处于 Preview 阶段，企业用户还需要管理员授权才能体验。新发布的 Kiro Crew 与 Kiro Web 在某些角度相似，都能在用户离开当前终端后继续处理任务，也都能使用 Steering、MCP 和自动化能力，但二者的执行位置、生命周期和责任边界不同。

选择建议如下：

• **选择 Kiro Crew：**需要自有主机、持久工作区、跨会话记忆、消息入口或长期后台流程，并具备相应运维能力。
• **选择 Kiro Web：**主要处理 Git 仓库任务，希望按任务获得隔离环境并以拉取请求交付，同时不希望维护服务器。

6、Kiro Crew 的费用构成

Kiro Crew 源代码采用 Apache License 2.0 发布，Kiro Crew 软件本身不收费。Kiro Crew 自身不存在注册/订阅。Kiro Crew 使用的模型，是借助在 Kiro Crew Gateway 所在主机上启动 kiro-cli 的 Agent Client Protocol（ACP）模式。因此，安装 Kiro Crew Gateway 的主机必须已经安装 Kiro CLI，并且 Kiro CLI 已完成有效登录、可以正常工作。

更多计费逻辑如下：

• Kiro Crew 复用 Gateway 主机或容器内 kiro-cli login 形成的登录状态，不单独保存另一套模型 API 密钥；因此可以在多台主机上安装，但每台安装主机内的 Kiro CLI 均需完成登录，也可以使用同一个订阅账户；
• 如果是在云端 EC2 虚拟机内部署，开发者本机的 Kiro CLI 已经登录好的状态不会自动同步到 EC2，二者是完全无关的两个客户端；
• Crew 发起的模型请求遵循该 kiro-cli 登录账户的 Kiro 套餐、模型配置和 Credit 额度，并按实际请求消耗 Credit；
• 部署 Kiro Crew 的云端 EC2 虚拟机相关费用，包括 EC2 虚拟机本身、EBS 云盘、云盘快照、数据传输、网络出口流量、第三方隧道服务等，费用由部署者自行承担；
• 此外，Kiro Crew 如果有多个并发会话、子代理和高频日程，那么将显著增加 Kiro Credit 消耗，对应的云端虚拟机也会消耗较多资源，成本由部署者承担。

二、Kiro Crew 任务编排和记忆功能介绍

1、长任务、日程与外部入口

默认数据根目录为：

~/.kiro/crew/

Docker 镜像中的持久化根目录为：

/home/kirocrew

会话、配置、记忆数据库、模型、skills、日程和安全事件都位于该目录中。该目录需要作为敏感数据处理，并纳入一致性备份。

当前架构中的 Gateway、ACP 会话和状态通常位于同一主机。Kiro Crew 没有内建多节点选主、共享外部数据库或无状态水平扩展机制，因此部署目标应定位为“可恢复的单节点长期服务”，而不是“开箱即用的多节点高可用服务”。

Kiro Crew 提供以下长期编排能力：

• **Task Runner：**读取任务规格，按步骤执行、验证、重试并保存检查点；
• **Cron 和 heartbeat：**执行时区相关的周期任务和持续检查；
• **Webhook：**响应外部事件；
• **消息及自定义应用入口：**通过 Gateway 访问同一组会话、记忆和审批服务；
• **Dashboard：**查看会话、任务、记忆、审批和运行状态。

长任务应拆成可验证步骤，并明确允许修改范围、停止条件和人工审批点。单次模型调用不应承担无限时长任务，真正的长时间运行依赖检查点、重试和会话恢复。

2、六层跨会话记忆

Kiro Crew 的“记忆”是保存在模型权重之外的外部状态。它通过 Markdown、SQLite、全文检索和向量索引保存内容，再由 ContextBuilder 在后续消息中检索并注入上下文。它不会训练 Kiro 基础模型，也不会修改模型权重。

主要 Markdown 文件包括：

~/.kiro/crew/workspace/memory/preferences.md
~/.kiro/crew/workspace/memory/projects.md
~/.kiro/crew/workspace/memory/history/YYYY-MM-DD.md

结构化索引主要包括：

memory.db
memory_index.db

Lessons 优先写入向量存储；当向量路径不可用时，可回退到 lessons.jsonl。这些文件和数据库均属于持久卷的一部分。

3、记忆的写入、检索与衰减

记忆既可以自动形成，也可以由用户显式触发：

• 会话累计约 30 条消息后，系统会尝试合并偏好和项目信息；
• 会话空闲约 3 小时后，系统会合并历史摘要、episodic memory 和隐式 lessons；
• 用户明确要求“记住某项规则”或纠正代理时，可立即形成 lesson；
• 每次处理消息时，ContextBuilder 会按当前查询检索相关记忆并注入上下文；
• 新会话的首条消息可触发 episodic memory 检索，用于召回相似任务及其结果。

历史注入采用时间衰减策略，避免旧内容长期占用上下文：

可通过以下命令管理 lessons 和记忆：

kirocrew learn add
kirocrew learn list
kirocrew learn remove
kirocrew memory list
kirocrew memory search
kirocrew memory stats
kirocrew memory audit
kirocrew memory export
kirocrew memory import
kirocrew memory migrate

具体参数应以当前安装版本的 --help 输出为准。Dashboard 也可用于查看、修改和删除记忆，并提供上下文预览和审计事件。

Incognito 或 temporary 会话可阻止记忆读取和写入，适合处理不应沉淀到长期上下文的临时任务。需要注意的是，为支持会话恢复，底层会话 JSONL 仍可能存在；“不写入长期记忆”不等同于“磁盘完全无记录”。

4、嵌入模型自动生成记忆

Kiro Crew 会在运行环境上，自动部署一个本地模型用于语义检索。默认使用 Qwen/Qwen3-Embedding-0.6B 的 Q8_0 GGUF 文件。其主要运行特征如下：

• 模型文件约 610 MB；
• 输出 1024 维向量；
• 通过随项目提供的 llama-cpp-python 0.3.34 在 Gateway 进程内运行；
• 默认路径为 ~/.kiro/crew/models/qwen3-embedding-0.6b.gguf；
• 首次 Gateway 启动时在后台下载，并使用固定 SHA-256 校验；
• 模型未就绪时自动回退到关键词和全文检索，下载完成后不要求重启；
• 共享 embedder 加载后约增加 700 MB 常驻内存，实际值受平台和版本影响；
• Linux CPU 可以运行，不需要额外部署 Ollama 或文本嵌入推理服务。

此外，配置取决于并发会话、子代理、MCP 进程和项目构建，因此以下是运行环境规格建议：

如果部署在云端，建议按以上要求预留模型下载空间、SQLite 增长空间、仓库空间和构建缓存。若网络限制导致模型无法下载，系统仍可使用关键词检索，但语义召回质量会受到影响。

三、在本机部署 Kiro Crew 时使用 Kiro Crew 桌面客户端发起任务

1、下载

当前公开发布状态如下：

macOS 稳定版下载地址：

https://download.crew.kiro.dev/desktop/stable/latest/KiroCrew.dmg

2、运行

在 macOS 上双击运行，客户端界面如下。

3、关于 Windows 系统的说明

Windows 原生源码安装用于在 Windows 本机运行 Kiro Crew 的 Gateway 组件，并不是 Windows 远程桌面客户端。截至 2026 年 8 月，官方仓库明确标注 Windows 桌面构建尚未公开发布。

四、在 AWS 云端 EC2 Ubuntu 24.04 LTS 上部署 Kiro Crew

Kiro Crew 支持 Ubuntu 22.04 及以上版本，因此可以运行在 Ubuntu Server 24.04 LTS 上。注意：Kiro Crew 内建的 kirocrew cloud launch 部署命令使用 Amazon Linux 2023 操作系统，因此如果需要使用更为熟悉的 Ubuntu 24.04 LTS 系统，可参考本文操作。

1、前置条件和机型配置

云端 EC2 虚拟机起始配置如下：

• 单用户试运行：2 vCPU、4 GiB RAM、30 GiB 加密 Amazon EBS gp3；
• 2～4 个并发会话：4 vCPU、8 GiB RAM、50 GiB EBS 起；
• 安全组不开放 TCP 5476 端口；
• 使用 SSH 时仅允许管理员固定地址访问 TCP 22；
• 使用 AWS Systems Manager Session Manager 作为 EC2 登录入口时，EC2 实例可以禁止所有入站连接；SSH 和 Kiro Crew Web Dashboard 的所有连接均通过 Session Manager 建立。此时，EC2 需要附加包含 AmazonSSMManagedInstanceCore 托管策略的 IAM 角色，才能接入 Session Manager；
• 出站仅允许访问 Kiro 服务、代码仓库、软件源以及经过批准的 MCP 服务。

总体链路如下：

Kiro Crew 桌面应用 / 浏览器 / 本机 Kiro CLI
                 │
                 │ 远程 SSH 登录或 AWS Systems Manager 之 Session Manager 登录
                 ▼
       EC2 Ubuntu 24.04 LTS 虚拟机
                 │
                 ▼
       原生 systemd Gateway
            ~/.kiro/crew/
                 │
                 │
                 ▼
          127.0.0.1:5476
        本机 Web Dashboard

2、安装系统依赖

升级本机到最新版本，升级完毕后重启。

sudo apt-get update
sudo apt-get upgrade -y
sudo reboot

执行如下命令安装基础依赖：

sudo apt-get install -y ca-certificates curl git python3 python3-pip python3-venv

3、安装 Kiro CLI 并完成 Kiro 订阅登录

安装 Kiro CLI，并完成设备授权登录（注意不要用 root 身份）：

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

完成 Kiro CLI 登录并确保订阅有效。此后，Kiro Crew Gateway 将通过 ACP 协议调用 Kiro CLI 执行对话任务。

4、安装 Kiro Crew

安装最新版本。

curl -fsSL https://download.crew.kiro.dev/cli.sh | sh

kirocrew --version
kirocrew setup

安装过程会收到提问：

• /home/ubuntu/workplace/kirocrew-workspace，使用默认值，按回车即可。
• Configure Slack tokens? [Y/n]，如果没有使用 Slack 软件，按 n 即可。
• Slash command name：直接回车默认。
• Timezone [Etc/UTC]：时区设置，直接回车默认。
• Launch KiroCrew on AWS now? [y/N]：该问题询问是否另外启动一台 EC2 实例进行安装。此处输入 n 并按回车键。

5、补充安装 llama.cpp 原生运行库

注意：0.1.2 和 0.1.3 版本的官方 wheel 在 Linux 平台存在一处打包缺陷，随包分发的 llama.cpp 原生库目录缺少主库 libllama.so，只保留了 libggml*.so.0 与 libgomp 这几个依赖库。该缺陷会导致内置的向量嵌入运行时无法加载，Gateway 服务启动时在日志中抛出如下异常，跨会话记忆随之退化为纯关键词检索（服务本身仍处于 active (running) 状态，因此不看日志很容易忽略）：

执行如下命令确认本机是否受该缺陷影响，其中 LIBS_DIR 通过 Python 解释器反查，避免硬编码虚拟环境与 Python 小版本号：

VENV_PY=$(ls $HOME/.kiro/crew-venv/bin/python3.* | head -1)
LIBS_DIR=$("$VENV_PY" -c "import kiro_crew, pathlib; print(pathlib.Path(kiro_crew.__file__).parent / '_vendor' / 'llama_cpp_libs' / 'linux_x86_64')")
ls -la "$LIBS_DIR"

返回结果如下，可以看到目录中没有 libllama.so：

-rwxrwxr-x 1 ubuntu ubuntu  873537 libggml-base.so.0
-rwxrwxr-x 1 ubuntu ubuntu 1160433 libggml-cpu.so.0
-rwxrwxr-x 1 ubuntu ubuntu  498497 libggml.so.0
-rwxrwxr-x 1 ubuntu ubuntu  168193 libgomp-a34b3233.so.1.0.0

解决办法是按 _vendor/README.md 中记录的来源，从官方预编译的 CPU wheel 中提取缺失的主库补齐依赖闭环。0.1.2 内置的 llama-cpp-python 版本是 0.3.34，如果部署的是其他 Kiro Crew 版本，需要先读取 $LIBS_DIR/../../README.md 确认对应的版本号与 sha256 校验值。执行如下命令下载并校验 wheel：

cd /tmp
curl -fsSL -o llama_cpp_python-0.3.34-x86_64.whl \
  https://github.com/abetlen/llama-cpp-python/releases/download/v0.3.34/llama_cpp_python-0.3.34-py3-none-manylinux2014_x86_64.manylinux_2_17_x86_64.whl
sha256sum llama_cpp_python-0.3.34-x86_64.whl

执行如下命令提取主库并安装到原生库目录：

"$VENV_PY" -c "import zipfile; zipfile.ZipFile('/tmp/llama_cpp_python-0.3.34-x86_64.whl').extract('llama_cpp/lib/libllama.so', '/tmp/whlx')"
install -m 0755 /tmp/whlx/llama_cpp/lib/libllama.so "$LIBS_DIR/libllama.so"
rm -rf /tmp/whlx /tmp/llama_cpp_python-0.3.34-x86_64.whl

执行如下命令验证嵌入运行时可以正常导入并生成向量：

"$VENV_PY" -c "
import time
from kiro_crew.embeddings import make_sync_embed_fn
fn = make_sync_embed_fn()
for _ in range(60):
    v = fn('embedding smoke test')
    if v is not None:
        print('dim =', len(v)); break
    time.sleep(2)
else:
    print('FAILED')
"

返回结果中，qwen3-embedding-0.6b 模型输出 1024 维向量，即表示修复生效。

dim = 1024

首次调用返回 None 属于正常现象，首次启动需要下载模型，模型在后台线程异步加载，因此上面的脚本带有重试。

注意：这里手工修复补充安装的 libllama.so 不在 pip 的 RECORD 清单内，重新安装或强制覆盖同一版本时会被清除，需要再次手工修复。直到官方安装包修正这个缺陷。另外，ARM 版本的 linux_aarch64/ 目录同样缺少该文件，在 Graviton 机型上部署时需要改用 manylinux2014_aarch64 对应的 wheel 并核对其自身的 sha256 校验值。

下面继续安装 Gateway 后台服务。

6、安装并启动 systemd 服务

执行如下命令：

kirocrew service install

安装成功返回结果如下：

✅ kirocrew service installed and started.
   unit: /etc/systemd/system/kirocrew.service
   AppArmor profile installed at /etc/apparmor.d/kirocrew-userns — grants unprivileged userns to the kirocrew service only, and enforcement is confirmed

   Status: kirocrew service status
   Logs:   kirocrew logs -f
   Remove: kirocrew service uninstall

启动服务：

kirocrew stop
kirocrew restart
kirocrew service status

7、原生部署的数据目录与环境变量

默认持久目录是：

/home/ubuntu/.kiro/crew/

其中包含配置、消息渠道凭证、会话、记忆数据库、模型和审计记录。若 EC2 登录用户不是 ubuntu，应替换为实际用户主目录。

常用环境变量如下：

如需为 systemd 服务设置非默认值，使用 drop-in，而不是直接修改自动生成的 unit：

sudo systemctl edit kirocrew

写入以下示例内容：

[Service]
Environment=KIROCREW_HOME=/home/ubuntu/.kiro/crew
Environment=KIROCREW_PORT=5476
# Environment=KIROCREW_EMBED_MODEL_URL=https://<your-mirror>/qwen3-embedding-0.6b.gguf
# Environment=KIROCREW_EMBED_MODEL_PATH=/opt/kirocrew/models/qwen3-embedding-0.6b.gguf

应用配置：

sudo systemctl daemon-reload
sudo systemctl restart kirocrew
kirocrew service status

注意：不要把消息平台令牌直接写入可被其他用户读取的 unit。消息渠道凭证应由 kirocrew setup 写入数据目录中的受限 .env 文件，并对文件权限进行检查。

8、诊断工具

如果安装遇到问题需要维护的话，可运行诊断：

kirocrew doctor

查看日志和验证健康状态：

kirocrew logs -f
curl -sS http://127.0.0.1:5476/api/health

卸载服务：

kirocrew service uninstall

安装完毕，下面开始设置远程访问。

五、在云端 EC2 虚拟机中部署 Kiro Crew 时使用 Session Manager 端口转发到开发者本机

1、使用 AWS EC2 Session Manager 进行端口转发

Kiro Crew 安装完毕后，其管理端口监听在 http://localhost:5476。由于 Kiro Crew 部署在云端，因此该端口只能在云端虚拟机上访问，开发者本机无法直接访问。不建议将该端口直接暴露在互联网，否则服务可能遭到入侵和恶意使用，进而危害内部网络与数据。

因此，本文通过设置端口转发来访问。

2、在开发者本机安装 AWS CLI 和 Session Manager Plugin

在 AWS 中创建 EC2 实例时，如果使用 AWS 提供的 Ubuntu AMI 模板，其内部已经包含 Systems Manager Agent（SSM Agent），因此可以使用 AWS Systems Manager 的 Session Manager 功能转发端口。

首先在本机安装 AWS CLI，macOS 系统下载地址：

https://awscli.amazonaws.com/AWSCLIV2.pkg

也可以直接在终端执行如下命令完成下载与安装：

curl "https://awscli.amazonaws.com/AWSCLIV2.pkg" -o "AWSCLIV2.pkg"
sudo installer -pkg ./AWSCLIV2.pkg -target /
aws --version

返回结果如下：

aws-cli/2.27.41 Python/3.13.4 Darwin/24.6.0 exe/x86_64

以 Apple M 芯片的 macOS 系统为例，执行如下命令：

curl "https://s3.amazonaws.com/session-manager-downloads/plugin/latest/mac_arm64/session-manager-plugin.pkg" -o "session-manager-plugin.pkg"
sudo installer -pkg session-manager-plugin.pkg -target /
sudo ln -s /usr/local/sessionmanagerplugin/bin/session-manager-plugin /usr/local/bin/session-manager-plugin
session-manager-plugin --version

返回结果如下：

1.2.707.0

备注：如果 installer 命令执行失败，需要确认 /usr/local/bin 目录是否存在，不存在时先手工创建该目录再重新执行。Session Manager Plugin 是 AWS CLI 之外的独立组件，缺少该插件时执行 start-session 会直接报出 SessionManagerPlugin is not found 的错误。

接下来在开发者本机配置具有相应权限的 AWS Access Key/Secret Key。该 AK/SK 对应的 IAM 用户需要具备如下 IAM 权限策略：

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "StartPortForwardingSessionToKiroCrew",
            "Effect": "Allow",
            "Action": [
                "ssm:StartSession"
            ],
            "Resource": [
                "arn:aws:ec2:<your-region>:<your-account-id>:instance/<your-instance-id>",
                "arn:aws:ssm:<your-region>:*:document/AWS-StartPortForwardingSession"
            ]
        },
        {
            "Sid": "DescribeSessionAndInstanceStatus",
            "Effect": "Allow",
            "Action": [
                "ssm:DescribeSessions",
                "ssm:DescribeInstanceInformation",
                "ssm:DescribeInstanceProperties",
                "ssm:GetConnectionStatus",
                "ec2:DescribeInstances"
            ],
            "Resource": "*"
        },
        {
            "Sid": "ManageOwnSessionOnly",
            "Effect": "Allow",
            "Action": [
                "ssm:TerminateSession",
                "ssm:ResumeSession"
            ],
            "Resource": [
                "arn:aws:ssm:*:*:session/${aws:userid}-*"
            ]
        }
    ]
}

上述策略的关键点在于两处收敛：一是 ssm:StartSession 的资源同时限定了具体实例 ARN 和具体会话文档 ARN，只允许该身份对指定的那一台 Kiro Crew 实例发起端口转发，而不是对账号内全部实例发起任意类型的会话；二是 ssm:TerminateSession 与 ssm:ResumeSession 通过 ${aws:userid}-* 限定为只能操作自己创建的会话，避免互相中断他人的调试会话。会话文档 ARN 的账号字段使用通配符，是因为 AWS-StartPortForwardingSession 属于 AWS 托管的公共文档，不归属于调用方账号；若省略该条资源，start-session 会因缺少文档权限而被拒绝。

部署 Kiro Crew 的 EC2 实例需要附加 IAM 角色，并为该角色附加如下 AWS 托管策略：

arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore

该托管策略是 AWS 官方为受管节点提供的最小权限集合，包含 SSM Agent 与 Systems Manager 服务端通信所需的 ssm:UpdateInstanceInformation、ssmmessages:* 和 ec2messages:* 等操作。EC2 实例需要具备访问 Systems Manager 服务端点的出站网络路径，即以下三种方式之一：公有子网加公网 IP、私有子网加 NAT 网关，或者为 ssm、ssmmessages、ec2messages 三个服务创建 VPC 接口终端节点。生产环境建议采用私有子网加 VPC 接口终端节点的组合，使实例完全不暴露于互联网。

在本机执行转发前，先确认实例已经被 Systems Manager 正确纳管：

aws ssm describe-instance-information \
  --filters "Key=InstanceIds,Values=<your-instance-id>" \
  --region <your-region> \
  --query "InstanceInformationList[].{Id:InstanceId,Ping:PingStatus,Agent:AgentVersion,Platform:PlatformName}" \
  --output table

返回结果如下：

--------------------------------------------------------------
|                DescribeInstanceInformation                 |
+------------+-----------------------+---------+-------------+
|   Agent    |          Id           |  Ping   |  Platform   |
+------------+-----------------------+---------+-------------+
|  3.3.2.582 |  i-0123456789abcdef0  |  Online |  Ubuntu     |
+------------+-----------------------+---------+-------------+

PingStatus 为 Online 表示纳管正常。若查询结果为空，说明 IAM 角色、出站网络路径或 SSM Agent 运行状态存在问题，应先排除这三项，再继续下一步。

3、在开发者本机启动端口转发

执行如下命令进行转发：

aws ssm start-session \
  --target <your-instance-id> \
  --region <your-region> \
  --document-name AWS-StartPortForwardingSession \
  --parameters '{"portNumber":["5476"],"localPortNumber":["5476"]}'

返回结果如下：

Starting session with SessionId: kirocrew-admin-0a1b2c3d4e5f67890
Port 5476 opened for sessionId kirocrew-admin-0a1b2c3d4e5f67890.
Waiting for connections...

其中 portNumber 是 EC2 实例内部 Kiro Crew Gateway 监听的端口，localPortNumber 是开发者本机映射出的端口。两者取相同的 5476 可以让本机浏览器直接使用 http://localhost:5476 访问，与在本机部署 Kiro Crew 时的访问地址保持一致，避免因端口不一致导致回调地址或前端资源路径出现偏差。如果本机 5476 端口已被占用，可将 localPortNumber 改为其他空闲端口，例如 15476，此时浏览器访问地址相应改为 http://localhost:15476。

该命令为前台阻塞式运行，终端窗口需保持打开。转发结束时在该终端按 Ctrl+C 即可关闭会话，Systems Manager 侧的会话随之终止。若需要长期保持转发，可结合 nohup 或 tmux 将其置于后台，并配合断线重连的守护脚本，但要注意会话空闲超时受 Session Manager 首选项中 idleSessionTimeout 的约束，默认值为 20 分钟。

至此本机与云端实例之间的加密通道已经建立，下面生成登录凭证。

4、生成登录密钥并登录

在开发者本机访问 http://localhost:5476，即可看到登录页面。如下截图。

通过 SSH 或 Session Manager 登录部署环境，执行如下命令生成登录密钥：

kirocrew token

返回结果如下：

http://localhost:5476?token=<temporary-dashboard-token>

将这个输出结果复制到地址栏，即可访问。如下截图。

登录成功。如下截图。

六、在 Kiro Crew 部署所在的 Linux 上使用 Kiro Crew CLI 发起任务交互

以上介绍了使用 Web 图形界面在 Kiro Crew 上发起任务。除了图形界面之外，还可以使用 Kiro Crew 专用的 CLI 命令。注意：Kiro Crew CLI 与 Kiro CLI 不是同一个程序，二者彼此独立。

1、Kiro Crew CLI 的常用命令

Kiro Crew CLI 提供聊天、任务执行、日程管理、子代理管理和 Gateway 运维等能力。常用命令如下：

具体参数可能随版本变化，应执行如下命令查看当前安装版本支持的完整选项：

kirocrew --help

2、子代理的执行模型

子代理用于把边界清晰、相互独立的工作分配给隔离会话。每个子代理使用独立逻辑 ACP 会话，其会话键采用 subagent:<id> 形式。子代理拥有独立上下文，完成后将结果返回父会话，由父会话负责综合，而不是让所有代理共享同一上下文窗口。

常用命令如下：

kirocrew spawn run "分析日志、代码变更和监控指标，并分别给出证据"
kirocrew spawn run --async "并行验证三个相互独立的故障假设"
kirocrew spawn list

默认 agent.max_subagents=0 表示根据环境自动计算并发上限；自动值下限为 3，默认上限为 32。单个子代理硬超时为 1800 秒，默认工具调用或 turn 预算为 100，相关值可通过配置治理。子代理的完整结果保存在：

~/.kiro/crew/subagents/<id>/result.txt

子代理会继承父会话可用的审批策略；缺少审批来源时，敏感操作默认拒绝。适合并行的任务包括独立资料分析、测试验证、按组件实现和多假设排查。不适合让多个代理同时修改同一文件，否则会增加覆盖、冲突和错误合并风险。

并发子代理会增加模型使用量、内存、CPU、MCP 进程和外部系统请求压力。生产环境应同时限制代理数量、工具预算、超时和外部接口速率。

七、安全最佳实践

1、网络、身份与凭证

推荐控制措施如下：

• Gateway 仅绑定或映射到 127.0.0.1:5476；
• 优先使用 Systems Manager，或把 SSH 安全组来源限制为管理员固定地址；
• 使用短期 Dashboard 令牌，并避免写入日志和命令历史；
• EC2 实例角色只授予任务所需权限，不附加组织或账户管理员权限；
• 不把主机 SSH 目录、AWS 管理员凭证或 Docker Socket（套接字）挂载到代理容器；
• 为 Git、消息平台、Webhook 和 MCP 分别使用可撤销的低权限凭证；
• 对异常登录、令牌生成、审批拒绝和异常网络连接建立审计告警。

注意：将 Docker Socket 挂载到容器通常等价于向容器授予主机级控制能力，不应作为普通工具接入方式。

2、记忆、会话和备份风险

长期记忆可能包含项目机密、个人偏好、错误结论和已经过期的规则。应建立以下治理流程：

• 定期查看和删除不准确的 preferences、projects 和 lessons；
• 对记忆导入、导出、迁移和删除保留审计记录；
• 对敏感临时任务使用 Incognito 或 temporary 会话；
• 不能因使用临时会话就假设磁盘无会话恢复记录；
• 加密 EBS、快照和备份，并限制备份账户及恢复权限；
• 按业务保留要求清理历史，而不是无限期积累；
• 恢复备份后检查旧令牌、旧凭证和过期项目规则。

语义检索返回的是相关历史，而不是权威事实。代理仍可能召回过期或错误内容，关键决策必须重新验证。

3、代理、子代理和提示注入

代码注释、问题描述、网页、日志和消息平台内容都可能包含面向代理的恶意指令。外部内容应作为不可信数据处理，不得自动覆盖系统策略或审批要求。

对子代理和自动化任务应实施以下限制：

• 按目录、组件或职责划分写入范围，避免多个代理并发修改同一文件；
• 限制最大子代理数、工具预算、执行时长和重试次数；
• 生产故障分析默认只读，重启、回滚和资源修改必须人工审批；
• 外部系统写操作、密钥访问、基础设施变更和生产部署必须保留人工确认；
• 对结果执行单元测试、类型检查、构建和独立代码审查；
• 确定性的数据搬运和固定流程优先使用脚本，只在需要语义判断时调用模型。

4、成本与可用性边界

Kiro Crew 软件采用开源许可，但运行仍会产生 EC2、EBS、快照、数据传输和 Kiro 套餐或模型使用成本。并发会话和子代理会提高模型调用量、MCP 进程数以及主机资源消耗。

当前单主机架构意味着实例、系统盘、持久卷或 Gateway 故障可能同时影响全部会话。容器自动重启只能处理进程故障，不能替代数据备份和主机恢复。建议通过 EBS 快照、外部健康检查、容量告警、固定版本和恢复演练实现可恢复性。

完成安全和责任边界后，下一章汇总推荐部署方式与远程调用结论。

八、小结

综上所述，使用 Kiro Crew 的前提是当前用户拥有有效的 Kiro 订阅，并且 Kiro CLI 可以正常工作。用户可以在本机部署 Kiro Crew，也可以在远程云端部署。使用 Kiro Crew 时应做好边界防护，避免向互联网直接暴露端口，并避免在本机授权高风险操作，例如执行高危脚本、删除数据或清空数据库。建议将 Kiro Crew 部署在独立的隔离环境中，既便于长时间运行，也便于划分安全边界。

参考文档

macOS 稳定版桌面应用下载地址如下：

https://download.crew.kiro.dev/desktop/stable/latest/KiroCrew.dmg

Linux x86_64 稳定版桌面应用下载地址如下：

https://download.crew.kiro.dev/desktop/stable/latest/KiroCrew-x86_64.AppImage

Kiro Crew 官方快速入门：

https://kiro.dev/docs/crew/

Kiro Crew 官方安装说明：

https://kiro.dev/docs/crew/installation/

Kiro Crew 官方 GitHub 仓库：

https://github.com/kirodotdev/KiroCrew

Kiro 官方博客《Introducing Kiro Crew》：

https://kiro.dev/blog/introducing-kiro-crew/

Kiro Crew 架构说明：

https://github.com/kirodotdev/KiroCrew/blob/main/docs/architecture/overview.md

Kiro Crew 远程访问指南：

https://github.com/kirodotdev/KiroCrew/blob/main/docs/guides/remote-and-mobile.md

Kiro Crew Docker 指南：

https://github.com/kirodotdev/KiroCrew/blob/main/docs/guides/docker.md

Kiro Crew 记忆、skills 与 hooks 说明：

https://github.com/kirodotdev/KiroCrew/blob/main/docs/system-specs/modules/memory-skills-hooks.md

Kiro Crew 子代理说明：

https://github.com/kirodotdev/KiroCrew/blob/main/docs/system-specs/modules/subagent.md

Kiro Crew CLI 说明：

https://github.com/kirodotdev/KiroCrew/blob/main/docs/system-specs/modules/cli.md

Kiro Crew Instances 说明：

https://github.com/kirodotdev/KiroCrew/blob/main/docs/system-specs/modules/instances.md

Kiro Crew Cloud Launcher 说明：

https://github.com/kirodotdev/KiroCrew/blob/main/docs/system-specs/modules/cloud.md

Kiro CLI ACP 官方文档：

https://kiro.dev/docs/cli/acp/

Kiro CLI 官方文档与安装入口：

https://kiro.dev/docs/cli/

Kiro Web 官方文档：

https://kiro.dev/docs/web/

Kiro Web Sandbox 官方文档：

https://kiro.dev/docs/web/sandbox/

Kiro Web Automations 官方文档：

https://kiro.dev/docs/web/automations/

AWS Systems Manager Session Manager 官方文档：

https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html

Session Manager plugin 安装文档：

https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-working-with-install-plugin.html

Session Manager plugin 在 macOS 上的安装文档：

https://docs.aws.amazon.com/systems-manager/latest/userguide/install-plugin-macos-overview.html

AWS CLI 第 2 版安装与升级官方文档：

https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html

在 IAM 策略中限定会话文档并使用 AWS-StartPortForwardingSession 的官方说明：

https://docs.aws.amazon.com/systems-manager/latest/userguide/getting-started-specify-session-document.html

Session Manager 端用户示例 IAM 策略：

https://docs.aws.amazon.com/systems-manager/latest/userguide/getting-started-restrict-access-quickstart.html

启动会话及端口转发命令参考：

https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-working-with-sessions-start.html

Session Manager 空闲会话超时设置说明：

https://docs.aws.amazon.com/systems-manager/latest/userguide/session-preferences-timeout.html

AmazonSSMManagedInstanceCore 托管策略说明：

https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonSSMManagedInstanceCore.html

最后修改于 2026-08-07