本地编码代理性能大比拼：Qwen3.6/North Mini/Nemotron谁更强？

随着开源大模型和编码代理工具的成熟，本地部署全链路的代码生成智能体已经成为可能。本文将完整介绍如何使用开源工具与开放权重模型，从零搭建一套完全本地的Coding Agent——所有模型与操作外壳都运行在本地，支持读取文件、修改代码、执行命令并验证修改，全程无需依赖第三方闭源服务。

本文的核心测试结论先行：Qwen3.6 35B-A3B搭配Ollama与Codex的组合表现超出预期——同一模型在Codex环境中的性能优于原生Qwen-Code环境；而Claude Code的token消耗量约为Codex的两倍以上。

为什么选择本地部署的代码智能体

尽管当前主流的编码代理工具仍以闭源服务为主，但本地部署方案的吸引力正在快速提升。本地方案的核心优势包括：成本可预测、数据隐私可控、支持离线使用，同时能够避免模型版本更新导致现有工作流被打乱的问题，还可以应对厂商对旗舰模型性能限速的潜在风险。

本地编码智能体的架构分为两个核心部分：大语言模型作为推理引擎，负责代码生成与逻辑推导；编码代理外壳（Harness）作为操作环境，让模型能够在本地项目中完成实际的代码读写、命令执行等任务。

• 可复现性：本地部署的模型不会悄悄更新版本，能够确保开发环境的稳定性
• 备用方案：避免第三方服务对模型能力的限制或调整

编码代理外壳的选型推荐

当前主流的Coding Agent Harness原理相似，但实现细节存在差异，且多数大模型会针对特定的Harness进行优化。经过对比，Qwen-Code是优先推荐的选择，主要基于三点理由：

1. Qwen-Code完全开源，与Codex同属开源方案，而Claude Code为闭源产品
2. Qwen系列模型针对Qwen-Code进行了专项优化，性能表现更突出
3. 支持在同一设备上同时运行Codex与Qwen-Code，无需频繁切换环境

相关测试数据也验证了这一点：根据NVIDIA今年5月发布的论文《Polar: Agentic RL on Any Harness at Scale》中的基准测试结果，Qwen模型在适配专属Harness时的表现优于其他环境，而最新的Qwen3.6版本针对Qwen-Code的优化进一步加深。

硬件方面，Qwen3.6 35B-A3B模型文件大小约22GB，运行需要30-40GB的内存，在M4 Mac Mini和DGX Spark设备上均可流畅运行。根据相关行业报告，该模型是同尺寸级别中性能最强的本地模型，甚至可以与闭源旗舰模型一较高下。

如果不想使用Qwen系列模型，同尺寸下的North Mini Code是极具竞争力的替代选择。

本地模型快速部署：五分钟完成配置

无论选择哪种Harness，第一步都是将本地大模型运行起来。目前可选的推理框架包括Ollama、LM Studio、vLLM等，其中Ollama以跨平台支持、命令行友好、安装简便成为首选。

Ollama不仅支持本地部署开源模型，还提供云端托管的开放权重模型服务，适合快速测试消费级硬件无法运行的大模型，采用订阅制收费模式。

安装完成后，可以通过两种方式下载模型：

1. 图形界面：macOS系统可直接通过Ollama应用查找并下载目标模型
2. 命令行：
   • Apple Silicon设备（推荐使用MLX版本以获得Metal加速）：ollama pull qwen3.6:35b-mlx
   • Linux设备：ollama pull qwen3.6:35b

下载完成后，可以通过终端命令验证模型是否正常运行。除了Qwen3.6，同尺寸的North Mini Code 1.0也是优质的替代选择。

速度与内存测试：达标标准与实测结果

选择本地模型时需要重点关注两项指标：生成速度（tokens/秒，需在长上下文场景下保持稳定）与内存占用（编码代理任务通常需要数万token的上下文，需避免内存溢出）。

我们开发的测速脚本可以通过不同长度的prompt测试模型的预填充速度、生成速度与内存占用情况。测试结果显示，在Q4量化模式下，Qwen3.6与North Mini Code的速度相当，后者略占优势。

根据经验，生成速度达到20-30 tok/s即可满足日常使用需求，这一速度接近主流闭源模型的高性能档位。本次测试的两款模型均轻松达到这一标准。实际使用中，建议将智能体部署在高性能设备上，避免占用轻薄本的内存与导致设备发热。

模型能力评估：私人任务集验证真实表现

