我在一台 16GB 的旧 Intel Mac 上跑 Qwen3-4B，给它准备了五个小仓库：改邮箱清洗、跨文件加币种、修 TTL 缓存、应对需求变化、写租户限流器。
云端对照用 OpenCode 和 DeepSeek V4 Flash，五个全过；本地只过一个。更麻烦的是，为了让它开始改代码，我先删掉了工具调用、自动跑测试和失败重试。最后跑起来的东西，已经不太像 Claude Code 了。
本地执行链路的实际成本
llama.cpp 的预编译包用了旧版 macOS 不支持的系统符号，启动即退出。我关掉 Accelerate 和 Metal，从源码重新编译，模型才成功加载。
模型本身加载不慢，约 12.5 秒。真正卡住的是 OpenCode：它发出的第一个请求有 17,630 个 token，超过最初设置的 8K 上下文。小仓库只占其中很少一部分，其余主要是系统提示词和工具定义。
我把上下文调到 32K，并发降到 1，进程内存随即涨到约 8.9GB。等了八十多秒，仍没有一次文件修改。
继续扩大上下文没有意义。我改写了一个单轮脚本：一次性把任务、源码和测试交给模型，让它只返回修改后的文件，再由外部脚本跑测试。输入从 17,630 token 降到几百 token，本地模型终于开始工作。
代价也很清楚：搜索仓库、调用命令、读取测试失败并继续修复，这些 Agent 最重要的能力都没了。
代码任务的交付结果
五项任务里，本地方案只通过邮箱清洗。即便这一次，模型输出的 JSON 末尾也多了一个右花括号；解析器增加容错后，原响应才顺利落盘。
另外四项里，有三个失败尤其值得警惕。跨文件加币种时，它只改了数据类，漏掉 service 和 serializer；TTL 缓存只需把 > 改成 >=，它却原样返回了 Bug；需求变化的新测试通过了，旧 API 却出现两个回归错误。
“新测试通过，看起来已经完成”最容易误导人。如果没有完整回归测试，需求变化那一项很可能被当成成功交付。
Claude Code CLI 当天登录态失效，因此这不是 Claude Code 与 Qwen3-4B 的直接跑分。结论来自另一条更基本的标准：这套本地方案连完整的 Agent 闭环都保不住，自然谈不上替代。
适合迁移的任务边界
Qwen3-4B 的模型文件只有 2.3GB，但 32K 上下文运行时占用接近 9GB，实测生成速度约 6 token/s。没有 API 账单，不代表没有等待和维护成本。
在这套硬件上，本地方案只适合文件少、需求明确、一次能给全上下文，而且测试能自动判定对错的低风险修改。跨文件联动、陌生仓库、多轮调试和需求变化，仍应交给云端 Agent。
基于这次实验，这套本地 Coding Agent 不能替代 Claude Code，只能接走一小部分简单任务。
如果准备迁移，不必先研究榜单或升级显卡。先从自己的仓库挑十个真实任务，保留完整测试和失败记录；哪一类连续通过，再迁哪一类。
参考资料
- Qwen：Qwen3-4B-GGUF
- Qwen：Qwen3-Coder-Next-GGUF
- llama.cpp：GitHub
- OpenCode：Providers
- 论文：The Scaffold Effect in Coding Agents
