Kiro Crew 在 AWS EC2 Ubuntu 24.04 远程部署指南

更新到 Kiro Crew 0.50 版本

一、背景

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。接下来使用转发工具，将云端虚拟机的管理端口映射到开发者本机，随后使用浏览器访问该端口，通过网页进行交互。从 0.2.0 开始，桌面应用与 Dashboard 增加了 Settings → Remote Crew 入口，可以把这台远程 Gateway 登记为受管实例，由 Gateway 自身维护隧道、令牌刷新和断线自愈，不再需要人工长期保持一个前台转发窗口。

如何选择二者：

• 希望获得充分的配置自由度，且开发者本机没有合规限制——本机部署。
• 企业有合规限制，开发者本机仅能使用特定应用，或者要求开发任务能够 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 消耗，对应的云端虚拟机也会消耗较多资源，成本由部署者承担。

7、从 0.2.0 到 0.5.0 的主要变化

本文对应的版本是 Kiro Crew 0.5.0，官方仓库标签为 v0.5.0，发布日期为 2026 年 9 月 5 日，kirocrew --version 的输出为 kirocrew 0.5.0。从本文上一版本 0.2.0 到 0.5.0 之间，官方依次发布了 v0.3.0、v0.4.0 和修复更新 v0.4.1，因此本节汇总的是三个功能版本累积形成的变化，而不是一次小范围增量更新。

对云端部署、远程使用和长期运维影响较大的变化如下，读过 0.2.0 版文章的读者可据此定位需要重新检查的环节：

升级现有 0.2.0 环境时，还需要重点检查以下兼容性变化：

• 旧语音配置会自动回退到新的 local 提供方。默认 base 模型约为 148 MB；如果历史配置保存的是 turbo，首次使用可能下载约 1.6 GB 模型，应预留磁盘空间并通过 kirocrew doctor 检查实际配置。
• 如果脚本仍调用 kirocrew snapshot --to s3://…、--aws-profile 或直接从 s3:// 恢复，需要改为本机快照或 AWS Control 的 Backup 功能，升级前应先验证现有备份的恢复路径。
• App 执行授权现在与用户同意时的代码仓库绑定。无法关联到仓库的旧授权会要求一次性重新确认，应用名称相同但代码来源变化时将拒绝沿用旧授权。
• 审批判定比 0.2.0 更严格。依赖帮助命令、版本命令或宽泛“始终允许”规则自动放行的无人值守任务，升级后可能进入等待或失败关闭状态，需要重新检查最小权限规则和无交互运行策略。
• Knowledge 的管理入口已迁入 Agent Capabilities。依赖旧入口或独立 Auto-Triage Pipeline 应用的操作文档和自动化流程需要同步调整。

stable、insider 和 nightly 三条发布通道仍然保留。生产或长期运行环境建议使用 stable 并锁定到经过验证的 0.5.0；升级之前先执行本机快照并验证恢复能力，不应以移动标签或未经验证的预发布版本替代固定版本。

下面转向任务编排与记忆功能的说明。

二、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 或文本嵌入推理服务；
• 配置项 memory.embedding_provider 只接受 llama_cpp 一个取值，旧配置中的其他取值会在加载时被强制改写为该值。

在 0.2.0 中，官方 wheel 已经完整随包分发 linux_x86_64、linux_aarch64、macos_arm64、macos_x86_64 和 win_amd64 五个平台的原生库闭环，其中 Linux 部分包含主库 libllama.so 以及 libggml*.so.0 和 libgomp 依赖。这一点与 0.1.2、0.1.3 两个版本存在差异，那两个版本的 Linux 目录缺少主库，需要部署者手工补齐，具体说明参见第四章第 5 节的备注。

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

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

三、在本机桌面部署 Kiro Crew 并直接使用桌面客户端

1、下载

从官网下载：https://kiro.dev/crew/

如果桌面是 Linux 的话，还可以从 Github 和如下网址下载：

https://github.com/kirodotdev/KiroCrew https://download.crew.kiro.dev/desktop/stable/latest/KiroCrew-x86_64.deb

2、运行

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

接下来进入云端部署环节。

四、在 AWS 云端 EC2 Ubuntu 24.04 LTS 上部署 Kiro Crew 作为后台环境长期运行

Kiro Crew 建议运行在 Ubuntu 24.04 LTS 上。

注意：不要使用本机的 Kiro Crew 内建的 kirocrew cloud launch 部署来部署，这种部署方式会拉起新的 Amazon Linux 2023 操作系统，而不是您更为熟悉的 Ubuntu 24.04 。所以如果您是使用 Ubuntu 自行部署，不要使用 kirocrew cloud launch 命令。

1、前置条件和机型配置

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

