使用本地编码代理

# 使用本地编码代理 来源：https://magazine.sebastianraschka.com/p/using-local-coding-agents 过去很多人问我关于我的本地代理栈以及我是如何设置它的。 所以，我想整理一个关于如何使用开源工具和开放权重 LLM 设置本地（编码）代理的小教程也许会有用。 图 1 (https://substackcdn.com/image/fetch/$s_!w1ai!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F98ebec9f-115a-4896-926d-5461220de62a_10126x2817.png) 图 1：本地栈概览，即一个编码代理工具，它使用通过推理引擎/运行时服务器托管的本地模型。 本文是一篇关于使用完全本地栈设置一个可用于生产的编码代理的教程。我们将使用一个本地服务的 LLM 以及一个本地的编码工具，该工具可以读取文件、进行编辑、运行命令并验证更改，如上图所示。 在这里，我们可以把 LLM 看作是提供推理和代码生成的引擎。而周围的工具则提供了操作环境，使 LLM 能够在我们的本地项目中进行有意义的编码工作。 为什么选择本地？对于许多编码工作流程来说，本地设置是 GPT in Codex 或 Opus in Claude Code 等专有服务的一个有趣替代方案。本地设置是透明的、可检查的，并且除了硬件和电费之外可以免费运行。它也完全在你的控制之下，并且你可以以任何你喜欢的方式修改编码工具。**而且，这非常有趣！** 顺便说一句，如果你想要更多关于编码代理工具的背景信息，我在这里介绍了编码代理的核心组件（以及为了学习目的从头构建一个编码代理）： 编码代理的组件 (https://magazine.sebastianraschka.com/p/components-of-a-coding-agent) 我不得不承认，目前我主要还是交替使用 Codex 和 Claude Code 作为我的日常工具（并且只是为了跟上不断添加的新工具和功能）。此外，计划限制（特别是 Codex）仍然非常宽松，到目前为止我还不必担心成本。 然而，我也使用本地解决方案一段时间了，用于测试一些东西，而且不知怎的，拥有并使用一个完全本地化的设置（相对于专有服务）让我感到快乐。 无论如何，本地解决方案每天都在变得越来越有吸引力。一方面是成本。如果你有硬件，它们几乎可以免费运行。当然还有隐私角度。例如，对于整理和处理我的收据，我更愿意让本地模型来处理它们，而不是将数据发送给 OpenAI 或 Anthropic。 （另外，如果我们考虑到 Anthropic 最近在限制其旗舰模型的 LLM 研究性能 (https://substack.com/@rasbt/note/c-273441982)，专有服务可能会随着时间的推移变得更加限制，也许熟悉开放权重替代方案作为后备是个好主意。） 还有许多许多类似的其他原因和用例。 你使用本地 LLM 和编码工具的动力可能包括： - 如果你的订阅计划达到上限，可预测的固定成本，并且不受 API 价格变化的影响。 - 可重复性；有时候如果模型升级（例如，GPT 5.4 -> GPT 5.5 -> GPT 5.6）并且更可靠地解决你所有的问题，这很不错。然而，这也可能破坏现有的工作流程。 - 在经典的飞机飞行场景中离线使用，网络速度慢或没有网络，或者在没有 Starlink 订阅的情况下在森林小屋里进行编码/写作静修时。 可能还有其他一些原因。 因此，在本文中，我们将设置并使用流行的工具，如 Codex 和 Claude Code，配合开放权重模型，并研究使用特定于模型的工具（如 Qwen-Code for Qwen3.6）是否带来额外的好处。（当然，还有许多其他工具，如 OpenCode、Cline、Pi 和 Noumena Code，但我认为大多数人已经对 Codex 或 Claude Code 有了肌肉记忆，这使得切换到开放权重模型更加顺畅。） 大多数编码代理工具遵循相似的原则，并且或多或少具有相同的特性和功能。然而，实现细节可能有所不同，并且某些 LLM 通常主要针对特定工具进行了优化。当然，许多开放权重 LLM（例如 GLM 5.2）也可以运行 Claude Code 等。 然而，如果 LLM 开发者同时开发了一个编码工具，那么可以安全地假设他们的模型首先针对自己的工具进行了优化（同时也支持其他工具）。 在这里，我将主要使用 Qwen3.6 配合 Qwen-Coder 编码客户端。但是，我也会介绍使用本地 LLM 配合其他代理工具的其他选项，例如 Claude Code、Codex 以及越来越流行的 Cline，但稍后会详细介绍。 我之所以在与 Qwen 模型一起工作时主要使用 Qwen-Code，原因是： 1. 它是开源的，就像 Codex (https://github.com/openai/codex) 一样，但不像 Claude Code； 2. Qwen 模型专门针对 Qwen-Code 工具进行了优化（下面有更多信息）； 3. 我可以在同一台机器上同时运行 Codex（使用最新的 GPT 模型）和带有本地 Qwen 模型的 Qwen-Code，而不必手动在模型之间来回切换。 关于上面列表中的第二点，即 Qwen 模型在 Qwen-Code 中工作得更好，Nvidia 的 Polar: Agentic RL on Any Harness at Scale (https://arxiv.org/abs/2605.24220) 论文（2026年5月）有一个基准测试，显示 Qwen3.5-4B 基础模型在上述 Qwen-Code 工具中具有最佳的编码性能（在 Polar-RL 训练之前和之后），我将其包含在下面。 上表中的基准测试是针对较旧的 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 在六月初分享的最新基准测试，它目前是同类尺寸中最好的本地模型。 如上所示，Qwen3.6 35B-A3B 在同类尺寸中几乎在所有基准测试中占据主导地位。不过话虽如此，Qwen Code 是一个通用工具，也支持其他类型的模型。例如，我们也可以在 Qwen Code 中连接 North Mini Code 或 Gemma 4。 图 4 (https://substackcdn.com/image/fetch/$s_!ZuIZ!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F2c1f1b73-8af7-478f-abfd-ae22886078f3_3128x1369.png) 图 4：是的，Qwen3.6 35B-A3B 确实是一个非常好的模型！（来自 x.com/pupposandro/status/2064707907489272147/） 在架构上，Qwen3.6 35B-A3B 模型具有类似于 Qwen3-Coder 和 Qwen3.5 的混合注意力机制。我在 Beyond Standard LLMs (https://magazine.sebastianraschka.com/p/beyond-standard-llms) 中写过更多相关内容。 图 5 (https://substackcdn.com/image/fetch/$s_!hp0Z!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fc38e986b-1116-49c9-936b-ac30c16f2f37_7215x9097.png) 图 5：来自我的 LLM 画廊 (https://sebastianraschka.com/llm-architecture-gallery/#card-qwen3-6-35b-a3b) 的 Qwen3.6 架构和事实表。 或者，如果你不想使用 Qwen3.6，Cohere 的 North Mini Code 可能是目前同类尺寸中最有趣、最有能力的替代品。我将下一节本地 LLM 设置中也介绍这个模型。 图 6 (https://substackcdn.com/image/fetch/$s_!dcyX!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F5319b62b-6922-43aa-af48-5d2e5a8de546_7089x8510.png) 图 6：来自我的 LLM 画廊 (https://sebastianraschka.com/llm-architecture-gallery/) 的 North Mini Code 架构和事实表。 无论我们使用什么代理工具（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 (https://ollama.com/) 作为我们高效的模型服务引擎，因为它相对容易安装，并且可以在不同操作系统上从命令行使用（尽管 LM Studio 也添加了一个非 GUI 的 `llmster` 客户端，但我对它不太熟悉）。 顺便说一句，我与本文中提到的任何工具都没有关联，但 Ollama 的一个好处是它们还可选地支持托管在云端的开放权重模型，包括目前最强的开放权重模型 GLM 5.2，该模型太大，无法在消费级硬件上本地运行。（云模型当然不是免费的，但有类似于 ChatGPT 和 Claude 的订阅计划；不过，有这个选项可以方便地“本地”测试最新的最先进的开放权重模型还是很不错的。） 无论如何，设置 Ollama 相当简单，你可以在他们的下载 (https://ollama.com/download/) 页面上找到官方的 macOS/Linux/Windows 下载说明。 安装后，我建议下载一个模型进行快速测试运行。例如，在 macOS 上，我们可以使用 ollama 应用程序通过 GUI 直接下载模型： 图 7 (https://substackcdn.com/image/fetch/$s_!qNMc!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F7d98c751-9718-49f8-b5fa-78b04921f540_5247x3974.png) 图 7：使用 Ollama 应用程序查找和下载模型 否则，也可以通过命令行完成： 顺便说一句，上面提到的 qwen3.6:35b-mlx 是一个使用 Apple 的 Metal 性能着色器的模型，即针对配备 Apple Silicon 芯片的 Mac 进行了优化。我强烈建议在 Mac 上使用模型的 *-mlx 版本（如果可用）。 图 8 (https://substackcdn.com/image/fetch/$s_!6ETy!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fc8fff02e-ce3e-42d4-96e0-bb0a962aeab7_6546x4306.png) 图 8：在 Mac（配备 Apple Silicon 芯片）上首选 MLX 版本。 在 Linux 机器上，使用非 MLX 版本： 然后，为了确保它能工作，你可以再次使用 GUI 或者从命令行启动 Ollama。 图 9 (https://substackcdn.com/image/fetch/$s_!dwyF!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fc1f314be-0a37-48ee-a194-9b339104b9ae_7518x5064.png) 图 9：在终端中运行 Ollama。 你可以通过 `/bye` 命令退出这个会话。 如前所述，目前 Qwen3.6 35B-A3B 模型的最佳替代品是类似大小的 North Mini Code 1.0。 图 10 (https://substackcdn.com/image/fetch/$s_!oH3j!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F730789df-4bdd-40a5-bc80-7b7e1628eb79_9216x3739.png) 图 10：North Mini Code 1.0 作为 Qwen3.6 35B A3B 的替代品。 在决定是否将 LLM 用作本地编码代理之前，通常最好先进行快速的速度和质量评估。在这里，对于速度评估，我会查看 tokens/sec 性能。此外，我还会确保在（非常）长的上下文中保持稳定，这通常是我们在代理编码工作流程中处理的情况（与更简单的聊天机器人不同）。 当然，我们也不希望内存成本爆炸。 你可以运行我的 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 分钟： 在 Linux 上，我们可以运行： 注意，这假设你已按照上一节所述下载了相应的模型。另外，取决于你的系统，如果你有少于 30 GB 的 RAM，你可能必须使用较小的模型，例如 gemma4:e2b，它在长上下文中最多使用约 8 GB RAM。（当然，也有许多更小的模型，但根据我的经验，它们作为本地编码代理表现相当差。） 注意，对于模型，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 (https://substackcdn.com/image/fetch/$s_!zYPa!,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F6e710c83-39f0-4785-80d3-be63fc8af766_6333x5706.png) 图 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 整体上可能略微领先。 无论如何，底线是，在我看来，任何快于 20-30 tok/sec 的速度对于本地代理工作来说都相当合理。**这与 GPT 5.5 的“高”推理速度大致相同**。在这种情况下，两个模型都轻松达标。 顺便说一句，我个人几乎完全在 DGX Spark 上运行我的代理，因为我不想让我的 Mac Mini 变得太热，而且我想把 RAM 留给其他任务。 当然，总会有方法通过不同的框架（除了 Ollama）、量化、MTP 等来进一步优化。然而，Ollama 是一个很好的即插即用全能型选手，设置时间最短，可以轻松连接到各种编码代理框架，并且切换和尝试不同模型非常简单。 在检查了