Kiro Crew 的巧思：把 agent 的记忆和长期工作都搬出聊天框

常见的 AI 编程工具把工作单位设成一次会话：用户提出任务，agent 修改代码，任务结束，对话也跟着沉下去。只要工作跨过几个仓库、多个工具和几天时间，用户就得重新解释背景，自己盯住进度，再把一个 agent 的结果交给下一个 agent。

Kiro Crew 是 Kiro 团队在 8 月初公开发布的开源开发工作区。它可以运行在本地或用户控制的远程机器上，把会话、文件、审批、记忆、定时任务和 Apps 放在同一个工作区里；开发者也可以从桌面应用、网页面板、命令行或 Slack、Discord 等入口继续处理同一份状态。12

Kiro Crew 和 Kiro IDE 里的单次 agent 任务不是一回事。后者仍然是用户在一段会话里驱动 agent；Kiro Crew 负责跨会话保留状态、并行调度多个 agent、按计划或 webhook 启动工作，并在任务完成、失败或需要批准时把结果送回来。3

跨会话工作的第一个难题不是「能不能保存聊天记录」，而是「下一次运行时，哪些过去的信息有资格改变 agent 的行为」。把所有历史对话都塞回上下文，会带来无关信息、过时规则和项目之间的串线；完全不保存，又会让每次工作从冷启动开始。

Kiro Crew 选择把长期记忆拆成三个可以查看和修改的对象：记忆保留项目背景与偏好，lessons 记录用户纠正 agent 后形成的规则，skills 则把反复出现的做法整理成可复用能力。官方说明里，三者都能检查、编辑、限定在某个工作区，或者删除；重复工作形成的 skill 也不是自动藏在模型里，而是以可读文件的形式留在工作区。12

这个设计的关键不在「记得更多」，而在于把记忆从模型内部状态变成了工作区资产。用户说「前端检查通过后，才能把改动标记为完成」，这条纠正可以成为项目范围内的 lesson；下次 agent 读取相关项目时，规则会影响行为，而不是只在旧对话里等待被重新引用。Kiro Crew 的仓库说明还把记忆、经验和 skill 设计成可检索、可持久化的状态，并允许用户在面板里观察 agent 使用了哪些上下文。4

对产品设计来说，保存「结果」和保存「会改变后续动作的规则」是两件事。前者像搜索历史，后者接近一个会参与决策的配置层。Kiro Crew 把后者暴露出来，换来了可纠错性：用户不必接受一个无法解释的「agent 现在就是这么做」，可以追到记忆条目，修改范围，或直接删除。

代价也很具体。持久记忆会把一次临时判断带进未来的任务；项目规则写错后，agent 可能稳定地重复同一种错误。可编辑和审计只能让修复成为可能，不能替用户判断哪条经验已经过期。对需要长期运行的 agent 来说，记忆管理本身就是工作，不是一个可以默认跳过的基础设施细节。

第二个难题是交互对象。聊天适合给出一个目标，却不适合长期承载待处理队列、定时扫描、环境状态、审批按钮和多个 agent 的交接。用户可以在对话里说「每天检查失败的部署」，但真正需要看的往往是一张带筛选条件的列表、某个任务的当前状态，以及一个明确的「批准」「重试」或「停止」入口。

Kiro Crew 的 Apps 正是为这层工作面设计的。一个 App 可以把自定义界面、agent、skills、计划任务、集成和后端服务组合起来；官方示例包括用于 issue 和 pull request 分流的 Issue Radar、执行长任务的 Task Runner，以及把 LaunchDarkly 的 feature flag 带进开发工作区的 App。12

LaunchDarkly 这个例子说明，App 不是给聊天框换一层皮。它把一个领域里的对象、状态和动作先定义出来，再让 agent 进入这套关系：flag 有环境和开关状态，代码有引用，agent 有可以执行的动作，用户有需要亲自确认的发布边界。用户因此审查的是「哪个 flag、哪个环境、准备做什么」，而不是从一长段对话里猜 agent 刚刚动过哪里。

这种设计也改变了「自动运行」的含义。Kiro Crew 的定时任务可以执行不需要模型判断的脚本或命令；需要推理的工作则会消耗 Kiro 账户的用量，并受并发、超时、审批和权限设置影响。2 长任务还会经过检查点、验证和重试，开发者回来时看到的是一个待审查的状态，而不是一条「我已经处理好了」的聊天回复。4

代价是，工作面越具体，设计和治理成本越高。InfoWorld 对 Kiro Crew 的报道提到，企业需要提前处理最小权限、审批、记忆保留、代码来源和审计等问题；并行 agent 还会同时放大模型调用、CI 活动、API 使用和人工复核量。Kiro Crew 在发布时仍运行在 Kiro CLI 之上，使用其他 coding agent 需要额外验证连接方式。5

Kiro Crew 处理的是 AI 编程工具最容易被忽略的两块：agent 离开当前对话后，什么会留下来；任务离开聊天框后，用户要在哪里接手。它把前者做成可查看、可编辑、可删除的记忆资产，把后者做成带状态、计划、集成和审批的 App。

可迁移的设计原则不是「让 agent 彻夜运行」，而是让长期运行的每一层都留下可检查的对象：记忆要能改，任务要有状态，动作要有权限，结果要有接手位置。自动化因此不再等于把人从流程里删掉，而是把人的判断从重复操作里移到真正需要负责的节点上。