Cline 压缩后又读同一文件？先查工具结果是否进入摘要

Cline 刚读过文件、跑过测试，一次上下文压缩之后，却又从同一个目录开始查。先别急着换模型：检查它保留下来的是“读过哪些文件”，还是“文件里发现了什么、测试实际返回了什么”。两者差别很大。

这篇处理的是压缩完成后任务接不上。如果第一次接入就失败，先看 Cline 自定义 API 配置；如果直接收到上下文超限错误，按上下文超限处理方法缩小输入。

本文于 2026-11-08 查证，具体代码以 Cline cli-v3.0.74 标签为准，其中 Core 包版本为 0.2.0。我们用公开的合成数据执行了该标签中的序列化函数，没有运行完整 CLI 或真实模型会话。下面的报告范围与这个局部验证分开说明。

先区分：合理复查，还是压缩后丢了关键事实

重新读文件有时是正确动作。文件刚被改过、切换了分支，或者模型准备编辑某一行，都有理由再读一次。值得排查的是：文件没有变化，任务也没换，它却重复寻找相同入口，甚至忘记上一轮失败的测试名称。

先找压缩前后各一个具体例子，比较三处记录：

检查位置	要找的内容	能说明什么
压缩前的工具结果	文件片段、命令结果、失败测试名	当时实际读到或执行了什么
生成的摘要或续接说明	具体发现、已做修改、验证状态	下一轮能否靠它继续工作
压缩后的第一步	针对性复查，还是从头搜索	哪条事实可能没有接上

“读取过 src/parser.ts”只保留了路径。“parseHeader 对空字符串返回了错误值，相关用例尚未通过”才提供继续排查所需的信息。后者仍应以真实文件和测试记录核对，不能让模型凭印象补齐。

一条近期报告：摘要模型收到的是空工具结果

Cline Issue #15550 于 11 月 4 日报告：Agentic 压缩处理 run_commands、read_files 的结果时，摘要模型能看到调用了什么，却看不到返回内容。作者填写 CLI 3.0.74 并注明使用 main，另给出了安装 @cline/core@0.2.0、连接本地模拟模型的复现脚本。

这是单个报告，不足以说明所有 Cline 客户端都会这样。它提供了一个可查的原因：工具结果还在原始记录里，转成摘要输入时却被漏掉了。

我们另外核查了正式版标签中的两个函数：

• toPersistedToolResultContent 遇到数组时保留数组；遇到普通对象时转为 JSON 字符串。
• flattenToolResultContent 将结果转成摘要文字时，识别 text、file、image 类型；没有匹配类型的数组项会变成空字符串。

例如，报告所指的命令结果采用这样的结构。下面是公开演示数据，不是用户日志：

[
  {
    "query": "ls",
    "result": "README.md\nsrc",
    "success": true
  }
]

其中没有 type。把它送入该标签的保存转换和消息序列化函数后，得到的结果只有标签：

[Tool result]:

标签后没有 README.md 或 src。同一次离线验证中，合法的 text 块、file 块、普通字符串，以及保存为 JSON 字符串的单个对象，都保留了对应文字。这解释了为什么某些操作记录能留下，而另一类操作的结果消失。

runAgenticCompaction 会将待压缩部分序列化后交给摘要模型，再把生成的摘要与保留的近期消息组合起来。这里涉及被压缩的那部分历史，不表示整个会话的所有工具结果都会被清空。 输入给摘要模型之前已经缺失的内容，不能指望它准确还原。

截至查证日，相关修复 PR #15551 仍为 Open、未合并。PR 提议把未知结构转成 JSON，再按长度裁剪；作者提供了测试说明，本文没有把它当成已发布修复，也不建议直接修改本机安装包或会话记录。

不必先读源码，按这个顺序缩小范围

第一步，记清产品和版本。 CLI 可运行 cline --version；编辑器扩展查看扩展详情中的版本。不要用 CLI 的版本号判断 IDE 扩展，也不要把“使用 main”当成某个正式版的保证。顺便记下本次模型 ID、Provider 和压缩策略；这条报告针对 Agentic 路径。

