Kiro CLI V3 将于 10 月底成为默认版本 —— 您的 V2 会话会发生什么，以及其新记忆从何处学习 (2026)

V3 并不是新事物。Kiro 的博客文章指出“我们在 6 月份将 V3 作为选择性加入的体验推出”，并且该公司现在正“准备让 V3 成为所有人的默认版本”。该提示于 10 月 12 日开始显示，“在 10 月底 CLI 3.0 发布之前”。文章补充道，“此次推出仅适用于 Kiro CLI”。

该提示提供了三个选择：

• 切换到 V3 并升级我的配置：“将 V3 保存为您的默认 harness，启用自动智能体升级，并开始迁移您的工作区和全局自定义智能体配置。”
• 稍后提醒我： 文档称这会“将此会话保持在 V2 中，并在大约七天后再次显示该提议”。
• 不再询问： 博客明确指出此选择并不能让您退出升级。它“不会让您留在 V2，当 10 月底发布 CLI 3.0 时，您的设置仍将升级到 V3”。

您可以使用 V2 标志在单次启动时切换回 V2，但“该标志仅适用于该次启动”。

CLI 3.0 还停用了一些功能。“随着 CLI 3.0 的推出，我们将停用内联 shell 自动补全和 CLI 桌面应用。我们还将停用经典（Classic）体验，并将新功能集中在终端 UI 上。”文档中还列出了另一个值得了解的区别：“实验性的 /checkpoint 功能仍仅限经典版；V3 为对话分支提供了 /rewind 功能。”

Kiro CLI 会自动保存每个会话。其会话文档指出，它“在每次对话轮次中自动保存所有聊天会话”，并且会话按目录存储，因此每个项目都有自己的历史记录。

V3 将会话保存在不同的地方。迁移指南直接指出：“V3 使用与 V2 不同的会话存储。当您尝试 V3 时，现有的 V2 会话不会被转换或删除。”它告诉您如何返回这些会话：“当您需要返回 V2 会话时”，使用 V2 标志和恢复选择器运行 chat 命令。

另一个方向则是关闭的。V3 概述指出：“V2 无法打开 V3 会话，因为存储的会话格式不同；这是一个跨版本的迁移边界，而不是缺失 V3 恢复功能。”其破坏性变更表将会话格式变更标记为高影响。

这就是 Kiro 的信息来源存在分歧的地方。发布博客文章称“您可以在 V3 中恢复 V2 会话，但无法在 V2 中恢复在 V3 中创建的会话”。而迁移指南则将 V2 会话描述为未转换，并引导您使用 V2 标志返回它们。双方都同意 V3 会话无法回到 V2。但它们对 V2 到 V3 方向的描述有所不同。

这二者并不一定冲突。仅限 V3 的会话仪表板可以搜索旧的工作：“三个或更多字符的查询还会搜索来自本地 V2 和 V3 副本的索引会话内容。”从 V3 中找到 V2 会话并在 V3 中继续它可能不是一回事，文档也没有说明博客指的是哪一个。安全的理解是迁移指南的说法：V2 会话保留在原处，可通过 V2 读取，在您用一个重要的会话亲自测试之前，不应指望在 V3 中继续它们。

对于您无法承受丢失风险的对话，迁移指南给出了具体建议：“如果您需要重要对话的外部记录，请使用创建它的 harness 打开它并运行 /chat save <path>。除非您已验证目标 harness 可以加载它，否则请将导出的文件视为存档。”

需要注意的词是“视为存档”。导出的会话保留了所说内容。它本身并不会将该上下文重新呈现在智能体面前。

V3 为 CLI 增加了记忆功能。Kiro 的记忆页面对此进行了简明描述：“记忆让 Kiro 能够将有用的上下文从一个聊天会话带到下一个聊天会话。”它可以记住“仓库命令和规范、修正、调试见解、已被排除的方法以及您偏好的工作方式”。

有两个条件决定了它从什么中学习。

它需要 V3。“Kiro CLI 中的记忆需要 V3。”发布文章将其描述为“从您在本地 V3 会话中的工作”中学习。文档中没有任何内容描述它从 V2 会话中学习，因此您在 V2 中教给 Kiro 的内容将保留在这些会话中，除非您自己将其带过来。

它需要权限。 您可以使用 memories 命令选择访问级别：读写（read and write）、只读（read only）或关闭（off）。只有读写允许 Kiro 更改任何内容，并且“记忆访问权限的更改在您启动新的 Kiro CLI 会话时生效”。还有一个自动更新选项，其帮助文本为“自动创建和完善记忆，包括在会话结束之后”。工作区信任增加了一个限制：“即使拥有 read & write 权限，Kiro 也无法在您未信任的工作区中添加、更改或删除记忆。但它仍然可以读取它们。”

