关于 OpenCode 的一些令人烦恼和令人警惕的事情

原文 ↗ Hacker News 讨论 ↗

对流行的 OpenCode AI 编码 harness 的批评主要集中在安全漏洞、资源消耗大、脆弱的提示缓存，以及带有强烈意见倾向的系统提示词会悄然改变代码风格，甚至移除注释。评论者认为，这些缺陷反映了当前“agentic” LLM 工具的更广泛问题：它们常常在薄弱的沙箱隔离和具有误导性的权限系统下运行不受信任的代码，从而带来严重的供应链和隐私风险。尽管许多人仍然觉得 OpenCode 非常高效——尤其是因为它能免费或低成本访问模型——但也有人正在迁移到 Pi、Codex 或自定义 harness，通常还会配合更强的外部沙箱或仅本地模型。

对 OpenCode 的总体反响

  • 许多人同意这篇文章有夸张成分，但认为其核心批评大体准确。
  • 几位用户表示，OpenCode 让他们非常高效，仍然是他们最喜欢的 harness。
  • 其他人已经迁移到（或现在打算迁移到）Pi / OhMyPi、Codex、Kilo、Mimo、Maki、Aider 等替代方案。

安全、权限与沙箱

  • 文中提到多项严重安全问题和 RCE；据称有些已修复，另一些则不明确。
  • 从安全角度看，文本命令过滤器 / “allowlist” 被广泛认为很弱或具有误导性。
  • 基本共识是：不要在你的真实文件系统上信任任何 coding agent；应将其运行在沙箱/VM 中（bwrap、sandbox-exec、flatpak、landlock 等）。
  • 争论点在于：沙箱应当集成到 harness 中，还是由独立工具来处理。

提示缓存、压缩与性能

  • 由于系统提示词变动（日期、AGENTS.md 变化等）导致的频繁缓存未命中，是一个主要烦恼，也是 token 的消耗大户。
  • 压缩/剪枝被认为速度慢、有 bug，而且经常适得其反；有人通过环境变量将其禁用。
  • 另一些人表示，后端缓存（例如 DeepSeek、vLLM）可以掩盖客户端效率低下的问题。
  • OpenCode 开发者提到，存在问题的剪枝默认已禁用，而 v2 的改动旨在避免破坏缓存。

系统提示词、注释与 LSP

  • 默认提示词被批评为体积巨大、杂乱，并强制一些可疑策略（例如“不要注释”），这会导致不必要地删除注释。
  • 有些人赞同尽量少注释的输出；也有人明确指示 agent 添加大量注释，并与默认设置对抗。
  • LSP 集成引发分歧：有人认为它是重构和符号查找的杀手级功能；另一些人则觉得收益不大、 token 成本很高。

治理、UX 与项目健康状况

  • 大量未关闭 issue、激进的 stale bot，以及稀少的 PR 接受，助长了“名义上开源”的说法。
  • 有人抱怨臃肿、高 CPU/RAM 占用，以及令人困惑的新 UI（标签页、workspace 支持丢失）。
  • 维护者回应称 v2 解决了若干被提出的问题，但也承认 GitHub issue 噪音很多。

对 LLM agent 和语气的更广泛看法

  • 许多人指出，同样的结构性问题也适用于大多数 agentic CLI，而不只是 OpenCode。
  • 有些人认为这篇文章本质上是在反对用于 SWE 的 AI；另一些人则将 LLM 视为“只是工具”，需要现实的预期和强隔离。
  • 文章激进、带嘲讽的语气也两极分化；有人喜欢这种吐槽，另一些人则觉得不公平或令人沮丧。