如果你不知道 OpenCode 是什么，可以想象一只靴子永远踩在一个人的脸上。这只靴子由 TypeScript 制成，而这张脸则代表了自1940年代电子计算机发明以来我们对安全性和系统软件所有的学习。创作者将其描述为一个 AI 编码代理。据我所知，这是当前最流行的开源编码代理，GitHub 上已有 161,000 个星标。我尝试在本地 LLM 上使用 OpenCode。我的结论是 OpenCode 是一个充满瑕疵的傻瓜工具，其安全态度如同“让我为你屈服，爸爸”。所有使用它的人都应该停止使用它。这篇文章分为两部分：令人烦恼的因素和令人担忧的因素。第二部分较长。我在写这篇文章时参考了 OpenCode git 版本 baef5cd4 的源代码。我不认为这篇文章中的任何内容都是安全披露。OpenCode 本质上是一个用于管道 llm | bash 的网络栈工具，而我所描述的所有问题都在“管道”部分。它失败的方式在拙劣决策的分形特性中是引人入胜的，但结果是可预见的。我尝试将 LLM 的使用讨论与每个人的机器是否应该被轻易利用或意外擦除分开。还有一段后记，包含一些关于本地 LLM 的简要想法。 令人烦恼的事情 让我们暂时把安全性放在一边，看看 OpenCode 如何作为一个工具失败，即使它不会导致你的问题被曝光。OpenCode 存在一种“贝塞斯达效应”，使得很难判断什么是错误，什么是设计造成的，因此我将其描述为“令人烦恼”。 提示缓存未命中 大多数本地 LLM 服务器都使用某种变体的 OpenAI /v1/chat/completions API。其思想是：你向服务器 POST 一个 JSON blob，包含至今为止的整个对话。你会收到一个 SSE 事件流，汇总成响应。整个会话的上传成本是二次方的，而下载则通过将微小的增量包裹在 JSON 中并重复元数据而放大。工具调用使用难以捉摸的“双重 JSON 编码”，这样它们可以序列化为多个 JSON 编码的增量，重新组合成更多 JSON。这个设置有一个好处，即服务器是无状态的。与往常一样，让无状态的东西变得快速的方法是：状态。服务器缓存评估。当它收到请求时，它： - 找到最长匹配的缓存前缀。 - 从前缀的末尾到最后发布的消息的末尾进行评估（“预填充”）。 - 生成新标记，直到遇到序列结束标记。 我在一台 M4 Max 上使用 Qwen3.6-27B dense，它具有合理的内存带宽（约 0.5 TB/s，CPU SoC 中较高，GPU 中较低）。标记生成是可用的，但在预填充时非常依赖计算。如果我的服务器在请求提示的窗口深处找不到一个好的匹配前缀，那么我可能需要等待 10 分钟的最大 GPU 使用率以开始生成响应。这很好，因为这种情况应该很少发生。但这里是 OpenCode 在这方面遗漏的一些方式：它遍历你的文件系统，并在每个 SSE 回合中重新读取 AGENTS.md（插入在 turn-0 系统提示中）。如果你在 AGENTS.md 中插入一个快速的说明，要求在下一个会话中读取，你会立即强制进行全面重新评估。它在每个代理 → 用户过渡时从工具调用中修剪上下文，从而使大部分前缀失效。修剪仅丢弃比写头落后固定距离 const PRUNE_PROTECT = 40000 的工具调用结果。在最佳情况下，你面临 40k 上下文未命中的情况，等同于每两到三轮读取一部完整的小说。代理 → 用户过渡包括中断，因此如果你需要把一个 clanker 从一个死胡同中拉出并重新引导，OpenCode 会立即丢弃提示缓存，并让你等待一个响应。我的个人最爱是：它在 turn-0 系统提示中放置当前日期，并在每个 SSE 回合中重新评估。如果你在午夜使用 OpenCode，你会得到一个完整的提示缓存未命中。我认为这样做是为了补救 clanker 倾向于将当前日期视为其训练截止日期的倾向，并拒绝相信更新事物的存在。这依然很有趣。这些是仅适用于这一类别的提示缓存未命中事件。还有许多其他的；我在后面会列举出来。 修剪 我在上一节中提到过修剪。提示缓存未命中并不值得，因此我禁用了它。另一个明显的问题是对早期读取缺乏保护。这可能不明显有多么完全破坏，因此让我们通过一个示例来处理。假设你开始一个新会话，告诉你的 clanker 首先阅读一个规范或实施计划，然后编写一些代码：规范被读入上下文。clanker 去阅读相关代码，很可能让它超出固定的 40k 修剪阈值。clanker 准备实施，但要么立即深入一个愚蠢的死胡同，要么在某个实际上非常简单或已经明确定义的事情上犹豫不决。你打断 clan...