3名开发者做出来的副业项目，半年冲进 4万人！亚马逊云科技把内部 Agent 工作台开源了

一年前，亚马逊云科技推出AI编程工具Kiro时，试图解决的是“生成代码之后怎么办”：与只凭一句提示词快速搭建原型不同，Kiro把需求、技术设计和任务拆解放在写代码之前，希望用规范驱动开发降低AI生成代码的随机性。 一年后，问题又向前推进了一步。 当开发者开始同时调度多个Agent，并把代码迁移、故障排查、依赖升级等任务交给它们持续运行数小时甚至更久，新的瓶颈不再只是模型会不会写代码，而是Agent能否跨会话记住项目背景、在无人值守时安全执行，并让开发者知道它究竟做了什么。 Kiro Crew正是在这一背景下出现的。它将持久记忆、多Agent协作、任务调度、失败重试和安全控制放进同一个工作空间，试图补齐Agent从单轮代码生成走向长期任务执行时缺少的工程控制层。 亚马逊云科技杰出开发者布道师Darko Mesaroš在近期分享中表示，长期运行并不意味着让模型无限循环，而是让任务能够跨越多个会话持续推进，同时保留必要的上下文、执行记录和人工干预入口。 从Vibe Coding到规范驱动开发，Kiro多走了一步 Kiro Crew于8月4日正式开源。与Kiro IDE面向单次开发会话、由开发者持续参与不同，Kiro Crew更像一个可以长期存在的Agent工作空间：它能够在本地电脑或远程服务器运行，协调多个Agent并行执行任务，在会话之间保留状态，还可以通过定时任务、Webhook和状态监测机制持续关注代码仓库、构建流水线与部署状态。 这也意味着，AI编程工具正在从“副驾驶”走向“任务承包者”。但从现场分享来看，亚马逊云科技并没有把这种变化简单解释为更高程度的自动化。Kiro Crew真正试图补上的，是长期委派背后的工程控制层。 Mesaroš将Kiro过去一年最核心的产品思路概括为：不只帮助开发者进行“氛围编程”，而是把规范重新带回软件开发。 所谓氛围编程，是开发者通过自然语言描述需求，由AI直接生成和修改代码。这种方式适合快速验证想法和搭建最小可行产品，但项目一旦变得复杂，单轮提示词很难完整承载业务约束、异常处理、技术选型和验收标准。模型即使生成了能够运行的代码，也不意味着它准确理解了需求。 Kiro采用的规范驱动开发，会先根据开发者的描述形成需求文档，再生成技术设计和任务清单，最后由Agent逐项执行。 Mesaroš将规范形容为开发者与Agent之间的一份“契约”：开发者可以在代码生成前检查、修改和补充目标，Agent则依据经过确认的文档工作，而不是根据一句模糊指令自行猜测。 这种设计针对的是AI编程中越来越受关注的“正确性”问题。 Mesaroš举例称，如果需求写着“用户点击按钮后，从数据库中删除一条记录”，这里仍然存在关键歧义：究竟是保留数据的逻辑删除，还是彻底移除数据的物理删除？如果这一问题直到代码完成或系统上线后才被发现，修复成本会明显上升。Kiro的需求分析会尝试在写入代码之前标记这类模糊表达，并要求进一步澄清。 过去一年，Kiro也在这条路径上补充了基于属性的测试、检查点、命令行工具和企业功能，并将使用入口扩展到IDE、网页、命令行和移动端。 据Mesaroš回忆，Kiro预览版发布后的前5天吸引了约10万名用户，随后用户数量继续增长。 不过，规范驱动并不意味着所有开发工作都需要先写一套庞大文档。对于一次性脚本、原型验证或边界清晰的小改动，直接对话依然更快。 它的价值主要出现在需求复杂、多人协作、任务周期较长，或者错误代价较高的场景。AI编程工具之间的竞争，也正在从“谁一次生成得更多”，转向谁能更好地管理需求、上下文、测试和变更过程。 Kiro Crew补齐跨会话的“工作连续性” 如果说Kiro解决的是单个开发会话中如何把事情做对，Kiro Crew解决的则是任务跨越多个会话、多个Agent甚至多天之后，如何继续向前推进。 Kiro Crew最初是亚马逊内部一个名为MeshClaw的业余项目。三名开发者希望获得一种新的工作方式：发起任务后可以暂时离开，回来时看到值得审查的结果；同时运行多项工作，而不是守着一个对话窗口不断追加提示。 据Kiro官方披露，该项目在不到6个月内被超过3.9万名亚马逊内部构建者采用，近500名贡献者参与开发。这种内部扩散最终促使团队以Apache 2.0许可证将其开源。 不过，这里需要区分的是，此次开放源代码的是Kiro Crew，而不是整个Kiro产品。Kiro Crew在底层调用Kiro命令行工具，并能够继承原有的配置、技能和自定义Agent。它既是独立工作空间，也是Kiro现有开发界面的延伸。 在实际使用中，两者的边界取决于开发者希望亲自控制还是向外委派。 Kiro IDE适合需要深入阅读和编辑代码、逐步参与决策的场景；Kiro命令行工具适合终端、远程连接和持续集成流水线；Kiro Crew则适合将多个任务交给并行Agent，在后台持续执行、重试和等待外部状态变化。 Mesaroš分享了一个例子：他为Kiro Crew提交新功能时，代码在GitHub构建环节多次失败。Agent被设定为每5分钟查看一次构建状态，分析错误、修复问题并重新提交。与简单地让Agent连续“思考”不同，这类任务包含等待、检查外部事件、执行下一步和失败重试，更接近真实的软件工程流程。 Kiro Crew还 提供面向具体工作的应用界面。例如“问题雷达”可以连接代码仓库，追踪问题和拉取请求，判断哪些事项可以处理，并为特定问题启动新的Agent会话。研发团队也可以设置每天执行的例行检查，或在构建失败、部署状态改变时触发任务。 这反映出Agent产品的一项明显变化：聊天窗口不再是唯一入口。对于故障处理、代码审查、版本迁移和依赖维护等工作，Agent需要进入代码仓库、流水线、消息工具和任务系统，成为工作流的一部分。Kiro Crew支持在本地或远程机器部署，并可通过Slack、Telegram、Discord等消息工具继续操作同一工作空间，其目的正是让任务不再依赖开发者始终守在电脑前。 记忆让Agent越用越懂，也可能把旧错误带进新项目 跨会话工作首先要解决的是记忆问题。今天不少编程Agent在会话结束后会丢失上下文，开发者不得不把进度、技术选择和注意事项整理成文本，再交给下一个会话。这不仅消耗Token，也很难在多个并行任务之间保持一致。 Kiro Crew会定期整合会话，把反复出现的问题、技术栈偏好和项目经验沉淀为语义记忆。 Mesaroš以升级云开发工具包依赖为例：当系统多次发现生成拉取请求说明时应读取专用文件，而不是通过标准输入传递内容，这一修正就可以被保留下来，供后续会话调用。 系统还会把重复工作模式推荐为可复用的技能。技能本质上是描述具体操作方式的Markdown文件。例如，在多次完成依赖升级后，Kiro Crew可以建议生成一项“验证版本升级”的技能。开发者审查并批准后，同一实例内的其他Agent便可以复用这套方法。 除了会话记忆，开发者还可以把多年积累的笔记或团队文档接入知识库。系统通过向量嵌入和全文检索，在需要时查找架构决策、编码偏好和项目背景，而不必每次重新读取全部资料。 但持久记忆同时带来一个新的治理问题：如果旧项目中的技术版本已经过期，或Agent把一次