亚马逊Kiro Crew开源：AI编程从单次迈向长期

当AI编程工具从单轮代码生成转向规模化工程应用时，开发者们遇到了新的瓶颈：当多个智能代理（Agent）同时被调度，将代码迁移、故障排查、依赖升级等任务交给它们持续运行数小时甚至更久，如何让这些Agent跨会话记住项目背景、在无人值守时安全执行，并让开发者清晰掌握任务进展？

一年前推出的Kiro，最初瞄准的是“生成代码之后怎么办”的问题——区别于仅通过自然语言提示快速搭建原型的工具，Kiro将需求梳理、技术设计和任务拆解前置到编码环节之前，通过规范驱动开发降低AI生成代码的随机性。

正是为了解决跨会话长期任务的痛点，Kiro Crew在今年8月4日正式开源。这款工具将持久记忆、多Agent协作、任务调度、失败重试和安全控制整合到同一个工作空间中，填补了AI代理从单轮交互走向长期工程执行时缺失的工程管控层。

业内常说的“氛围编程”，指开发者通过自然语言描述需求，由AI直接生成和修改代码。这种方式适合快速验证想法和搭建最小可行产品，但一旦项目复杂度提升，单轮提示词很难完整承载业务约束、异常处理、技术选型和验收标准，即便AI生成了可运行的代码，也未必准确匹配真实需求。Kiro的规范驱动开发模式，则先根据开发者的描述生成需求文档，再输出技术设计方案和任务清单，最终由Agent逐项执行。

相关负责人表示，规范就像是开发者和Agent之间的“契约”：开发者可以在代码生成前检查、修改和补充目标，Agent则依据经过确认的文档开展工作，而非根据模糊指令自行猜测。这种设计直击AI编程中日益受关注的“正确性”问题——比如当需求描述为“用户点击按钮后，从数据库中删除一条记录”时，仍存在关键歧义：究竟是保留数据的逻辑删除，还是彻底移除数据的物理删除？如果这类问题直到代码完成或上线后才被发现，修复成本会大幅上升。Kiro的需求分析模块会在编码前标记这类模糊表达，并要求开发者进一步澄清。

过去一年间，Kiro在这条路径上补充了基于属性的测试、检查点、命令行工具和企业级功能，使用入口也扩展到IDE、网页、命令行和移动端。根据官方数据，Kiro预览版发布后的前5天就吸引了约10万名用户，后续用户量持续增长。

不过规范驱动开发并不意味着所有开发工作都需要先撰写一套庞大的文档，对于一次性脚本、原型验证或边界清晰的小改动，直接对话交互依然效率更高，其核心价值主要体现在需求复杂、多人协作、任务周期较长，或者错误代价较高的场景中。当前AI编程工具的竞争，也正在从“谁一次生成的代码更多”，转向“谁能更好地管理需求、上下文、测试和变更流程”。

如果说Kiro解决的是单个开发会话中如何把事情做对，Kiro Crew则聚焦于任务跨越多个会话、多个Agent甚至多天之后，如何持续推进工作。

Kiro Crew最初是内部一个名为MeshClaw的业余项目，三名开发者希望实现一种全新的工作模式：发起任务后可以暂时离开，回来时就能看到值得审查的结果；同时可以运行多项工作，而不必始终守在对话窗口中追加提示。根据官方披露，该项目在不到6个月的时间里就被超过3.9万名内部构建者采用，近500名贡献者参与开发，这种内部广泛的使用最终促使团队以Apache 2.0许可证将其开源。

需要注意的是，此次开源的是Kiro Crew而非整个Kiro产品，它在底层调用Kiro命令行工具，可以继承原有配置、技能和自定义Agent，既是独立的工作空间，也是Kiro现有开发界面的延伸。在实际使用中，两者的边界取决于开发者希望亲自参与控制还是向外委派任务：Kiro IDE适合需要深入阅读和编辑代码、逐步参与决策的场景；Kiro命令行工具适合终端、远程连接和持续集成流水线；而Kiro Crew则适合将多个任务交给并行Agent，在后台持续执行、重试和等待外部状态变化。

比如相关负责人分享的案例：他在为Kiro Crew提交新功能时，代码在GitHub构建环节多次失败，Agent被设定为每5分钟检查一次构建状态，自动分析错误、修复问题并重新提交。这类任务包含等待、检查外部事件、执行下一步和失败重试，更贴近真实的软件工程流程。

