Cline 最新版本修复了三处隐蔽的上下文丢失问题 —— 哪些规则、Hook 和长任务摘要需要重新检查 (2026)

第一项修复涉及规则。发布说明写道：“规则面板仅列出了 .clinerules 和 Documents 全局文件夹，因此从 .cline/rules、~/.cline/rules 或 ~/Cline/Rules 加载的规则虽然应用到了模型中，但在面板中却缺失了 —— 并且在具有 OneDrive 重定向 Documents 文件夹的 Windows 系统上，完全找不到全局规则。”

这句话里包含两个故障：在三个位置，规则起作用了但不可见；而在带有 OneDrive 重定向的 Windows 系统上，全局规则根本没有被加载。

第二项修复涉及 hook。“UserPromptSubmit 和 TaskStart hook 可以再次注入上下文。这些 hook 作为 contextModification 返回的内容被丢弃了 —— 只有 cancel 幸免于难 —— 因此旨在向任务添加仓库事实或内部规则的 hook 实际上什么也没做。”说明中补充道，上下文“现在作为运行的首次请求中的 <hook_context> 块进行传递，与回归发生前相同。”

第三项修复涉及长任务。“在长任务进行到一半时，压缩（Compaction）不再悄然回退到截断（Truncation）。摘要生成器保留了任务启动时捕获的凭据，因此一旦凭据刷新，其请求就会因授权错误而失败并被吞掉；它现在会遵循任务当前的凭据和模型。”

