同样的模型，为什么 OpenCode 跑得更像“真 Agent”？从一次 Reddit 实测谈起

同样的模型为什么 OpenCode 跑得更像“真 Agent”从一次 Reddit 实测谈起摘要最近看到一个很有代表性的 Reddit 实测同一个约 10k LoC 的 Electron React TypeScript 项目同一个重构目标换不同的 coding agent 和 provider 跑一遍结果差异非常明显。最值得注意的并不是“哪个模型参数更强”而是同样的模型在不同 harness 之下表现会像两个系统。在这组测试里Claude Code Sonnet 4.6 基本没做出像样的重构而 OpenCode 同样的 Sonnet 4.615 分钟内已经开始跨多个文件推进实质性修改。再往前一步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.85136 次 API calls6.9M prompt tokenscache hit 88%只改了 2 个文件4/-4作者主观感受是“几乎没做事”。OpenCode 同样 Sonnet 4.6约 15 分钟$3.18157 次 calls7.5M prompt tokenscache hit 95%改了 8 个文件43/-44明显更像在认真执行任务。OpenCode GPT-5.3 Codex约 7 分钟$1.4479 次 calls4.9M tokens95% 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 Codex7 分钟、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 里决定结果的往往不是“谁最聪明”而是谁最像一个真正能工作的工程系统。