Kiro Crew还提供面向具体工作的应用界面，例如“问题雷达”可以连接代码仓库，追踪问题和拉取请求，判断哪些事项可以处理，并为特定问题启动新的Agent会话。研发团队也可以设置每日执行的例行检查，或在构建失败、部署状态改变时触发任务。

这也反映出Agent产品的一个明显变化：聊天窗口不再是唯一的交互入口，对于故障处理、代码审查、版本迁移和依赖维护等工作，Agent需要接入代码仓库、流水线、消息工具和任务系统，成为工作流的一部分。Kiro Crew支持在本地或远程机器部署，还可以通过Slack、Telegram、Discord等消息工具继续操作同一工作空间，目的就是让任务不再依赖开发者始终守在电脑前。

跨会话工作首先需要解决的是记忆问题，当前不少编程Agent在会话结束后会丢失上下文，开发者不得不手动整理进度、技术选择和注意事项，再传递给下一个会话，这不仅消耗Token资源，也很难在多个并行任务之间保持一致性。

Kiro Crew会定期整合会话，将反复出现的问题、技术栈偏好和项目经验沉淀为语义记忆。比如在升级云开发工具包依赖的场景中，当系统多次发现生成拉取请求说明时应读取专用文件，而非通过标准输入传递内容，这一修正就可以被保留下来，供后续会话调用。

系统还会将重复出现的工作模式推荐为可复用的技能，技能本质上是描述具体操作方式的Markdown文件，例如在多次完成依赖升级后，Kiro Crew可以建议生成一项“验证版本升级”的技能，开发者审查并批准后，同一实例内的其他Agent就可以复用这套方法。

除了会话记忆，开发者还可以将多年积累的笔记或团队文档接入知识库，系统通过向量嵌入和全文检索，在需要时快速查找架构决策、编码偏好和项目背景，无需每次重新读取全部资料。

但持久记忆同时带来新的治理挑战：如果旧项目中的技术版本已经过期，或者Agent将一次错误处理总结为经验，这些内容可能在后续项目中反复造成干扰。对此，Kiro Crew提供了记忆检查与审计记录功能，开发者可以查询一条记忆的来源和创建时间，并对错误、陈旧内容进行编辑或删除；技能和经验也可以限定在特定工作空间内使用。

这类治理机制的重要性不亚于“记忆更多”，企业真正需要的不是一个无限积累信息的Agent，而是一套能够解释信息来源、被采用原因，并允许人工纠错和设置适用范围的记忆系统，否则长期记忆只会将单次的幻觉变成可持续复用的错误。

长周期Agent最容易被误解的一点，是将“可以持续调度”等同于“可以无限保持高质量工作”。相关负责人表示，Kiro Crew并未给Agent设定统一的最长运行时限，开发者可以让它通宵工作，也可以通过周期检查让某项任务长期存在，但他同时强调，实际运行时长应由任务本身决定，并不建议让Agent在没有明确规范的情况下无休止地猜测和重试。

首要的限制仍是上下文窗口：任务持续时间越长，Agent需要保留的日志、决策和代码变更就越多，当达到上下文上限后，系统必须压缩或总结历史信息，关键细节可能在这一过程中丢失。随着循环次数增加，新增信息会越来越少，而Token消耗、延迟和错误累积却会持续上升。

因此，长期运行更适合拆分为一系列有明确状态的步骤：在检查point保存进度，等待外部事件，在验证通过后继续执行，并在失败时进行有限重试。它并非让一个模型连续思考一个月，而是让一个工作空间在一个月内多次唤起Agent，恢复必要上下文并执行当下任务。

这一差异也决定了Agent工程接下来的关注重点：模型的上下文长度固然重要，但要让Agent真正进入生产环境，还需要更可靠的状态管理、任务终止条件、成本预算、失败恢复和人工接管机制。对于企业而言，“Agent完成了多少任务”并不是唯一的衡量指标，“为什么继续执行、何时停止、出了问题如何回退”同样重要。

从这个角度来看，Kiro Crew所代表的变化，是AI编程工具开始为长期任务补上记忆、调度、审计和安全边界。过去一年，行业比拼的是模型一次能生成多少代码，而接下来更核心的问题将会是：Agent能否在更长的工作周期中保持目标一致，并让开发者始终拥有检查、纠错和叫停的权力。