原文地址：Using Local Coding Agents，by Sebastian Raschka, on 2026-07-27

使用本地 Coding Agent

以开源权重模型搭建本地编码框架，替代 Claude Code 与 Codex 订阅

过去常有读者问起我日常使用的本地代理技术栈，以及具体的搭建方式。
因此我打算整理一份简明教程，介绍如何用开源工具与开源权重大模型，搭建一套本地化的（编码）代理系统。

图 1：本地技术栈总览 —— 即通过推理引擎 / 运行时服务托管本地模型，在此之上运行编码代理框架。

本文是一篇搭建生产级本地编码代理的实操教程。我们将采用本地部署的大语言模型，搭配本地编码代理框架；该框架可读取文件、执行修改、运行命令并验证变更，整体架构如上图所示。

我们可以把大模型看作提供推理与代码生成能力的核心引擎，而外围的代理框架则提供运行环境，让大模型能在本地项目中完成有实际价值的编码工作。

为什么选择本地化方案？对很多编码场景而言，本地部署是 GPT（搭配 Codex）、Opus（搭配 Claude Code）这类商业服务的优质替代方案。本地架构透明可查，除硬件与电费外几乎零运行成本；数据完全由自己掌控，编码代理框架也可按需任意修改。除此之外，整个搭建过程本身也很有乐趣。

顺便一提，如果想了解编码代理框架的更多背景知识，我在这篇文章里讲过编码代理的核心组件，以及如何从零搭建一个用于学习的编码代理：
https://magazine.sebastianraschka.com/p/components-of-a-coding-agent

1. 引言

坦白说，目前我日常主力还是在 Codex 和 Claude Code 之间切换使用 —— 一方面是为了跟进持续新增的工具与功能，另一方面两者的订阅额度（尤其是 Codex）还很充裕，暂时不用太担心成本问题。

不过我也已经使用本地方案有一段时间了，既用于技术测试，也因为相比商业服务，一套完全本地化的环境总能带来一种特别的满足感。

无论如何，本地方案正变得越来越有吸引力。首先是成本因素：只要硬件到位，运行几乎零成本。其次是隐私角度：比如整理和处理个人收据时，用本地模型读取数据，总比发给 OpenAI 或 Anthropic 更让人安心。

再考虑到商业服务未来可能会愈发收紧，提前熟悉开源权重替代方案作为备份，或许是个明智的选择。

类似的理由与适用场景还有很多很多。
你选择本地大模型与编码代理框架的原因可能包括：

当订阅额度触顶后，可获得可预期的固定成本，同时不受 API 价格波动影响；
可复现性：模型升级有时能更稳定地解决问题，但也可能破坏已有工作流；
离线使用：比如飞机上网络差或断网的场景，或是去林间小屋闭关写代码、没有 Starlink 的时候。

除此之外应该还有不少其他原因。

因此在本文中，我们会将 Codex、Claude Code 这类主流框架对接开源权重模型使用，同时探讨专用模型框架（比如搭配 Qwen3.6 的 Qwen-Code）是否能带来额外增益。当然还有 OpenCode、Cline、Pi、Noumena Code 等很多框架，但考虑到大多数人已经习惯了 Codex 或 Claude Code 的操作，直接在这两个框架里接入开源模型，上手会更顺滑。

2. 编码代理框架概览

绝大多数编码代理框架的设计原则相近，功能也大体相当，但实现细节各有差异，而且特定大模型通常会针对某一款框架做优先优化。当然，很多开源权重模型（例如 GLM 5.2）也都能在 Claude Code 等框架中运行。

不过，如果一家大模型厂商同时开发编码框架，基本可以认为他们的模型会优先针对自家框架做优化，同时也兼容其他框架。

本文我主要以 Qwen3.6 搭配 Qwen-Coder 客户端为例展开，同时也会介绍本地大模型接入其他代理框架的方案，比如 Claude Code、Codex 以及日渐流行的 Cline，后面会详细说明。

我选择 Qwen 模型时优先搭配 Qwen-Code，原因有三点：

它和 Codex 一样是开源的，而 Claude Code 不开源；
Qwen 系列模型针对 Qwen-Code 框架做了专门优化；
我可以在同一台机器上同时运行 Codex（搭载最新 GPT 模型）和 Qwen-Code（搭载本地 Qwen 模型），不用手动来回切换模型。

关于第二点，即 Qwen 模型在 Qwen-Code 中表现更优，英伟达 2026 年 5 月的论文中有一组基准测试数据显示，Qwen3.5-4B 基础模型在 Qwen-Code 框架中的编码表现最佳（无论是否经过 Polar-RL 训练）。

