OpenCode 2.0

原文 ↗ Hacker News 讨论 ↗

OpenCode 2.0 作为一个开源 AI 编码 harness，采用客户端—服务器架构，被认为相较 v1 有显著功能升级，加入了后台任务、热重载插件、更好的配置处理以及更强的多客户端支持。与此同时，许多用户也报告了严重问题：高内存/CPU 占用、缓慢且耗 GPU 的宣传网站与安装器、围绕沙箱与远程配置的安全回归，以及一种“vibe-coded”式的质量和支持印象。几位评论者表示他们已经转向或正在考虑转向 Pi、Claude Code、Codex 或 DeepSeek 的 harness，通常是因为更好的性能、更简单的 UX 和更清晰的定价，不过也有人仍认为 OpenCode 的 Go 订阅和生态系统很有价值。

OpenCode 2.0 的整体反馈

  • 许多老用户认为 2.0 相比 1.x 有显著改进（客户端/服务器模型、后台任务、子代理、技能/插件自动重新加载、从项目文件夹读取配置、内置配置编辑器）。
  • 一些人把它当作日常主力工具，并赞赏其与模型无关的设计、通过服务器进行远程访问，以及非 TUI 界面（网页/桌面端）。
  • 另一些人则感到失望：回归问题、基础功能损坏（例如侧边栏隐藏）、使用感笨重，以及对如何安装甚至如何从 npm 获取“2.0”感到困惑。

性能、资源占用与守护进程

  • 对宣传网站的强烈抱怨很多：动画/WebGL 风格行为过重、滚动缓慢、CPU/风扇占用高，尤其在手机和笔记本上；有些人觉得几乎无法使用。
  • 工具性能是反复出现的问题：RAM/CPU 占用高、文件监视器数量大、此前临时文件膨胀，以及“内存泄漏”式行为的名声。
  • 2.0 的持久后台服务器改善了启动速度并支持多客户端使用，但也有人强烈反对默认始终运行的守护进程。
  • 有少数人报告称，即使关闭 UI 后，Opencode 仍继续驱动本地模型。

安全、沙箱与插件

  • 多位用户将 2.0 描述为存在安全回归：
    • 后台进程绕过现有 TUI 的沙箱。
    • 插件添加的工具不遵守权限配置。
    • 插件热重载使代理能够立刻改变其自身环境。
    • 强制从提供商的 .well-known/opencode 加载远程配置，被描述为实际上等同于远程代码执行。
  • 与使用成熟引擎相比，极简的自定义 JavaScript 解释器被认为尤其危险。
  • 建议的缓解措施：--standalone、在容器/虚拟机中运行，或使用专用沙箱工具；也有人认为 harness 无法实现真正安全，隔离是必须的。

安装器、打包与工具链

  • curl | sh 安装器因为误用 curl trace，导致“进度条”极慢；后已修复。
  • TUI 中的复制粘贴劫持仍然是一个主要烦恼。
  • npm 打包方式遭到批评：postinstall 下载真正代码，常常失败（“postinstall script not run”），并且对带标签的发布版本也存在混淆。

与其他 harness 及定价的比较

  • Pi、Codex、Claude Code、DeepSeek harness 等常被拿来比较：
    • Pi 因资源占用低、提示最少、简单，以及在本地/开源模型上表现强劲而受到称赞；不少用户因 UX、性能或安全顾虑从 OpenCode 转向了它。
    • 也有人仍选择 OpenCode，因为它有客户端/服务器设计、UI 选项以及对不同提供商的灵活性。
  • OpenCode Go 订阅被广泛视为非常划算，限额慷慨且有补贴，不过定价模型和请求/限额表让人困惑。
  • 有一位用户报告称，自己的账单一直高于文档所示的每 token 价格，而且在最初得到确认后就再也没有回应，这损害了他们的信任。

UX、生态与工作流

  • 一些人主要把 OpenCode 当作后端，配合 OpenChamber、Paseo、Termic 等替代 UI，或编辑器集成（Vim/Neovim/VSCode/Zed）使用。
  • 关于 TUI 与 GUI 的争论：键盘驱动的 TUI 被一些人视为强大；另一些人则认为 TUI 不适合长篇文字和 Markdown，更偏好更丰富的 GUI。
  • 扩展/插件生态（MCP、tools、skills）是主要吸引点，但同时也是复杂性和潜在安全问题的来源。
  • 还提到了 harness 基准测试；结果各不相同，用户强调行为高度依赖 harness 设计、工具和提示，而不仅仅是基础模型。