一年前，亚马逊云科技推出 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 把一次错误处理总结成了经验，这些内容可能在后续项目中反复造成干扰。对此，Kiro Crew 提供记忆检查与审计记录，开发者可以查询一条记忆的来源和创建时间，并对错误、陈旧内容进行编辑或删除；技能和经验也可以限定在特定工作空间内。
这类机制的重要性不低于“记得更多”。
企业真正需要的不是一个无限积累信息的 Agent，而是一套能够解释信息从哪里来、为什么被采用，并允许人工纠错和设置适用范围的记忆系统。否则，长期记忆只是把单次幻觉变成可持续复用的错误。
Agent 可以一直运行，但有效工作时间并非无限
长周期 Agent 最容易引发的误解，是把“可以持续调度”理解为“可以无限保持高质量工作”。
Mesaroš表示，Kiro Crew 并未给 Agent 设定统一的最长运行时限，开发者可以让它通宵工作，也可以通过周期检查让某项任务长期存在。但他同时强调，实际运行多久应由任务决定，并不建议让 Agent 在没有明确规范的情况下无休止地猜测和重试。
首要限制仍是上下文窗口。任务持续时间越长，Agent 需要保留的日志、决策和代码变更越多；达到上下文上限后，系统必须压缩或总结历史信息，关键细节可能在这一过程中丢失。循环次数增加后，新增信息也会越来越少，Token 消耗、延迟和错误累积却会继续上升。
因此，长期运行更适合被拆成一系列有明确状态的步骤：在检查点保存进度，等待外部事件，在验证通过后继续，并在失败时有限重试。它不是让一个模型连续思考一个月，而是让一个工作空间在一个月内多次唤起 Agent，恢复必要上下文并执行当下任务。
这一差别也决定了 Agent 工程接下来的关注重点。
模型上下文长度固然重要，但要让 Agent 真正进入生产环境，还需要更可靠的状态管理、任务终止条件、成本预算、失败恢复和人工接管机制。
对于企业而言，“Agent 做了多少”并不是唯一指标，“为什么继续、何时停止、出了问题如何回退”同样重要。
从这个角度看，Kiro Crew 所代表的变化，是 AI 编程工具开始为长期任务补上记忆、调度、审计和安全边界。过去一年，行业比拼的是模型一次能生成多少代码，接下来更重要的问题，将会是 Agent 能否在更长的工作周期中保持目标一致，并让人始终拥有检查、纠错和叫停的权力。