图 2：论文《Polar: Agentic RL on Any Harness at Scale》中不同编码框架下的 Qwen 模型表现

上表是较早的 Qwen3.5 模型的测试结果，我推测最新的 Qwen3.6 系列针对 Qwen-Code 做了更进一步的专项优化。

另外，Pi 看起来也是个很有意思的选项，之后我打算专门试用一下。

顺便说一下，Qwen3.6 35B-A3B 的下载体积约 22 GB，运行需要约 30–40 GB 内存，在搭载 M4 的 Mac Mini 和 DGX Spark 上运行都很流畅。

根据 6 月初 Cohere 发布的最新基准测试，它目前是同尺寸级别中表现最好的本地模型。

图 3：6 月发布的 North Mini Code 报告中的 Cohere 基准测试

可以看到，Qwen3.6 35B-A3B 在该尺寸级别的几乎所有基准测试中都占据领先。不过话虽如此，Qwen Code 是通用框架，也支持其他类型的模型，比如我们也可以把 North Mini Code 或 Gemma 4 接入 Qwen Code 使用。

图 4：Qwen3.6 35B-A3B 模型表现参考（来源：x.com/pupposandro/status/2064707907489272147/）

架构方面，Qwen3.6 35B-A3B 采用了与 Qwen3-Coder、Qwen3.5 类似的混合注意力机制。我在另一篇文章里写过更详细的介绍。

图 5：Qwen3.6 架构与参数速览（来源：LLM Architecture Gallery）

如果你不想用 Qwen3.6，目前同尺寸级别里 Cohere 的 North Mini Code 大概是最值得关注、能力也足够的替代方案。下一节本地大模型搭建部分我也会介绍这款模型。

图 6：North Mini Code 架构与参数速览（来源：LLM Architecture Gallery）

3. 本地大模型搭建

无论使用哪种代理框架（Qwen-Code、Codex 还是 Claude Code），都需要先部署好本地大模型，比如 Qwen3.6 35B-A3B。

本地模型服务的可选方案有 Ollama、LM Studio、vLLM、SGLang、MLX 等。了解我系列项目的读者知道，我喜欢自己动手实现这些组件。从零实现模型的好处是能完整理解整个技术栈，还可以自行修改、继续训练与微调。

但本文我们只需要一个针对推理速度与资源占用深度优化的模型服务框架，因为暂时不涉及训练或微调。作为进阶步骤，我们也可以把自己从零微调的模型转换格式后导入这些高效服务框架中，但这超出了本文范围。

本教程我们选用 Ollama 作为高效模型服务引擎，因为它跨平台安装简单，命令行操作方便。尽管 LM Studio 也推出了非 GUI 的 llmster 客户端，但我对它不太熟悉。

顺便说明，我和本文提到的任何工具都没有利益关联。Ollama 一个不错的附加功能是，它还可选支持云端托管的开源权重模型，包括目前最强的开源模型 GLM 5.2—— 这款模型体量太大，消费级硬件无法本地运行。云端模型当然不是免费的，订阅方案和 ChatGPT、Claude 类似；但能方便地 “本地式” 体验最新的顶尖开源模型，依然是很实用的选项。

Ollama 的安装非常简单，官方下载页提供了 macOS / Linux / Windows 全平台的安装说明。

安装完成后，建议先下载一个模型做快速测试。比如在 macOS 上，可以通过 Ollama 应用的 GUI 直接下载模型：

图 7：使用 Ollama 应用查找并下载模型

也可以在命令行执行：

ollama pull qwen3.6:35b-mlx

上面的 qwen3.6:35b-mlx 是基于 Apple Metal 性能着色器优化的版本，专为苹果硅芯片 Mac 打造。在 Mac 上使用模型时，强烈建议优先选用带 *-mlx 的版本（如果有的话）。

图 8：使用苹果硅 Mac 时优先选择 MLX 版本

Linux 机器则使用非 MLX 版本：

ollama pull qwen3.6:35b

下载完成后，可以通过 GUI 或命令行启动 Ollama，验证是否正常运行。

图 9：在终端中运行 Ollama

输入 /bye 命令即可退出会话。

如前所述，目前 Qwen3.6 35B-A3B 之外，同尺寸级别里最好的替代方案是 North Mini Code 1.0。

图 10：作为 Qwen3.6 35B A3B 替代的 North Mini Code 1.0

4. 简单速度性能评估

在决定是否把某款大模型用作本地编码代理之前，先做一轮速度与质量的快速评估通常不会错。速度评估主要看 tokens/sec 指标，同时还要确认在超长上下文下速度依然稳定 —— 编码代理工作流面对的往往就是长上下文，这和简单的聊天场景不同。