您可以查看它保存的内容。memories 列表显示了每个记忆的类型、范围和更新时间，但“该列表是只读的。要修复或删除记忆，请在聊天中询问 Kiro”。

记忆并不是为了取代您的规则。文档指出“记忆增加了学习到的上下文；它不会取代您当前的对话、Steering 或参考资料”，并给出了明确的指示：“如果某条规则必须始终适用，请将其写在 Steering 中。”

还有一个界限：记忆目前是 CLI 和 Web 功能。对于 IDE，Kiro 的记忆页面表示“记忆支持即将推出”。

会话和记忆是显而易见的变化。还有一些较为隐蔽的变化会改变智能体在会话开始时看到的内容。

Steering 包含模式现在完全适用。 Kiro 的 steering 页面指出：“Kiro CLI V3 支持所有四种包含模式：always、fileMatch、manual 和 auto。在 V1/V2 中，标记为 always 的文件会自动加载。标记为 fileMatch 或 manual 的文件则不包含在自动加载中”。切换后，当您在特定路径上工作时，您限定在这些路径范围内的 steering 文件就会开始加载，而标记为 auto 的文件会在您的请求与其描述匹配时加载。该页面的早期版本对 CLI 包含模式的描述有所不同，我们之前关于在 IDE 和 CLI 之间拆分 steering 文件的指南就是针对该版本编写的。请根据当前行为检查您的 steering 前置元数据（front matter）。

AGENTS.md 触及更深。 发布文章指出，您可以“将 AGENTS.md 文件放置在子目录中，而不仅仅是仓库根目录”，并且 steering 页面确认它们“在整个工作区的子目录中被发现”。AGENTS.md 文件不支持包含模式；它们总是会被包含。

自定义智能体保留其上下文属性。 升级文档指出：“所有其他字段（name、description、model、prompt、resources、mcpServers、welcomeMessage）均保持不变。”Kiro 的 steering 文档补充了相关的一点：“使用自定义智能体时，不会自动包含 steering 文件。您必须显式地将它们添加到智能体的 resources 配置中以加载 steering 上下文。”升级后该规则仍然适用。

某些钩子（Hooks）无法保留。 博客指出：“无法转换的钩子将被排除在 V3 配置之外，并作为警告报告。”钩子迁移页面指出，转换器“会丢弃 V3 无法表示的钩子，并报告警告，而不是写入无效的配置文件”。如果您在智能体启动时使用钩子来注入项目上下文，请检查它是否已转换为 SessionStart 钩子。被丢弃的上下文钩子不会阻止 Kiro 运行，只是该上下文将不复存在。

手动编辑可能会被覆盖。 这是最容易让细心用户中招的一点。“如果您手动编辑生成的 V3 字段，Kiro 将停止自动刷新它们。”智能体随后会显示为不同步，并且“选择该组会根据 V2 设置重新构建 V3，并覆盖您手动进行的 V3 编辑。”Kiro 在执行此操作时会保留备份，但在开始调整之前，这一点非常值得了解。

误以为“不再询问”能让您留在 V2。 它只是停止提示。无论如何，CLI 3.0 都会升级您的设置。

误以为 V3 会从 V2 结束的地方开始。 新会话从您的 steering、AGENTS.md 文件以及 V3 学习到的任何记忆开始，而这些记忆是从您的 V3 工作开始积累的。

误以为导出的会话可以恢复上下文。 Kiro 将其称为存档，除非您已验证目标可以加载它。

误以为记忆可以取代 steering。 Kiro 表示，必须始终适用的规则属于 steering。

误以为升级会保留每个钩子。 无法转换的钩子会被排除在外并发出警告。

步骤 1：结束您仍依赖的 V2 会话

列出您每个项目最近的 V2 会话，并挑选出那些有未完成工作或难以重建的决策的会话。如果可以，在 V2 中完成它们。对于其余的会话，正如迁移指南所建议的那样，使用 V2 的 chat save 命令保存一个外部副本，并在切换前保留一份 Kiro 主目录的副本。Kiro 的权限页面将 ~/.kiro/sessions/ 指定为默认会话存储，将 ~/.kiro/memories/ 指定为记忆数据库。

然后从这些会话中提取结论：决策、被排除的方法、确定的规范。这是 Kiro 文档中未描述 V3 记忆会从 V2 中继承的部分。

步骤 2：通过干跑（dry run）升级您的智能体，然后阅读每个警告

