为什么不要用 @prevalentware/opencode-goal-plugin

1. 现象

@prevalentware/opencode-goal-plugin 提供了类似 Claude Code 原生的 /goal 体验：设定长期目标、自动续写、状态持久化，使用起来确实方便。然而，实际使用中发现，一旦启用该插件，缓存命中率几乎降为零，每次请求输入 token 高达 10～12 万，输出仅数百 token，连续请求成本稳定在 $0.05 左右。其功能虽好，但成本完全失控。

2. 原因分析

该插件破坏缓存的原因在于其续写机制实现不当，具体包括：

• 每次续写强制重新注入完整的会话上下文：插件在自动续写时，会重新构建请求，导致系统提示词前缀发生变化，使缓存无法命中。
• 动态注入目标状态信息：插件会持续更新目标状态、历史记录等动态内容，这些内容写入系统块后，使前缀哈希变化。
• 可能触发进程重启：部分实现方式可能导致每次 opencode run 或续写操作启动新进程，使得 OPENCODE_EXPERIMENTAL_CACHE_STABILIZATION 冻结的日期失效。
• 与 OpenCode 官方的系统提示拆分不兼容：该插件可能绕过官方拆分机制，将动态内容重新塞入稳定块，使 S1 的缓存失效。

3. 实测对比

在相同 DeepSeek 模型、相同项目、相同任务下，对比启用该插件前后的缓存命中率：

结果一目了然：插件功能虽好，但成本是原生方式的 4 倍，且实际任务推进效率并未提升（输出 token 同样少）。

4. 为什么不修复？

该插件并非官方出品，其设计目标优先于“易用性”而非“缓存友好”。作者可能未充分理解 OpenCode 缓存机制，或未适配 #14743 的修复。即使后续更新，当前版本仍存在此问题。

5. 替代方案

OpenCode 原生已提供足够的能力实现长期目标自动延续：

• 使用 opencode run -c 循环：在脚本中每 N 秒执行一次 opencode run -c "Continue..."，完全无插件依赖，缓存前缀稳定。
• 使用 opencode serve + attach：常驻进程方式，缓存命中率最高（99%+），且不会因进程重启破坏日期冻结。
• 手动设置长期目标：在会话开始输入清晰目标，后续每隔一段时间发送“继续”，同样有效。

这些原生方式不仅成本可控，而且配合环境变量后缓存命中率可达 97% 以上。

6. 结论

@prevalentware/opencode-goal-plugin 虽然功能强大、体验接近 Claude Code，但其实现严重破坏缓存机制，导致输入 token 成本急剧上升，实际性价比极低。建议立即弃用，转而使用 OpenCode 原生的 -c 或 serve 方式自动化延续任务。若仍需图形化目标状态，可考虑其他轻量插件（如 oh-my-goal），但务必先测试其缓存表现。

一句话总结：插件的便利性，远不值它烧掉的成本。