使用本地编码代理

Using Local Coding Agents

二〇二六年六月二十八日 · 英文原文

摘要

本文介绍如何使用开源工具和开放权重LLM搭建完全本地化的编码agent。教程涵盖模型服务（Ollama）、编码框架（Qwen-Code、Codex、Claude Code）及性能评估。关键模型包括Qwen3.6 35B-A3B、North Mini Code 1.0和Nemotron 3 Nano，在30-40 GB RAM下以约30-40 tok/sec运行。作者Sebastian Raschka在DGX Spark和Mac Mini上测试，Qwen3.6在Codex框架中解决5个任务中的4个，Claude Code中达5/5。提供隐私审计清单和SSH隧道跨机部署方案。

过去很多人问我关于我的本地 agent 栈以及如何搭建它。所以，我觉得整理一个小教程，介绍如何使用开源工具和开放权重 LLM 搭建一个本地（编码）agent，可能会很有用。

图 1：本地栈概览，即一个编码 agent 框架，它使用通过推理引擎/运行时服务器托管的本地模型。

本文是一篇教程，介绍如何搭建一个完全本地化的、可用于生产的编码 agent。我们将使用一个本地服务的 LLM，配合一个本地的编码框架，该框架可以读取文件、进行编辑、运行命令并验证更改，如上图所示。在这里，我们可以把 LLM 看作是提供推理和代码生成的引擎。而周围的框架则提供了操作环境，使 LLM 能够在我们的本地项目中进行有意义的编码工作。

为什么选择本地？

对于许多编码工作流来说，本地设置是 GPT in Codex 或 Opus in Claude Code 等专有服务的一个有趣替代方案。本地设置是透明的、可检查的，并且除了硬件和电费外，可以免费运行。它也完全在你的控制之下，你可以随意修改编码框架。另外，这还非常有趣！

顺便提一下，如果你想要更多关于编码 agent 框架的背景信息，我在这里介绍了编码 agent 的核心组件（以及为了学习目的从头构建一个编码 agent）：

介绍

我必须承认，目前我日常主要还是在 Codex 和 Claude Code 之间交替使用（只是为了跟上不断添加的新工具和功能）。而且，计划限制（尤其是 Codex）仍然非常慷慨，以至于到目前为止我还没有担心过成本。不过，我也使用本地解决方案一段时间了，用于测试一些东西，而且拥有并使用一个完全本地的设置（相对于专有服务）不知何故让我感到快乐。无论如何，本地解决方案每天都变得越来越有吸引力。

一个方面是成本。如果你有硬件，它们几乎可以免费运行。当然，还有隐私方面的考虑。例如，对于整理和处理我的收据，我更愿意让本地模型来处理它们，而不是将数据发送给 OpenAI 或 Anthropic。（此外，如果我们考虑到 Anthropic 最近为了 LLM 研究而限制了其旗舰模型的性能，专有服务可能会随着时间的推移变得更加受限，因此熟悉开放权重替代方案作为备份可能是个好主意。）

还有很多很多类似的原因和用例。你使用本地 LLM 和编码框架的动机可能包括：

如果你达到了订阅计划限制，成本是可预测且固定的，并且不受 API 价格变化的影响。
可复现性；有时，模型升级（例如，GPT 5.4 -> GPT 5.5 -> GPT 5.6）并更可靠地解决你所有查询是件好事。然而，这也可能破坏现有的工作流。
在经典的飞机场景中离线使用，网络速度慢或没有网络，或者在没有 Starlink 订阅的情况下，去森林小屋进行编码/写作静修时。
可能还有其他原因。

因此，在本文中，我们将使用开放权重模型设置并使用流行的框架，如 Codex 和 Claude Code，并研究使用特定于模型的框架（如用于 Qwen3.6 的 Qwen-Code）是否会带来额外的好处。（当然，还有很多其他框架，如 OpenCode、Cline、Pi 和 Noumena Code，但我认为大多数人已经对 Codex 或 Claude Code 有了肌肉记忆，这使得切换到开放权重模型会更顺畅一些。）

