AWS 开源了 Kiro Crew，却把智能体框架留在了手里

Kiro Crew 是开源的吗？是，而且确实是开源，开放的部分甚至比我预想的更多。但真正让它变得有用的那一层也开源了吗？这是另一个问题，而这次发布最值得看的地方，恰恰就在答案里。

8 月 4 日，AWS 发布了 Kiro Crew。它是一个持久化智能体工作区，可以让编程智能体跨会话、定时任务和消息入口持续运行，并以 Apache 2.0 许可证开源。它最初只是 Amazon 内部一个叫 MeshClaw 的副项目，不到六个月就扩展到 39,000 多名内部开发者，如今则进入了公开仓库，并采用开放治理模式。我把发布公告、仓库和许可证都读了一遍，也花了些时间把仓库里真正开放的东西，与产品要正常工作仍然必须从 AWS 获得的部分逐层对照。那条边界是有意画在那里的。在你决定站在哪一边构建之前，最好先把它看清楚。

要点速览 - Kiro Crew 是 AWS 推出的持久化智能体工作区，于 2026 年 8 月 4 日以 Apache 2.0 许可证开源。它最初是 Amazon 内部的副项目 MeshClaw，公开发布前已有 39,000+ 名开发者使用。 - 已开源的部分包括：网关（会话、记忆、调度、审批、安全策略）、仪表盘、CLI、桌面应用、应用与 App SDK、技能，以及完整的安全栈。这些部分都可以阅读源码、分叉并自行托管。 - 仍然闭源的部分包括：Kiro CLI，也就是 Crew 通过 Agent Client Protocol 驱动的智能体引擎，以及 Kiro 的登录、模型路由和点数计费。Crew 的智能体提供方固定为 ACP 和 kiro-cli，因此每一次模型调用仍会经过 AWS 的商业产品。 - 这是一个部分开放的厂商智能体框架，不是开放的智能体运行时。可以对照 TrueForge，它把智能体框架本身以 MIT 许可证开源，并把任何模型都当成普通端点。 - 这个设计依然有价值。自托管状态、可见的记忆，以及认真做过的安全模型都是真东西。只是你需要清楚，自己真正押注的是哪一层。

发生了什么

2026 年 8 月 4 日，AWS 发布了 Kiro Crew 公告，并以 Apache 2.0 许可证开放了 kirodotdev/KiroCrew 仓库。同一周，SiliconANGLE 和 DevOps.com 都做了报道。我查看时，仓库大约有 3,400 个星标和 400 个分叉。几个关键事实是：

• Kiro Crew 是面向开发智能体的持久化工作区，可以运行无人值守的多步骤任务、按计划重复执行的作业、持续观察 PR 或部署直到需要人工处理的心跳任务，以及并行展开后再汇总结果的子智能体。

• 它运行在你指定的地方：桌面应用、一行命令安装、GHCR 上的 Docker 镜像，或者由你控制的远程 Linux 主机。状态（会话、记忆、检查点）保存在你自己的硬件上，路径是 ~/.kiro/crew，而不是 AWS 的控制平面里。

• 你可以通过网页仪表盘、CLI、桌面应用或消息平台把工作交给它，包括 Slack、Discord、Telegram、Teams、Webex、WeCom、WeChat 和 WhatsApp。

• 它源自 MeshClaw，这是 Amazon 内部一个受 OpenClaw 启发的副项目。公告称，在公开发布前，它已经覆盖 39,000+ 名内部开发者，有近 500 名贡献者提交了接近 600 次更新。

• 治理方式是公开的：MAINTAINERS.md 中列出了指导委员会，提案通过拉取请求提交并公开讨论。目前维护者仍是 Kiro 和 AWS 的工程师，但项目明确表示，随着可信的外部贡献者出现，会逐步加入外部维护者。

Kiro Crew 是 AWS 于 2026 年 8 月 4 日发布的开源持久化智能体工作区，采用 Apache 2.0 许可证。根据 AWS 的公告和项目仓库，它可以在用户自己的硬件上自托管，运行无人值守的多步骤任务、定时作业、心跳任务和子智能体。

哪些层开放了，哪些没有

这一部分大多数报道都略过去了，所以我自己把仓库翻了一遍。它的架构可以分成三层：你直接使用的交互入口（仪表盘、桌面端、CLI、消息平台），保存状态的网关（会话、记忆、计划任务、审批、安全策略），以及真正执行模型循环的智能体会话。许可证的边界落在这里：

真正承重的那条线写在配置文档里：agent.provider 固定为 acp，Kiro Crew 通过 Agent Client Protocol 驱动 kiro-cli。每一次模型请求，都是由你 Kiro 账户下的 kiro-cli 按照对应模型配置处理。工作区、记忆、计划任务、安全策略都属于你，可以分叉，也可以验证。真正负责推理的引擎，以及负责计费的计量器，则属于 AWS。