除了官方基准测试数据，我们建议维护一套私人任务集，收集日常工作中遇到的真实编码问题，用于快速评估新模型的实际能力。我们开发的测试脚本覆盖了推理、代码生成与工具调用三类任务，仅要求模型返回工具调用结果而非实际执行：

• qwen3.6:35b：得分3/5。概念调试与安全审查类题目全部答对，但在代理决策类题目中出现失误，整体可用但仍无法完全放心托管
• north-mini-code-1.0：得分约2/5，存在选错工具的情况
• gemma4:e2b：得分0/5，不仅工具选择错误，在信息足够的情况下仍会反问澄清，基本不适合作为编码代理模型

部署前的安全审计：比模型本身更重要的环节

在完成模型部署后，接下来需要将模型接入编码代理Harness。我们优先推荐Qwen-Code，它不仅针对Qwen模型优化，且完全开源，可以理解为“开源版Claude Code”。

需要特别注意的是：Harness的权限远高于模型本身，它可以直接读取本地文件、修改代码并执行shell命令，因此安全审计是必不可少的环节。我们总结了两条核心安全原则：

1. 优先审计开源的Agent代码库，确保没有恶意代码
2. 在独立硬件设备或至少独立的用户账户/虚拟机中运行代理，避免影响主系统安全

具体的审计流程可以通过以下步骤完成：将代码仓库克隆到本地，交由可信的智能体进行代码审计，使用聚焦的审计prompt覆盖安装脚本、命令执行权限、文件读写边界、环境变量继承、prompt注入风险、插件集成、网络调用、自动更新机制等10个维度，最终输出高/中风险点、外发端点以及明确的运行建议。

经审计，Qwen-Code符合行业通用安全标准，未发现超出常规编码代理的高风险问题。

Qwen-Code配置：连接本地Ollama模型

审计通过后即可开始安装Qwen-Code，官方提供两种安装方式：

curl -fsSL https://qwen-code-assets.oss-cn-hangzhou.aliyuncs.com/installation/install-qwen-standalone.sh | bash
# 或使用npm安装
npm install -g @qwen-code/qwen-code@latest

不过这两种方式默认假设发布产物与GitHub代码一致，追求更高安全性的用户可以选择从源码自行编译：克隆仓库后执行npm install、npm run build，再手动链接到本地二进制目录。

安装完成后运行qwen命令，即可通过图形界面完成配置：

1. 选择Custom Provider
2. 选择OpenAI-compatible兼容模式
3. 配置Ollama本地端点
4. 填写API密钥占位符
5. 选择已下载的本地模型
6. 开启thinking模式
7. 通过/model命令快速切换模型
8. 编辑settings.json添加自定义模型配置

Codex配置：意外的性能赢家

作为补充方案，我们也测试了Codex与Claude Code的本地部署方式。Codex的官方UI不支持非OpenAI的模型，但开源的Codex CLI可以实现这一功能。最简便的方式是在~/.codex/目录下创建独立的配置文件ollama.config.toml：

model = "qwen3.6:35b"
model_provider = "ollama"
model_reasoning_effort = "high"
personality = "pragmatic"
[projects."/home/your-user-name"]
trust_level = "trusted"

在完成配置后启动Codex，我们重跑了之前的代理任务测试，结果发现Codex环境的表现超出预期，成为本次测试的意外赢家。

Claude Code配置：能力出色但Token消耗过高

Claude Code是本次测试中最不推荐的本地部署方案，其核心问题在于代码库闭源，无法进行安全审计且无法关闭数据上报功能。其本地部署可以通过Ollama的官方集成完成：

ollama launch claude
# 同样的方式也支持启动Codex

我们对三家Harness的token消耗量进行了横评，得出两个关键结论：

1. Token消耗量主要由Harness决定，而非模型本身：能够完成全部测试题的模型在同一Harness中的token消耗几乎一致
2. 任务成功率对比：Claude Code环境中多数模型均可拿到满分或及格分数

但Claude Code的token消耗量约为Codex的两倍以上，这主要源于其输入token的冗余：每一轮对话都会将更多的上下文（历史消息、工具调用记录、命令输出、文件内容等）反复发送给模型，而非输出内容更多。

在本地部署场景中，token消耗直接对应任务耗时，节省50%的token相当于将任务速度提升一倍，因此Codex成为更具性价比的选择。

更多相关教程与测试脚本，可以参考公开的技术文档与开源仓库。