Kiro Crew：让 agent 工作跨会话持续的开源常驻工作台

Kiro Crew 是 kirodotdev 开源的开发工作台，采用 Apache 2.0 许可。它的定位很明确：一个「持久、自学习、自演进」的工作空间，可以跑在你自己的本机或远程主机上，让开发工作在一次会话结束之后继续向前。多数 agent 会话在聊天窗口关闭时就结束了。Kiro Crew 反其道而行：它以一个常驻的 Gateway 进程为核心，把会话、记忆、计划任务和任务检查点都保存下来，在两次对话之间依然保持工作。 从公开的项目说明可以拆出四层结构。第一层是 Gateway，一个常驻服务，默认监听 5476 端口；官方 Docker 示例把它绑定在 127.0.0.1，说明默认姿态是只对本机开放。第二层是入口：桌面应用、Web 仪表盘和命令行，外加 Slack、Discord 等连接工具，同一项工作可以在这些入口之间接续。第三层是 agent 后端：默认 agent 运行在 kiro-cli 之上，通过 ACP 后端接入，同时项目提到还有其他经过验证的 ACP harness。第四层是 Kiro Crew Apps：把一个为特定任务定制的界面，与 agents、skills、计划任务、集成和后端服务打包在一起。

它的核心机制可以归结为三件事。第一是持久化。会话、记忆、计划任务和任务检查点在 Gateway 重启后依然存在。检查点的意义在于：多步任务被打断后，可以从断点恢复，而不是整个重来。第二是无人值守执行。多步任务可以在无人盯着终端时运行，周期性作业按你设定的日程触发，心跳（heartbeat）持续监控系统，直到出现需要人介入的情况才提醒。第三是自学习。项目称纠正和任务失败会被沉淀为持久的经验。需要说明的是，我们拿到的 README 节选在这里被截断，具体如何存储、如何复用这些经验，要以官方文档为准。 分发和安装方式透露了工程上的取舍。一行命令 curl -fsSL https://download.crew.kiro.dev/cli.sh | sh 会安装已签名的 Stable wheel，无需克隆仓库或自己构建前端。用 --version 可以固定版本，但最低只能固定到 0.1.2，原因是 0.1.0 和 0.1.1 发布时还没有清单签名，无法验证。这说明团队把供应链完整性放在了明处。项目还提供三个发布通道：Stable 为默认，Insider 跟随候选发布，Nightly 跟随 main 分支。容器方面，Gateway 以多架构公共镜像发布在 GHCR，适合常驻服务器。源码构建要求 Python 3.12 以上、Node.js 22.12 以上，流程是 make build，然后依次运行 kirocrew setup、kirocrew doctor 和 kirocrew gateway。其中 doctor 命令用来在启动前检查环境。

关于性能，要说清楚一点：我们看到的公开材料里没有基准测试数据，没有延迟、吞吐或任务成功率的对比，因此本文不会编造任何数字。可以做的是定性判断成本结构。Kiro Crew 自身是调度与持久化层，真正的推理开销来自它所连接的 agent 后端，默认是 kiro-cli 背后的模型调用。常驻的计划任务和心跳意味着持续的后台调用，团队需要为这部分自行做预算，并为心跳设置合理的频率。换来的好处是人的时间：同一件事不必每次重新交代背景。 对开发者和企业的影响，主要在三个方面。其一，工作方式从「一次性对话」变成「长期队友」，记忆和检查点让上下文不再随会话消失。其二，自托管加 Apache 2.0 许可，让代码和数据留在自己的硬件上，这对有合规要求的团队很有吸引力。其三，ACP 兼容的多 harness 设计降低了对单一 agent 的绑定。Slack 和 Discord 的接入，则让它能进入团队已有的沟通流程。Trendshift 上的榜单标记也显示它在发布初期就受到了开发者社区的关注。 局限同样明显。第一，默认后端要求你另行安装并登录 kiro-cli，首次启动会检查这一前置条件，缺失时给出官方指引。第二，无人值守运行放大了权限风险：一个能长期自主执行任务的 agent，必须配合沙箱、最小权限和审计，项目为此提供了安全策略文档和沙箱设置，使用者应当认真阅读。第三，「自学习」是一把双刃剑：被固化下来的错误经验会反复影响后续任务，需要有人审查和修剪。第四，项目版本仍然很早，文档里以 0.6.0 作为固定版本的示例，接口和行为可能继续变化。此外，项目含有匿名使用遥测章节，企业用户在部署前应当确认其范围和关闭方式。 如果把它放进团队的日常流程，可以设想这样的用法：白天由工程师通过桌面应用或 Slack 交代任务，夜里 agent 继续执行多步工作并在检查点保存进度；定时作业负责例行巡检，心跳在系统出现异常时才提醒负责人。第二天早上，同一个会话里的记忆和进度都还在，人只需要审阅结果，而不是重新搭建上下文。这种模式对长周期、低频但需要持续跟进的工作尤其合适，比如依赖升级、日志巡查、文档同步和回归检查。当然，这些场景是基于公开功能描述的推演，具体效果取决于所接 agent 的能力和你设定的权限范围。 总的来看，Kiro Crew 值得关注的地方，不在于某个单项指标，而在于它把「agent 要长期在线」这件事当作一等公民来设计：持久化的状态、可恢复的任务、定时与心跳、多入口接续、签名分发。能否兑现承诺，要看自学习的质量和无人值守时的安全边界，这两点值得在后续版本中持续观察。