当然，我们也不希望内存开销失控。

你可以运行我的 ollama_speed_memory_bench.py 脚本做快速检测。简单来说，它会向 Ollama 模型发送长度从 1k 到 50k 词不等的不同提示词，默认要求模型最多生成 8k token，然后输出简单的统计数据：包括根据 Ollama 提示词评估指标算出的预填充速度、根据输出 token 计时得到的生成速度，以及 Ollama 进程的内存占用（如有 NVIDIA GPU 还会统计显存）。

例如，要在 macOS 上评估 qwen3.6:35b-mlx，先从对应 GitHub 仓库下载或克隆脚本，然后执行以下命令，耗时约 5 分钟：

uv run speed-memory-benchmark/ollama_speed_memory_bench.py --model qwen3.6:35b-mlx

Linux 上执行：

uv run speed-memory-benchmark/ollama_speed_memory_bench.py --model qwen3.6:35b

注意，这需要你已经按上一节说明下载好了对应模型。另外根据你的系统配置，如果内存小于 30 GB，可能需要换用更小的模型，比如 gemma4:e2b，它在长上下文下最多占用约 8 GB 内存。当然还有更多更小的模型，但根据我的经验，它们作为本地编码代理的表现会很差。

补充说明：在 macOS 上，模型的 RSS 内存报告准确度有限（尤其是使用 Metal 后端的 mlx 版本模型），建议运行时同时查看活动监视器里 Ollama 的内存占用。本次测试中，内存占用在 20–29 GB 之间波动。

总而言之，在 50k 上下文下，Qwen3.6 和 North Mini Code 两款模型最多占用 30 GB 内存；在新款 Mac Mini 上生成速度约 40 tok/sec，在 DGX 上约 30 tok/sec。

不同运行环境的直观对比见下图：

图 11：不同模型在不同系统上的速度对比。注意 macOS 上的内存消耗数据准确度不高；另外得益于优化的 MLX 版本，Qwen 35B-A3B 在 Mac 上比在 DGX Spark 上更快（Gemma 4 E2B 则相反）。复现代码：https://github.com/rasbt/local-coding-agent-evals

另一个有意思的问题是，Qwen 35B-A3B 和同尺寸的 Cohere North Mini 相比表现如何？如果都采用同等级量化（上面我用的是 Qwen3.6 默认版本），两者表现非常接近，不过 North Mini 整体可能略胜一筹，如下图所示：

图 12：Q4 量化版 Qwen3.6 35B 与 North Mini Code 对比。复现代码：https://github.com/rasbt/local-coding-agent-evals

总之在我看来，只要速度能达到 20–30 tok/sec 以上，用于本地代理工作就相当够用了，这和开 “高” 推理档位的 GPT 5.5 速度差不多。上面两款模型都轻松达到了这个门槛。

顺便说，我几乎只在 DGX Spark 上运行代理，一是不想让 Mac Mini 发热太高，二是想把 Mac 的内存留给其他任务。

当然，换用其他框架、调整量化方式、开启 MTP 等手段总能做更多优化。但 Ollama 是个开箱即用的多面手，配置成本极低，能轻松对接各类编码代理框架，切换和试用不同模型也非常简单。

5. 简单基准性能评估

确认模型速度满足本地使用需求后，建议再做一轮快速的模型能力评估。诚然有很多标准化基准测试可以参考，甚至自己也能跑。

通常在模型的技术报告或模型平台页面上都能查到相关基准分数。我也常去 artificialanalysis.ai 上看模型间的横向对比。

图 13：来自 artificialanalysis.ai 的基准测试结果：综合表现（上）、编码表现（中）、代理能力表现（下）

从上图可以看出，比如 Qwen3 35B-A3B 的能力远强于 Gemma 4 E4B 和 E2B。

需要注意的是，Artificial Intelligence Index 的数值会随基准替换、权重更新而不断变化，因此没有一个 “绝对数值” 可以用来判断模型 “够不够好”。更实用的做法是，把新的、感兴趣的模型和你之前用过的模型做对比，作为参照锚点。

除了标准基准测试，我还建议整理一套和你自身工作相关的专属任务集，快速检验模型是否能胜任你想让它做的各类工作。

下面是一组推理与编码相关的测试题输出，同时也考察模型的工具调用能力。测试中模型只返回工具调用，不实际执行代码。

➜  uv run ollama_hard_reasoning_bench.py --model qwen3.6:35b
PASS debug_empty_tokenizer_regression: ok
PASS review_shell_command_injection: ok
FAIL choose_minimal_edit_for_cross_platform_path: argument instructions missing required content
FAIL triage_import_error_after_refactor: wrong tool: expected read_file, got ask_clarification
PASS debug_mutable_default_cache_leak: ok