Kiro Crew 的网关、交互入口、应用和安全层都在 KiroCrew 仓库中以 Apache 2.0 许可证开源，但底层智能体引擎 kiro-cli 仍是 AWS 的闭源产品。Crew 的智能体提供方固定通过 ACP 接入 kiro-cli，因此模型访问、登录和点数计费仍由 AWS 控制。

为什么边界偏偏画在这里

最省事的解读是，AWS 开源 Crew 要么是在释放善意，要么是在设套。更有用的解读其实简单得多：这条边界沿着钱走，而且 AWS 画得并不遮掩。

工作区可以送出去，引擎和计量器要留下来。很多合理的开源基础设施本来就是这么做生意的，AWS 对这一点也说得很直白：公告明确写着 Crew 运行在 Kiro CLI 之上，并且开箱即可读取你现有的 .kiro 配置。如果你本来就在用 Kiro，那 Crew 基本就是白送的增强包。原来的引导文件、技能和自定义智能体都能直接沿用，同时免费得到持久化、定时调度和十来种消息入口。39,000 名内部用户说明这种产品形态确实能在规模化环境里跑起来，而不只是一句营销话术。

但也要看看这种开放给 AWS 带来了什么。每一次 Crew 安装，本质上也都是一次 Kiro 安装，因为首次启动会配置 kiro-cli 并完成设备代码登录。每一次智能体回合都会消耗 Kiro 点数，具体模型由 Kiro 路由决定，而 Kiro 在 Bedrock 上的路由已经覆盖 Claude 以及中国的开放模型 Qwen、DeepSeek、GLM、MiniMax。一位早期用户做个人项目时，一周就烧掉了 5,000 点。这很好地说明了，一个始终在线的智能体工作区会怎样消耗按量计费的模型套餐。开放层把更多人送进闭源层，而闭源层才是收入所在。这一点既没有被藏起来，也谈不上阴险。只是值得看清，因为同一周还出现了一个完全开放的替代方案，它把边界画在了另一个位置。

开放层里还有一件事值得认真肯定。它的安全模型不是靠提示词约束，而是在运行时边界强制执行：Linux 和 macOS 上有操作系统级沙箱，命令默认拒绝，凭据会脱敏；Windows 上采取失败即拒绝的策略，除非你明确选择放开，否则智能体子进程宁可不运行，也不会在没有隔离的情况下启动。因为这些实现全都在仓库里，你可以逐层验证，而不是只能相信厂商网页上的一句话。这也是最有力的证据，说明它开放的部分是真的，不是表演。

Kiro Crew 的开放工作区会把用户导向闭源且按量计费的 Kiro 引擎：每次安装都会配置 kiro-cli 和 Kiro 登录，每个智能体回合也都会消耗 Kiro 点数。与此同时，安全栈本身确实开放且可以审计，包括操作系统沙箱、命令默认拒绝、凭据脱敏和审计日志，代码都在项目仓库里。

和 TrueForge 放在一起看

Kiro Crew 发布两周后，TrueFoundry 以 MIT 许可证发布了 TrueForge。把两者放在一起，正好能做一个很干净的自然实验：一家厂商到底愿意把智能体栈里的多少东西交出来。

TrueForge 开源的是智能体框架本身，包括包在模型外面的循环、会话、沙箱、审批和上下文管理。任何兼容 OpenAI 的端点都能接进去，因此能完成任务的最低成本模型就可以拿到这份工作负载；商业层则放在更下面，作为一个可选网关，你完全可以不用。Kiro Crew 开源的则是框架周围的一切：持久化、调度、交互入口和安全策略。框架本身，也就是 kiro-cli，仍然闭源，而它背后的模型层正是商业产品。

两种做法都谈不上不诚实，但承诺完全不同，失效方式也不同。你分叉 TrueForge，仍然保有一个能工作的智能体运行时，只是失去 TrueFoundry 的网关和支持。你分叉 Kiro Crew，得到的是一个很优秀、却没有引擎的工作区。一旦 kiro-cli 改协议、改价格或调整退役时间表，你的分叉版本也得跟着承担后果。如果你正在为自己的智能体栈权衡自研还是采购，那么面对任何部分开放的产品，都应该先问这个问题：厂商路线图一动，究竟哪一层会停止工作？我在谈智能体架构时也说过类似的事。真正有意思的问题很少只是选哪个模型，而是模型外面包了什么，以及那层东西到底归谁。

还有一个我忍不住要加的杭州脚注：Kiro 的路由已经把 Qwen、DeepSeek、GLM 和 MiniMax 当作 Bedrock 上的一等模型来处理，Crew 也直接内置 WeCom 和 WeChat 连接器。中国模型和中国消息平台，已经成了美国厂商技术栈里很普通的组成部分。我在其中一半模型诞生的城市看到这件事，多少还是有点开心。

现在该怎么做

如果你正在评估 Kiro Crew，我建议按顺序做三件事。

1. 今天： 安装之前先读仓库。从 README 的架构部分、GOVERNANCE.md 和 MAINTAINERS.md 开始，然后看安全文档。开放这一层最大的意义，就是你可以自己验证，那就真的去验证。安装本身只要一行命令，仪表盘默认也只绑定 localhost。

