过去很多人问我关于我的本地代理栈以及我是如何搭建它的。
所以，我觉得整理一个关于如何使用开源工具和开放权重大语言模型搭建本地（编码）代理的小教程可能会很有用。
本文是一篇关于使用完全本地栈搭建一个可用于生产环境的编码代理的教程。我们将使用一个本地服务的大语言模型，配合一个本地的编码框架，该框架可以读取文件、进行编辑、运行命令并验证更改，如上图所示。
在这里，我们可以将大语言模型视为提供推理和代码生成的引擎。而周围的框架则提供了操作环境，使得大语言模型能够在我们的本地项目中进行有意义的编码工作。
为什么选择本地？对于许多编码工作流程来说，本地设置是Codex中的GPT或Claude Code中的Opus等专有服务的一个有趣替代方案。本地设置透明、可检查，并且除了硬件和电费外，运行是免费的。它也完全在你的控制之下，你可以随意修改编码框架。而且，这非常有趣！
顺便提一下，如果你想要更多关于编码代理框架的背景信息，我在这里介绍了编码代理的核心组件（以及为了学习目的从头构建一个编码代理）：
[
](https://magazine.sebastianraschka.com/p/components-of-a-coding-agent)
我不得不承认，目前我主要还是在Codex和Claude Code之间交替使用，作为我的日常工具（只是为了跟上不断添加的新工具和功能）。另外，计划限制（尤其是Codex）仍然非常宽松，所以到目前为止我还没有担心过成本问题。
不过，我也使用本地解决方案一段时间了，用于测试一些东西，而且不知为何，拥有并使用一个完全本地的设置（相对于专有服务）让我感到快乐。
无论如何，本地解决方案每天都在变得越来越有吸引力。一个方面是成本。如果你有硬件，它们几乎是免费运行的。当然，还有隐私方面的考虑。例如，对于整理和处理我的收据，我更倾向于让本地模型来处理它们，而不是将数据发送给OpenAI或Anthropic。
（那么，如果我们考虑到Anthropic最近为了大语言模型研究而限制其旗舰模型的性能，专有服务可能会随着时间的推移变得更加严格，也许熟悉开放权重替代方案作为备份是个好主意。）
还有许多类似的原因和用例。
你使用本地大语言模型和编码工具集的动机可能包括：
- 可预测的固定成本，当达到订阅计划限制时不受影响，且不受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形成了肌肉记忆，这使得切换到开放权重模型更加顺畅。）
大多数编码代理工具集遵循相似的原则，并具备大致相同的特性和功能。然而，实现细节可能有所不同，某些大语言模型通常主要针对特定工具集进行了优化。当然，许多开放权重大语言模型（例如GLM 5.2）也能运行Claude Code等。
不过，如果大语言模型开发者同时开发编码工具集，那么可以合理假设他们的模型首先针对自家工具集进行了优化（同时也支持其他工具集）。
在这里，我主要将Qwen3.6与Qwen-Coder编码客户端配合使用。但我也会介绍其他选项，例如使用本地大语言模型配合Claude Code、Codex以及日益流行的Cline等代理工具集，不过这些内容稍后再谈。
我主要使用Qwen-Code来处理Qwen模型的原因如下：
- 它是开源的，像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训练前还是训练后），我将其附在下方。
上表中的基准测试针对的是较旧的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 月初分享的最新基准测试，它目前是同尺寸类别中最好的本地模型。
如上所示，Qwen3.6 35B-A3B 在该尺寸类别中几乎在所有基准测试中占据主导地位，仅有一项例外。不过话虽如此，Qwen Code 是一个通用框架，也支持其他类型的模型。例如，我们也可以在 Qwen Code 中连接 North Mini Code 或 Gemma 4。
在架构方面，Qwen3.6 35B-A3B 模型采用了与 Qwen3-Coder 和 Qwen3.5 类似的混合注意力机制。我在《超越标准大语言模型》一文中对此有更详细的介绍。
另外，如果你不想使用 Qwen3.6，Cohere 的 North Mini Code 可能是目前同尺寸类别中最有趣、最有能力的替代方案。我将在下一节本地大语言模型设置中详细介绍这个模型。
无论我们使用哪种智能体框架（Qwen-Code、Codex 或 Claude Code），我们都需要先设置一个本地大语言模型，例如 Qwen3.6 35B-A3B。
有多种选项可用于在本地提供模型服务，例如 Ollama、LM Studio、vLLM、SGLang、MLX 等。从我的《从零开始构建大语言模型》和《从零开始构建推理模型》项目中，你知道我喜欢自己编写这些代码。从头实现一个模型的好处是，我们能够理解整个技术栈，并且可以对其进行修改、进一步训练和微调。
然而，在这里，我们只是寻找一个在推理速度和资源需求方面经过高度优化的模型服务框架，因为我们目前不打算进行任何训练或微调。（作为额外步骤，我们可以将我们自己从头微调的模型转换并导入到这些高效的服务栈中，但这超出了本文的范围。）
在本教程中，我们将使用 Ollama 作为我们的高效模型服务引擎，因为它相对容易安装，并且可以在不同操作系统上通过命令行使用（尽管 LM Studio 也添加了一个非图形界面的 llmster 客户端，但我对它不太熟悉）。
顺便提一下，我与本文中提到的任何工具均无关联，但 Ollama 的一个优点是，它还可选地支持托管在云端的开放权重模型，包括目前最强的开放权重模型 GLM 5.2，该模型体积过大，无法在消费级硬件上本地运行。（当然，云端模型并非免费，但其订阅方案与 ChatGPT 和 Claude 类似；不过，能方便地在“本地”测试最新的顶尖开放权重模型，这一点仍然很不错。）
无论如何，Ollama 的设置非常简单，你可以在其下载页面找到官方的 macOS/Linux/Windows 下载说明。
安装后，我建议下载一个模型进行快速测试。例如，在 macOS 上，我们可以通过 Ollama 应用直接使用图形界面下载模型：
否则，也可以通过命令行完成，命令如下：
顺便提一下，上面提到的 qwen3.6:35b-mlx 是一个使用 Apple Metal 性能着色器的模型，即针对搭载 Apple 芯片的 Mac 进行了优化。我强烈建议在 Mac 上使用模型的 *-mlx 版本（如果可用）。
在 Linux 机器上，请使用非 MLX 版本：
然后，为了确保一切正常，你可以再次使用图形界面，或者从命令行启动 Ollama。
你可以通过 /bye 命令退出此会话。
如前所述，目前这个 Qwen3.6 35B-A3B 模型的最佳替代品是类似大小的 North Mini Code 1.0。
在决定是否使用 LLM 作为本地编码代理之前，通常最好先进行快速的速度和质量评估。这里，对于速度评估，我会关注 tokens/秒的性能。此外，我还会确保它在（非常）长的上下文中保持稳定，而这正是我们在代理式编码工作流中通常需要处理的（与简单的聊天机器人不同）。
当然，我们也不希望内存成本急剧增加。
你可以运行我的 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 上，我们可以运行：
请注意，这假设你已经按照上一节所述下载了相应的模型。此外，根据你的系统，如果你的 RAM 少于 30 GB，你可能需要使用更小的模型，例如 gemma4:e2b，它在长上下文下最多使用约 8 GB RAM。当然，还有很多更小的模型，但根据我的经验，它们作为本地编码代理表现不佳。）
请注意，对于模型而言，RSS RAM 报告在 macOS 上并不十分准确（尤其是对于利用 Metal 后端的 mlx 模型变体），我建议在运行期间也密切关注活动监视器中 Ollama 的 RAM 使用情况。在这种情况下，RAM 使用量在 20 到 29 GB 之间波动。
无论如何，底线是，对于 50k 上下文，Qwen3.6 和 North Mini Code 模型在最新的 Mac Mini 上使用高达 30 GB RAM，并以约 40 tok/sec 的速度生成输出，而在 DGX 上则为 30 tok/sec。
以下是不同运行的视觉摘要。
另一个有趣的问题是，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 是一个即插即用的全能型工具，设置时间极短，能轻松连接各种编码代理框架，并且更换和尝试不同模型也非常简单。
确认模型在本地运行速度足够快后，我建议快速评估一下建模性能。当然，市面上有很多标准化基准测试可以参考，甚至我们自己也可以运行。
通常，你可以在模型的技术报告或模型中心页面上找到相关基准测试的数值。我也觉得在 https://artificialanalysis.ai/models/ 上查看与其他模型的相对对比很有用。
根据上图，我们可以看到，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 测试中全部失败，这是一个强烈信号，表明它不太适合这类工具使用推理，即使它速度很快。请注意，这些失败不仅仅是格式问题。它似乎会选择错误的工具，在上下文足够时仍要求澄清等。我可能不会将其用作编码代理模型，除非是非常狭窄或高度受限的任务。
现在，在冗长的铺垫之后，我们回到主要话题——编码代理框架。正如本文开头所述，我们将使用 qwen-code（https://github.com/QwenLM/qwen-code）框架，因为 Qwen 模型已针对其进行了优化。
如果你熟悉 Claude Code，它基本上是一样的，但完全开源。不过，我还会在接下来的部分介绍如何将本地 Qwen3.6 模型连接到 Codex 和 Claude Code。
请注意，编码框架本身比单独的 LLM 强大得多。这就是我建议在运行内容和位置时要更加谨慎的原因。例如，在尝试新的（编码）代理时，我喜欢：
- 首先对（开源）代理代码库进行审计。
- 至少在单独的硬件（例如我的 DGX Spark）或单独的账户和/或虚拟环境中运行它。
关于审计，我建议检查数据共享/出口、文件权限的默认影响范围，以及针对提示注入的基本鲁棒性。下图试图总结主要要点。
类似的担忧也适用于本地模型服务引擎（例如 Ollama）。然而，编码代理需要更多关注，因为它们可以直接读取你机器上的数据并操作文件。
要进行基本审计，我建议如下：
- 克隆仓库：
- 使用你之前信任的代理（例如 Codex 中的 GPT 5.5 或 Claude Code 中的 Opus 4.8）通过聚焦提示进行审查。类似以下内容：
你正在审计 ./qwen-code，之后我才会在机器上安装或运行该代理。
仅关注已安装代理带来的实际本地机器风险，以及产生这些风险的代码路径：
安装脚本和包生命周期钩子
代理执行的 shell 命令
运行时的文件读/写边界
密钥处理和环境变量继承
仓库文件、项目指令和工具输出如何影响代理
MCP、插件、扩展或工具集成
网络调用和遥测
安装后的更新机制
终端转义/输出处理
数据出口和数据驻留
忽略安装所严格必需的互联网下载，检查当我通过 Ollama 使用本地模型时，已安装的代理是否可以将提示、文件、遥测、日志、标识符或元数据发送到远程服务器。忽略云端模型配置。
不要仅凭项目所有者推断风险。识别控制网络行为的具体端点、SDK、默认提供商、环境变量、配置默认值和文档，包括在外国或由第三方公司运营的任何端点。
不要进行广泛的风格审查。不要重构。请提供：
高风险发现，附带文件/行引用
中等风险问题
网络/数据出口发现，包括任何外国、第三方或与中国相关的端点或默认设置
在审查完成前应避免运行的命令
可降低本地机器风险的设置或环境变量
简短建议：可在沙箱中安全测试、可安全使用，或不要运行
对于每一项，说明这是编码代理的预期行为，还是本质上比 Codex 或 Claude Code 风险更高。
以下是主要发现的摘要（因为完整报告可能有点枯燥，且对于本文来说篇幅过长）：
-
本地执行 Qwen Code 可以通过其 shell 工具在我们的机器上运行 shell 命令，但除非启用
--yolo等宽松模式，否则有严格的批准控制。这对于编码代理来说是预期的，实际上也是它在实践中发挥作用的原因。但当然，如果在非沙箱环境中运行或包含完整的环境变量（含密钥），它就会变得有风险。 -
数据出口 即使使用本地 Ollama，Qwen Code 也可以将使用遥测和元数据发送到阿里云端点，除非禁用使用统计和遥测（下文详述）。这比纯本地设置风险更高，因为模型提示可能保留在本地，但会话 ID、工具元数据、模型信息和本地基础 URL 元数据仍可能离开机器。但同样，这在各类工具中也很常见（是的，Codex 和 Claude 也会这样做）。
-
文件和密钥边界 默认情况下，工作区文件可读，而写入通常需要批准，并包含一些覆盖保护。这是良好且标准的代理实践。
-
提示注入面 仓库指令、工具输出、MCP工具、扩展和项目配置都可能影响智能体的行为。通过上述审批关卡可以减少提示注入攻击。这对编码智能体来说是正常的，但默认情况下应将不受信任的仓库视为具有敌意，因为它们可能引导智能体读取文件、运行命令或通过已批准的工具发送数据。
关于第2点中主要的隐私问题，大部分可以通过自定义 ~/.qwen/settings.json 文件并包含以下内容来解决：
"general": { "enableAutoUpdate": false } 设置是一种权衡。安全修复不会自动安装，但我更倾向于明确控制更新时间，而不是让工具在后台拉取并应用新代码。
顺便提一下，cline（https://github.com/Cline/Cline）、Codex（https://github.com/openai/codex）和Claude Code也有类似的遥测数据共享默认设置，需要显式禁用。
（注意：Claude Code没有其代码库的官方开源版本，这使得信任它更加棘手，而且它似乎确实会向Anthropic和Datadog发送数据。）
无论如何，总体来看，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以及
然而，运行上述命令假设发布的工件与我们刚刚在GitHub仓库中审查的代码相匹配。如果我们格外谨慎/多疑，也可以从GitHub仓库自行构建。但请注意，这会更手动/更混乱（我建议逐个执行命令，而不是将整个代码块复制粘贴到终端中）：
完成安装后，我们现在可以通过终端中的qwen命令启动Qwen-Code客户端，完成设置并连接到本地提供的LLM。
为此，在运行 qwen 命令后，我们选择“自定义提供商”，如下所示。
Ollama 使用 OpenAI API 标准。因此，接下来我们按照屏幕上的设置指南，选择“兼容 OpenAI”选项。
接下来，我们需要提供正在运行的 Ollama 应用程序的 API 端点，该应用程序服务于我们的本地 LLM。通常默认是本地地址。我们输入 http://127.0.0.1:11434/v1（包含 /v1），因为这是兼容 OpenAI 的基础 URL。
http://127.0.0.1:11434/v1。接下来，我们输入 ollama 作为我们的自定义提供商。
ollama 作为本地自定义提供商的 API 密钥占位符。接下来，我们可以选择可用的模型。这些是我们通过 ollama pull 下载的模型。您可以只输入一个模型，或用逗号分隔输入多个模型。您可以通过 ollama list 再次确认已下载的模型列表。顺便提一下，您之后随时可以轻松添加更多模型（我将在完成设置后解释）。
我们快完成了！在第 5/6 步中，我们当然要选择“启用思考”模式，这会导致更高的令牌使用量，但更好的问题解决能力是值得的。
/model 切换模型。顺便提一下，正如我之前所说，从 ollama 添加新模型相对容易。一旦通过 ollama pull 拉取新模型，你就可以将其作为新条目添加到 ~/qwen/settings.json 中。具体操作是：将现有条目复制粘贴到文件中，然后将 “id” 和 “name” 改为 Ollama 模型的名称。
~/qwen/settings.json 配置文件来添加新的 ollama 模型。这里，"xxxxx" 是 ollama 模型的名称，例如 "nemotron-3-nano:30b"。顺便提一下，为了不时更新 qwen-code 工具，如果我们采用 git clone 和本地构建的方式，可以拉取最新的 GitHub 快照并按如下方式更新：
现在我们已经拥有了一个功能完善的本地编码代理，问题是：它的表现如何？它是否真的足够好，能胜任我的任务？当然，这方面有基准测试，但在我看来，没有什么比在自己的工作流程中亲自尝试更有效了。换句话说，这基本上意味着花一两天时间使用它，来判断它是否达到你的标准。
我还建议整理一小套能反映你常见编码代理使用场景的任务。如果你在处理某个项目时遇到了特别有挑战性的任务，将其添加到这个任务集中以便未来评估新模型，也不失为一个好主意。
为了举例说明我的意思，我在 GitHub 上分享了一套相对较小、简单且通用的任务集，我们可以用它来测试代理：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 的结果。
我们可以看到，Qwen3.6 和 North Mini Code 35B-A3B 模型都解决了 5 个问题中的 4 个。Gemma 4 E2B 失败率很高。出于好奇，我还添加了稍旧一点的 Nemotron 3 Nano 模型。它的大小和计算性能与前面提到的 Qwen 和 North 模型相似，表现也同样出色。
在配置好本地编码代理（且文章已超过5000字）后，这或许是个合理的停笔之处。不过作为额外福利，我觉得简要补充一下Codex和Claude Code的说明也挺有意思。
遗憾的是，据我所知Codex UI不支持非OpenAI模型，但我们可以通过Codex CLI来运行Ollama模型。
如果你尚未安装OpenAI Codex CLI，可以像安装qwen-code那样从其开源GitHub仓库获取并安装：https://github.com/openai/codex（没错，Codex CLI是开源的！）
我就不详细列出命令了，建议查阅该仓库的README获取官方安装说明。（克隆仓库并像qwen-code那样进行审计也是个不错的主意。）
安装完成后，有多种方式启用本地模型。在我看来，最便捷的方式是在已有的~/.codex文件夹内创建一个独立的配置文件~/.codex/ollama.config.toml，并设置一些默认选项：
这样，我们仍然可以使用codex启动常规的“Codex with GPT 5.5”模式，并通过codex --profile ollama使用我们的Ollama模型。
当重新运行“代理能力评估”部分的测试用例时，令我惊讶的是，Qwen3.6在Codex上的表现实际上比其“原生”的Qwen-Code编码框架更好，如下所示。
虽然这只是一个小型基准测试集，但它表明使用Codex作为通用编码代理框架或许并非坏事。
当然，还有广受欢迎的Claude Code代理框架，我们也可以用它来封装本地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 方式，因为它能让我对运行机制等有更深入的了解和掌控。
然而，作为用户，感觉 Claude Code 得出解决方案所需的时间要长得多。它可能消耗了更多的 token。因此，下面我额外查看了所有三个框架的 token 使用情况。
我们可以看到，Claude Code 平均使用的 token 最多，而 Codex 最少。
在小型智能体能力评估基准测试中，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 更少，但它也几乎无法完成所有任务，这很可能是因为其工具调用能力不足，导致任务提前中断。
作为参考，下面再次给出汇总的任务成功率。
总之，这里的要点是：如果更多的 token 能帮助模型-框架组合解决更多（且更复杂）的问题，那很好！但如果两个框架的任务成功率相同，而其中一个框架使用的 token 少 50%（例如 Codex 对比 Claude Code），那将是一个巨大的优势，因为它能让任务运行速度快一倍。
然而，这里一个重要的注意事项是：任务正确性是一个必要条件，但它无法衡量代码质量和可读性，而这些是很难自动评估的。
PS：我尝试分析了Claude Code为何消耗更多Token，发现差异主要来自输入Token而非输出Token。也就是说，Claude并没有写出两倍的内容。日志显示，Claude在每次交互中反复向模型回传更多上下文，包括历史消息、工具调用、命令输出和文件内容。例如，某次Claude运行在25轮交互中使用了约57.8万输入Token，但输出Token仅约4500个。因此，合理的解释是：在多步骤代理运行过程中，Claude的框架会累积或计入更大的提示历史记录。
到目前为止，我们讨论的所有配置都假设本地LLM与编码框架运行在同一台机器上。
但如果我们对编码代理框架建立了一定信任，希望在主Mac上使用它，而模型本身托管在另一台机器（例如DGX Spark）上呢？
在我看来，最佳（或最便捷）的方案是从Mac到DGX建立SSH隧道。
首先，建议退出Mac上的Ollama，或将下方配置中的11434改为其他端口。
假设我们退出了Mac上的Ollama应用，请检查以下命令返回空输出，以确认Ollama不可用：
然后在Mac的终端窗口中运行以下命令：
该命令表示我们以用户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模型：
如果返回了DGX上的模型列表，那么你的Mac工具就可以像使用本地服务一样使用DGX的Ollama服务器。
然后，像之前一样直接使用Qwen Code和Codex即可。
对于通过ollama launch claude使用Claude，关键是Mac端的ollama命令必须能访问隧道端点。如有需要：
我们重点介绍Qwen Code、Codex和Claude Code，因为它们最直接适用于编码代理工作流。OpenClaw和Hermes同样功能强大，但它们是更通用的代理框架，更适合需要单个代理协调工具、应用、浏览器、终端和长期运行工作流的场景。
对于编码工作，我建议先尝试Qwen Code、Codex或Claude Code（此外还有许多其他有趣的编码框架，如OpenCode、Cline、Pi和Noumena Code）。而OpenClaw和Hermes更适合作为编码之外的后续探索选项，而非本地编码代理配置的首选基线。
这是一篇信息量很大、配置步骤很多的长文。如果说有几个核心要点，那就是：运行本地编码智能体的关键，不在于机械化的设置流程，而在于运行时的各种考量。也就是说，最重要的不是安装某个特定的工具，而是要理解模型服务层、智能体框架、权限模型，以及如何评估这套方案是否真的能可靠地解决编码任务。
当然，GPT 5.5 和 Opus 4.8 目前仍然优于在 Mac 或 DGX Spark 上运行的较小开源模型。但新一代 30-35B 参数的混合专家模型（例如 Qwen3.6、North Mini Code 和 Nemotron 3 Nano）已经非常、非常强大，足以胜任许多任务。而且，通过 Pro 订阅，它们的 Token 生成速度与 GPT 5.5 相同，因此不一定会拖慢你的工作流程。
在设置本地智能体时，除了模型本身，另一个主要考量是选择哪个框架。普遍的看法是，模型通常针对特定框架进行了更多优化（例如，Qwen3.6 在 Qwen Code 中的表现可能优于在 Claude Code 中）。不过，根据小规模的智能体评估，这未必是事实（但这只是一个非常小的基准测试，所以请谨慎看待）。因此，如果你对另一个框架（如 Codex 或 Claude Code）更熟悉，已经形成了肌肉记忆，那么直接把模型放进那个框架里试试，或许也是个不错的主意！
总之，希望这篇文章对你有用，并激发了你对摆弄开源模型的兴趣。它们正变得越来越强大，而且出于某种说不清道不明的原因，在本地运行模型本身就是一件很有趣的事。
如果你想亲自尝试这些基准测试，本文使用的代码和小型评估任务可在此处获取：https://github.com/rasbt/local-coding-agent-evals
另外，我的新书《从零开始构建推理模型》已经付印并开始发货。我本想发张照片，但还要等三天才能收到。
如果你喜欢我之前写的《从零开始构建大型语言模型》这本书，那么这本新书本质上就是它的续作，从零开始实现了推理时扩展技术和强化学习算法。
如果你想支持更多像这样的长篇深度文章，可以考虑成为付费订阅用户。这能帮助我继续独立撰写这些深度内容，并分享配套的代码、图表和实验。