先看证据
把联网假设从工作流里拿掉
一篇题为《Coding From the Himalayas With an Offline AI Agent》的文章，记录了一位在汤森路透担任首席工程师的作者，尝试在喜马拉雅山麓的网络与电力中断环境中继续使用编码代理。文章讨论的不是一种新模型，而是一套由 OpenCode、Ollama 和 Qwen3.5 9B 组成的本地工作流：代理在项目里读写代码，模型则在同一台笔记本上运行。
这次尝试值得技术负责人看的地方，在于它把“离线开发”拆成了一个具体工程问题：哪些环节必须访问网络，哪些任务可以依赖本地文件、模型和工具完成？答案不是所有开发工作都能离线，而是有些工作可以先把依赖准备齐，再在一个相对封闭的环境里完成。断网不是代理能力的证明，任务能否在本机闭环才是关键。
代理、运行时和模型各做一部分
这套方案的组件分工，比“在电脑上装一个模型”更重要。OpenCode 负责代理工作流，可以读取项目文件、提出修改并运行命令；Ollama 在本机载入 Qwen，并提供本地模型服务；Qwen 则负责根据上下文生成回答或工具调用。模型不是代理本身，能否把一次请求变成读文件、改代码、跑测试的连续操作，还取决于代理如何管理工具和权限。
文章选择 OpenCode，是因为它可以在终端里连接本机的 Ollama 服务，并通过权限提示让使用者审核命令和改动。这为断网工作保留了一道人为把关，但不意味着所有动作都自动安全。实际使用时，仍要确认代理获准访问哪些文件、能运行哪些命令，以及模型请求是否确实指向本地服务。材料支持本地连接的设计，不足以证明任意配置下整条工作流都不会联网。
模型分数不是笔记本上的实测成绩
文章给出的模型卡数据，可以帮助理解为什么选 9B 版本，却不能直接回答它在某台笔记本上好不好用。LiveCodeBench v6 衡量代码生成，BFCL-V4 衡量函数调用能力；后者与代理选择工具、提供参数有关。以下是材料引用的已发布分数，而非这次本地运行的测试结果：
| 模型 | LiveCodeBench v6 | BFCL-V4 | |---|---:|---:| | Qwen3.5 4B | 55.8 | 50.3 | | Qwen3.5 9B | 65.6 | 66.1 | | gpt-oss-20b | 74.6 | 未报告 |
9B 在这两项指标上都高于 4B，因此是一个有依据的起点；但这张表不衡量生成速度、整套 OpenCode 工作流的成功率，也不能预测具体项目里的表现。材料还列出模型下载体积：4B 约 3.3–4.0 GB，9B 约 6.6–7.6 GB，27B 约 17–20 GB。下载体积不是运行所需内存，文章引用的估算认为，6.6 GB 的 9B 构建可能需要 12–16 GB 内存预算。设备配置、量化方式和实际速度在现有材料中没有给出，不能把模型卡分数误读成硬件承诺。
小任务能闭环，大项目仍是未知数
材料所述的演示把代理放进一个小型 Python 示例里，处理费用累计逻辑：程序原本只返回最后一笔费用，修改后改为累计金额。文章称代理运行了测试，作者随后又独立复跑，五项测试全部通过，示例总额为 25.50。这个结果展示了离线代理最实际的工作形态：在已有项目上定位一个范围有限的问题，修改本地文件，再用已安装的测试工具检查结果。
它的价值不在于证明本地模型已经能独立承担大型代码库工作，而在于说明一个任务可以在本地形成可审查的闭环。代码、依赖和测试工具都在机器上时，解释函数、排查失败测试或做小型重构，不必每一步都访问云端。但五项测试和一个小例子无法代表大型仓库、多模块改动或复杂调试；现有材料也没有提供本地任务成功率、运行耗时或更广泛项目的验证数据。
把离线当作任务边界，而不是产品标签
对工程团队而言，可行的做法不是笼统地宣布“我们有离线编码代理”，而是列出哪些任务能在本地闭环。断网前要准备好模型、项目、依赖和测试工具；如果工作需要下载新包、查网页或访问未缓存的服务，就仍然需要网络。部署时还应实际断开连接，确认代理没有切换到云端提供商，并检查其他启用功能是否会发出网络请求。使用 Ollama 或开源权重本身，都不能替代这项验证。
因此，这类工具最适合被纳入现有审查流程：让代理做范围有限的修改，用本地测试验证，再由工程师检查差异和命令记录。它为出差、网络不稳定或需要把代码留在本机的场景增加了一种工作余地，但代价是资源预算、预先准备和能力边界都由团队自己承担。更稳妥的判断是：把离线代理看作一个可用的本地执行选项，而不是云端代理的等价替身；先验证自己的项目能否在断网条件下完成一项具体任务，再决定扩大使用范围。