2. 本周： 先拿一个边界明确、风险较低的工作负载去跑，例如定时盯 PR、每天早上的摘要、周期性审查。通过 Activity 视图和审计日志观察它做了什么，也盯住点数消耗。持久化智能体会在你睡觉时继续花钱，这既说明产品按设计正常工作，也意味着预算问题必须一起谈。

3. 本月： 决定你真正要承诺的是哪一层。如果团队已经全面使用 Kiro，Crew 很容易就是“可以上”。如果你从零开始选技术栈，就把这条边界和 TrueForge 这类完全开放的智能体框架放在一起比较，并在团队工作流被固化之前想清楚自托管的取舍。如果决定继续用，Crew 的 MCP 支持意味着现有工具基本都能带过来。我的值得接入的 MCP 服务器清单可以作为起点。

常见问题

Kiro Crew 是开源的吗？

工作区是开源的。网关、仪表盘、桌面应用、CLI、应用、技能和整个安全栈都以 Apache 2.0 许可证放在 kirodotdev/KiroCrew 仓库里，你可以完全在自己的硬件上自托管，不需要 AWS 控制平面。底层智能体引擎 kiro-cli 则不是开源的，而 Crew 没有它就无法运行。所以，用“开源”描述这个仓库是准确的，但如果拿来描述整个产品，就不完整。

Kiro Crew 需要 AWS 账户吗？

它需要 Kiro 登录，模型访问和点数计费都由 kiro-cli 通过这个账户处理。在本地使用时，你不需要把任何东西部署进 AWS 账户，工作区和状态都留在自己的机器上。如果你想要一个始终在线的远程实例，kirocrew cloud launch 可以在你自己的 AWS 账户中启动 EC2，但普通 Linux 服务器或家里的实验环境也能用。

Kiro Crew 和 Kiro 的自主模式有什么区别？

区别在范围。自主模式处理的是单个会话中的一个任务，而且你通常就在旁边看着。Crew 会跨会话和重启保持状态，不管你是否在线都能执行定时任务和响应式任务，并行编排子智能体，还能在多次运行之间延续记忆、经验和技能。它是在同一个 Kiro 引擎之上的新交互层，读取的仍是同一套 .kiro 配置。

我可以让 Kiro Crew 使用不同的智能体引擎或模型提供方吗？

目前不行。智能体提供方固定为通过 ACP 驱动 kiro-cli，因此模型来自你的 Kiro 账户当前能够路由到的范围，目前包括 Claude，以及 Bedrock 上的 Qwen、DeepSeek、GLM、MiniMax 等开放模型。项目的治理模式是公开的，维护者也表示欢迎外部贡献，所以未来出现可插拔引擎并非不可想象。但这不是现在已经交付的设计，我不会据此做规划。

最后怎么判断

Kiro Crew 是一个围绕闭源商业引擎构建的优秀开源项目，而且 AWS 对这种安排的说明，比多数厂商都直白。开放层是真的：自托管状态、可见的记忆、可审计的安全模型、公开治理。闭源层也同样是真的：真正的智能体框架、登录和计量器都还在 AWS 手里。如果你一开始就清楚自己的投入落在边界的哪一边，Crew 值得花时间。如果你需要把这条线画在别处，同一个月里也已经有一个 MIT 许可的智能体框架把它画到了那里。

如果你正在判断自己的智能体栈应该把开放边界放在哪里，这也是我经常和客户讨论的问题。联系我。

来源

• Kiro（AWS），《Kiro Crew 正式发布》：https://kiro.dev/blog/introducing-kiro-crew/ （发布于 2026 年 8 月 4 日，检索于 2026 年 8 月 29 日）

• kirodotdev，KiroCrew 仓库（README、LICENSE、GOVERNANCE.md、安全文档）：https://github.com/kirodotdev/KiroCrew （检索于 2026 年 8 月 29 日）

• Kiro，Kiro Crew 产品页（许可证与功能常见问题）：https://kiro.dev/crew/ （检索于 2026 年 8 月 29 日）

• SiliconANGLE，《AWS 发布 Kiro Crew，为 24/7 代码开发提供自主智能体编排》：https://siliconangle.com/2026/08/04/aws-launches-kiro-crew-autonomous-agentic-orchestrator-24-7-code-development/ （发布于 2026 年 8 月 4 日，检索于 2026 年 8 月 29 日）

• DevOps.com，《AWS 为 Kiro AI 编程工具加入智能体工作区》：https://devops.com/aws-adds-agentic-workspace-to-kiro-ai-coding-tool/ （发布于 2026 年 8 月 5 日，检索于 2026 年 8 月 29 日）

• Playing AWS，《使用 Kiro Crew 一周之后（以及超过 5000 点数）》：https://www.playingaws.com/posts/what-is-kirocrew/ （发布于 2026 年 8 月 8 日，检索于 2026 年 8 月 29 日）