如何在不丢失上下文的情况下从 Cline 迁移到 Kilo Code (2026)

你的 memory-bank/ 目录会原封不动地迁移。 projectbrief.md、productContext.md、activeContext.md、systemPatterns.md、techContext.md 和 progress.md 是你仓库中普通的 Markdown 文件。它们没有任何 Cline 特有的东西。Cline 的文档将它们描述为“项目中你和 Cline 都可以访问的常规 markdown 文件”。将它们完全保留在原处。

如果你有 AGENTS.md，它也会迁移。 Cline 将 AGENTS.md 和 ~/.agents/AGENTS.md 读取为“跨工具兼容性的标准格式”。Kilo Code 在项目根目录下读取 AGENTS.md，并回退到 AGENT.md，其文档警告说“文件名必须是大写（AGENTS.md），而不是小写”。如果你已经有一个，那就是唯一不需要考虑的文件。

你的 .clinerules/ 目录不会作为被发现的源进行迁移。 Kilo Code 文档中记录的指令源是项目根目录下的 AGENTS.md 和 AGENT.md、项目和全局 kilo.jsonc 中的 instructions 键、.kilo/rules/ 文件，以及——为了向后兼容——.kilocode/rules/ 目录和旧版 .kilocoderules 文件。CLI “还支持 .claude/ 和 .agents/ 目录，以实现与其他工具的兼容性”。.clinerules/ 不在该列表中。

这是最棘手的地方，因为如果你遵循了 Cline 的设置，.clinerules/memory-bank.md 就是 Memory Bank 指令所在的位置。如果直接迁移到 Kilo 而不解决这个问题，你的 memory-bank/ 文件就会完整且最新地留在仓库中，但没有任何东西去读取它们。Cline 自己的指令文本明确说明了为什么这对于该模式是致命的：“我必须在每个任务开始时读取所有 memory bank 文件——这不是可选的。”删除该指令，这些文件就会变成无人问津的文档。