CLI 版本从用户的角度描述了相同的故障：“你得到的是被截断的对话记录而不是摘要，这在 cline-free/* 模型上最为明显。”它还指出，“在会话中途切换模型后，摘要生成器仍保持在原始模型上。”

桌面版则更进一步。“桌面应用中的长会话现在会自动压缩。自动压缩在这里实际上从未运行过。”并且它明确指出这并非新出现的退化：“这并不是最近的回归 —— 这一差距可以追溯到 4 月份核心代码中压缩变为选择性开启（opt-in）的时候。”

CLI 和 SDK 说明中还出现了另一项关于压缩的更改。压缩以前是根据字符估算触发的，而密集的内容破坏了这种估算：“压缩现在根据提供商的实际 token 使用情况触发，而不是字符估算。”CLI 说明阐明了旧的症状 —— 长会话“可能会在从未压缩的情况下达到真实的上下文上限，然后被挤压到每轮仅剩几个输出 token。”

首先从最重要的界限开始。发布说明描述的是你更新后代码的行为。这些说明中没有任何内容描述修复更新前运行的会话。8 月份被截断的任务仍然保持其已变成的对话记录。

Hook 的修复也比看起来要窄。CLI 版本指出，“运行启动 hook 控制（cancel 以及来自 agent_start/agent_resume 脚本的上下文注入）在 CLI 中仍处于非活动状态，有待刻意的选择性开启。”因此，如果你的 hook 是通过 CLI 运行的，那么插件的修复并不适用于你的配置。

规则修复改变了面板显示的内容，也改变了文档承诺在实践中的含义。Cline 的规则页面写道：“所有检测到的规则类型都会显示在规则面板中，你可以在其中单独切换它们。”在 v4.1.20 之后，这句话描述了插件对修复中命名的三个位置的行为。在此之前，这些位置的规则已被应用，但未出现在列表中。

这对于任何将面板用作清单的人来说都有直接影响。之前关于在任务前映射哪些 Cline 规则处于活动状态的指南将面板视为已检测规则的清单。在 4.1.20 之前的版本中，.cline/rules、~/.cline/rules 和 ~/Cline/Rules 中的规则不在此清单中，但仍能传递给模型。该指南中的双重门控逻辑 —— 面板切换加上规则自身的条件 —— 依然成立；只是清单步骤需要当前版本才能完整。

压缩修复恢复了文档中记录的设计，而不是引入了新设计。Cline 的自动压缩（Auto Compact）页面描述了预期的行为 —— “创建发生过的一切的全面摘要”和“用摘要替换对话历史” —— 并将其与之前的行为进行了对比：“以前，Cline 在达到上下文限制时会截断较旧的消息，从而丢失重要的上下文。”该 Bug 在没有声明的情况下，让受影响的长任务退回到了旧的行为。

该页面还明确指出，在某些模型上截断仍然是设计使然：“对于其他模型，即使启用了自动压缩，Cline 也会回退到标准的基于规则的上下文截断。”因此，在此版本之后，截断并不自动意味着是 Bug。它是一个信号，提示你去检查任务使用的是哪个模型。

流传的第一种解读将是“Cline 忽略了我的规则”。对于大多数用户来说，这并不是说明所表达的意思。在三个位置，规则“应用到了模型中，但在面板中缺失”。模型正在遵循它们；只是你看不见它们。唯一的例外是带有 OneDrive 重定向 Documents 文件夹的 Windows，其中全局规则“完全找不到”。该群体应将此修复视为行为上的改变，而不仅仅是显示上的改变。

第二种解读是压缩不可靠，应该关闭。这把历史弄反了。摘要是截断的替代方案，而这次的故障是摘要生成器悄悄地把工作交回给了截断。关闭压缩并不能避免旧的行为；一旦长任务空间耗尽，它反而保证了旧行为的发生。

第三种解读是 hook 现在可以在任何地方工作。它们在插件的 UserPromptSubmit and TaskStart 路径中再次起作用。CLI 说明指出，其运行启动上下文注入“在 CLI 中仍处于非活动状态，有待刻意的选择性开启”，而 SDK 版本为基于其构建的主机描述了一个新的运行启动通道。你的 hook 在哪里运行决定了这些句子中哪一句适用于你。

最值得抵制的误读是普遍存在的这种观点：面板、hook 或摘要证明了上下文已送达。此版本记录了三个可见表面与实际上下文不一致的案例。这也是导致智能体看起来忽略指令文件的同类问题 —— 问题很少在于文件是否存在，而通常在于特定会话是否加载了它。

你无法审计过去会话中丢失的上下文。但你可以确保在你使用 Cline 的每个地方都运行着当前版本，并且你可以对照工具之外保留的记录来检查这三个通道。

步骤 1：更新你实际使用的每个 Cline 界面

这些修复是针对每个界面分别发布的。VS Code 插件的修复在 v4.1.20 中。桌面应用的压缩和规则修复在桌面版 v0.0.33 中。CLI 的压缩、token 触发和规则修复在 cli-v3.0.63 中。如果你在插件和 CLI 之间移动任务，两者都需要是最新版本，因为发布说明分别描述了每个界面的行为。

写下每个界面所在的版本。下个月出现行为问题时，这是第一件值得了解的事情。

步骤 2：从磁盘获取规则清单，然后与面板进行对比

不要从面板开始。从 Cline 文档记录的位置开始，列出实际存在的内容。

工作区规则可以存在于 .clinerules/ 或 .cline/rules/ 中；文档指出：“如果两个目录都存在，则都会进行搜索，因此你无需将规则复制到这两个位置。”全局规则存在于 Documents 下的 Cline Rules 文件夹中，文档补充道：“Cline 还会搜索 ~/.cline/rules 和 ~/Cline/Rules 以获取全局规则。”在 Windows 上，它还会检查 OneDrive 重定向的 Documents 位置。此外，Cline 还会“从 ~/.agents/AGENTS.md 读取跨工具的全局 AGENTS 指令”。

列出你找到的每个文件，然后打开更新后插件上的规则面板并逐一勾选。更新后，任何存在于磁盘上但在面板中缺失的内容都值得报告。面板中任何你没有预料到的内容 —— 来自旧工具的文件、多年前写的全局规则 —— 都值得阅读，因为在此版本发布之前，其中一些规则在没有显示在面板中的情况下就已经传递给了模型。

如果你使用的是带有 OneDrive 的 Windows，请再检查一件事：你所依赖的全局规则现在是否确实被遵循。说明中提到这些规则“完全找不到”，因此更新后行为可能会发生变化。

步骤 3：运行一个长任务并确认你能看到什么

Cline 的自动压缩（Auto Compact）页面指出了可见的信号：“发生这种情况时，你会看到一个摘要工具调用，像任何其他 API 调用一样显示成本。”在长任务中，寻找它。如果支持自动压缩的模型上的长任务空间耗尽，且没有出现摘要调用，这就是修复所描述的情况，在报告之前值得记录下版本和模型。

对于 hook，在你的 hook 注入的上下文中添加一个无害的标记 —— 写有日期的一行字 —— 并要求智能体在任务开始时重复它。如果它可以，说明上下文已送达。如果你通过 CLI 运行 hook，请预期说明中“保持非活动状态”的行为并进行相应规划。

这三项检查背后的通用原则与自动压缩触发时保留什么中的原则一致：提前决定哪些事实必须在长会话中留存，并将它们放在摘要无法丢弃的地方。

上述三项检查都取决于一件事：在工具之外保留一份关于智能体应该了解什么的简短记录。MemoryLake 就是保存该记录的地方，因此它不依赖于面板、hook 或摘要生成器在特定会话中是否正常工作。

You write the entries yourself, in your own words. Nothing is read out of, written to, or deleted from Cline's rules folders, its task history, or any vendor's store.

步骤 1：创建 API 密钥

登录并在控制面板中生成一个密钥。该密钥允许智能体读取你编写的条目，无论当前运行任务的是哪个 Cline 界面（插件、桌面版还是 CLI）。

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

从被截断的对话记录最先丢失的事实开始：在长任务早期做出的决定、hook 旨在注入的约束，以及存在于全局文件夹中的内部规则。每个条目一个事实，并附带原因。

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

将你的智能体指向该工作区。这样，在每个任务开始时都可以使用这些决定，这意味着即使长会话丢失了早期的轮次，仍然保留了关键的部分。

第一个实际的变化在于面板可以承载多少分量。更新后，它是一个更好的清单，但它仍然只是 Cline 检测到什么的视图，而不是你意图的记录。保留你自己的列表才能让你注意到下一次的不一致，而不是被动接受它。

第二个变化在于你如何阅读长任务。在对话内部，被截断的对话记录和被摘要的对话记录看起来可能很相似，因为两者都让智能体在少于开始时的内容上工作。区别在于早期的决定是否保留了下来。任何见过 Cline 忘记其在任务早期所做的事情的人都遇到过这种症状；此版本确定了其原因之一。

第三个变化在于 Memory Bank 的用途。Cline 的 Memory Bank 指南建议你“让自动压缩处理日常的上下文管理”，并将手动更新留给检查点 —— 这一建议在设置 Cline 的 Memory Bank 指南中得到了重复。这种划分仍然合理，但对于这些版本之前的任何内容都有一个警告：日常上下文管理并不总是像文档描述的那样发生，因此检查点文件承担了比你想象的更多的负载。

第四个变化在于你如何比较 Cline 的记忆设置：通过其在底层发生故障时能保留什么来评估每种设置，而不仅仅看它在一切正常时的表现。

保留你自己的规则文件清单。 一份路径列表和每个文件的一行用途说明就足够了。这是判断面板是否完整的唯一方法。

记录出现症状的版本。 三个界面在同一天发布了独立的修复。一份指明界面和版本的报告才是别人可以据此采取行动的。

将早期决定放在对话记录之外的某个地方。 长任务的第一个小时是最容易被截断的部分。在那里做出的、且任务其余部分所依赖的任何决定，都应该在做出决定时就记录下来。

标记注入的上下文，以便确认其已送达。 在 hook 的输出中加入一行带有日期的文字，可以将“hook 是否起作用”变成一个你可以在一轮对话中回答的问题。

在归咎于功能之前先检查模型。 Cline 文档指出，即使启用了自动压缩，某些模型也会回退到基于规则的截断。在这些模型上，截断是设计使然，而不是 Bug。

定期重新审计智能体所相信的内容。 审计你的 AI 记住什么背后的相同习惯也适用于此：唯一可靠的检查是询问智能体它知道什么，并将答案与你自己的记录进行对比。

Cline 的 v4.1.20 说明，以及随之发布的桌面版和 CLI 说明，其具体程度是发布说明中少有的。它们指出了面板遗漏的位置、被丢弃的 hook 结果，以及摘要生成器失败的确切原因。它们还坦白地表示，其中一个差距可以追溯到 4 月份。

这些都无法修复已经运行的会话。它给你的是一张寻找问题的地图：磁盘上的规则与面板的对比、hook 上下文与智能体能重复的内容的对比，以及你在长任务中应该看到的摘要调用。

更新每个界面，从磁盘获取清单，并将重要的决定保存在被截断的对话记录无法带走的地方。面板、hook 和摘要生成器今天都比上周更好了。而你自己保留的记录，才能在其中一个再次出错时提醒你。