Score: 3/5 passed (60.0%)

➜  uv run ollama_hard_reasoning_bench.py --model  north-mini-code-1.0
FAIL debug_empty_tokenizer_regression: wrong tool: expected final_answer, got edit_file
PASS review_shell_command_injection: ok
FAIL choose_minimal_edit_for_cross_platform_path: invalid JSON: Extra data: line 2 column 1 (char 235)
FAIL triage_import_error_after_refactor: wrong tool: expected read_file, got ask_clarification
FAIL debug_mutable_default_cache_leak: wrong tool: expected final_answer, got edit_file

Score: 1/5 passed (20.0%)

uv run ollama_hard_reasoning_bench.py --model gemma4:e2b
FAIL debug_empty_tokenizer_regression: wrong tool: expected final_answer, got edit_file
FAIL review_shell_command_injection: wrong tool: expected final_answer, got ask_clarification
FAIL choose_minimal_edit_for_cross_platform_path: wrong argument path: expected 'code/tool-reasoning-benchmark/ollama_tool_reasoning_bench.py', got 'code/tool-reasoning-benchmark/personal_tool_reasoning_tasks.jsonl'
FAIL triage_import_error_after_refactor: wrong tool: expected read_file, got ask_clarification
FAIL debug_mutable_default_cache_leak: wrong tool: expected final_answer, got edit_file

Score: 0/5 passed (0.0%)

举例来说，qwen3.6:35b 能正确完成概念调试与安全审查类任务，但在 “先操作哪个文件 / 执行什么动作” 这类代理判断上还有欠缺。3/5 的得分属于可用水平，但要实现完全自主的工具调用还不够可靠。不过如果框架本身能约束动作、支持重试、再提供更充分的项目上下文，还是能达到不错的实用度。

反观 gemma4:e2b 拿了 0/5，这就很说明问题：哪怕速度快，它也不太适合这类工具调用推理场景。注意这些失败不只是格式问题，而是会选错工具、明明上下文足够还反复要求澄清等等。我个人不会把它用作编码代理模型，除非是非常窄的场景或者约束极强的任务。

6. 代理代码库审计

铺垫了这么久本地大模型的搭建，现在回到正题：编码代理框架。文章开头说过，我们会用 qwen-code 框架，因为 Qwen 系列模型针对它做了优化。

图 14：接下来，我们把本地部署的模型接入编码代理框架。

如果你用过 Claude Code，会发现两者基本一致，只不过 Qwen Code 是完全开源的。后面几节我也会讲怎么把本地 Qwen3.6 模型接入 Codex 和 Claude Code。

注意，编码代理框架的能力远超大模型本身。也正因为如此，运行什么、在哪里运行，都要更谨慎。比如我试用新的（编码）代理时，习惯：

先对（开源）代理代码库做一次审计；
至少放在独立硬件上跑（比如我的 DGX Spark），再不济也要用单独的用户账号或者虚拟机运行。

关于审计，建议重点关注：数据共享 / 流出情况、文件权限的默认影响范围，以及对提示注入的基础鲁棒性。下图概括了核心要点。

图 15：运行已安装的编码代理框架前的实用审计清单

本地模型服务引擎（比如 Ollama）也有类似的注意事项，但编码代理权限更高 —— 它能直接读取你机器上的数据、操作文件，所以要更上心。

做基础审计可以按下面的步骤来：

克隆仓库：

git clone https://github.com/QwenLM/qwen-code.git

找一个你信得过的代理（比如 Codex 里的 GPT 5.5，或者 Claude Code 里的 Opus 4.8），用针对性的提示词帮你审查。大概像这样：

我要在机器上安装运行这个 ./qwen-code 代理，请你做一次审计。
只关注已安装代理对本地机器带来的实际风险，以及构成风险的代码路径：

安装脚本与包生命周期钩子

代理执行 shell 命令的逻辑

运行时文件读写的权限边界

密钥处理与环境变量继承

仓库文件、项目指令、工具输出会如何影响代理行为

MCP、插件、扩展、工具集成

网络调用与遥测

安装后的更新机制

终端转义 / 输出处理

数据流出与数据驻留

忽略安装必需的网络下载，检查使用本地 Ollama 模型时，已安装代理是否会把提示、文件、遥测、日志、标识符或元数据发送到远程服务器。忽略云端模型配置。
不要仅凭项目所有者判断风险。找出具体的端点、SDK、默认服务商、环境变量、配置默认值、控制网络行为的文档，包括任何境外或第三方运营的端点。
不要做泛泛的风格评价，不要重构代码。输出：

