我们现在正进入最先进的（SOTA）开源模型时代。
Kimi K3 在几周前发布，在此之前我们有 GLM 5.2。OpenAI、Anthropic 和 Google 终于越来越明显地迎来了来自开源模型的真正竞争。
我们已经知道，前沿 LLM 正在进入平台期有一段时间了。每一代新旗舰的提升都比上一代更小。这本来就意味着，开源权重模型最终会缩小与闭源实验室之间的差距。只不过是时间问题。
而这个夏天的新变化是，“最终”开始越来越像“现在”。
过去一年里，我试过几种 AI 编码 harness：Gemini CLI、Claude Code、Kiro、Antigravity，以及现在的 OpenCode。
如果你在四五个月前问我，对于构建中小型项目的开发者来说，最好的选择是什么，我大概会毫不犹豫地说 Claude Code 或 Codex。
我的理由很简单：
这些公司的 agentic coding 模型最强。它们能用更少的 tokens 完成任务，而且尽管人们对严格使用限制有合理抱怨，它们的订阅方案在每 token 成本上仍然比通过原始 API 直接运行同样的模型更划算。 比如，通过 Claude 订阅运行 Opus，在每 token 成本上肯定比通过 OpenRouter 之类的 API 提供商访问同一个模型更便宜。 除此之外，我也更倾向于使用 TUI/CLI Agents，而不是集成在 IDE 里的 agents，而当时后者才是最显眼的选项。另外，我的使用场景也不需要非常吃 token 的配置，而且我工作的代码库并不庞大，所以标准订阅计划提供的算力对我来说已经绰绰有余。
但如果你今天问我，答案就是 OpenCode。
两个月下来，它带给我的体验比我起初预期的更好。
下面用实际数字说原因。
开源模型确实在追上来
GLM 5.2 于 6 月中旬由 Z.ai 推出。它是一个大约 7500 亿参数的 mixture-of-experts 模型，采用宽松的 MIT 许可证发布。它的性能与 Opus 4.8 相当，但每百万输入 tokens 便宜 0.6 美元，每百万输出 tokens 便宜 20.6 美元。
随后，Moonshot AI 又在 7 月中旬推出了 Kimi K3，参数规模达到 2.8 万亿，同样面向长周期 coding 和 agentic 工作。它的性能与 Fable 5 相当，但每百万输入 tokens 便宜 7.0 美元，每百万输出 tokens 便宜 35.0 美元。
这些都是顶级模型，并且根据 Arena.ai，它们都位列 Web Dev 总榜前 10，如下图所示。
不过，从下图可以看到，Claude Opus 4.8 在所有相关基准测试（Intelligence、Coding 和 Agentic）上的整体表现仍然比 GLM 5.2 更好。对于标准的 agentic 和 coding 任务来说，这个差距其实并不算明显。
当要求模型一次性从零构建整个应用或游戏时，这个差距就会明显得多。这类极端任务仍然是前沿模型优势最明显的地方。
但这并不是大多数开发者实际使用 coding agents 的方式。
现实中的大多数使用场景都是更小的迭代任务：
-
调试、实现功能、重构代码、编写测试、探索陌生代码库，以及改进现有系统。
对于这些工作流，最好的闭源模型和最好的开源权重模型之间的差距，正变得越来越难以仅从能力角度去证明其合理性。
Kimi K3 不只是缩小了与 Claude Fable 5 的差距，它还在多个基准上直接胜出，包括在社区投票的 Frontend Code Arena 中拿下第一名，领先榜单上的所有闭源模型。
这并不意味着开源权重模型已经赢了。
GLM 5.2 和 Kimi K3 都不是在每个基准上都占优，而且评估 LLM 远不只是看几个排行榜，或者发布时的某个“信我兄弟”基准测试。
性能高度依赖具体工作流、任务类型、agent harness，以及开发者的预期。
但至少对我来说，“在最难的一小部分任务上仍然领先”与“对其余所有情况都值得付出数倍价格”是两回事。而毫无疑问，后者才是决定我大多数日子里会用什么的因素。
Harness 和模型提供商的选择
如果要足够严谨，我得测试所有可用的 harness，而那数量很多。光是统计支持 OpenRouter 的 coding agents，就有 34 个，如下图所示。
不过，这篇文章并不是要做一个通用基准测试。它基于我个人的工作流和经验。
所以，除非你的使用场景、工作流和项目规模和我非常像，请把这篇文章当作一个数据点，而不是绝对事实。
我之前试过的 Harness
过去一年里，我试过 Gemini CLI、Kiro、Claude Code 和 Antigravity。没有一个像 OpenCode 那样留下来。下面是简要概述：
Gemini CLI 是我的第一次“vibe coding”体验。我喜欢 Gemini 2.5 Pro 在调试上的表现，所以我想试试这个 CLI。起初它还不错，有很大的改进空间，但做 POC 和要求不高的 coding 任务已经能用。让我沮丧的是，它没法稳定遵守我在 GEMINI.md 文件里指定的规则和指南。它适合快速脚本，但从来不像是为持续工作而设计的。有意思的是，Google 似乎也意识到了类似的局限，并且后来把重点转向了更新的、面向 agent 的工具。
Kiro 是下一个。它当时是新推出、很时髦的 harness，对 coding agents 的理解也不一样。Kiro 是 AWS 的 spec-first IDE；它会先根据你的提示自动生成需求和设计规格，然后再实现，不过你也可以跳过 spec 生成，直接写代码。这种方式感觉比 Gemini CLI 真正上了一个台阶。它一度非常好，直到它不行了。
它过度依赖 specs，以至于在简单项目里显得过于“spec 化”，而当时的模型也不够可靠，没法处理这么多流程。除此之外，我也是个坚定的 VS Code 用户，所以长期切换 IDE 从来都不在考虑范围内（这也是我从没试过 Cursor 的原因）。Claude Code 是下一个。老实说，我主要是想看看它到底有什么好吹的。X 上的人一直在谈论它。但因为我并不喜欢 Anthropic 或 OpenAI，所以我其实没有真正投入到它们的产品中。尽管如此，我不能否认它在各方面都比我之前试过的东西更强，部分原因是 Claude Code 本身就是更好的 harness，部分原因是当时 Anthropic 的模型在 agentic coding 上确实更强。
Antigravity 2.0 是最后一站。我听说它相比首个版本有了很大改进，而且它被宣传为一个 agent-first 平台（下面我会解释这是什么意思），并且是和 Gemini 3.5 一起发布的，所以我试了一下。正如预期，它并不适合我的 coding 工作流，也不符合我希望 AI 参与 coding 的方式。
还有一点值得注意：我从来没有把这些 harness 任何一个用超过一个月。对我来说这已经足够了。每次试用之间，我都回到“旧方式”做事，需要帮助时就依赖聊天机器人。
然后，我切换到了 OpenCode。
为什么是 OpenCode
OpenCode 是 Anomaly 团队在 2025 年中期构建的开源工具。从那以后，它从一个相当小众的终端工具，变成了一个巨大的项目；截至本文写作时，它已经拥有超过 190,000 个 GitHub stars，以及数百万月活开发者。 我知道它，但从来没有足够感兴趣去用它。就像我说的，每个月都有新的 AI harness 发布，追逐每一次 hype cycle 并不高效。
真正让我开始研究开源 harness 的，是 GLM 5.2 以及它提供的极高性能/价格比。于是我决定认真研究到底该用哪个开源 harness。
我就不展开细节了，但最后只剩下 Pi 和 OpenCode 两个选择。
基于我之前的经验，我对基于 CLI/TUI 的 agents 有些保留，而且我意识到自己其实并不想把 coding agent 直接集成进 IDE。所以我开始认为，单独的 GUI 才是更合适的选择，原因有几个：
更容易使用。
浏览历史、调整偏好和管理会话时，感觉更自然。
在审查 agent 的工作时，人体工学更好：diff、tool calls、reasoning。
GUI 通常也更先进，支持远程环境、移动端控制、图片处理和文件浏览器等功能。
值得庆幸的是，除了 CLI 和 TUI 之外，OpenCode 还有一个桌面应用，而且仍处于 beta 阶段。
除此之外，OpenCode 是一个 human-first harness，并且它有一个订阅计划，除了其他开源模型之外还提供 GLM 5.2，而且根据下面的 Coding Agent Index，它作为 harness 的表现比 Cursor CLI 和 Caude Code 更好。
这基本上就是我为什么在 Pi 和 OpenCode 之间选择了 OpenCode 的原因。
关于 Human-first 与 Agent-first 的方法
OpenCode 默认采用两种模式（agents）设置：
Plan mode 是只读的，并且在接触你的 shell 之前会请求许可。
Build mode 才是真正写代码的地方。
只要你看过它的建议，就可以用一个按键/点击在两者之间切换。简而言之，AI 不会完全自主行动，而你对实际执行的内容保留完全控制权。
这就是简短意义上的 human-first 方法。
agent-first 的方法则是你从远处管理一组 agents：
-
你和一个 orchestrator 对话，而它会继续生成子 agents 并给它们分配任务。
所以，不是逐步指导每一个动作，而是设定高层目标，让 AI 系统自主执行。
现在，我不认为 agent-first 是错的。它只是和我的工作流不匹配。我构建的大多数东西，并不需要五个 agent 并行自我管理。它需要的是一个我可以直接引导和监督的 agent。
选择模型提供商
在 harness 定下来之后，我开始寻找在价格/算力比方面最好的模型提供商。这是个相当有挑战的任务，因为订阅计划的主要问题是，大多数都不透明，并没有真正按 tokens 去量化它们提供了多少算力。所以客观比较它们很难，因为没有共享标准可供衡量。
我能想到的最好替代方案就是 用户评价。
于是我读了无数关于 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 tokens 的结果：
基于这些数值，我的工作流变成了：
用 GLM 5.2 处理复杂推理和困难实现任务。
用更便宜的捆绑模型，比如 DeepSeek V4 pro，处理常规 coding。
用免费的模型，比如 DeepSeek V4 Flash，处理简单问题和对话。
在订阅的前 3 周里，我几乎没有感到受限。
说明：
在我第一个月使用时，Kimi K3 还不可用，但它现在已经可以用了，而且对于高度复杂的任务来说，是一个非常有吸引力的选择。
如果你更倾向于按量付费，我的建议是跳过 OpenRouter。它很流行，但还有更好的选择。Neuralwatt 是我会推荐你去看的一个。我最初是通过 这个 Reddit 讨论串 了解到它的，如果你想看细节，值得一读。
对于需要比 Go 订阅提供的容量更多算力的开发者来说，把它和一个更便宜的按量付费提供商结合起来，会是一个非常高性价比的方案。等我自己测试完这个组合后，我会写写什么才是最佳搭配。
OpenCode 体验
把桌面应用和 Go 订阅配置好之后，我就直接开始干活了。我有一个搁置了一段时间的小项目想法，所以这正是终于试一试的合适时机。
首先，我按自己喜欢的方式设置了 harness：
连接了模型提供商。
创建了自定义 agents 和 sub-agents。
下载了相关 skills。
设置了全局
AGENTS.md文件。
我这样设置的目标，是创建一个让 agent 从一开始就理解我的工作流和 coding 偏好的环境。
工作流
我在第一个月的日均花费大约是 3 到 4 美元。
我用 GLM 5.2 做规划和更难的 coding 任务，用 DeepSeek V4 Pro 和 MiniMax M3 处理标准和简单的 coding 工作，用免费的 DeepSeek V4 Flash 聊天和快速提问。
这个组合的表现出乎意料地好，而且我会一直推荐它。
与其在每次交互中都用最贵的模型，不如把模型当作具有不同强项的不同工具。
性能和可靠性
老实说，这次体验比我预期的更顺畅。
我没有遇到任何宕机、错误或延迟。
生成速度可以接受，不过这自然取决于所选模型和任务复杂度。
OpenCode 桌面应用和 VS Code 的组合对我的工作流特别合适。
我没有把 AI 助手直接嵌入编辑器里，而是拥有了一个专门的空间来管理对话、审查改动和控制 agent。
这种分离感觉非常自然。
到了第二个月，我用 OpenCode 开始做的那个项目已经增长到超过 20,000 行代码，我也更快触及了自己设定的每日 4 美元上限。这意味着我需要更有意识地管理会话，以及选择使用哪个模型或 agent。
这就是为什么对于中型项目来说，混合方案更合理。
比如：
以 OpenCode Go（每月 10 美元）作为主订阅。
需要时再加上额外的 Zen credits。
再搭配一个更便宜的按量付费提供商，比如 Neuralwatt，用于溢出使用量。
与传统的前沿模型订阅（通常 20 美元）相比，总成本仍然非常有竞争力。
最后的想法
OpenCode 是一个可定制、对初学者友好的 harness，支持你能想到或需要的所有功能。它的桌面应用设计良好，使用起来很自然，也没有给你的 coding 工作流增加阻力。
在模型提供商方面，Go 订阅绝对是一个很好的起点，甚至可能是最好的起点。但如果你在做中型或更大的项目，它并不足以支撑整个月。尽管如此，因为它只要 10 美元，所以我建议的做法是再叠加第二个订阅，或者加一个按量付费选项。
所以，如果你现在还在为每一个 token 支付前沿模型价格，也许值得检查一下，你是否真的还需要这样做。
更新：
在这篇文章里，我建议使用 Neuralwatt 作为额外算力的按量付费提供商，因为它是别人推荐给我的。我用和测试 OpenCode Go 时相同的设置做了一个小测试。下面是使用结果：
如成本卡片所示，使用 energy pricing 在我这次用到的输入/输出 tokens 数量上只省了 0.05 美元。这差别不大，不过他们网站上到处都写明，energy pricing 真正的效率会在使用“efficient architectures”时体现出来，也就是本质上的 MoE 模型，比如 Kimi 系列模型和一些 Qwen 模型。所以，如果你只用 dense models，比如 GLM 5.2，那你就知道会得到什么结果了。