你下班前交代 AI 排查故障，第二天回来，它不仅记得任务，还已经拆出几个分工、跑完工具，并留下结果供你检查。Kiro Crew 想实现的就是这种工作方式：把编码助手从必须守着对话框使用的工具，变成能在后台持续协作的 Agent 团队。它值得关注，因为软件开发的下一步，可能不只是让 AI 写得更快，而是改变任务如何被安排和推进。
这里的 Coding Agent，是能读取代码、调用开发工具，并自行修改和测试的软件 Agent。本文事实主要来自 InfoQ 的一篇报道，尚无独立信源交叉核验，项目能力与采用数据应视为 Amazon 方面的介绍，而非外部评测结论。
离开对话框，任务仍然继续
据 InfoQ 报道，Amazon 以 Apache 2.0 许可证开源了 Kiro Crew。它允许多个 Kiro Coding Agent 跨 Session、工具和任务协同运行。Session 可以理解为一次交互或运行周期；“跨 Session”意味着系统会把上下文和工作状态保存下来，下次不必重新认识项目。
这也是“异步”的关键：开发者提交任务后，不用一直守在电脑前。Agent 可以继续处理事故调查、工单分诊、迁移和 PR 监控，也能按时启动任务。Kiro Crew 提供共享记忆、可复用 Skills、定时任务、并发 Agent 和专用 Apps，还能把任务委派给子 Agent。多个 Agent 因而可以同时分头工作，而不是排队等待同一个对话窗口。
它通过 ACP（Agent Client Protocol，一套协调 Agent 的接口协议）进行编排。Activity 视图则像一块工作看板，实时展示各 Agent 的计划、工具调用、等待审批的位置和执行结果。开发者可以离开，但并非完全失去观察和介入的入口。
把 Agent 接进现有工具链
Kiro Crew 可通过 MCP 和 Webhook 连接外部工具。MCP 是让模型用统一方式访问数据和工具的协议；Webhook 则让外部事件主动通知系统。例如，新的工单或代码更新出现后，相关流程可以被触发，而不必等人手动发出下一条提示。
系统运行在 Kiro CLI 之上，可以沿用已有的 .kiro 配置，包括 Steering 文件、Skills 和自定义 Agent。Amazon 还称，它能直接使用其他开放、基于标准的 Agent 平台所构建的 Skills，无需修改。这个兼容性说法目前没有材料说明适用标准、版本和边界。
部署方式也强调控制权：项目既可在本地运行，也可放到开发者自己管理的基础设施上。目前报道列出的支持平台包括 macOS、Linux 和 Windows，并提到 Slack、Telegram 与企业微信集成。
三个人的业余项目，为何长成团队工具
据 Kiro 官方博客转述，Kiro Crew 的前身叫 MeshClaw，最初是三名工程师受常驻型 Agent 启发做出的业余项目。他们想要一种“交代任务后走开”的体验，同时满足 Amazon 内部的安全要求。工具开放给同事后，使用者开始直接补上各自需要的功能，最终推动团队将它开源。
InfoQ 称，该工具已被超过 3.9 万名 Amazon 内部开发者采用。不过，“采用”究竟指注册、试用还是活跃使用，材料没有说明。社区人士所称的“六个月内近 500 名贡献者、并非强制推广”，也只有单一评论来源，不宜据此判断真实渗透率。
真正的变化是编排，而不只是生成
单个编码助手解决的是“这一段代码怎么写”。Kiro Crew 更关心“这批工作由谁做、何时做、做到哪一步需要人批准，以及失败后如何接续”。共享记忆、持久化状态、子 Agent 委派和外部工具连接，组合起来才构成一个可持续运行的协作系统。
这也把风险从一次回答扩展到连续行动。项目方称其采用纵深防御设计，包括操作系统级沙箱、默认拒绝命令、可疑模式拦截、输入验证、敏感路径保护、凭据脱敏和签名审计日志。纵深防御的意思是设置多层关卡，避免一道保护失效便直接暴露系统。但这些属于项目方宣称，不能等同于经过独立安全审计。
局限与未知
- 现有材料没有提供独立测试，无法判断异步任务的成功率、恢复能力和多 Agent 协作质量。
- 各项安全机制的默认启用范围、隔离强度及不同操作系统上的差异尚不清楚。
- 有用户反映 Kiro Crew 比 Kiro CLI 消耗 Token 更快，但没有任务、模型、并发度或统计方法，暂时不能据此得出成本结论。
Kiro Crew 初期将由 Kiro 和 AWS 工程师维护，并计划逐步让社区参与开发、路线图规划和项目维护。眼下最值得观察的，不是它列出了多少功能，而是这种后台常驻、跨会话接力的 Agent 团队，能否在可控成本与安全边界内稳定完成真实开发工作。