高风险发现，附文件 / 行号

中等风险关注点

网络 / 数据流出发现，包括任何境外、第三方或关联中国的端点与默认配置

审查完成前应避免运行的命令

可降低本地机器风险的设置或环境变量

简短建议：沙箱测试安全、可正常使用、不建议运行
每条都说明这是编码代理的正常行为，还是天生比 Codex / Claude Code 风险更高。

下面是主要发现摘要（完整报告太长也有点枯燥，就不贴全文了）：

本地执行：Qwen Code 可以通过 shell 工具在机器上运行命令，但默认有严格的审批控制，除非开启 --yolo 这类放行模式。对编码代理来说这是正常的，也正是它实用的原因；但如果在无沙箱环境运行，或是加载了带密钥的完整环境，就会有风险。
数据流出：即便搭配本地 Ollama 使用，Qwen Code 默认也会向阿里巴巴 / 阿里云端点发送使用遥测与元数据，除非关闭使用统计与遥测（后面会讲怎么关）。这比纯本地方案风险高 —— 模型提示可能留在本地，但会话 ID、工具元数据、模型信息、本地基础 URL 元数据仍可能流出机器。不过这也是各类工具的通病（没错，Codex 和 Claude 也这么干）。
文件与密钥边界：工作区文件默认可读，写入一般需要审批，还有一定的防覆盖保护。这一点做得不错，也是代理的标准做法。
提示注入面：仓库指令、工具输出、MCP 工具、扩展、项目配置都可能影响代理行为。前面说的审批闸门能降低提示注入攻击的影响。这对编码代理来说很正常，但默认情况下不可信的仓库都应当作恶意处理 —— 它们可以诱导代理读文件、跑命令、或是通过已授权工具发数据。

关于第 2 点的主要隐私顾虑，大部分都可以通过自定义配置文件 ~/.qwen/settings.json 解决，内容如下：

{
  "privacy": {
    "usageStatisticsEnabled": false
  },
  "general": {
    "enableAutoUpdate": false
  },
  "telemetry": {
    "enabled": false,
    "logPrompts": false,
    "includeSensitiveSpanAttributes": false
  },
  "disableAllHooks": true,
  "mcpServers": {},
  "artifact": {
    "publisher": "local",
    "autoOpen": false
  }
}

其中 "general": { "enableAutoUpdate": false } 是个权衡：不会自动安装安全修复，但我更希望更新时机由自己掌控，而不是让工具后台偷偷拉取和应用新代码。

顺便说，Cline、Codex、Claude Code 也有类似的遥测数据共享默认设置，都需要手动关闭。
（注意 Claude Code 没有官方开源版本的代码库，信任成本更高，而且它确实会同时向 Anthropic 和 Datadog 发数据。）

总的来说，Qwen-Code 遵循行业通行做法，截至写作时，没有发现什么超出编码代理常规的特殊问题。

7. Qwen-Code 搭建

如果接受上面的风险结论（我个人是没看到什么红线），就可以继续安装，把本地的 Qwen3.6-35B-A3B 模型接入 Qwen Code（后面几节再讲 Codex 和 Claude Code）。

前面说过，我更倾向于在独立机器上实验和运行能读写本地文件的编码代理（我用 DGX Spark，也可以是另一台 Mac 或 Linux 工作站）。退一步的话，也可以放在虚拟机里，或是新建一个 macOS / Linux 用户账号运行。

（听朋友说也有人租 Linode、Heroku 这类服务器来折腾。不过比起每月付服务器费，我更愿意花 200–500 美元整个便宜硬件盒子，甚至拿旧笔记本改一台，跑本地框架；如果想要更强的开源模型，再通过 Ollama 云端模型、OpenRouter 这类服务走云端，作为 GPT 或 Claude 的替代。）

好了，开始安装 Qwen-Code。官方提供的安装方式比如：

curl -fsSL https://qwen-code-assets.oss-cn-hangzhou.aliyuncs.com/installation/install-qwen-standalone.sh | bash

以及

npm install -g @qwen-code/qwen-code@latest

不过直接运行上面的命令，等于默认发布的构建包和 GitHub 仓库里的代码是一致的。如果特别谨慎 / 担心安全，也可以从 GitHub 仓库自己构建。提醒一下，手动构建会麻烦一些（建议一条条执行，不要整段复制粘贴进终端）：

# 进入你的开发目录
cd ~/Developer

# 克隆 Qwen Code GitHub 仓库
git clone https://github.com/QwenLM/qwen-code.git

# 进入克隆的仓库
cd qwen-code

# 安装 JavaScript 依赖
npm install