• 单用户试运行：2 vCPU、4 GiB RAM、30 GiB 加密 Amazon EBS gp3；
• 2～4 个并发会话：4 vCPU、8 GiB RAM、50 GiB EBS 起；
• 使用 SSH 时仅允许管理员固定地址访问 TCP 22；
• 使用 AWS Systems Manager Session Manager 作为 EC2 登录入口时，EC2 实例可以禁止所有入站连接；
• 不建议将 Kiro Crew Web Dashboard 的 5476 端口暴露在互联网，建议通过 AWS Systems Manager Session Manager 转发到本机；
• 创建 EC2 时候、或者创建完毕之后，需要给 EC2 附加 AmazonSSMManagedInstanceCore 托管策略的 IAM 角色，此时 Session Manager 才有权限提供转发；
• 安全组出站请求一般整体都放行，即出站允许 0.0.0.0/0 。

总体链路如下：

Kiro Crew 桌面应用 / 浏览器 / 本机 Kiro CLI
                 │
                 │ 远程 SSH 登录或 AWS Systems Manager 之 Session Manager 登录
                 ▼
           127.0.0.1:5476
      本机 Web Dashboard 转发端口
                 │
                 │
                 ▼
   云端 EC2 Ubuntu 24.04 LTS 虚拟机
      原生 systemd 服务 Kiro Crew Gateway

2、安装系统依赖、Kiro CLI

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

sudo apt-get update
sudo apt-get upgrade -y
sudo apt-get install -y ca-certificates curl git python3 python3-pip python3-venv unzip
sudo reboot

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

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

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

3、Kiro Crew 安装和后台服务配置

注意：如果您是使用 EC2 Session Manager 登陆到 Ubuntu 的，必须强制设置自己的身份：

sudo -u ubuntu -i

# 收紧 AppArmor 附着路径链（幂等，可反复执行）
BIN=$(readlink -f "$HOME/.local/bin/kirocrew")
D="$BIN"
while [ "$D" != "$HOME" ] && [ "$D" != "/" ]; do
  chmod g-w,o-w "$D"
  D=$(dirname "$D")
done

# 让 cgroup v2 资源上限可用
sudo loginctl enable-linger "$USER"

执行如下命令安装 stable 通道的最新版本：

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

返回结果如下：

sing a managed Python (the default; opt out with --system-python).
Downloading uv 0.10.11 (x86_64-unknown-linux-musl) ...
Installed Python 3.12.13 in 780ms
 + cpython-3.12.13-linux-x86_64-gnu (python3.12)
Provisioned managed Python: /home/ubuntu/.kiro/crew-python/cpython-3.12-linux-x86_64-gnu/bin/python3.12
Resolving KiroCrew (stable channel) ...
Verified signed manifest.
Downloading kirocrew 0.5.0 ...
Verified SHA-256.
Installing into managed venv at /home/ubuntu/.kiro/crew-venv ...

Installed kirocrew 0.5.0 (channel: stable).

Next steps:
  kirocrew gateway            # start the dashboard now (http://localhost:5476)
  kirocrew service install    # run it 24/7 as a service (survives logout, restarts on crash)
  kirocrew --help             # everything else

Need a non-default port (e.g. 5476 is already taken)? Set it at install time;
it is baked into the service unit:
  KIROCREW_PORT=5477 kirocrew service install

安装完毕后执行配置向导：

kirocrew gateway

返回结果如下：

kirocrew gateway
👻 Created default config: /home/ubuntu/.kiro/crew/config.json
09:00:33 WARNING kiro_crew.sandbox: SECURITY: cgroup v2 scope enforcement unavailable (cannot read delegated controllers: [Errno 2] No such file or directory: '/sys/fs/cgroup/user.slice/user-1000.slice/cgroup.controllers'); agent subprocess fork-bomb / memory-DoS ceilings are NOT enforced on this host. RLIMIT_NOFILE still applies. See docs/architecture/resource-protection.md.
👻 Checking for updates…
👻 Dashboard:
   http://localhost:5476?token=eyJzdWIiOiJsb2NhbC1zdGFydHVwIiwiZXhwIjoxNzg5MDMxMTM0LjE3MTQ2NTksInNlc3Npb25fZXhwIjoxNzg5MTAyODM0LjE3MTQ2NTksImlhdCI6MTc4OTAzMDgzNC4xNzE0NjU5LCJub25jZSI6IjFhYjQ1OWZmY2E1OWYyZTEiLCJnZW4iOjB9.xGbgxaYn9W1T8jTQr2x1ayIbpO6050Q9JaE4XGgYAeY
👻 Remote:    ssh -NL 5476:localhost:5476 ip-172-16-0-87
👻 Probing MCP servers…
👻 Already on latest version
👻 Kiro Crew gateway starting…

⚠️  Do not enter sensitive, secret, or regulated data into KiroCrew.
   Treat anything you send as potentially logged or processed by the
   configured model provider.

09:00:34 WARNING kiro_crew.browser_cli.launch: installed playwright-cli does not expose the stable daemon socket/session hooks; leaving its lifecycle environment unchanged

现在服务进程已经启动，安装完毕，这里还打印了登陆 URL，但是我们不使用这个 URL，而且他的 Token 一会还会过期，我们会重新生成。

现在按 Ctrl + C 停止服务，我们继续将其配置为后台服务。执行如下命令：

kirocrew service install

安装完毕。且服务启动服务。执行 kirocrew status 确认服务已经启动：

