为什么压缩会保留您的状态并压缩您的推理
Kiro 自身对该机制的总结非常直接。压缩“通过在会话增长时自动总结较旧的对话历史，保持长会话的高效”，其核心逻辑是“您的目标、决策和技术进展得以保留——只有冗长的中间过程会被压缩”。
该过程包含三个部分：“Kiro 创建一个结构化总结，捕获您的目标、决策、进展和后续步骤”，然后“较旧的对话历史被该总结替换，而您最近的消息则逐字保留”，接着会话“从您中断的地方继续，不发生中断”。
这种设计是合理的，它选择的类别也是继续工作所需的正确类别。一个知道哪些文件发生了更改、哪些测试通过了、还剩下什么以及您的约束是什么的总结，绝对可以让工作继续进行。Kiro 的实际案例很好地证明了这一点：在进行了 45 分钟的重构后，总结保留了修改了哪些文件、哪些测试通过、剩余的两个文件，以及“所有更改必须向后兼容”的约束。
这里的差距是类别上的差异，而不是 Bug。总结能高效地保留结论，但很难保留论证过程。“所有更改必须向后兼容”作为约束保留了下来。而您用来确定为什么向后兼容在这里不可妥协的 20 分钟——无人能更新的调用者、使用旧版本的客户端、去年失败的迁移——恰恰是表格中归类为探索性讨论和中间推理步骤的内容。
可压缩栏中的另外两个条目也值得关注。“已解决问题的错误详情”意味着您已经解决的失败过程会被压缩——而您解决过的失败通常是您最终决定采用某种方法的最强有力证据。“早期消息中的代码片段”意味着被拒绝的实现消失了，而接受的实现保留了下来，这消除了证明该选择合理性的对比基础。
Kiro 对缺失细节的补救措施既坦诚又发人深省：“如果智能体似乎丢失了会话早期的特定细节，请重新陈述它。智能体将立即将其合并。”这确实有效。但这也意味着，对于任何不在保留栏中的内容，其保留机制就是你，记住再把它说一遍——这就是我们在如何停止向您的 AI 重复解释上下文中描述的循环。
这并非 Kiro 特有的设计。Amazon Q Developer 在不同的名称下记录了相同的形式：压缩后，“Amazon Q 使用压缩后的总结（而非完整历史记录）来生成回复”，虽然完整的对话在会话面板中仍然可见，但“当您重启 IDE 时，详细的聊天历史记录将会重置”。两个厂商，两个独立的实现，同样的结论——对话是工作记忆，而不是存储。
人们尝试的其他替代方案
关闭压缩。 在大多数界面上不可用。Kiro 的文档指出，压缩“在 IDE 中是自动进行的。没有手动触发器”，并在 Web 和移动端重复了同样的话。只有 CLI 提供了 /compact，而那是一个手动触发器，而不是开关。不进行压缩的代价就是耗尽上下文。
调整保留设置。 CLI 提供了两个设置：compaction.excludeMessages，被描述为“要逐字保留的最近消息对的最小数量”，以及 compaction.excludeContextWindowPercent，“要作为最近消息保留的上下文窗口的最小百分比”。两者默认值均为 2，并且“两个设置都会被评估，以更保守（更大）的值为准”。
提高这些值可以逐字保留更多最近的尾部内容，这确实有助于保持连贯性。但它对一小时前发生的推理毫无帮助，因为尾部是由新近度定义的，而不是重要性。这就是我们在为什么长上下文窗口不是记忆中阐明的一般性限制。
导出会话。 Kiro 推荐这样做是有充分理由的：“如果您需要保留完整的历史记录，请在发生压缩之前导出您的会话。”导出是防止完全丢失的真正保障。但它不是一种检索机制——转录记录是按时间顺序排列的、未索引的，描述的是说过什么，而不是当前什么是真实的。这种区别正是索引会话日志能记住什么，以及记不住什么的全部主题。
为每个阶段启动一个新会话。 合理的习惯，Kiro 的 CLI 指南也建议“在同一会话中开始新阶段的工作之前”执行 /compact。但是，新会话启动时只有引导文件而没有对话，因此您在上一个会话中确立但未写下来的任何内容，在定义上就已经消失了，而不仅仅是被总结了。
将所有内容放入引导文件中。 过度矫正。.kiro/steering/ 下的 Kiro 引导文件默认始终启用，并且引导位置中的 AGENTS.md 根本无法限制范围——文档指出“AGENTS.md 文件不支持包含模式，并且始终包含在内”。将您的整个推理历史移到那里，您就把压缩问题转换为了上下文预算问题，这是在您应该给 AI 智能体多少记忆中探讨的权衡。
解决方案：在会话压缩之前将原因移出对话
表格就是工具。在事实出现的那一刻将其用作路由规则，而不是事后剖析。
步骤 1：将两栏视为路由规范
字面理解 Kiro 的表格并在工作时应用它。当会话中确立了某些重要内容时，询问它属于哪一栏。
如果是任务状态、修改后的路径、下一步或陈述的需求，请将其留在对话中。Kiro 会保留这些内容，在其他地方复制它们会创建两个不一致的记录。
如果是论证、被拒绝的选项、让您学到东西的已解决错误，或者您正在对比的代码片段——它就在可压缩列表中。这就是您的信号，现在就把它写到别的地方，趁它还是逐字记录的时候。
边界情况是“关键决策和约束”，它位于保留栏中。决策保留了下来，但其合理性解释没有。因此，决策的路由规则是：将决策留在对话中，并将合理性解释写出来。没有记录原因的约束会被下一个觉得它不方便的人删除。
步骤 2：将可重用的部分提升到引导文件中，并保持引导范围受控
您写出的某些内容属于 Kiro 自身的配置，因为在下一个会话中它同样适用。
引导文件在工作区范围内位于 .kiro/steering/，在全局范围内位于 ~/.kiro/steering/，它们在 front matter 中接受包含模式——有一个值得注意的文档约束：“包含配置必须是文件中的第一个内容——前面不能有空行或内容。”这三种模式是 always（默认）、带有 fileMatchPattern 的 fileMatch 以及 manual。
根据生命周期使用它们。适用于整个仓库的规范放入 always 文件中。适用于某一区域的规范使用 inclusion: fileMatch 和一个模式，这样当您在其他地方时就不会消耗任何成本。您偶尔调用的长流程使用 manual。
不属于引导文件的是项目决策的运行历史。每个会话的每个任务都会加载引导文件；决策日志会无限制地增长。Kiro 还记录了全局引导是单机目录——在 Web 端，“全局引导”指的是您本地的 ~/.kiro/steering/ 目录，“云沙箱无法读取该目录”，跨云会话重用它需要通过 Configuration Sync 上传。保存在一台笔记本电脑上的文件不是团队记录。
步骤 3：为原因提供一个不运行总结的归宿
其余部分——被拒绝的方法、约束背后的原因、智能体卡住时人工提供的事实——具有三个属性，排除了前两个目的地。它持续增长，因此不能始终启用。它很少被查询且针对性强，因此不应该出现在每个提示词中。而且它必须能被下一个会话、下一个人和下一个工具读取，因此它不能保存在单台机器的转录记录中。
那是一个存储库，不是文件，也不是对话。在做出决策时向其追加内容，在决策受到质疑时进行读取，其中的任何内容都不会受到总结处理。
在 MemoryLake 中进行设置
MemoryLake 就是那个存储库：一个共享层，保存您的会话所压缩的以及您的引导文件不应承载的推理。Kiro 保留状态；引导文件保留现行规范；该层保留论证。从这里开始。
步骤 1：创建 API 密钥
为项目创建一个工作区并生成一个 API 密钥。每个项目一个工作区，而不是每个会话一个——关键在于它能跨越压缩重置的会话。
步骤 2：上传您的第一批记忆
不要从头开始。导出已经压缩的会话，并从中挖掘可压缩栏的内容：您尝试过并放弃的方法、改变您设计的错误、某人口头陈述的约束。为您已有的每个引导文件添加背后的原因，因为这些文件只陈述了规则，而没有说明原因。
步骤 3：连接您的 AI 和智能体
在您实际使用的界面上连接 Kiro——IDE 和 CLI 在压缩上的行为不同，两者都应该读取相同的数据集。如果您运行 Kiro Crew 进行团队工作流，也请连接这些智能体，这样定时运行的智能体就不会基于比设置它的人更窄的记录来工作。
这在实践中改变了什么
长会话不再以隐形的方式丢失信息。压缩仍然会触发，仍然按照其自身的计划进行，总结仍然会保留状态。但是每个约束背后的论证都保存在一个不会被总结的地方，因此压缩后的会话只是一个更小的上下文，而不是更短的记忆。
重新陈述的循环缩小了。Kiro 重新陈述丢失细节的建议偶尔用一次还可以。但如果一个月内每个会话都要重复陈述相同的三个事实，代价就太高了，而且这并不可靠，因为重新陈述的人必须记住该事实曾经被确立过。
被拒绝的方法不再重新出现。“已解决问题的错误详情”在可压缩列表中，这意味着关于什么行不通的记录是最先被清除的。把这些写下来，智能体就不会再建议您在周二已经排除掉的方法。
引导文件保持足够小以发挥作用。当决策日志有了自己的归宿时，引导文件可以是一组简短的现行规范，而不是一个在每次请求时都消耗上下文的不断增长的文档。保持始终启用层精简的一般性论点见智能体记忆如何通过减少保留内容变得更准确。
长 Kiro 会话的最佳实践
在说出原因的那一刻就把它写下来，而不是在会话结束时。到结束时，对话可能已经压缩了，Kiro 自身的警告同样适用：压缩点之前的历史记录“在会话内是无法恢复的”。
在进行长时间的自主运行之前进行导出。这成本很低，Kiro 也推荐这样做，而且这是防止您得到一份无法审计的总结的唯一屏障。
提高 CLI 保留设置是为了连贯性，而不是为了长期保留。增加 compaction.excludeMessages 有助于智能体在跨越边界时保持连贯。它不是存储，因为它保护的窗口是由新近度决定的。
多使用 fileMatch 引导，少使用 always 引导。每个 always 文件在每次请求时都会竞争相同的上下文，而那些本可以限制范围的文件则是纯粹的开销。另请注意，引导位置中的 AGENTS.md 没有可用的包含模式。
在您撰写的内容中，区分决策和约束。“不要在支付中使用共享的重试助手”是一个约束，在压缩中得以保留。“因为它在会导致重复收费的失败路径上进行重试”是原因，无法保留，而这是防止该约束在六个月后被删除的唯一依据。
如果您保留会话日志供自己参考，请将其与存储库分开。日志是按时间顺序排列的，描述的是说过什么。存储库描述的是当前什么是真实的。将它们混在一起意味着最新的矛盾会与最旧的主张并存，且无法区分——而且如果您以后更换工具，只有存储库能够干净地迁移，正如我们在从 Kiro 迁移到 Codex中所发现的那样。
结论
Kiro 的压缩表格比大多数厂商文档更有用，因为它准确地告诉了您应该围绕什么进行规划。状态、路径、决策、后续步骤和意图得以保留。工具调用详情、探索性讨论、中间推理步骤、已解决的错误详情以及早期的代码片段则可能无法保留——而且该操作是单向的。
实际的应对方法不是对抗压缩。而是停止将对话作为第二栏内容的存储位置。在当下决定一个事实属于哪一栏，将现行规范提升为有范围限制的引导文件，并为推理提供一个任何总结处理都无法触及的归宿。这样，压缩后的会话就完全符合 Kiro 的描述：一个更小的上下文，且没有任何损失。