# 在本地 dist/ 目录构建 CLI 产物
npm run build

# 如果不存在则创建用户级 bin 目录
mkdir -p ~/.local/bin

# 创建一个 qwen 包装脚本，从源码目录运行 CLI
# 保留 ~/Developer/qwen-code 目录不动，因为脚本指向这里
cat > ~/.local/bin/qwen <<'SH'
#!/usr/bin/env sh
exec "$HOME/Developer/qwen-code/scripts/cli-entry.js" "$@"
SH

# 给包装脚本加执行权限
chmod +x ~/.local/bin/qwen

# 让当前 shell 会话能找到 qwen 命令
export PATH="$HOME/.local/bin:$PATH"

# 验证 qwen 命令可用并输出版本号
qwen --version

安装完成后，就可以在终端通过 qwen 命令启动 Qwen-Code 客户端，完成配置并连接本地大模型。

运行 qwen 命令后，选择 “Custom Provider”（自定义服务商），如下图所示。

图 16：选择 “自定义服务商”，这样就能接入 Ollama 大模型。

Ollama 遵循 OpenAI API 标准，所以下一步跟着屏幕指引，选择 “OpenAI-compatible”（兼容 OpenAI）选项。

图 17：因为 Ollama 遵循 OpenAI API 标准，这里选 “兼容 OpenAI”。

接下来要填入正在运行的、托管本地模型的 Ollama 应用的 API 端点。默认一般是：
http://127.0.0.1:11434

输入 http://127.0.0.1:11434/v1（带上 /v1），因为这是兼容 OpenAI 的基础地址。

图 18：配置 Qwen Code 使用 Ollama 的本地兼容 OpenAI 端点：http://127.0.0.1:11434/v1

然后，自定义服务商名称填 ollama。

图 19：输入 ollama 作为本地自定义服务商的 API 密钥占位符

接下来可以选择可用的模型，就是我们之前用 ollama pull 下载的那些。可以只填一个，也可以用逗号分隔填多个。可以用 ollama list 确认已下载的模型列表。之后也可以随时加新模型（配置完我会讲怎么加）。

图 20：选择 Qwen Code 通过自定义服务商提供的本地 Ollama 模型

快完成了！第 5 步当然是开启 “Enable thinking”（思考模式），虽然会消耗更多 token，但换来更强的问题解决能力是值得的。

图 21：为本地模型服务商开启思考模式

基本上就大功告成了。第 6 步是确认页，按回车就行。

恭喜，现在你已经有了一套完全本地化的大模型工作流。用法和 Claude Code 差不多，用 / 开头的命令调用各种功能。比如可以用 /model 切换模型，如下图所示。

图 22：用 /model 切换模型

顺便说，从 Ollama 添加新模型很简单。用 ollama pull 拉取新模型后，在 ~/qwen/settings.json 里加一条新条目就行。复制现有条目，把 “id” 和 “name” 改成 Ollama 里的模型名即可。

图 23：可以通过编辑～/qwen/settings.json 配置文件添加新的 ollama 模型。这里的 “xxxxx” 就是 ollama 模型名，比如 “nemotron-3-nano:30b”。

另外，如果是用 git clone + 本地构建的方式安装的，想更新 qwen-code 工具可以这样做：

# 进入本地 Qwen Code 源码目录
cd ~/Developer/qwen-code

# 拉取 GitHub 最新改动
git pull

# 如果包文件有变动就安装/更新依赖
npm install

# 重新构建本地 CLI
npm run build

# 验证更新后的 CLI
qwen --version

8. 代理能力评估

现在我们有了一套完全可用的本地编码代理，问题来了：它表现怎么样？能不能胜任你的工作？当然有各种基准测试，但在我看来，都不如拿你自己的工作流实际用两天试试来得准。

我也建议整理一小套任务，反映你日常使用编码代理的典型场景。如果做项目时遇到特别有挑战性的问题，也可以加进这套任务里，用来评估以后的模型。

举个例子，我在 GitHub 上分享了一套偏小、偏通用的测试任务，可以用来测代理：https://github.com/rasbt/local-coding-agent-evals/tree/main/agent-problem-pack。基本就是 “本地大模型搭建” 那节里任务的扩展版。

具体运行方法看 GitHub 上的 README。

下面是不同大模型在 Qwen-Code 里的测试结果。

图 24：用 Qwen-Code 做的小型本地代理能力基准。复现代码：https://github.com/rasbt/local-coding-agent-evals

可以看到，Qwen3.6 和 North Mini Code 35B-A3B 都解决了 5 道题里的 4 道。Gemma 4 E2B 差很多。出于好奇我还加了稍早一点的 Nemotron 3 Nano 模型，它的体量和算力表现和前面两个差不多，表现也相近。