2. 编码 Agent 框架概览

大多数编码 agent 框架遵循相似的原则，并具有或多或少相同的特性和功能。然而，实现细节可能有所不同，并且某些 LLM 通常主要针对特定框架进行了优化。当然，许多开放权重 LLM，例如 GLM 5.2，可以运行 Claude Code 等。然而，如果 LLM 开发者同时也开发了一个编码框架，那么可以合理地假设他们的模型首先针对自己的框架进行了优化（同时也支持其他框架）。

在这里，我主要将使用 Qwen3.6 配合 Qwen-Coder 编码客户端。不过，我也会介绍其他选项，例如将本地 LLM 与其他 agent 框架（如 Claude Code、Codex 以及日益流行的 Cline）一起使用，但稍后会详细介绍。

我主要在使用 Qwen 模型时使用 Qwen-Code 的原因是：

它是开源的，像 Codex (https://github.com/openai/codex) 一样，但不同于 Claude Code；
Qwen 模型专门针对 Qwen-Code 框架进行了优化（更多信息见下文）；
我可以在同一台机器上同时运行 Codex（使用最新的 GPT 模型）和 Qwen-Code（使用本地 Qwen 模型），而无需手动在模型之间来回切换。

关于上面列表中的第二点，即 Qwen 模型在 Qwen-Code 中表现更好，Nvidia 的论文 Polar: Agentic RL on Any Harness at Scale（2026 年 5 月）中有一个基准测试显示，Qwen3.5-4B 基础模型在 Qwen-Code 框架中具有最佳的编码性能（无论是在他们的 Polar-RL 训练之前还是之后），我将其包含在下面。

图 2：通过 Polar: Agentic RL on Any Harness at Scale (https://arxiv.org/abs/2605.24220) 得到的 Qwen 模型在不同编码框架中的性能

上表中的基准测试是针对较旧的 Qwen3.5 模型的，我假设最新的 Qwen3.6 模型进一步优化，以便在 Qwen-Code 中表现良好。然而，Pi (https://github.com/earendil-works/pi) 似乎也是一个非常有趣的候选者，我将来需要尝试一下。

顺便提一下，Qwen3.6 35B-A3B 下载大小约为 22 GB，需要大约 30-40 GB 的 RAM，并且在配备 M4 的 Mac Mini 和 DGX Spark 上运行得相当快。根据 Cohere 在 6 月初分享的最新基准测试，它目前是其尺寸类别中最好的本地模型。

图 3：来自 Cohere 6 月发布的 North Mini Code 报告的基准测试 (https://huggingface.co/blog/CohereLabs/introducing-north-mini-code)

如上所示，Qwen3.6 35B-A3B 在该尺寸类别中主导了除一个基准测试之外的所有测试。不过，话虽如此，Qwen Code 是一个通用框架，也支持其他类型的模型。例如，我们也可以在 Qwen Code 中连接 North Mini Code 或 Gemma 4。

图 4：是的，Qwen3.6 35B-A3B 是一个非常棒的模型！(Via x.com/pupposandro/status/2064707907489272147/)

在架构方面，Qwen3.6 35B-A3B 模型具有类似于 Qwen3-Coder 和 Qwen3.5 的混合注意力机制。我在 Beyond Standard LLMs 中写了更多相关内容。

图 5：来自我的 LLM 画廊的 Qwen3.6 架构和概况表

或者，如果你不想使用 Qwen3.6，Cohere 的 North Mini Code 可能是目前该尺寸类别中最有趣、最有能力的替代方案。我也将在下一节本地 LLM 设置中介绍这个模型。

图 6：来自我的 LLM 画廊的 North Mini Code 架构和概况表

3. 本地 LLM 设置

无论我们使用什么 agent 框架（Qwen-Code、Codex 或 Claude Code），我们首先都必须设置一个本地 LLM，例如 Qwen3.6 35B-A3B。有几种选项可以在本地服务模型，如 Ollama、LM Studio、vLLM、SGLang、MLX 等。你从我的 Build A Large Language Model (From Scratch) 和 Build A Reasoning Model (From Scratch) 项目中知道，我喜欢自己编写这些代码。从头实现一个模型的好处是我们理解整个栈，此外我们还可以修改并进一步训练和微调它。然而，在这里，我们只是寻找一个在推理速度和资源需求方面经过超级优化的模型服务框架，因为我们目前不打算进行任何训练或微调。（我们可以，作为额外步骤，将我们自己从头微调的模型转换并导入到这些高效的服务栈中，但这超出了本文的范围。）

在本教程中，我们将使用 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 性能着色器的模型，即针对配备 Apple Silicon 芯片的 Mac 进行了优化。我强烈建议在 Mac 上使用模型的 *-mlx 版本（如果有的话）。

图 8：在 Mac（配备 Apple Silicon 芯片）上时，优先选择 MLX 版本。

在 Linux 机器上，使用非 MLX 版本：ollama pull qwen3.6:35b

然后，为了确保它工作正常，你可以再次使用 GUI 或从命令行启动 Ollama。

图 9：在终端中运行 Ollama。你可以通过 /bye 命令退出此会话。

如前所述，目前 Qwen3.6 35B-A3B 模型的最佳替代品是类似大小的 North Mini Code 1.0。

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

4. 简单速度性能评估

在决定是否使用 LLM 作为本地编码 agent 之前，运行一个快速的速度和质量评估通常不是一个坏主意。在这里，对于速度评估，我会关注 tokens/sec 性能。此外，我还会确保这在（非常）长的上下文中保持稳定，这是我们在 agentic 编码工作流中通常要处理的（与更简单的聊天机器人不同）。当然，我们也不希望内存成本爆炸。

你可以运行我的 ollama_speed_memory_bench.py 脚本来进行快速检查。简而言之，它向 Ollama 模型发送不同的提示（范围从 1k 到 50k 个单词），并默认要求其生成最多 8k 个 token。它报告简单的统计数据，如来自 Ollama 提示评估指标的预填充速度、来自输出 token 计时的生成速度，以及来自 Ollama 进程的内存使用情况（如果可用，还包括 NVIDIA GPU 内存）。

例如，要在 macOS 上评估 qwen3.6:35b-mlx，如果你从 https://github.com/rasbt/local-coding-agent-evals 下载或克隆了脚本，我们可以运行以下命令，大约需要 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

请注意，这假设你已经按照上一节所述下载了相应的模型。另外，根据你的系统，如果你的 RAM 少于 30 GB，你可能必须使用较小的模型，如 gemma4:e2b，它在长上下文下最多使用约 8 GB RAM。（当然，还有很多更小的模型，但根据我的经验，它们作为本地编码 agent 表现很差。）

请注意，对于模型，RSS RAM 报告在 macOS 上并不非常准确（尤其是对于利用 Metal 后端的 mlx 模型变体），我建议在运行期间也关注活动监视器中 Ollama 的 RAM 使用情况。在这种情况下，RAM 使用量在 20 - 29 GB 之间波动。

无论如何，底线是，对于 50k 上下文，Qwen3.6 和 North Mini Code 模型最多使用 30 GB RAM，并在最新的 Mac Mini 上以约 40 tok/sec 的速度生成输出，在 DGX 上以约 30 tok/sec 的速度生成输出。以下是不同运行的视觉摘要。

图 11：不同系统上不同模型的快速速度比较。请注意，macOS 的 RAM 消耗在那里并不非常准确。另外，请注意，由于优化的 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 的速度对于本地 agent 工作来说都是相当合理的。这与具有“高”推理能力的 GPT 5.5 的速度大致相同。在这种情况下，两个模型都轻松达标。

顺便提一下，我个人几乎完全在我的 DGX Spark 上运行我的 agent，因为我不想让我的 Mac Mini 变得太热，并且我希望将 RAM 用于其他任务。当然，总有一些方法可以使用不同的框架（除了 Ollama）、量化、MTP 等来进一步优化。然而，Ollama 是一个很好的即插即用全能选手，设置时间最短，可以轻松连接到各种编码 agent 框架，并且交换和尝试不同的模型非常简单。

5. 简单基准性能评估

在检查模型足够快以方便本地工作后，我建议进行快速的建模性能评估。当然，外面有很多标准化的基准测试，我们可以查看甚至自己运行。通常，你可以在模型的技术报告或模型中心页面上找到相关基准测试的数字。通常，我还发现查看 https://artificialanalysis.ai/models/ 上与其他模型的相对比较很有用。

图 13：来自 https://artificialanalysis.ai/models/ 的基准测试。平均性能（顶部）、编码性能（中部）、agentic 性能（底部）。

基于上图，我们可以看到，例如，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 正确完成了概念性调试和安全审查任务，但在关于“先处理哪个文件/操作”的 agentic 判断上仍然存在困难。3/5 的分数是可用的，但对于自主工具使用来说并非完全可靠。但是，一个能够约束操作、添加重试机制，并可能提供更强项目上下文的框架，可以使其变得相当可用。另一方面，gemma4:e2b 的 0/5 失败是一个强烈的信号，表明它不太适合这种工具使用推理，即使它很快。请注意，失败不仅仅是格式问题。它似乎选择了错误的工具，在上下文足够时要求澄清，等等。我可能不会将其用作编码 agent 模型，除非是非常狭窄或高度受限的任务。

6. Agent 代码库审计

在冗长的本地 LLM 设置序言之后，让我们回到主要话题：编码 agent 框架。正如本文开头提到的，我们将使用 qwen-code (https://github.com/QwenLM/qwen-code) 框架，因为 Qwen 模型已针对它进行了优化。

图 14：接下来，我们尝试将本地服务的模型连接到编码 agent 框架。如果你熟悉 Claude Code，这基本上是相同的东西，但完全开源。不过，我将在下一节中介绍如何将本地 Qwen3.6 模型连接到 Codex 和 Claude Code。

请注意，编码框架本身比 LLM 强大得多。这就是我建议在运行什么以及在哪里运行时要更加小心的原因。例如，在尝试新的（编码）agent 时，我喜欢：

首先对（开源）agent 代码库进行审计。
在单独的硬件（例如，我的 DGX Spark）上运行它，或者至少在我的机器上使用单独的用户帐户和/或虚拟环境运行它。

关于审计，我建议在文件权限方面寻找数据共享/外泄和默认破坏半径，以及一些针对 prompt injection 的基线鲁棒性。下图试图总结要点。

图 15：在运行已安装的编码 agent 框架之前的实用审计清单。类似的担忧也适用于本地模型服务引擎（例如 Ollama）。然而，编码 agent 需要更多关注，因为它们可以直接读取你机器上的数据并操作文件。

为了进行基本审计，我建议：

克隆仓库：git clone https://github.com/QwenLM/qwen-code.git
让你以前使用过的受信任 agent（例如 Codex 中的 GPT 5.5 或 Claude Code 中的 Opus 4.8）使用聚焦的提示对其进行审查。类似如下内容：
你正在审计 ./qwen-code，然后我才会在我的机器上安装或运行该 agent。仅关注已安装 agent 对本地机器的实际风险以及创建它的代码路径：
- 安装脚本和包生命周期钩子
- agent 的 shell 命令执行
- 运行时文件读/写边界
- 秘密处理和环境变量继承
- 仓库文件、项目指令和工具输出如何影响 agent
- MCP、插件、扩展或工具集成
- 网络调用和遥测
- 安装后的更新机制
- 终端转义/输出处理
- 数据外泄和数据驻留忽略严格为安装所需的互联网下载。检查当我通过 Ollama 使用本地模型时，已安装的 agent 是否可以将提示、文件、遥测、日志、标识符或元数据发送到远程服务器。忽略云模型配置。不要仅从项目所有者推断风险。识别控制网络行为的具体端点、SDK、默认提供者、环境变量、配置默认值和文档，包括任何在外国或由第三方公司运营的端点。不要进行广泛的风格审查。不要重构。输出：
- 带有文件/行引用的高风险发现
- 中等风险问题
- 网络/数据外泄发现，包括任何外国、第三方或与中国相关的端点或默认值
- 在审查之前应避免运行的命令
- 降低本地机器风险的设置或环境变量
- 简短建议：在沙箱中测试安全、使用安全或不要运行对于每个项目，说明这是编码 agent 的预期行为，还是本质上比 Codex 或 Claude Code 风险更高。

以下是主要发现的摘要（因为完整报告可能有点无聊，并且对于本文来说太长）：

本地执行：Qwen Code 可以通过其 shell 工具在我们的机器上运行 shell 命令，但除非启用了诸如 --yolo 之类的宽松模式，否则有严格的批准控制。这对于编码 agent 来说是预期的，实际上这也是它在实践中变得有用的原因。但当然，如果在没有沙箱或包含秘密的完整环境中运行，它会变得有风险。
数据外泄：即使使用本地 Ollama，Qwen Code 也可以将使用遥测和元数据发送到 Alibaba/Aliyun 端点，除非禁用了使用统计和遥测（更多内容见下文）。这比纯本地设置风险更高，因为模型提示可能保持本地，但会话 ID、工具元数据、模型信息和本地 base URL 元数据仍然可以离开机器。但同样，这在各种工具中也很常见（是的，Codex 和 Claude 也这样做）。
文件和秘密边界：工作区文件默认是可读的，而写入通常需要批准并包含一些覆盖保护。这是良好且标准的 agent 实践。
Prompt injection 面：仓库指令、工具输出、MCP 工具、扩展和项目配置可以影响 agent 的行为。Prompt injection 攻击可以通过上述批准门来减少。这对于编码 agent 来说是正常的，但默认情况下，不受信任的仓库应被视为具有敌意，因为它们可以引导 agent 读取文件、运行命令或通过已批准的工具发送数据。

关于第 2 点中的主要隐私问题，大部分可以通过自定义 ~/.qwen/settings.json 文件并包含以下内容来解决：

{
  "privacy": {
    "usageStatisticsEnabled": false
  },
  "telemetry": {
    "enabled": false,
    "logPrompts": false
  },
  "outboundCorrelation": {
    "propagateTraceContext": false
  },
  "general": {
    "enableAutoUpdate": false
  },
  "tools": {
    "approvalMode": "default",
    "sandbox": true
  },
  "mcpServers": {},
  "hooks": {
    "disableAllHooks": true
  }
}

"general": { "enableAutoUpdate": false } 设置是一个权衡。安全修复程序不会自动安装，但我更喜欢明确控制何时进行更新，而不是让工具在后台拉取和应用新代码。

顺便提一下，cline (https://github.com/Cline/Cline)、Codex (https://github.com/openai/codex) 和 Claude Code 也有类似的遥测数据共享默认设置，需要明确禁用。（请注意，Claude Code 没有其代码库的官方开源版本，这使得信任它更加棘手，并且它似乎确实将数据发送给 Anthropic 和 Datadog。）

无论如何，总体而言，Qwen-Code 似乎遵循标准实践，并且在撰写本文时，没有发现对编码 agent 来说非标准的特别问题。

7. Qwen-Code 设置

如果我们接受报告中的发现和风险（就我个人而言，我没有看到任何危险信号），我们现在可以继续进行安装，并将我们的本地 Qwen3.6-35B-A3B 模型连接到 Qwen Code（以及下一节中的 Codex 和 Claude Code）。

如前所述，我更喜欢在单独的机器上（在我的情况下是 DGX Spark，但也可以是单独的 Mac 或 Linux 工作站）实验和运行能够读取和编辑本地文件的编码 agent。或者，我会在虚拟机中运行它，或者设置一个单独的 macOS 或 Linux 用户帐户作为实用的折中方案。（我听说一些朋友也会为此租用服务器，比如 Linode 或 Heroku，用于摆弄。然而，与其为一台性能尚可的机器支付月租费，我可能更愿意买一个相对便宜的 200-500 美元的硬件盒子，甚至是一台旧的退役笔记本电脑，运行本地框架，然后如果你正在寻找 GPT 或 Claude 的替代品，可以通过 Ollama 云模型、OpenRouter 等使用托管在云端的更强的开放权重模型。）

无论如何，让我们安装 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 << 'EOF'
#!/bin/bash
exec node "$HOME/Developer/qwen-code/dist/cli.mjs" "$@"
EOF

# 使包装器可执行
chmod +x ~/.local/bin/qwen

# 确保 ~/.local/bin 在你的 PATH 中
# （如果尚未添加，请将以下行添加到你的 ~/.zshrc 或 ~/.bashrc）
export PATH="$HOME/.local/bin:$PATH"

安装完成后，我们现在可以通过终端中的 qwen 命令启动 Qwen-Code 客户端来完成设置并连接到本地服务的 LLM。为此，在运行 qwen 命令后，我们选择“Custom Provider”，如下所示。

图 16：选择“Custom Provider”，这使我们能够连接 Ollama LLM。

Ollama 使用 OpenAI API 标准。所以，接下来，我们按照屏幕上的设置指南进行操作，并选择“OpenAI-compatible”选项。

图 17：由于 Ollama 遵循 OpenAI API 标准，我们在此选择“OpenAI-compatible”。

接下来，我们需要提供正在运行的服务于我们本地 LLM 的 Ollama 应用程序的 API 端点。通常，默认是本地的 http://127.0.0.1:11434 地址。我们输入 http://127.0.0.1:11434/v1（包括 /v1），因为那是与 OpenAI 兼容的 base URL。

图 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/6 步中，我们当然选择“Enable thinking”模式，这将导致更高的 token 使用量，但由此带来的更好的问题解决能力是值得的。

图 21：为本地模型提供者启用思考模式。

基本上就是这样。第 6 步基本上是一个审查步骤，我们可以按“Enter”键确认。恭喜，你现在应该已经设置了一个可用的完全本地 LLM 工作流。其用法与 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"。

顺便提一下，要偶尔更新 qwen-code 工具，如果我们使用了 git clone & local build 的方式，我们可以拉取最新的 GitHub 快照并按如下方式更新：

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

# 从 GitHub 获取最新更改
git pull

# 如果包文件发生更改，则安装或更新依赖
npm install

# 重新构建本地 CLI
npm run build

# 验证更新的 CLI
qwen --version

8. Agent 能力评估

现在我们有了一个完全可用的本地编码 agent，问题是：它的表现如何，它是否真的足够好以完成我的任务？当然，有这方面的基准测试，但在我看来，没有什么比亲自在你的工作流上试用一下更好的了。换句话说，这基本上意味着使用它一两天来决定它是否满足你的标准。我还建议编译一小套反映你常见编码 agent 使用情况的任务。如果你在处理某个项目时遇到了一个特别具有挑战性的任务，将其添加到这个集合中以评估未来的模型可能是个好主意。

作为我意思的一个例子，我在 GitHub 上分享了一套相对较小、简单且通用的任务，我们可以用来测试 agent：https://github.com/rasbt/local-coding-agent-evals/tree/main/agent-problem-pack。这基本上是本地 LLM 设置部分任务的扩展。如何运行这些任务的详细信息在 GitHub README 中：https://github.com/rasbt/local-coding-agent-evals/tree/main/agent-problem-pack#quick-start-running-benchmarks-manually。以下是在 Qwen-Code 中测试的不同 LLM 的结果。

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

正如我们所见，Qwen3.6 和 North Mini Code 35B-A3B 模型都解决了 5 个问题中的 4 个。Gemma 4 E2B 失败了很多。出于好奇，我还添加了稍旧一点的 Nemotron 3 Nano 模型。它具有与前述 Qwen 和 North 模型相似的尺寸和计算性能，并且表现同样出色。

图 25：来自我的 LLM 画廊的 Nemotron 3 Nano 架构概览

9. Codex 设置

在设置了本地编码 agent（并且文章超过了 5000 字）之后，这可能是一个合理的停止点。然而，作为额外内容，我也认为为了完整性而添加简短的 Codex 和 Claude Code 说明可能会很有趣。不幸的是，据我所知，Codex UI 不支持非 OpenAI 模型，但我们可以使用 Codex CLI 来运行我们的 Ollama 模型。如果你还没有安装 OpenAI Codex CLI，你可以从他们的开源 GitHub 目录（https://github.com/openai/codex）中获取并安装它，类似于 qwen-code。（是的，Codex CLI 是开源的！）我将省去冗长的命令列表，建议你查看仓库的 README 以获取官方说明。（在这里，克隆仓库并运行类似于 qwen-code 的审计也不是一个坏主意。）

然后，安装完成后，有多种方法可以启用本地模型使用。在我看来，最方便的方法是设置一个单独的配置文件 ~/.codex/ollama.config.toml（在现有的 ~/.codex 文件夹内），并包含一些默认选项：

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

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

图 26：为 Codex 设置一个单独的 Ollama 配置文件以方便使用。

然后，我们仍然可以使用 codex 启动常规的“Codex with GPT 5.5”模式，并通过 codex --profile ollama 使用我们的 Ollama 模型。

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

当重新运行 Agent 能力评估部分的测试用例时，令我惊讶的是，Qwen3.6 通过 Codex 的表现实际上比通过其“原生”的 Qwen-Code 编码框架更好，如下所示。

图 28：Codex 中的小型本地 agent 能力基准测试。尽管这只是一小套基准测试，但它表明使用 Codex 作为通用编码 agent 框架可能毕竟不是一个坏主意。

10. Claude Code 设置

当然，还有流行的 Claude Code agent 框架，我们可以将其用作本地 LLM 的框架。虽然非常流行且功能强大，但这可能是我最不喜欢的本地设置选项，因为其代码库是专有的。这也意味着我们不能轻易检查和/或禁用 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：三个框架对不同 LLM 的平均 token 使用量。重现代码：https://github.com/rasbt/local-coding-agent-evals

在小型 agent 能力评估基准测试中，Qwen 和 North Mini Code 模型也获得了 5/5 的分数，甚至较小的 Gemma 4 模型也表现不错！有趣的是，我们还可以看到 token 使用量主要由框架驱动，而不是 LLM 本身。也就是说，在所有三个能够解决（几乎）所有 5 个任务的 LLM 中，它们都使用了相同数量的 token（例如，Qwen3.6 在 Claude Code 内部使用时，使用的 token 数量与 North Mini Code 和 Nemotron 3 Nano 大致相同）。只有 Gemma 4 使用了更少的 token，但它也几乎失败了所有任务，很可能是因为工具调用能力不足，导致任务提前中断。作为参考，下面是再次总结的任务成功率。

图 31：总结的任务成功率。

无论如何，这里的要点是，如果更多的 token 有助于模型-框架组合解决更多（和更复杂的）问题，那太好了！但是，如果我们有两个框架，它们的任务成功率相同，而一个框架使用的 token 少 50%（例如，Codex 相对于 Claude Code），那么这是一个巨大的胜利，因为它将使任务运行速度快两倍。然而，这里最大的警告是，任务正确性是一个必要条件，但它不能衡量代码质量和可读性，而这些很难自动评估。

附注：我试图分析为什么 Claude Code 使用更多的 token，似乎差异主要来自输入 token 而不是输出 token。换句话说，Claude 并没有写两倍多的内容。日志表明，Claude 在多次交互中反复将更多上下文反馈给模型，包括先前的消息、工具调用、命令输出和文件内容。例如，一次 Claude 运行在 25 次交互中使用了大约 578k 个输入 token，但只使用了大约 4.5k 个输出 token。所以，可能的解释是，Claude 的框架在多步 agent 运行期间累积或计入了更大的提示端历史记录。

11. Mac DGX

到目前为止，我们讨论的所有设置都假设我们在与编码框架相同的机器上运行本地 LLM。然而，如果我们对编码 agent 框架建立了一些信任，并希望在我们的主 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 的身份打开一个到 DGX-Spark 的 SSH 连接，你需要根据你的用户名和机器名称进行调整。然后，由于 -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 上使用这个命令来查看 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，因为它们最适合编码 agent 工作流。OpenClaw 和 Hermes 也很有能力，但它们是更广泛的 agent 框架。当你希望一个 agent 协调工具、应用程序、浏览器、终端和更长时间运行的工作流时，它们更合适。对于编码工作，我建议首先从 Qwen Code、Codex 或 Claude Code 开始（还有许多其他有趣的编码框架，如 OpenCode、Cline、Pi 和 Noumena Code）。我会将 OpenClaw 和 Hermes 视为超越编码的有趣后续选项，而不是这个本地编码 agent 设置的第一个基线。

13. 结论

这是一篇很长的文章，包含大量信息和配置。如果说有几个主要收获，我会说，重要的不是机械的设置流程，而是在本地运行编码 agent 时的考虑因素。也就是说，最重要的部分不是安装一个特定的工具，而是理解模型服务层、agent 框架、权限模型，以及如何评估该设置是否确实能可靠地解决编码任务。

当然，GPT 5.5 和 Opus 4.8 目前比在 Mac 或 DGX Spark 上运行的较小的开放权重模型更好。但是，30-35B 范围内较新的 Mixture-of-Experts 模型（如 Qwen3.6、North Mini Code 和 Nemotron 3 Nano）都非常非常强大，并且对于许多任务来说确实足够。是的，它们通过 Pro 订阅以与 GPT 5.5 相同的 token 速度运行，因此不一定需要减慢你的工作流。

在设置本地 agent 时，除了模型本身之外，主要考虑因素还包括我们想要使用哪个框架。普遍的看法是，模型通常针对某个特定框架的优化程度高于其他框架（例如，Qwen3.6 在 Qwen Code 中可能比在 Claude Code 中工作得更好）。然而，基于小型 agent 评估，这可能不一定成立（这只是一个非常小的基准测试，所以请谨慎对待）。所以，如果你对另一个你有很多肌肉记忆的框架（如 Codex 和 Claude Code）更熟悉，那么将模型放入那个框架并尝试一下，也许并不是一个坏主意！

无论如何，我希望这篇文章对你有用，并让你对使用开放权重模型进行一些摆弄产生了兴趣。它们每天都在变得更有能力，而且出于某种无法解释的原因，在本地运行模型就是很有趣。

进一步资源

如果你想自己尝试基准测试，本文中使用的代码和小型评估任务可在此处获得：https://github.com/rasbt/local-coding-agent-evals

另外，我的 Build a Reasoning Model (From Scratch) 一书现已付印并开始发货。我想放一张照片，但它还需要 3 天才能到货。

Build a Reasoning Model (From Scratch)

如果你喜欢我之前的 Build a Large Language Model (From Scratch) 一书，这本质上是续集，从头实现了推理时扩展技术和强化学习算法。如果你想支持未来像这样的长篇文章，请考虑成为付费订阅者。这有助于我继续撰写这些独立的深度文章，并分享附带的代码、图表和实验。

译自 Ahead of AI · Sebastian Raschka · 录于二〇二六年六月二十八日