第二步，选一条确实丢失的事实。 例如压缩前明确出现的错误码、函数名或失败用例。先确认对应文件没有被其他任务改动，再看摘要是否还包含它。摘要只写“测试失败”，通常不足以接着修。

第三步，有诊断数据再比较转换前后。 若你的版本能在本地查看摘要、导出任务或输出相关诊断，检查原工具结果和待摘要内容；看不到摘要请求时，保留“重复读取”的现象，不据此断言命中了 #15550。普通请求成功记录也不能证明摘要包含了正确内容。

通过 Nbility 接入时，可在用量日志按时间与模型核对是否出现请求错误。它帮助确认模型调用这一段；要判断工具结果在哪里丢失，还需客户端的脱敏记录。不要把完整项目、终端环境、Key 或整个会话直接贴到公开 Issue。

第四步，一次只改一个条件。 先保留模型与项目不变，用公开的小文件检查一次续接。换模型、换策略、升级程序同时进行，即使好了，也难以知道哪一步有效。新版本是否修复，应继续追到合并提交和实际发布记录。

先把正在做的任务接回来

如果任务已经开始重复探索，先暂停连续修改，保存当前 diff 和真实验证结果。可以向原会话发出下面这段要求，再逐项核对；已经缺失的事实需要从原记录或当前文件补充，不能把模型新写的交接说明直接视为证据。

先暂停修改，整理一份可以交给新会话的续接说明：

目标：本次任务要得到什么结果，怎样算完成。
约束：必须保留的行为，以及已否决的方案与原因。
当前改动：实际修改的文件、符号，以及尚未提交的差异。
关键发现：具体文件位置、错误信息、已经确认的原因。
验证：实际运行的命令和结果；未运行或未通过的项目单独写明。
下一步：一个最小的待办动作，以及它要验证什么。

只引用可核对的文件和已有记录；不知道的内容标为待确认。
不要重新扫描整个仓库，不要安装依赖、提交或发布。

另在终端检查一次 git status --short、git diff --stat 和相关文件的 git diff，确认交接说明对应当前工作区。这些 Git 命令只能检查版本控制范围内的改动；未跟踪文件需单独检查，也不能据此推断外部服务的状态。

新会话先只读相关文件，让它复述目标、当前改动和下一步，核对无误后再继续编辑。恢复是否成功，看它能否指出已经改了哪里、哪些验证仍没过、接下来只需查什么。有理由地重读某个函数是正常复查，从头重复同一轮探索才需要继续排查。

文件没有改坏时，不必仅为“忘记上下文”回滚代码。官方 Checkpoints 说明 区分恢复文件、恢复任务和两者一起恢复；选择前先看清影响范围。它不能替你撤回已发生的外部操作。

调大窗口、关掉压缩能解决吗

调大客户端声明的窗口，不会补回转换时丢失的工具结果，还必须符合实际模型限制。关闭压缩也只是改变后续历史如何增长，长任务仍可能达到窗口上限。先区分“触发得太早”“摘要请求失败”“摘要缺少事实”，再决定调整哪一处。

如果准备在 Nbility 上重新验证，按 Cline 接入文档确认模型与 Provider，用公开小文件、受限权限和一个明确的继续动作检查。验收目标是任务能接着做完；连接成功或摘要生成成功，都只验证了其中一步。

查证资料

• Cline Auto Compact 官方说明：说明压缩目的；“保留全部细节”等概括不能替代对具体版本输入的检查。
• CLI 3.0.74 发布记录：与本文固定代码标签对应；发布说明未确认 #15550 已修复。
• Issue #15550 与 PR #15551：报告、复现材料与待合并补丁，不代表故障发生率。

中文社区中，Tw93 在 V2EX 的 AI Coding 实践讨论里提到，多次失败后重新写清问题、诉求与已尝试方案。本文采用的是这种保留具体任务状态的思路；该讨论没有验证 Cline 的这条缺陷。