图 25：Nemotron 3 Nano 架构概览（来源：LLM Architecture Gallery）

9. Codex 搭建

本地编码代理搭完（文章也已经五千多字了），本来可以到此为止。不过作为补充，我觉得再简单讲讲 Codex 和 Claude Code 的配置也挺好，更完整。

遗憾的是，据我所知 Codex UI 不支持非 OpenAI 模型，但我们可以用 Codex CLI 来跑我们的 Ollama 模型。

如果你还没装 OpenAI Codex CLI，可以从它的开源 GitHub 仓库获取安装，和 qwen-code 类似：https://github.com/openai/codex（没错，Codex CLI 是开源的！）

我就不列一大串命令了，建议直接看仓库 README 里的官方说明。（和 qwen-code 一样，先克隆仓库、做个审计也不是坏事。）

安装好之后，有多种方式启用本地模型。我觉得最方便的是在已有的 ~/.codex 目录里新建一个配置文件 ~/.codex/ollama.config.toml，设置一些默认选项：

model = "qwen3.6:35b"
model_provider = "ollama"
model_reasoning_effort = "high"
personality = "pragmatic"

[projects."/home/rasbt"]
trust_level = "trusted"

图 26：为 Codex 单独建一个 Ollama 配置文件，方便使用

然后我们平时还是可以用 codex 启动常规的 “GPT 5.5 版 Codex”，而要用 Ollama 模型时就执行 codex --profile ollama。

图 27：用本地 Ollama 模型启动 Codex

重新跑一遍 “代理能力评估” 里的测试用例，我意外地发现：Qwen3.6 在 Codex 里的表现居然比在 “原生” Qwen-Code 框架里还要好。

图 28：Codex 里的小型本地代理能力基准

虽然只是很小一组基准，但也说明把 Codex 作为通用编码代理框架，未必是个坏主意。

10. Claude Code 搭建

当然还有很火的 Claude Code 代理框架，也可以套在我们的本地大模型外面。它虽然流行又强大，但对本地方案来说大概是我最不推荐的选项 —— 因为代码库是闭源的。这也意味着我们没法直接检查和关闭 Anthropic 的数据日志行为。

要安装的话，如果你机器上还没有 Claude Code，建议看官方文档里的推荐安装命令：https://code.claude.com/docs/en/quickstart。

Claude Code 本身没有 Codex 那样的本地服务商配置路径。不过 Ollama 提供了集成方式：ollama launch claude，详见：https://docs.ollama.com/integrations/claude-code

也就是说，执行 ollama launch claude 就能用 Ollama 模型跑 Claude Code 框架。

顺便说，Codex 也可以这么用：ollama launch codex，但我个人更喜欢前面讲的 codex --profile ollama 方式，因为对运行机制更清楚、掌控力更强。

图 29：通过 Ollama 用本地 Qwen3.6 模型运行 Claude Code

不过实际用起来，Claude Code 得出结果的感觉要慢得多，token 消耗应该高很多。所以下面我又统计了三个框架的 token 使用量。

可以看到，Claude Code 平均消耗的 token 遥遥领先，Codex 最少。

图 30：三个框架搭配不同大模型的平均 token 用量。复现代码：https://github.com/rasbt/local-coding-agent-evals

在代理能力评估测试里，Qwen 和 North Mini Code 模型也都拿到了 5/5，就连小个的 Gemma 4 表现也还可以！

有意思的是，token 用量主要是由框架而非大模型本身决定的。也就是说，三个能解出（几乎）全部 5 道题的大模型，在同一个框架里用的 token 数差不多（比如在 Claude Code 里，Qwen3.6、North Mini Code、Nemotron 3 Nano 的 token 用量都差不多）。只有 Gemma 4 用得少，但它也几乎全错，大概率是工具调用能力不足，任务早早中断了。

任务成功率汇总见下图。

图 31：任务成功率汇总

所以结论是：如果多用 token 能让模型 + 框架组合解决更多、更难的问题，那当然好；但如果两个框架成功率差不多，有一个能少用 50% 的 token（比如 Codex 比 Claude Code），那优势就很大了 —— 任务速度能快一倍。

不过这里有个重要前提：任务正确率是必要指标，但它衡量不了代码质量和可读性，这两点很难自动评估。

附：我试着分析了 Claude Code 为什么耗 token 多，差别主要来自输入 token 而非输出 token。换句话说，不是 Claude 写得更长。日志显示，Claude 会在多轮交互中反复把更多上下文喂回模型，包括之前的消息、工具调用、命令输出、文件内容。比如有一次 Claude 跑了 25 轮，用了约 57.8 万输入 token，输出却只有约 4500 token。所以原因大概率是：Claude 框架在多步代理运行中，会累积或计入更多的提示端历史。

