为什么 OpenCode 胜出？

我们正在进入最先进（SOTA）开源模型的时代。

Kimi K3 在几周前发布，而在它之前还有 GLM 5.2。越来越明显的是，OpenAI、Anthropic 和 Google 终于迎来了开源模型的真正竞争。

我们早就知道前沿 LLM 正在触及平台期。每一款新旗舰的进步幅度都比上一款更小。这始终意味着开放权重模型最终会缩小与封闭实验室之间的差距——问题只是什么时候。

今年夏天的新变化是："最终"开始看起来非常像"现在"。

在过去一年里，我试过几款 AI 编程工具：Gemini CLI、Claude Code、Kiro、Antigravity，现在还有 OpenCode。

如果你在四五个月前问我，对于构建中小型项目的开发者来说什么是最好的选择，我会毫不犹豫地说 Claude Code 或 Codex。

我的理由很简单：

这些公司拥有最强的智能体编码模型。它们能用更少的 token 完成任务，而且尽管关于严格使用限制的抱怨不无道理，它们的订阅方案在每 token 成本上仍比通过原始 API 运行同样的模型更划算。 例如，通过 Claude 订阅运行 Opus，肯定比通过 OpenRouter 等 API 提供商访问同一模型更便宜。 此外，我当时更倾向于 TUI/CLI 智能体，而不是当时最主流的 IDE 集成智能体。而且，我的使用场景不需要消耗大量 token 的配置，我处理的代码库也不算庞大，所以标准的订阅方案给我的算力绰绰有余。

但如果你今天问我，答案是 OpenCode。

用了两个月之后，它的体验比我预期的还要好。

以下是原因，附上真实数据。

1、开放权重模型确实在迎头赶上

GLM 5.2 于 6 月中旬出自 Z.ai。这是一个约 7500 亿参数的混合专家（MoE）模型，以纯 MIT 许可证发布。它的性能可与 Opus 4.8 相媲美，但每百万输入 token 便宜 $0.6，每百万输出 token 便宜 $20.6。

随后，Moonshot AI 在 7 月中旬推出了 Kimi K3，2.8 万亿参数，同样为长周期编码和智能体工作而构建。它的性能可与 Fable 5 相媲美，但每百万输入 token 便宜 $7.0，每百万输出 token 便宜 $35.0。

根据 Arena.ai 的排名，这些都是顶级模型，位列 Web 开发整体模型 Top 10，如下图所示。

虽然 Claude Opus 4.8 在所有相关基准（智能、编码和智能体）上的整体表现仍然优于 GLM 5.2（如下图所示），但对于标准的智能体和编码任务来说，这个差距并不明显。

当要求模型从头一次性生成整个应用或游戏时，差距会变得明显得多。这些极端任务正是前沿模型仍然展现优势的地方。

但这不是大多数开发者实际使用编码智能体的方式。

大多数真实世界的使用是更小的迭代任务：

• 调试、实现功能、重构代码、编写测试、探索陌生代码库，以及改进现有系统。

对于这些工作流，从纯能力角度看，最好的封闭模型与最好的开放权重模型之间的差异越来越难以论证。

Kimi K3 不仅在多个基准上缩小了与 Claude Fable 5 的差距，还直接超越了它，包括在社区投票的前端代码竞技场（Frontend Code Arena）上夺得第一，领先榜单上的所有封闭模型。

这并不意味着开放权重模型已经赢了。

GLM 5.2 和 Kimi K3 都没有在每个基准上占据主导地位，而且评估 LLM 需要远不止看几个排行榜或发布时的"信我没错"式基准。

性能在很大程度上取决于具体工作流、任务类型、智能体工具和开发者的期望。

但至少对我而言，"在最难的那部分任务上仍然领先"和"在其他所有事情上值几倍的价格"是两个不同的论断。毫无疑问，第二个论断决定了我大多数日子会拿起什么工具。

2、工具与模型提供商的选择

要完全严谨，我得测试每一款可用的工具，而那数量很多。仅统计与 OpenRouter 兼容的编码智能体就有 34 个，如下所示。

不过，这篇文章并非意在成为通用基准。它基于我个人的工作流和经验。

所以，除非你的使用场景、工作流和项目规模与我类似，否则请把这当作一个数据点，而不是绝对事实。

3、我之前试过的工具

在过去一年里，我试过 Gemini CLI、Kiro、Claude Code 和 Antigravity。它们都没有像 OpenCode 那样让我留下来。快速回顾如下：

