把 Wi-Fi 关掉、拔掉网线，一台笔记本还能不能靠 AI Agent 自己读代码、改 Bug、跑通单元测试？Thomson Reuters 首席工程师 Rittika Jindal 搬到喜马拉雅山麓后，面对当地频繁的断网和停电，用一套纯本地组合给出了肯定答案，即终端 Agent 工具 OpenCode（1.19.4 版本）配合本地推理运行时 Ollama，挂载开源权重模型 Qwen3.5 9B。但把这套看似田园牧歌的离线方案放到真实工程环境里审视，决定它能不能用起来的核⼼变量，根本不是模型智商，而是脚手架的资源吞吐率与本地工具调用的解析稳定性。
先看这套离线方案的账面配置与能力水位。作者在 Mac 上用 Ollama 拉取了下载体积 6.6–7.6 GB 的 Qwen3.5 9B，将 OpenCode 的主模型与辅助小模型均指向本地端口，并把上下文窗口设为 64k-token（Voltti 为 6.6 GB 构建版预算的运行内存为 12–16 GB）。在预置好依赖和 Python 标准库 unittest 测试的前提下，这套组合能在完全断网时读懂一个报销计算脚本，定位循环覆盖总和的 Bug，提出一行代码修改（把 = 改为 +=）并跑通全部 5 项测试。
| 模型版本 | 下载体积 | LiveCodeBench v6 (代码生成) | BFCL-V4 (函数/工具调用) |
|---|---|---|---|
| Qwen3.5 4B | 3.3–4.0 GB | 55.8 | 50.3 |
| Qwen3.5 9B (实测选用) | 6.6–7.6 GB | 65.6 | 66.1 |
| gpt-oss-20b | 未列入 | 74.6 | 未报告 |
从官方模型卡数据看，Qwen3.5 9B 的代码生成得分比 4B 版本高出近 10 分，离线的代价则是比 gpt-oss-20b 低了 9.0 分。不过跑通 Agent 闭环更看重 BFCL-V4 衡量的函数调用能力（66.1 分），它决定了模型能不能选对读写文件、执行终端命令的工具并传对参数。
40 倍 Token 膨胀如何吞噬本地内存
如果只看喜马拉雅山麓的演示，读者很容易产生一种错觉，以为只要腾出 16 GB 内存，本地 Agent 就能平替云端工作流。但原文顺手引用的一篇预印本《The Scaffold Effect in Coding Agents》，恰恰暴露了把云端脚手架直接搬到本地的巨大隐患。
该研究在 50 个 Terminal-Bench Pro 任务上横评了 OpenCode、Goose 和 OpenHands-SDK 三种开源 Agent 脚手架。配合云端模型 Qwen3.6 Plus 和 MiniMax M2.5 时，三者的任务通过率在统计学上拉不开差距（OpenCode 与 OpenHands-SDK 均为 50% 和 46%，Goose 为 48% 和 38%，95% 置信区间高度重叠）。真正的分水岭在账单背面，OpenCode 每解决一个任务消耗的 Token 数量，高达 Goose 的 40 倍。
在云端 API 时代，40 倍的 Token 膨胀只是多付点账单；一旦断网落回本地笔记本，这 40 倍冗余就会直接变成压垮内存和算力的稻草。
云端烧的是 API 账单，端侧烧穿的是物理内存与上下文窗口。
这也是为什么作者即便只改一行代码，也要在启动命令里硬塞一句 OLLAMA_CONTEXT_LENGTH=65536。GitHub 仓库 marcelotournier/qwen-opencode 对同一套组合（OpenCode + Ollama + Qwen3.5-9B）的实测印证了这个坑，默认的 16K 上下文会迅速饱和，必须扩容到 32K 甚至 r/opencodeCLI 社区用户建议的 64K，才能让大多数工具调用正常工作。
那如果笔记本内存不够，能不能靠极限压缩模型来保住长上下文？这条路同样走不通。社区实测发现，一旦退守到 Qwen3.5-2B，或者使用极小的 2-bit 量化版本，模型虽然能塞进内存，但会出现断崖式的能力退化——它不再发起结构化的工具调用，而是直接把终端命令当成纯文本吐在屏幕上。在端侧跑 Agent，模型体积和上下文窗口是一道死板的算术题，两头都不能省。
跑分之外的暗礁：JSON 崩溃与标签打架
即便你的 Mac 内存够大、老老实实跑原版 Qwen3.5 9B 并开了 64K 上下文，喜马拉雅山麓那次顺滑的演示依然很难在复杂项目里复现。
我不太买账的是很多教程把离线 Agent 描绘成“下载即用”的积木。翻一翻 GitHub 和 Reddit 的排障记录就会看到，当开发者真正把 OpenCode、Ollama 和 Qwen3.5 拧在一起时，报错重灾区根本不是模型写不出代码，而是底层工程管道在格式对齐上频繁炸膛。
在 GitHub 的 Ollama Issue #14492 中，开发者报告 ollama-qwen3.5:35b 在 8K 到 256K 的各种上下文设置下，都会复现 HTTP 500 错误和 JSON 解析崩溃（unexpected end of JSON input）。排查下来，病根出在 OpenCode 的 question 工具以及解析器修改破坏了对模型 thinking-tag（思考标签）的处理。另一条 Issue #14493 则记录了 Qwen 3.5 27B 工具调用失效及重复惩罚被静默忽略的问题；Reddit 的 r/unsloth 社区也集中反馈了模板错误和潜在内存泄漏的 MaxListenersExceededWarning 警告。
这就像早年 PC 时代的驱动地狱——显卡和主板各自跑分都很漂亮，插在一起却蓝屏。古人讲“工欲善其事，必先利其器”，但今天端侧 Agent 的现状是三把利器各自为战，模型厂商在卷 BFCL-V4 的基准跑分，Agent 脚手架按云端算力自由的逻辑挥霍着 40 倍的 Token，而本地推理运行时夹在中间，连一个带思考标签的 JSON 字符串都还会解析崩盘。
- 风险.如果你准备在航班、长途列车或涉密内网里依赖这套离线方案，切勿指望它接手大型代码库重构；必须提前在联网状态下跑通一次完全相同的配置，并在提示词里硬编码具体的测试命令（如
python3 -m unittest -v），否则光是模型猜错测试框架（比如误调pytest）引发的重试，就足以在本地撑爆你的上下文窗口。
从喜马拉雅山麓的那行 total += Decimal(amount) 开始，离线编程 Agent 确实跨过了从零到一的门槛。但要让它从应急备胎变成主力工具，接下来真正要盯紧的不是 Qwen 下一个版本把代码跑分再提几分，而是 OpenCode 这类脚手架何时能把 40 倍的 Token 冗余砍下来，以及 Ollama 何时能把本地工具调用的 JSON 解析彻底焊牢。