同样的模型，为什么 OpenCode 跑得更像“真 Agent”？从一次 Reddit 实测谈起
摘要
最近看到一个很有代表性的 Reddit 实测：同一个约 10k LoC 的 Electron + React + TypeScript 项目，同一个重构目标，换不同的 coding agent 和 provider 跑一遍，结果差异非常明显。最值得注意的并不是“哪个模型参数更强”，而是同样的模型，在不同 harness 之下，表现会像两个系统。
在这组测试里，Claude Code + Sonnet 4.6 基本没做出像样的重构；而 OpenCode + 同样的 Sonnet 4.6，15 分钟内已经开始跨多个文件推进实质性修改。再往前一步，OpenCode + GPT-5.3 Codex 在速度、成本和改动覆盖面上都更亮眼。这个结果未必能直接外推到所有代码库，但它非常适合提醒我们一件事：agentic coding 的上限不只取决于 model，更取决于 harness、orchestration、context packing、tool loop、cache、retry 以及 provider/runtime 的整体设计。
如果你正在评估 AI coding agent，尤其是面向真实工程环境的场景，这一点比 benchmark 排名更重要。
一次看似普通的重构测试，为什么值得认真看
这次测试的任务并不花哨：在一个大约 1 万行代码的 Electron + React + TypeScript 项目里，分析简化与去重机会，重点是减少 null / undefined 带来的复杂类型定义和大量空值判断。
这类任务很接近真实团队的日常工作。它不是“从 0 生成一个 Todo App”，也不是单点修 bug，而是典型的中等复杂度演进型任务：
- 需要理解已有代码结构
- 需要跨文件发现重复模式
- 需要在不破坏行为的前提下做连续修改
- 需要维持类型一致性与局部回归风险控制
也正因为如此，它非常适合测一个 coding agent 到底是不是“会编程”，还是只是“会聊天”。
从结果看：
- Claude Code + Sonnet 4.6：约 15 分钟，$3.85，136 次 API calls，6.9M prompt tokens，cache hit 88%，只改了 2 个文件，
+4/-4，作者主观感受是“几乎没做事”。 - OpenCode + 同样 Sonnet 4.6：约 15 分钟，$3.18，157 次 calls，7.5M prompt tokens，cache hit 95%，改了 8 个文件，
+43/-44，明显更像在认真执行任务。 - OpenCode + GPT-5.3 Codex：约 7 分钟，$1.44，79 次 calls，4.9M tokens，95% cache hit，改了 16 个文件，
+91/-101，被作者认为综合表现最好，而且最便宜。 - Gemini 3.1 Pro 也能做事，但代码行数增长较多。
- 部分 open models 在 OpenRouter 下稳定性较差，但换到 Ollama Cloud 又变得更稳。
如果只看“模型名字”，你很容易得出错误结论。真正值得讨论的，是为什么同样的 Sonnet 4.6，到了 OpenCode 手里，行为就明显更像一个有效的工程 agent。
真正拉开差距的，不只是模型，而是 harness
很多人讨论 AI coding 时，默认思路还是“换个更强模型”。这当然重要，但在 agentic coding 场景里，模型往往只是发动机，harness 才是变速箱、底盘和整车控制系统。
所谓 harness，可以粗略理解为围绕模型搭建的一整套执行框架，包括但不限于：
- 任务拆解方式
- 工具调用编排
- 上下文打包与裁剪
- 多轮计划—执行—校验循环
- 失败重试策略
- 文件级 diff 管理
- 缓存命中策略
- provider 的延迟、稳定性与限流处理
在简单问答里，模型能力通常直接映射到结果质量；但在 coding agent 场景里，模型能力需要被“转译”为一连串稳定的行动。而这个转译过程，恰恰是 harness 决定的。
所以，“同样是 Sonnet 4.6，为什么 OpenCode 更能干活”，答案大概率不是 Sonnet 变强了，而是 OpenCode 更擅长把 Sonnet 组织成一个会持续推进任务的 agent。
为什么同模型下，OpenCode 更容易做出“实质性改动”
1. 更强的 task alignment：不是回答任务，而是推进任务
很多 coding agent 的常见问题是：它们会产出一段看起来很合理的分析，但不真正落到代码修改上。
这本质上是任务对齐失败。
用户要的是“完成重构”，不是“写一篇关于如何重构的建议”。如果 harness 在提示设计、阶段目标、工具触发阈值上没有压实，模型就很容易停留在保守分析、少量试探性修改，甚至只做局部象征性改动。
从这次测试结果看，Claude Code + Sonnet 4.6 的 +4/-4 基本就是这种症状：它可能理解了问题，但没有被有效驱动到“跨文件推进重构”这个目标态。
而 OpenCode + Sonnet 4.6 改了 8 个文件，说明它的执行框架更倾向于把模型推向“持续完成任务”，而不是“谨慎地说正确的话”。
这类差异在 agent 系统里非常关键。一个能稳定推进的 85 分 agent，往往比一个只会谨慎解释的 95 分模型更有生产力。
2. 更好的 context packing：把上下文喂对，比喂多更重要
重构任务最怕两种情况：
- 上下文太少：模型只能做局部修补，看不到重复模式
- 上下文太乱：模型注意力被噪音拖走，无法抓住关键改造路径
这就要求 harness 具备较好的 context packing 能力：
它要知道哪些文件相关、哪些符号关系关键、哪些历史调用值得保留、哪些上下文可以压缩成摘要。
这也是为什么 tokens 多并不自动等于效果好。OpenCode + Sonnet 4.6 虽然 token 量略高，但 cache hit 也更高，而且最终落到了更多有效改动上。这说明它不是单纯“喂得更多”，而是更可能喂得更对、复用得更稳。
在 agentic coding 里，上下文管理不是附属优化，而是主战场。因为模型做的不是一次性生成，而是多轮决策。每一轮拿到的上下文质量，都会影响下一轮的搜索方向和改动质量。
3. 更成熟的 tool loop：会不会“继续干活”非常重要
一个真实 coding agent 的价值，不在于第一步分析多聪明，而在于它能不能形成有效循环：
- 读代码
- 识别可改进模式
- 修改文件
- 检查影响范围
- 继续扩展到相邻模块
- 必要时回退、重试或调整策略
这就是典型的 tool loop。
很多系统的问题不在第一步，而在第三步以后：要么不敢继续改，要么改完不检查，要么一旦遇到不确定性就提前结束。
从这次结果看，OpenCode 更像是具备了较好的循环推进能力。尤其是 OpenCode + GPT-5.3 Codex，7 分钟、79 次调用、16 个文件改动，这种表现不像“单次回答型助手”，而更像一个在工程空间里持续迭代的 agent。
说白了，coding agent 不是看它会不会写代码，而是看它会不会在代码库里工作。
4. 缓存与重试机制，直接决定成本和稳定性
很多团队低估了 cache 和 retry 的价值，觉得这只是工程优化。但在 agent workflow 里，这其实决定了两个核心指标：
- 你敢不敢让 agent 跑更长链路
- 它能不能在复杂任务里保持稳定输出
这次测试里，OpenCode 的 cache hit 达到 95%，不仅降低成本，也意味着它在多轮调用里更能维持上下文复用效率。对长链路任务来说，这很关键。
因为只要每轮成本稍微高一点、延迟稍微抖一点、失败率稍微大一点，整个 agent loop 就会迅速变得不可用。
所以，OpenCode 的“便宜”并不只是价格标签，而是系统设计带来的可持续执行能力。这和单轮 benchmark 的“每次回答多聪明”完全不是一个维度。
Provider 和 runtime，经常是被忽视的第三变量
这组素材里还有一个特别重要的信息：一些 open models 在 OpenRouter 下稳定性不佳，但在 Ollama Cloud 下更稳定。
这说明什么？说明我们常说的“模型表现”，很多时候其实混杂了第三变量：provider/runtime。
同一个模型族，在不同 provider 上可能出现：
- 延迟差异
- 超时策略差异
- 上下文处理差异
- 限流行为差异
- tool call 稳定性差异
- streaming/断流恢复差异
对普通聊天来说，这些差异只是体验问题；但对 agent workflow 来说，它们会被放大成成败问题。
因为 agent 依赖长链条、多轮次、强状态的执行环境。只要某一环不稳，整体就可能退化为“能想、但做不完”。
因此，评估 coding agent 时，应该至少看三个层面：
- Model：推理、代码理解、生成能力
- Harness：任务编排、上下文管理、工具循环、校验与重试
- Provider：稳定性、延迟、缓存、限流、runtime 行为
只盯模型排行榜，往往会做出错误采购。
OpenCode 的实战优势，到底体现在哪里
基于这次测试，我认为 OpenCode 最值得工程团队关注的，不是某个单点数字，而是它展现出的四个实战特征：
1. 更强的“干活感”
它给人的直观感受不是“分析得很像回事”，而是“确实在推进任务”。
文件改动数量、diff 规模、覆盖范围，都说明它更容易进入有效工作状态。
2. 更好的性价比
OpenCode + Sonnet 4.6 比 Claude Code + 同模型更便宜；OpenCode + GPT-5.3 Codex 甚至在更短时间内拿到更好的综合结果。
这意味着它的优化不是单点堆料，而是系统效率更高。
3. 更大的稳定性潜力
无论是更高 cache hit，还是对不同 provider/runtime 差异的适配空间，都说明 OpenCode 更像一个可调优的平台，而不是一个固定风格的聊天壳。
4. 更适合真实工程工作流
对开发者、DevOps、AI 工程师来说，最有价值的不是 demo 级炫技，而是：
能否在已有代码库里，持续、低成本、可预期地推进任务。
从这组案例看，OpenCode 至少展示出了朝这个方向更成熟的迹象。
也要保持审慎：这不是“盖棺定论”
当然，必须强调：这只是一个 Reddit 用户在一个具体代码库、一个具体任务上的实测，不能直接推导出“OpenCode 全面优于所有方案”。
它的局限性至少包括：
- 样本量有限，任务类型单一
- 不同 agent 的默认配置可能不同
- provider 侧状态可能随时间波动
- diff 大小不必然等于改动质量
- 没有完整的测试通过率、回归风险、人工复核成本数据
所以，正确的结论不是“OpenCode 必胜”，而是：这个案例强烈提示我们，harness 对 agentic coding 的影响，已经大到足以压过很多人对“模型差距”的直觉。
结论：别再只问“哪个模型最强”，要问“哪个系统最会干活”
如果把 AI coding 只看成一次 prompt 对话，那么模型当然是主角。
但一旦进入 agentic coding，主角就变成了整个系统：模型、harness、provider 缺一不可。
这次案例之所以有价值，不是因为它替我们选出了唯一赢家，而是因为它把一个常被忽视的事实摆到了台面上：同样的模型，在不同 harness 下，可能表现得像两种完全不同的工具。
从实战角度看，OpenCode 的优势不只是“回答更聪明”，而是更容易表现出：
- 更强的 task alignment
- 更实质性的代码改动
- 更好的成本效率
- 更高的稳定性潜力
对于真正要把 AI 引入工程流水线的人来说，这个判断框架可能比任何单项 benchmark 都更重要。
下一次你评估 coding agent 时，别只问“它用的是什么 model”，更该问：
它的 harness 怎么设计？上下文怎么打包？tool loop 怎么收敛？cache 命中如何？provider 稳不稳？
因为在 agentic coding 里，决定结果的，往往不是“谁最聪明”，而是谁最像一个真正能工作的工程系统。