你的条件规则不会迁移。 Cline 支持通过 YAML 前置内容中的 paths 数组进行范围限定，并根据实际工作上下文对其进行评估：“它从你当前的工作中收集上下文（打开的文件、可见的标签页、提及的路径、编辑的文件），评估每个规则的条件，并激活匹配的规则。”Kilo Code 的 instructions 键接受文件路径和 glob 模式，但这些 glob 选择的是加载哪些文件，而不是何时加载它们。Kilo 确实记录的唯一条件行为在本质上是不同的：每个目录的 AGENTS.md 文件是“在智能体读取该目录中的文件时动态加载的——它们在会话开始时不会被预加载”，并且它们的内容会“作为 <system-reminder> 标签注入到对话中”。这很有用，而且它是基于目录而不是基于 glob 的，因此在整个树中范围限定为 **/*.test.ts 的规则没有直接的等价物。

规则组合的行为不同。 Cline “处理 .clinerules/ 内的所有 .md 和 .txt 文件，将它们合并为一组统一的规则”，并使用数字前缀作为可选的排序约定，并且“当工作区规则与全局规则冲突时，工作区规则优先”。Kilo Code 则发布了一个明确的优先级列表：配置中每个智能体的提示词最高，然后是 kilo.jsonc 中的项目 instructions 键，然后是项目根目录下的 AGENTS.md，最后是全局 instructions 键，技能按需加载。请注意根目录 AGENTS.md 的位置——在项目 instructions 键下方，而不是上方。

这两个工具都遗漏了同样的东西。 它们都没有记录一个可以积累你的团队跨项目和跨人员所学知识的存储库。Cline 的解决方案是你维护的文档方法论；Kilo 的解决方案是 AGENTS.md 加上你维护的规则文件。Memory Bank 的存在正是因为这种差距是真实存在的——这就是为什么智能体即使配置良好也会让人觉得健忘的原因——当你决定其内容应该存放在哪里时，这一点值得记住。

步骤 1：重新附加指令，而不是内容

你有两种干净的方法让 Kilo 运行 Memory Bank 模式，而且它们并不等价。

最直接的选择是项目 kilo.jsonc 中的 instructions 键。将其指向你已有的规则文件——即同一个 .clinerules/memory-bank.md，或者如果你不想保留以 Cline 命名的目录，可以将其复制并重新定位到 .kilo/rules/memory-bank.md。Kilo 的文档显示 instructions 既接受显式路径也接受 glob，因此单个条目就可以覆盖整个规则文件夹。这处于优先级第二位，高于根目录 AGENTS.md，对于必须在其他任何事情之前运行的指令来说，这是正确的位置。

另一个选择是将指令文本放入 AGENTS.md 中。这就是 Kilo 的弃用说明所指向的方向，而且它确实有效。这也意味着该指令会受到 Kilo 文件保护的约束（在下一步中讨论），并且它会与 AGENTS.md 的其余内容争夺空间。

无论你选择哪一个，都要调整命令词汇。Cline 的 Memory Bank 指令是围绕三个短语编写的——“遵循你的自定义指令”、“初始化 memory bank”和“更新 memory bank”。第一个是依赖于 Cline 概念的短语。将其重写为直接陈述：在开始任何任务之前读取 memory-bank/ 中的每个文件。另外两个是对智能体的普通英语指令，可以原样保留。

然后通过启动一个新任务并询问智能体加载了什么指南来进行验证。你要寻找的是 memory-bank/ 文件列表。Cline 在这里给你提供了一个可见的信号——“已应用条件规则”通知——而 Kilo 针对每个目录文件的等效信号是 <system-reminder> 注入，所以请主动询问而不是凭空假设。

步骤 2：不要将 memory-bank 内容倒入 AGENTS.md

Kilo 的弃用说明为其自身的 memory bank 提供了两步迁移：“检查 .kilo/rules/memory-bank/（或旧版 .kilocode/rules/memory-bank/）中的内容”，然后“将该内容移入项目的 AGENTS.md 文件中（或让 Kilo 替你完成）”。该建议对于它所描述的情况是正确的——Kilo 的 memory bank 存在于其规则目录中，因此将其合并到 AGENTS.md 中是一种简化。

如果应用到 Cline 的 Memory Bank，同样的举动会破坏使其工作的机制。以下是原因，用 Kilo 自己的话来说：“AGENTS.md 和 AGENT.md 在 Kilo Code 中都是写保护文件”，这意味着“AI 智能体在没有用户明确批准的情况下无法修改这些文件”，并且“系统会提示你确认对这些文件的任何更改”。

Memory Bank 不是一个静态文档。activeContext.md 是 Cline 文档中指出“更新最频繁”并建议“在每次会话后”更新的文件；progress.md 跟踪里程碑。整个模式取决于智能体在你发出“更新 memory bank”指令时能够写入这些文件。将它们合并到 AGENTS.md 中，每一次写入都会变成一个确认提示——这要么会训练你不断点击项目配置文件上的提示，要么会训练你停止运行更新。

因此，保持这种分离：指令进入指令源，而内容保留在 memory-bank/*.md 中，这些是没有特殊保护的普通项目文件。独立于 Kilo 之外，这种分离也是更好的习惯。它将智能体不断重写的文件排除在定义项目护栏的文件之外。如果你也想要一个规范的 AGENTS.md，migrating CLAUDE.md to AGENTS.md 介绍了该文件的结构。

还有一件事需要预期且无需担心：Kilo 指出“旧版 Memory Bank 状态指示器（如 [Memory Bank: Active] 和 [Memory Bank: Missing]）仍可能出现，但无法保证在所有客户端或模式中都可用。”如果你一直通过读取徽章来确认该模式是否处于活动状态，请停止这样做。改为询问智能体它加载了什么。

Memory Bank 的洞察是正确的：智能体需要持久的记录，而一个 Markdown 文件夹是一个完全合理的初步实现。但它的限制也是结构性的，你可能已经知道了。

它是针对每个仓库的，因此跨服务的知识必须重复或丢失。在实践中，它是针对每个工具的，因为激活它的指令是特定于工具的——这就是本次迁移需要步骤的全部原因。它没有检索功能；每个任务都会读取所有六个文件，无论它们是否相关。而且它属于那些记得运行“更新 memory bank”的人，这就是为什么它在团队中会过时，以及为什么上下文会随着人员的流失而流失，我们在在有人离职时保留 AI 上下文中讨论过这个问题。

MemoryLake 是消除了这四个限制的相同理念：一个位于任何仓库或编辑器之外的存储库，可通过 MCP 或 API 读取，可检索而不是整体读取，并在团队中共享。你的 memory-bank/ 文件是它的一个很好的种子。

步骤 1：创建 API 密钥

生成一个密钥并在大约三十秒内发出你的第一次请求。一个密钥即可在 Kilo Code、Cline（如果团队成员仍在使用它）以及接下来的任何工具中工作。

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

放入你已有的文档、图像和文件——从 systemPatterns.md、techContext.md 和 progress.md 开始，这三个文件通常保存着真正的决策，而不是对 README 的重新陈述。

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

允许 Claude、Codex、OpenClaw 和其他智能体通过 MCP 或 API 进行访问。在 Kilo Code 中，这会将“在每个任务中读取所有六个文件”转变为仅检索与你面前的任务相关的两个事实。

强制性的完整读取消失了。Cline 的指令文本坚持在每个任务开始时读取每个 memory bank 文件，因为没有检索层——这是保证包含相关文件的唯一方法。有了检索，该要求就不再必要了，就像不再需要让智能体在每次会话中重新读取代码库一样。

activeContext.md 停止漂移。Cline 标记为更改最频繁的文件是最有可能过期的文件，因为更新它是在你思想上已经离开的会话结束时的手动步骤。在做出更正时捕获它，比事后重建会话是一个更小的动作。

工具迁移不再影响你的知识。这次迁移很繁琐，因为激活指令是工具形状的。当内容存在于外部时，更换工具意味着编写一条新指令，而不是审计仍在读取的内容。

而且六文件结构变得可选，而不是承重的。对于必须完整读取的文件夹来说，这是一个合理的模式。一旦存在检索，你可以保留它，或者只保留事实。

在信任它之前确认发现。 .clinerules/ 不在 Kilo 的文档列表中。启动一个任务并询问加载了什么。

将写操作频繁的文件排除在 AGENTS.md 之外。 它在设计上是写保护的，这对于护栏来说很好，但对于运行日志来说是错误的。

使用目录放置进行范围限定。 Kilo 的每个目录 AGENTS.md 文件在智能体读取那里的文件时会延迟加载。这是最接近 Cline 条件规则的东西，并且它适用于目录而不是 glob。

注意优先级顺序。 kilo.jsonc 中的项目 instructions 优于根目录 AGENTS.md。如果两个源不一致，通常就是这个原因。

预期需要重新加载。 Kilo 指出“对 AGENTS.md 的更改在新的任务中生效（可能需要重新加载）”。不要在任务中途调试你编辑的规则。

不要依赖状态徽章。 旧版的 Memory Bank 指示器明确表示“无法保证在所有客户端或模式中都可用”。

这次迁移看起来似乎是不友好的——你正在将一个 Memory Bank 迁移到一个弃用了 memory bank 的工具中——但事实并非如此。Kilo Code 弃用的是一个功能包装器，而 Cline 自己的文档指出该方法论“适用于任何能够读取文档的 AI”。文件本身没有问题。

有两件事需要注意。Kilo 文档中记录的指令源不包括 .clinerules/，因此使该模式运行的规则必须重新附加，最好是通过 kilo.jsonc 中的 instructions 键，该键的优先级高于根目录 AGENTS.md。并且 Kilo 关于将 memory bank 内容移入 AGENTS.md 的弃用建议不应应用于 Cline 的版本，因为 AGENTS.md 是写保护的，而智能体需要不断写入这些文件。指令在内，内容在外。

做好这些，就不会丢失任何东西。那么更有趣的问题是，在每个任务中完整读取的每个仓库文件夹是否仍然是你的团队所知知识的最佳归宿——或者它是否属于某个可检索、共享且与你今天早上打开哪个编辑器无关的地方。