• Gemini CLI是我第一次"氛围编程"（vibe coding）体验。我喜欢 Gemini 2.5 Pro 在调试方面的表现，所以我想着试试它的 CLI。一开始还可以，还有很大的改进空间，但用于 POC 和要求不高的编码任务够用。令人沮丧的是它无法始终遵循我在 GEMINI.md 文件中指定的规则和指南。它处理快速脚本没问题，但感觉从来不是为持续性工作而设计的。有趣的是，Google 似乎也认识到了类似的局限，此后已把重心转向更新的、面向智能体的工具。
• Kiro是下一个。它是当时新推出、流行的工具，对编码智能体有不同的思路。Kiro 是 AWS 的"规格优先"（spec-first）IDE；它会在实现之前自动从你的提示词生成需求和设计规格，不过你也可以跳过规格生成直接编码。这种方法感觉比 Gemini CLI 前进了一大步。它真的很好——直到不好用了。 它过于依赖规格，以至于对简单项目来说显得太"规格化"，而且当时的模型还不够可靠，无法处理所有这些。此外，我是一个忠实的 VS Code 用户，所以永久换 IDE 从来不在考虑范围内（这也是我从没试过 Cursor 的原因）。
• Claude Code是下一个。说实话，我主要是想看看大家到底在激动什么。X 上的人没完没了地谈论它。但由于我不是 Anthropic 或 OpenAI 的粉丝，我对它们的任何产品都不是很投入。话虽如此，我无法否认它在各方面都超越了我之前试过的一切，部分原因是 Claude Code 整体上是更好的工具，部分原因是 Anthropic 的模型在当时就是更擅长智能体编码。
• Antigravity 2.0是最后一站。我听说它相比第一个版本有巨大改进，而且它被宣传为智能体优先（agent-first）平台（稍后细说这意味着什么），并与 Gemini 3.5 一同发布，所以我试了试。不出所料，它和我的编码工作流以及我想用 AI 编码的方式并不契合。

还有一点值得注意：这些工具我每款都没用超过一个月。对我来说，那已经是足够的测试时间。在试用之间，我会退回"老办法"，需要帮助时依赖聊天机器人。

然后，我换到了OpenCode。

4、为什么是 OpenCode

OpenCode 是 Anomaly 团队在 2025 年中期构建的开源工具。自那以后，它从一个相当小众的终端工具成长为一个庞大的项目，截至本文写作时已拥有超过 190,000 个 GitHub 星标和每月数百万开发者。 我知道它，但从未有兴趣去使用它。正如我所说，每个月都有新的 AI 工具发布，追逐每一个炒作周期并不高效。 真正让我开始研究开源工具的是 GLM 5.2 及其非凡的性价比。那时我决定彻底研究该用哪个开源工具。 我不拿细节烦你，但最后的选择落在了 Pi 或 OpenCode 之间。

基于我之前的经验，我对基于 CLI/TUI 的智能体有所保留，而且我意识到我并不真的想要把编码智能体直接集成到我的 IDE 里。所以我开始相信，独立的 GUI 是更好的选择，原因有几个：

• 它更容易使用。
• 浏览历史、调整偏好和管理会话感觉更自然。
• 在审查智能体的工作（diff、工具调用、推理过程）时有更好的人机工效。
• GUI 通常更先进，支持远程环境、移动端控制、图像处理和文件浏览器等功能。

幸运的是，除了 CLI 和 TUI，OpenCode 还有一个仍处于测试版的桌面应用。

除此之外，OpenCode 是一个人类优先（human-first）的工具，它有一个订阅方案，提供 GLM 5.2 等开源模型，而且根据下面的 Coding Agent Index，它作为工具的性能优于 Cursor CLI 和 Claude Code。

这基本上就是我选择 OpenCode 而不是 Pi 的原因。

5、关于人类优先 vs. 智能体优先的方法

OpenCode 默认采用双模式（智能体）设置：

• Plan 模式是只读的，在触碰你的 shell 之前会请求许可。
• Build 模式才是真正写代码的地方。

你可以在读完它提议的内容后，用一次按键/点击在两者之间切换。简而言之，AI 从不完全自主行动，你对实际执行的内容保留完全的控制权。

这简要来说就是人类优先的方法。

智能体优先的方法则是你在远处管理一群智能体：

• 你对一个编排器说话，它再派生子智能体并分配任务。

所以，与其指导每一步，你设定高层目标，让 AI 系统自主执行。

现在，我并不认为智能体优先是错误的思路。它只是不适合我的工作流。我构建的大部分东西不需要五个智能体并行管理自己。它需要一个我能直接引导和监督的智能体。

6、选择模型提供商

工具确定之后，我寻找在价格与算力比方面最好的模型提供商。这是一项相当有挑战性的任务，因为订阅方案的主要问题是，大多数都不透明，不会真正以 token 量化它们提供多少算力。所以客观比较它们很难，因为没有共同的衡量标准。

