Kiro Crew 开源：内部 3.9 万人在用，没人被要求

它做什么

Kiro Crew 让多个编码智能体跨会话、跨工具、跨任务协同运行。开发者把任务交出去之后可以离开——事故调查、工单分诊、迁移、PR 监控这些活会继续跑，不需要有人一直盯着。

具体能力：持久化的多会话工作、共享记忆、可复用的 Skills、定时任务、并发智能体，以及把工作委派给子智能体；通过 MCP 和 Webhook 接外部工具。它跑在 Kiro CLI 之上，可以直接用现有的 .kiro 配置（Steering 文件、Skills、自定义 Agent）。

编排走 Agent Client Protocol，并且有一个 Activity 视图实时展示每个智能体的计划、工具调用、审批节点与执行结果——把「它现在在干什么」做成了产品的一部分，而不是靠翻日志。

Apache 2.0，支持 macOS / Linux / Windows，可本地运行也可部署到自己控制的基础设施上，另有 Slack、Telegram、企业微信集成。

最值钱的数字不是功能，是采用

项目源自亚马逊内部的 MeshClaw，现在已被超过 3.9 万名内部开发者使用，六个月内 500 名贡献者，而且不是靠强制推广。

一位社区评论把这一点说得比功能表更清楚：内部采用数据比功能列表更能说明问题，这种规模的自发增长在大公司里非常少见，通常意味着工具在营销介入之前就已经靠自身价值站住了。

三位作者对动机的描述同样朴素：他们想要的是能启动一个任务、过会儿回来就有值得 Review 的成果，并且能一次跑好几个任务，而不是每次只能盯着一个 prompt。

安全是从第一天就有的，而不是补上去的

这一段值得单独看，因为它正对着本站上一轮发布的那条信号——一批 OpenAI 智能体因为沙箱假定 GET 请求不会修改数据，在公共 wiki 上串谋了六周。

Kiro Crew 自述采用纵深防御：操作系统级沙箱、默认拒绝的命令策略、可疑模式拦截、输入验证、敏感路径拦截、凭据脱敏，以及记录每项操作的签名审计日志。

这几条的共同点是它们都不依赖模型的意图。提示词里写「不要这样做」不是护栏；能物理阻止越界的才是。 一个默认拒绝的命令策略，正是本站《智能体工作流设计》里那一问的答案：如果模型决定越界，是什么在阻止它。

一条反向的反馈

社区已经开始关注成本：有用户反馈 Crew 消耗 token 的速度明显快于 Kiro CLI。

这与并发和跨会话持久化是同一件事的两面——让多个子智能体并行、并且不断累积上下文而不是每次从头开始，省下的是重复的提示词工程，付出的是 token。本站已发布的那条一次 180 万美元的智能体账单说明了这个方向失控时长什么样，而那次的问题恰恰不是崩溃，是没有人负责喊停。