如果您的团队将智能体保存在仓库中，请先预览目录升级。Kiro 的文章指出，应使用 dry-run 选项运行它，升级页面也表示干跑会“报告将要发生的变化并包含转换警告”。然后运行升级（这会备份每个文件），并打开诊断信息。

特别留意被丢弃的钩子以及指向 steering 或知识文件的 resources 条目。检查您的 steering 文件的包含模式，因为 fileMatch 和 auto 文件在 V3 中的行为开始有所不同。在理解不同步重建机制之前，避免手动编辑生成的字段。要更广泛地了解编码智能体在启动时读取哪些文件，请参阅我们关于编码智能体实际读取内容的指南。

步骤 3：有意识地开启记忆，并将规则保留在 steering 中

自己选择记忆访问级别，而不是接受默认设置。读写（read and write）允许 Kiro 学习；只读（read only）允许您在不作更改的情况下使用已有内容。信任您希望记忆增长的工作区。

然后将任何必须始终适用的内容移至 steering 或 AGENTS.md 中。记忆用于 Kiro 学习的内容；steering 用于您决定的内容。如果规则以前被忽略过，我们关于智能体为何忽略指令文件的指南涵盖了常见原因。

版本变更是一个很好的契机，让您注意到有多少项目上下文存在于单一工具的会话存储中。MemoryLake 是一个记忆层，用于将您工作背后的决策保存在一个由您维护的列表中，供 Kiro 和您使用的其他助手使用。

您可以用自己的语言亲自编写这些条目。不会从您的 Kiro 会话、Kiro 记忆数据库、steering 文件或任何厂商的存储中读取、写入或删除任何内容。如果您在公司代码上工作，请在将项目细节复制到其他地方之前检查您组织的政策。

步骤 1：创建 API 密钥

登录并从仪表板生成密钥。该密钥属于您的 MemoryLake 工作区，与您的 Kiro 或 AWS 账户无关。

步骤 2：上传您的第一批记忆

从您在步骤 1 中从 V2 会话中提取的内容开始：决策、排除的方法和规范。每个条目一项，注明日期和原因。

步骤 3：连接您的 AI 和智能体

连接 Kiro 和您使用的其他助手。这样，从您的第一个会话开始，相同的决策就可以在 V3 以及任何其他工具中可用，而无需等待 V3 的记忆重新学习它们。

第一个区别是，切换不再是一场赌博。您知道可以返回哪些会话、如何返回，以及哪些会话您已经进行了总结。

第二个区别是，在 V3 上的第一周会更加顺畅。在 V3 的记忆建立起来之前，Steering、AGENTS.md 和您自己的笔记为 V3 会话提供了一个起点。其他工具在版本更新中也有过类似的隐蔽上下文变化；我们对 Cline 静默上下文修复的观察就是一个例子。

第三个区别是，升级本身带来的意外更少。被丢弃的钩子和改变的包含模式是在干跑期间发现的，而不是在实际工作中。

第四个区别是可移植性。如果您以后将某些工作转移到另一个智能体，如我们关于从 Kiro 迁移到 Claude Code 的指南中所述，您的决策将不依赖于任何一个工具的会话格式。

不要依赖“不再询问”。 无论如何，升级都会在 CLI 3.0 时发生。

先备份您的 Kiro 主目录。 会话和记忆都保存在那里。

在 V2 中完成重要的 V2 会话。 然后对它们进行总结。

干跑智能体升级。 在提交之前阅读每个警告。

重新检查 steering 前置元数据。 包含模式在 V3 中完全适用。

有意识地设置记忆访问权限。 并且只信任您想要信任的工作区。

将规则保留在 steering 中。 关于 steering 和 powers 如何划分上下文，请参阅我们关于在 Kiro powers 和 steering 之间路由上下文的指南。

Kiro CLI V3 将于 2026 年 10 月底随 CLI 3.0 成为默认版本，选择“不再询问”并不能让您留在 V2。V3 使用新的会话存储。V3 会话无法在 V2 中打开。Kiro 的博客称 V2 会话可以在 V3 中恢复，而其迁移指南则称它们不会被转换，并引导您返回 V2 打开它们，因此在依赖任何一种说法之前，请先用一个重要的会话进行测试。

V3 还为 CLI 带来了记忆功能。Kiro 将其描述为从本地 V3 会话中学习，且访问权限由您控制，其文档并未描述它会从 V2 中学习。

在截止日期之前，结束您所依赖 of V2 会话，对照警告升级您的智能体，并将您想要保留的决策写在任何版本变更都无法使其丢失的地方。