11. Mac 与 DGX 互联

前面讲的所有搭建方式，都默认本地大模型和编码代理跑在同一台机器上。

但如果我们已经信任了编码代理框架，想在主力 Mac 上用，而模型跑在另一台机器（比如 DGX Spark）上呢？

我觉得最好（也最方便）的方案是从 Mac 到 DGX 建一条 SSH 隧道。

首先建议先把 Mac 上的 Ollama 关掉，或者把 11434 端口改成别的。

假设 Mac 上已经退出 Ollama 应用，执行下面命令应该返回空，说明 Ollama 不可用：

curl http://127.0.0.1:11434/v1/models

然后在 Mac 的终端里执行：

ssh -N -L 11434:127.0.0.1:11434 rasbt@DGX-Spark

这条命令的意思是：以 rasbt 用户身份 SSH 连接到 DGX-Spark（用户名和机器名换成你自己的）。-L 11434:127.0.0.1:11434 表示把 Mac 本地的 11434 端口转发到 DGX 上的 127.0.0.1:11434，也就是 Ollama 的地址。

运行 ssh -N -L ... 的终端看起来像挂起了一样，这是正常的。用 Qwen Code、Codex 或 Claude Code 的时候保持它开着就行，按 Ctrl-C 停止隧道。

隧道跑起来之后，在 Mac 上试试能不能访问 DGX 上的 ollama 模型：

curl http://127.0.0.1:11434/v1/models

如果返回了 DGX 上的模型列表，Mac 上的工具就能像访问本地一样使用 DGX Ollama 服务了。

然后 Qwen Code 和 Codex 就按前面的方法用就行。

如果是通过 ollama launch claude 用 Claude，关键是 Mac 端的 ollama 命令要能访问到隧道转发的端点。需要的话这样写：

OLLAMA_HOST=http://127.0.0.1:11434
ollama launch claude --model qwen3.6:35b

12. OpenClaw 和 Hermes 呢？

我们重点讲了 Qwen Code、Codex、Claude Code，因为它们最贴合编码代理工作流。OpenClaw 和 Hermes 也能做，但它们是更广义的代理框架，更适合用来协调跨工具、跨应用、跨浏览器、跨终端的任务，以及长周期工作流。

做编码工作的话，建议先从 Qwen Code、Codex 或 Claude Code 入手（当然还有 OpenCode、Cline、Pi、Noumena Code 等很多有意思的编码框架）。OpenClaw 和 Hermes 更适合作为编码之外的进阶选项，而不是搭建本地编码代理的首选。

13. 结论

这篇文章信息量大、配置步骤多。如果说有几个核心要点，我想说：重要的不是机械地走完安装流程，而是运行本地编码代理时的各种考量。也就是说，最关键的不是装上某个特定工具，而是理解模型服务层、代理框架、权限模型，以及如何评估这套方案能不能可靠地完成编码任务。

当然，GPT 5.5 和 Opus 4.8 目前还是比 Mac 或 DGX Spark 上能跑的小体积开源模型强。但 30–35B 级别的新型混合专家模型（比如 Qwen3.6、North Mini Code、Nemotron 3 Nano）能力已经非常强了，很多任务都完全够用。而且它们的 token 速度和 Pro 订阅的 GPT 5.5 差不多，不一定会拖慢工作流。

搭建本地代理时，除了模型本身，选哪个框架也很重要。大家通常觉得模型对特定框架有优化（比如 Qwen3.6 在 Qwen Code 里可能比在 Claude Code 里更好用）。但从小规模代理测试来看，未必如此 —— 当然这只是非常小的基准，参考一下就好。所以如果你更习惯另一个框架、用得很熟，比如 Codex 或 Claude Code，直接把模型塞进去试试也未尝不可！

总之希望这篇文章对你有用，能激起你折腾开源权重模型的兴趣。它们一天比一天强，而且不知为什么，本地跑模型就是有种特别的乐趣。

扩展资源

想自己跑基准测试的话，本文用到的代码和小型评估任务都在这里：https://github.com/rasbt/local-coding-agent-evals

另外我的新书已经付印开始发货了。本来想晒个图，不过还要三天才到。

https://mng.bz/Nwr7

如果你喜欢我之前那本书，这本基本就是续作，从零实现推理时缩放技术与强化学习算法。

非常感谢付费订阅的读者，你们的支持对我持续写这些深度拆解、分享配套代码和实验帮助巨大。

【转载】使用本地 Coding Agent