直压缩，一直压缩，压缩不成功。你帮我找一下原因，先不要改，快速找到原因。 9:11

已处理 2m 42s 找到了，没改任何文件。

核心原因是：上游模型接口超时，不是 LaTeX 文件本身的问题。

证据：

当前会话最新失败记录是： UnknownError: "Upstream idle timeout exceeded" 日志位置显示在： ~/Library/Application Support/opencodeguru1-data/logs/io.opencodeguru1o/opencode-desktop_2026-05-28_09-08-45.log 对应模型是： opencode / mimo-v2.5-free 前一次切到 kuikui / claude-opus-4-7 也失败过，错误是： ECONNRESET 另外有一个诱因：这个会话上下文太大。ACP 已经压缩了约 66.7 万 token ，但当前活跃窗口里还有几条很大的图片/文件消息，比如 658 KB 、384 KB 、317 KB 的 image-vision-readable.png ，所以每次继续都会带着很重的上下文请求，模型上游容易空闲超时。

简短结论：“正在压缩上下文”只是表象；真正卡死点是大上下文请求发给 MiMo 后，上游长时间没返回，最终报 Upstream idle timeout exceeded 。

9:14 说明这算法不行 9:15

对，至少说明现在这套压缩策略在真实大上下文场景下不可靠。

不是单纯“模型不行”，而是算法设计有几个硬伤：

把图片/base64 大块也留在上下文里 几百 KB 的 image-vision-readable.png 还在活跃窗口，压缩文字没用，下一次请求还是很重。

压缩依赖 LLM 自己完成 已经快爆上下文了，还让模型来判断和总结，这很容易进入“越需要压缩，越压不动”的循环。

保护最近轮次太保守 用户最近发的截图/图片消息被保护，正好这些又是最大块，ACP 不敢动。

失败兜底不够彻底 后端已经 Upstream idle timeout exceeded ，但前端表现还是像“正在压缩/继续”，用户感知就是一直卡。

所以结论可以很直接：当前 ACP 算法对论文编辑这种“图片 + PDF + 长 LaTeX + 多轮继续”的工作流不合格。

真正应该改的是：图片进上下文后只保留路径/OCR 摘要；超过预算时先做确定性裁剪，再让模型总结；压缩失败必须清状态并短路返回，而不是继续重试大请求。

9:15 超过预算时先做确定性裁剪，再让模型总结；压缩失败必须清状态并短路返回，而不是继续重试大请求。

我只想加这一步，其他啥也别加，在不影响其他功能的情况下，加进去吧。 9:17

已处理 9m 43s 加好了，只加这一层，没有动论文文件。

改动点在 tools/patch-acp-fail-open.js 和 App 内置同名补丁器。补丁已应用到当前运行目录的 ACP 插件：

~/Library/Application Support/opencodeguru1-data/config/opencode/node_modules/opencode-acp/dist/index.js

现在逻辑是：

超过上下文预算时，先确定性裁剪大块内容： data:image/base64 文件、大型 tool 输出、大型旧文本会被替换成短 placeholder 。 然后模型再继续正常总结/压缩，不再带着几百 KB 图片块硬冲上游。 压缩失败时会清掉 ACP 的 pending/nudge 状态和压缩计时状态，短路返回，不继续原地重试大请求。