为什么 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 订阅后，我直接投入工作。我有一个搁置了一段时间的小项目想法，所以感觉是时候终于试一试了。

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