Kiro Crew gateway is running (token auth enabled).
  For detailed stats, see the Overview page in the dashboard.

接下来配置远程端口映射，将 EC2 的 5476 端口映射到本机，即可远程访问。

4、在开发者本机上使用 AWS EC2 Session Manager 进行端口转发

(1) 两种端口转发方式

本文通过设置端口转发来访问。在展开操作之前，先明确两种隧道方式的取舍：

因为本文讲解部署在 AWS 上，且为了安全起见，EC2 不开放 SSH 端口，所以选择方法 2 之 Session Manager。

(2) 安装 AWS CLI 和 Session Manager Plugin

从如下网址，下载对应的操作系统的 AWS CLI。

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

安装后，还需要填写 Access Key/Secret Key，完成访问 AWS 的密钥配置。

从如下网址，下载对应的操作系统的 Session Manager plugin。

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

按照以上文档，下载并完成安装。

(3) 启动端口转发

注意，需要事先配置 AWS CLI 所需要的 Access Key/Secret Key。

执行如下命令进行转发：

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...

现在远程 EC2 Ubuntu 的 5476 端口已经转发到本机的 5476 端口了，保持当前 SSH 窗口打开，不要关闭。关闭的话，转发连接就失效了。

5、获取登陆 Kiro Crew 的认证 Token 并访问 Kiro Crew Dashboard

回到 EC2 Ubuntu Linux，执行如下命令：

kirocrew token

返回如下：

http://localhost:5476?token=eyJzdWIiOiJsb2NhbC1hcHAiLCJleHAiOjE3ODkwMzQ1MTcuNTQ4MTQ3Nywic2Vzc2lvbl9leHAiOjE3ODkxMDYyMTcuNTQ4MTQ3NywiaWF0IjoxNzg5MDM0MjE3LjU0ODE0NzcsIm5vbmNlIjoiZWNmZTI5NmE3YjBkOTY0OCIsImdlbiI6MH0.1w0L9M-lxzstX18AMBIR4wwmlkDCP_ly7KSWXgoTczo

在确认上一步 Session Manager 转发端口生效的情况下，把这个 URL 复制到开发者本机，即可看到网页访问 Kiro Crew 正常。如下截图。

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

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

1、Kiro Crew CLI 的常用命令

Kiro Crew CLI 提供聊天、任务执行、日程管理、子代理管理和 Gateway 运维等能力。以下命令均在 0.5.0 版本上验证有效，常用命令如下：

除上述与本文部署流程直接相关的命令之外，0.5.0 版本还提供以下命令分组，供后续运维与治理使用：

注意：kirocrew gateway 与 kirocrew service install 启动的是同一个 Gateway，区别仅在于生命周期。前者在前台运行，随 Ctrl-C 或终端关闭而终止；后者以 systemd 单元或 launchd 代理的形式常驻，可在登出后存活、崩溃后重启并随系统启动。由于二者绑定同一端口，同一时间只能运行其中之一。

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

kirocrew --help

单个子命令的选项通过如下形式查看：

kirocrew <command> -h

2、子代理的执行模型

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

常用命令如下：

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

默认 agent.max_subagents=0 表示根据环境自动计算并发上限；自动值下限为 3（_LEGACY_DEFAULT_MAX），默认上限由 agent.subagent_auto_max=32 约束。单个子代理硬超时为 agent.subagent_timeout_secs=1800 秒，默认工具调用或 turn 预算为 agent.subagent_max_turns=100，空转判定阈值为 agent.subagent_stall_idle_secs=120 秒，相邻子代理的启动间隔为 agent.subagent_spawn_stagger_secs=2.0 秒，相关值均可通过配置治理。当前实际生效值可执行如下命令确认：

kirocrew config get agent.max_subagents

子代理的完整结果保存在：

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

该路径以数据主目录（data home）为基准解析，默认即 ~/.kiro/crew。结果文件在交付后保留 agent.subagent_result_ttl_secs=3600 秒，超过该窗口会被回收进程清理，因此需要留档的结论应及时转存。同目录下的 state.json 记录任务描述、父会话、状态、已执行 turn 数与最后一次工具调用，可用于排查中断原因。

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

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

六、安全最佳实践

1、网络、身份与凭证

推荐控制措施如下：

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

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

关于最后一条需要展开说明。该配置项的作用是允许 Agent 子进程在完全没有操作系统级约束的情况下运行，代价是子进程可以读取用户主目录，包括 ~/.aws 与 ~/.ssh。Kiro Crew 仍会清理凭证类环境变量，但无法阻止一个有恶意的仓库或文档读取文件。因此在 Ubuntu 24.04 上遇到沙箱不可用时，正确做法是按第四章第 5 节修复用户命名空间与 AppArmor 配置，而不是打开这个开关。该开关的授予动作本身也会写入审计日志，审计日志不可写时 Kiro Crew 会拒绝授权并保持失败关闭状态。

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

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

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

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

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

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

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

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

4、成本与可用性边界

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

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

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

七、小结

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

八、参考文档

Kiro Crew 官方快速入门：

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

最后修改于 2026-08-07