我能想到的最佳替代方案是用户评价。

于是我通读了大量关于 OpenCode Go、Ollama Cloud 和 Z.ai 的评价和讨论——这是我能找到的仅有的三家为 GLM 5.2 提供订阅方案的提供商。

这些评价一致指向以下几点：

• 性价比：OpenCode Go 略优于 Ollama Cloud Pro，远优于 Z.ai Lite。
• 可靠性与可用性：Ollama Cloud Pro 和 Z.ai Lite 都有大量关于停机、延迟和超时的抱怨。
• 速度：OpenCode Go 生成响应的速度明显快于另外两家。

所以总的来说，Go 方案是推荐之选。

不过，主要的限制是它面向小项目，所以在大型代码库上使用会在不到两周内耗尽你的用量，因为有一个你无法超越的每周用量阈值。

一旦用完，它要么降级到免费层模型，要么在你保持余额的情况下扣减你的 Zen（OpenCode 的按量付费选项）余额。

但 Go 方案实际提供多少算力呢？

订阅价格是每月 $10，它提供价值 $60 的原始 API 成本。那么对于 GLM 5.2、Kimi K3 和 DeepSeek V4 pro，这换算成 token 就是：

基于这些数值，我的工作流变成了：

• 复杂推理和困难实现任务用 GLM 5.2。
• 常规编码用更便宜的捆绑模型，比如 DeepSeek V4 pro。
• 简单问题和对话用 DeepSeek V4 Flash 等免费模型。

在订阅的头三周里，我很少感到受限。

• Kimi K3 在我第一个月时还不可用，但现在可用了，而且对于非常复杂的任务，它是一个非常有吸引力的选择。
• 如果你更倾向于按量付费，我的建议是跳过 OpenRouter。它很流行，但外面有更好的选择。Neuralwatt 就是我想指给你的一个。我最初是通过这个 Reddit 帖子了解到它的，想了解细节的话值得一读。

对于需要比 Go 订阅提供更多容量的开发者来说，把它与一个更便宜的按量付费提供商结合使用，可以是一个非常有成本效益的设置。等我亲自测试过这种组合后，我会写一篇关于最佳组合的文章。

7、OpenCode 体验

配置好桌面应用和 Go 订阅后，我直接投入工作。我有一个搁置了一段时间的小项目想法，所以感觉是时候终于试一试了。

首先，我按照自己喜欢的方式配置了工具：

• 连接我的模型提供商。
• 创建自定义智能体和子智能体。
• 下载相关技能（skills）。
• 设置我的全局 AGENTS.md 文件。

我这样配置的目标是创造一个智能体从开始就理解我的工作流和编码偏好的环境。

工作流

我第一个月的日均花费大约在 $3 到 $4。

规划和要求更高的编码任务我用 GLM 5.2，标准和简单编码用 DeepSeek V4 Pro 和 MiniMax M3，聊天和快速问题用免费的 DeepSeek V4 Flash。

这种组合效果出奇地好，我会一直推荐它。

与其每次交互都用最贵的模型，不如把模型当作不同优势的不同工具。

说实话，体验比我预期的更顺畅。

我没有遇到任何停机、错误或延迟。

生成速度可以接受，尽管它自然取决于所选模型和任务复杂度。

OpenCode 桌面应用与 VS Code 的组合对我的工作流来说尤其好用。

我没有把 AI 助手直接嵌入编辑器，而是有一个专门的空间来管理对话、审查变更和控制智能体。

这种分离感觉非常自然。

到第二个月，我用 OpenCode 启动的项目已经增长到超过 20,000 行代码，我开始更快地触及自己设定的每天 $4 上限。这意味着在会话管理以及使用哪个模型或智能体上要更加深思熟虑。

这就是为什么混合方案对中型项目更有意义。

例如：

• OpenCode Go（每月 $10）作为主要订阅。
• 需要时补充 Zen 积分。
• 一个二级按量付费提供商（如 Neuralwatt）用于溢出用量。

与传统的顶级订阅（通常 $20）相比，总成本仍然非常有竞争力。

8、结束语

OpenCode 是一个可定制、对新手友好的工具，支持你所期望或需要的所有功能。它的桌面应用设计精良，使用起来很自然，不会给你的编码工作流带来摩擦。

说到模型提供商，Go 订阅绝对是一个很好的起点——如果不是最好的话。但如果你在做中型或更大的项目，它不够撑一整月。不过因为只要 $10，我建议叠一个二级订阅或加一个按量付费选项。

所以，如果你还在为每一个 token 支付顶级价格，也许值得检查一下是否还有这个必要。

原文链接：为什么 OpenCode 胜出？ - 汇智网