外网大神博士 Sebastian Raschka, PhD 最近发了一篇文章来讲述《在本地编码工具中使用开放权重模型作为Claude代码和Codex订阅的替代方案》刚发布就火爆外网如果你不知道 Sebastian Raschka, PhD那你一定知道《从零开始构建大型语言模型》 这本书没错他就是这本书的作者。下面我就以他新推出的这个方法给大家做一个讲解下面是原文目前在本地编码工具中使用开放权重模型作为Claude代码和Codex订阅的替代方案过去很多人联系作者询问作者本地的代理协议栈以及作者是如何搭建本地代理协议栈的。所以作者觉得做一个关于如何用开源工具和开权级大型语言模型搭建本地编码代理的小教程可能会很有用。本文是关于如何搭建一个完全本地化栈的生产准备编码代理的教程。我们将使用本地服务的LLM和本地编码框架这些工具可以读取文件、编辑、执行命令并验证更改如上图所示。在这里我们可以把LLM看作是提供推理和代码生成的引擎。而周围的线束则提供了运行环境使LLM能够在本地项目中进行有意义的编码工作。为什么是本地化对于许多编码工作流程来说本地配置是对 Codex 中的 GPT 或 Claude Code 中的 Opus 等专有服务的有趣替代方案。本地配置透明、可检查且除了硬件和电力费用外免费运行。它完全由你控制你可以随意修改编码线束。而且这非常有趣1. 引言作者说因此本文将搭建并使用像Codex和Claude Code这样的热门线束与开放权重模型并探讨使用模型专用线束如Qwen Code用于Qwen 3.6是否带来了额外优势。当然还有更多线束比如OpenCode、Cline、Pi和Noumena Code但他以为大多数人已经有Codex或Claude Code的肌肉记忆这让切换到开放权重模型更顺畅一些。他得承认目前他主要还是在Codex和Claude Code之间交替使用也是为了跟上不断添加的新工具和功能。而且套餐限制尤其是Codex依然非常宽松到目前为止他还没担心过费用。不过他也用本地解决方案一段时间了既是为了测试也因为拥有和使用完全本地化的配置让他感到很开心相比于专有服务。无论哪种情况本地解决方案每天都变得越来越有吸引力。其中一个方面是成本。如果你有硬件它们几乎可以免费运行。当然还有隐私方面的问题。比如在整理和处理他的收据时他更愿意用本地模型来采集而不是把数据发送给OpenAI或Anthropic。然后如果我们考虑到Anthropic最近在限制其旗舰模型在LLM研究中的性能专有服务可能会随着时间变得更严格或许最好能接受开放权重替代品作为备选方案。还有许多类似的原因和使用场景。你使用本地大型语言模型和编码工具的动机可能包括如果你达到订阅套餐限制成本可预测且固定并且对API价格变化享有免疫。可重复性;有时候模型升级比如GPT 5.4 - GPT 5.5 - GPT 5.6能更可靠地解决所有问题。然而这也可能破坏现有工作流程。在经典的飞机飞行场景下网络慢或没有网络或者在树林小屋参加编程/写作静修时无需Starlink订阅即可离线使用。而且可能还有其他几个。因此本文将搭建并使用像Codex和Claude Code这样的热门线束与开放权重模型并探讨使用模型专用线束如Qwen Code用于Qwen 3.6是否带来了额外优势。当然还有更多线束比如OpenCode、Cline、Pi和Noumena Code但我以为大多数人已经有Codex或Claude Code的肌肉记忆这让切换到开放权重模型更顺畅一些。2. 编码代理束概述大多数编码代理束遵循类似原则具备或多或少相同的功能和特性。然而实现细节可能有所不同某些大型语言模型通常主要针对特定线束进行优化。当然许多开放权重的大型语言模型比如GLM 5.2会运行Claude代码等。然而如果LLM开发者也开发了编码束可以相对安全地假设他们的模型优先为自己的束流器优化同时也支持其他束。这里我主要打算使用 Qwen 3.6 和 Qwen-Coder 编码客户端。不过我还会介绍其他将本地LLM与其他代理约束结合使用的方法比如Claude Code、Codex以及越来越流行的Cline但稍后会详细说明。我主要使用 Qwen Code 来处理 Qwen 模型的原因是它是开源的类似于Codexhttps://github.com/openai/codex但不同于Claude Code;Qwen 模型专门针对 Qwen-Code 框架进行了优化更多信息见下文;我可以在同一台机器上同时运行Codex用最新的GPT模型和Qwen-Code同时用本地的Qwen模型而不必手动在模型间切换。关于上述第二点即Qwen模型在Qwen代码中表现更好Nvidia的Polar Agentic RL在Any Harness at Scale2026年5月论文中有一个基准测试显示Qwen3.5-4B基础模型在该Qwen代码框架中无论是在Polar-RL训练前后的编码性能最佳我在下面也包括了这一点。上表中的基准测试是针对较旧的Qwen 3.5型号我猜最新的Qwen 3.6型号在Qwen代码中表现更好。不过Pihttps://github.com/earendil-works/pi似乎也是我未来需要尝试的一个非常有趣的候选。顺便说一下Qwen3.6 35B-A3B大约需要22GB下载大约需要30-40GB内存并且在搭载M4的Mac Mini和DGX Spark上运行速度都相当快。根据Cohere六月早些时候分享的最新基准数据它目前是同规模类别中本地最好的模型。如上所述Qwen3.6 35B-A3B在该尺寸级别中几乎占据主导地位仅有一个基准。不过话说回来Qwen Code 是一个通用的线束也支持其他类型的模型。比如我们也可以把北方小码或Gemma 4连成Qwen码。在架构上Qwen3.6 35B-A3B模型采用了类似于Qwen3-Coder和Qwen3.5的混合关注。我在《超越标准大型语言模型》中写过更多相关内容。另外如果你不想用Qwen3.6Cohere的North Mini Code可能是目前这个规模级别中最有趣、最有能力的替代品。我也会在下一个本地LLM设置部分介绍这个模型。3. 本地LLM搭建无论我们使用哪种代理框架Qwen-Code、Codex 还是 Claude Code我们都必须先搭建本地大型语言模型比如 Qwen3.6 35B-A3B。有几个选项比如 Ollama、LM Studio、vLLM、SGLang、MLX 等可以本地服务模型。你知道从我的《Build A Large Language Model从零开始》和《Build A Reasoning Model从零开始》项目中我喜欢自己编写这些代码。从零开始实现模型的好处是我们了解整个技术栈同时还能修改、进一步训练和微调它。不过我们只寻找一个在推理速度和资源需求方面经过高度优化的模型服务框架因为目前不打算进行任何训练或微调。我们也可以额外一步将我们自己从零开始微调的模型转换并导入这些高效的服务堆栈但这超出本文范围。在本次教程中我们将使用 Ollama 作为高效的模型服务引擎因为它相对容易通过命令行在不同操作系统中安装和使用虽然 LM Studio 也添加了非 GUI 客户端但我对它不太熟悉。llmster顺便说一句我与本文提到的任何工具没有任何关联但 Ollama 的一个好处是它们还可选地支持托管在云端的开放权重模型包括目前最强的开放权重模型 GLM 5.2它太大无法在本地消费级硬件上运行。当然云模型并非免费但订阅计划与ChatGPT和Claude类似;不过这个选项能方便地“本地”测试最新的开放权重模型还是挺好的。总之设置 Ollama 很简单你可以在他们的下载页面找到官方的 macOS/Linux/Windows 下载说明 。安装后我建议下载一个模型进行快速测试。例如在macOS上我们可以直接通过GUI使用ollama应用下载模型否则也可以在命令行通过以下方式实现ollama pull qwen3.6:35b-mlx顺便说一句上述qwen3.635b-mlx是使用苹果Metal性能着色器优化的型号即针对苹果芯片的Mac优化。我强烈建议使用适用于Mac的*-mlx版本模型如果有的话。在Linux机器上使用非MLX版本ollama pull qwen3.6:35b然后为了确保它能正常工作你可以重新使用图形界面或者从命令行启动 Ollama 。你可以通过命令退出这个会话 。/bye如前所述目前Qwen3.6 35B-A3B型号的最佳替代品是尺寸相近的North Mini Code 1.0。4. 简单速度性能评估在决定是否将LLM作为本地编码代理之前通常进行快速的速度和质量评估是个不错的主意。在这里速度评估时我会关注代币/秒数的表现。此外我还会确保它在非常长的上下文中保持稳定这正是我们在代理编码工作流程中通常遇到的而非简单的聊天机器人。当然我们也不希望内存成本爆炸式增长。你可以用我的 ollama_speed_memory_bench.py 脚本快速检查一下。简而言之它会向 Ollama 模型发送不同的提示从1000到50,000字不等并默认要求其生成最多8k个代币。它报告了简单的统计数据如来自 Ollama 提示词评估指标的预填充速度、输出令牌时序生成速度以及 Ollama 过程的内存使用情况以及 NVIDIA GPU 内存如有时。例如如果你从 https://github.com/rasbt/local-coding-agent-evals 下载或克隆脚本可以运行以下操作大约需要5分钟qwen3.6:35b-mlxuv run speed-memory-benchmark/ollama_speed_memory_bench.py--modelqwen3.6:35b-mlx在 Linux 上我们可以运行uv run speed-memory-benchmark/ollama_speed_memory_bench.py--modelqwen3.6:35b请注意这假设你已经按照上一节的解释下载了相应的型号。另外根据你的系统如果你的内存少于30GB可能需要使用像gemma4e2b这样较小的型号在长时间上下文下内存消耗最多可达8GB。当然也有很多小型模型但以我的经验来看它们作为本地编码代理表现相当差。请注意对于模型来说macOS上的RSS RAM报告并不非常准确尤其是使用Metal后端的mlx型号我建议在运行过程中关注活动监视器的Ollama的RAM使用情况。在这种情况下内存使用量在20到29GB之间波动。总之对于5万上下文Qwen3.6和North Mini Code型号使用最多30GB内存输出速度在最近的Mac Mini上大约是40 tok/secDGX上大约是30 tok/sec。以下是不同系列的视觉总结。另一个有趣的问题是Qwen 35B-A3B与同尺寸的Cohere North Mini型号相比如何如果考虑类似的量子化模型上面我用的是Qwen3.6默认它们相当相似尽管North Mini整体上可能略领先如下所示。总之归根结底我认为任何超过20-30 tok/sec的速对本地代理来说都相当合理。 这与GPT 5.5带“高”推理的速度差不多。在这种情况下两个型号都很容易通过杠杆。顺便说一句我个人几乎完全用DGX Spark运行代理因为我不想让Mac Mini过热而且我也想留出内存做其他任务。当然总有方法通过不同的框架除了Ollama、量化、MTP等来优化。不过Ollama 是一个非常实用的全能工具设置时间极短可以轻松连接各种编码代理框架切换和尝试不同模型也非常简单。5. 简单基准绩效评估在确认模型足够快以方便本地工作后我建议做一次快速的建模性能评估。当然市面上有许多标准化基准我们可以参考甚至自己运行。通常你可以在模型的技术报告或模型中心页面找到相关基准的数值。通常我也觉得在 https://artificialanalysis.ai/models/ 上与其他型号做相对比较很有帮助。根据上图我们可以看到Qwen3 35B-A3B的能力远强于Gemma 4的E4B和E2B型号。请注意人工智能指数的数字会随着时间不断变化因为他们会交换基准并更新权重因此没有“绝对”的数字可以作为判断哪个模型“足够好”的参考点。相反我会把一个新的、有趣的模型和你之前用作锚点或参考点的模型做比较。除了标准基准测试外我还建议你整理一组与你相关的个人任务快速检查这个模型是否适合你想让它执行的任何类型的工作。以下是一组推理和代码相关问题的输出这些问题也测试模型的工具调用能力。在这里模型返回工具调用但不执行代码本身。➜ uv run ollama_hard_reasoning_bench.py--modelqwen3.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--modelnorth-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: line2column1(char235)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--modelgemma4: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: expectedcode/tool-reasoning-benchmark/ollama_tool_reasoning_bench.py, gotcode/tool-reasoning-benchmark/personal_tool_reasoning_tasks.jsonlFAIL 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:35b3/5另一方面 失败 则强烈表明它不适合这种工具使用推理即使它很快。注意失败不仅仅是格式问题。看起来它选错了工具明明有足够的上下文却要求澄清等等。我可能不会把它当作编码代理模型除非任务非常狭窄或受限。gemma4:e2b0/56. 代理代码库审计现在在做了这么长的前言介绍本地LLM之后让我们回到主要话题——编码代理束带。如本文开篇所述我们将使用qwen代码https://github.com/QwenLM/qwen-code框架因为Qwen模型已针对此进行了优化。如果你熟悉Claude Code它基本上是同样的东西但完全开源。不过我也会在接下来的章节中讲解如何将本地的 Qwen3.6 模型连接到 Codex 和 Claude Code。需要注意的是编码束比单靠LLM的能力要强得多。这时我建议你更谨慎选择使用什么和在哪里跑。比如在尝试新的编码代理时我喜欢先对开源代理代码库做审计。至少要在不同的硬件比如我的DGX Spark上运行或者在我的机器上用独立的用户账户和/或虚拟环境运行。关于审计我建议查看数据共享/泄露以及文件权限的默认传播半径以及对提示注入的基础鲁棒性。下图试图总结主要观点。类似的担忧也适用于本地模型服务引擎例如 Ollama。然而编码代理需要更多的关注因为它们可以直接从你的机器读取数据并操作文件。进行基础审计时我建议以下方法克隆仓库gitclone https://github.com/QwenLM/qwen-code.git请你之前用过的信赖代理比如Codex中的GPT 5.5或Claude Code中的Opus 4.8用一个针对性的提示来审阅。大致如下你是在我安装或运行代理之前审计 ./qwen-code。只关注安装代理及其代码路径带来的实际本地机器风险安装脚本和包生命周期钩子代理执行壳命令运行时文件读写边界秘密处理与环境变量继承仓库文件、项目说明和工具输出如何影响代理MCP、插件、扩展或工具集成网络通话与遥测安装后的更新机制终端转义/输出处理数据出口与数据驻留不考虑安装时必须的互联网下载检查安装代理是否能在我通过 Ollama的本地模型时向远程服务器发送提示、文件、遥测、日志、标识符或元数据。忽略云模型配置。不要仅从项目所有者身上推断风险。确定具体的端点、SDK、默认提供者、环境变量、配置默认和控制网络行为的文档包括任何在国外或第三方公司运营的端点。不要做宽泛的综述。不要重构。农产品带有文件/行引用的高风险发现中等风险问题网络/数据出口发现包括任何外国、第三方或中国关联的端点或默认情况我应该避免运行的命令直到审核降低本地机器风险的设置或环境变量简短建议安全测试沙盒安全使用或者不要运行对于每个项目说明它是编码代理的预期行为还是本质上比Codex或Claude代码风险更高。以下是主要发现的摘要因为完整报告可能有些无聊且篇幅过长不适合本文本地执行的 Qwen Code 可以通过其 shell 工具在我们的机器上运行 shell 命令但除非启用了允许模式否则有严格的审批控制 。这对编码代理来说是预期的这实际上也是它在实际中有用的原因。但当然如果是非沙盒运行或包含秘密的完整环境风险就会很大。–yolo数据出口即使本地 Ollama 使用Qwen Code 也能向阿里巴巴/阿里云终端发送使用遥测和元数据除非禁用使用统计和遥测下文会详细说明。这比仅本地设置风险更大因为模型提示符可能仍留在本地但会话ID、工具元数据、模型信息和本地基URL元数据仍可能离开机器。但同样这在各种工具中也很常见是的Codex和Claude也这样做。文件和秘密边界Workspace 文件默认可读而写入通常需要批准并包含一些覆盖保护。这是良好的标准经纪人操作。提示注入表面仓库指令、工具输出、MCP工具、扩展和项目配置都会影响代理的行为。通过上述批准门可以减少即时注入攻击。这对编码代理来说是正常的但不受信任的仓库应默认被视为敌对因为它们可以引导代理读取文件、执行命令或通过批准的工具发送数据。关于第二点中的主要隐私问题大部分可以通过 以下内容的自定义修复~/.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 }顺便说一句clinehttps://github.com/Cline/Cline、Codexhttps://github.com/openai/codex和Claude Code都有类似的遥测数据共享默认设置需要明确禁用。注意Claude Code 没有官方的开源代码库这使得信任它更加困难而且它似乎同时向 Anthropic 和 Datadog 发送数据。无论如何总体来看Qwen代码遵循标准实践截至目前为止编码代理没有特别的非标准问题。7. Qwen代码建立如果我们接受报告的发现和风险就我个人而言我没有看到任何危险信号我们现在就可以继续安装并将本地的Qwen3.6-35B-A3B模型连接到Qwen代码以及后续章节中的Codex和Claude代码。如前所述我更倾向于在另一台机器上尝试并运行编码代理这些代理可以读取和编辑本地文件我用的是DGX Spark也可以是独立的Mac或Linux工作站。或者我会在虚拟机里运行或者单独设置一个macOS或Linux用户账户作为一个实用的折中方案。我听一些朋友说他们也会租用服务器比如Linode或Heroku用于调试。不过与其每月为一台功能不错的机器支付托管费用我可能更愿意买一台相对便宜的200-500美元硬件盒甚至一台旧的退役笔记本运行本地线束然后使用更强的开放权重模型通过Ollama云模型、OpenRouter等托管在云端如果你想找GPT或Claude的替代方案。总之我们安装Qwen代码吧。列出的选项包括例如curl-fsSLhttps://qwen-code-assets.oss-cn-hangzhou.aliyuncs.com/installation/install-qwen-standalone.sh|bash以及npminstall-gqwen-code/qwen-codelatest然而运行上述命令假设发布的工件与我们刚刚在 GitHub 仓库中审查的代码相符。如果我们更谨慎/多疑也可以自己从GitHub仓库构建它。不过要注意这更手动且更麻烦我建议一次执行一个而不是把整个区块复制粘贴到终端里# Go to your development foldercd~/Developer# Clone the Qwen Code GitHub repositorygitclone https://github.com/QwenLM/qwen-code.git# Enter the cloned repositorycdqwen-code# Install JavaScript dependenciesnpminstall# Build the CLI output in the local dist/ foldernpmrun build# Create a user-level bin directory if it does not already existmkdir-p~/.local/bin# Create a qwen wrapper that runs the CLI from this source checkout.# Keep ~/Developer/qwen-code in place, since this wrapper points into it.cat~/.local/bin/qwenSH #!/usr/bin/env sh exec $HOME/Developer/qwen-code/scripts/cli-entry.js $ SH# Make the wrapper executable.chmodx ~/.local/bin/qwen# Make qwen available in the current shell session.exportPATH$HOME/.local/bin:$PATH# Verify that the qwen command is found and prints a version.qwen--version安装完成后我们可以通过终端的qwen命令启动Qwen代码客户端完成设置并连接到本地服务的LLM。为此运行 qwen 命令后我们选择“自定义提供者”如下所示。Ollama 采用了 OpenAI API 标准。接下来我们按照屏幕上的设置指南选择“兼容 OpenAI”选项。接下来我们需要提供运行中的 Ollama 应用的 API 端点该应用服务于本地 LLM。通常是当地的http://127.0.0.1:11434默认地址。我们输入包括 /v1因为那是兼容 OpenAI 的基础 URL。http://127.0.0.1:11434/v1接下来我们以 定制供应商身份进入。ollama接下来我们可以选择可用的模型。这些是我们通过 .下载的。 你可以输入单个型号也可以用逗号分隔多个型号。你可以通过 .再次核对已下载的模型列表。顺便说一句你以后总可以轻松添加更多模型完成设置后我会详细说明。ollama pullollama list我们快完成了在第5/6步我们当然选择了“启用思考”模式这会导致代币使用率更高但更好的问题解决能力是值得的。基本上就是这样。第6步基本上是一个复习步骤我们可以通过按“回车”来确认。恭喜你现在应该已经有一个完全本地化的LLM工作流程了。它的用法基本和Claude Code类似你可以用/命令来实现各种功能。例如你可以通过命令切换型号 如下所示。/model顺便说一句正如我之前提到的从ollama添加新模型相对容易。一旦你通过 拉取一个新模型你可以将其作为新条目添加到 。这里只需复制粘贴一个已有的条目到文件中并将“id”和“name”改成Ollama模型名称的名称。ollama pull~/qwen/settings.json顺便说一句为了偶尔更新 qwen 代码工具如果我们使用 git 克隆和本地构建路线可以拉取最近的 GitHub 快照并按如下方式更新# Go to the local Qwen Code source checkoutcd~/Developer/qwen-code# Fetch the latest changes from GitHubgitpull# Install or update dependencies if package files changednpminstall# Rebuild the local CLInpmrun build# Verify the updated CLIqwen--version8. 代理能力评估现在我们有了完全可用的本地编码代理问题是它的表现如何它是否足够满足我的任务当然这有基准测试但在我看来没有什么比亲自在某些工作流程中尝试更重要。换句话说这意味着用一两天判断它是否符合你的标准。我还建议你编排一组反映你常用编码代理使用的任务。如果你在某个项目中遇到特别有挑战性的任务加入这套任务以评估未来的模型也不错。举个例子我在GitHub上分享了一组相对较小、简单且通用的任务可以用来测试代理https://github.com/rasbt/local-coding-agent-evals/tree/main/agent-problem-pack。这基本上是本地LLM设置部分任务的扩展。关于如何运行这些程序的详细信息见GitHub READMEhttps://github.com/rasbt/local-coding-agent-evals/tree/main/agent-problem-pack#quick-start-running-benchmarks-manually。以下是在Qwen-Code中测试的不同大型语言模型的结果。正如我们所见Qwen3.6和North Mini 35B-A3B型号都能解决5个问题中的4个。Gemma 4 E2B经常失败。出于好奇我还添加了稍早的Nemotron 3 Nano型号。它的尺寸和计算性能与前面提到的Qwen和North型号相似性能也相当不错。9. 兵籍书设定在设置好本地编码代理以及文章超过5000字后这里大概是个合理的停笔点。不过作为额外奖励我觉得为了完整性添加简短的Codex和ClaudeCode注释可能会很有趣。遗憾的是据我所知Codex UI不支持非OpenAI模型但我们可以用Codex CLI来运行我们的Ollama模型。如果你还没安装OpenAI Codex CLI可以从他们的开源GitHub目录里下载并安装类似qwen-code的代码https://github.com/openai/codex是的Codex CLI是开源的我就不详细列出命令了建议你直接查看仓库的README获取官方说明。克隆仓库并运行类似qwen代码的审计也是个不错的主意。安装后有多种方式可以启用本地模型使用。我认为最方便的方法是在现有文件夹内设置一个单独的配置 并设置一些默认选项/.codex/ollama.config.toml/.codexmodelqwen3.6:35bmodel_providerollamamodel_reasoning_efforthighpersonalitypragmatic[projects./home/rasbt]trust_leveltrusted然后我们仍然可以用 常规的“用 GPT 5.5 编写 Codex”模式并通过 Ollama 模型 。codexcodex --profile ollama在重跑代理能力评估部分的测试用例时令我惊讶的是Qwen3.6 通过 Codex 实际表现优于其“原生”Qwen-Code 编码框架如下所示。虽然这只是一小部分基准测试但这表明将Codex作为通用编码代理工具或许并不是个坏主意。10. Claude代码设置当然还有一种流行的Claude Code代理框架我们可以用它作为本地大型语言模型的框架。虽然非常受欢迎且功能强大但这可能是我最不喜欢的本地配置选项因为代码库是专有的。这也意味着我们无法轻易检查和/或禁用Anthropic的数据记录做法。如果你的机器上还没安装Claude Code建议查看官方文档推荐的安装命令https://code.claude.com/docs/en/quickstart。Claude Code 本身并不与 Codex 提供相同的本地提供者配置路径。然而Ollama 通过 提供集成https://docs.ollama.com/integrations/claude-codeollama launch claude也就是说我们可以执行 Claude代码的线束并用Ollama模型运行。ollama launch claude顺便说一句这对通过 的 Codex 也适用但我个人更喜欢 我们之前讨论的路线因为它让我对机制有更多的洞察和控制。ollama launch codexcodex --profile ollama然而作为用户感觉 Claude Code 需要更长时间来找到解决方案。它的代币使用率可能高得多。所以下面我还探讨了三种线束的代币使用情况。正如我们所见Claude Code 平均使用最多的标记Codex 最少。在小型代理能力评估基准测试中Qwen和North Mini Code型号也获得了5分满分5分即使是小型的Gemma 4型号也表现尚可有趣的是我们还可以看到代币的使用主要由框架驱动而非大型语言模型本身。也就是说在这三款能够解决几乎全部5个任务的大型语言模型中它们使用的token数大致相同例如Qwen3.6在Claude Code中使用时其token数大致与North Mini Code和Nemotron 3 Nano相同。只有Gemma 4使用更少的令牌但几乎所有任务都失败可能是因为工具调用能力不足任务会提前中断。供参考下面再次展示了任务成功率的总结。总之这里的结论是如果更多的代币帮助模型-约束组合解决更多且更复杂的问题那很好但如果我们有两个任务成功率相等的束带且使用标记数减少50%例如Codex比Claude Code少那就是一个巨大的胜利因为它会让任务运行速度翻倍。不过这里最大的警告是任务正确性是必要的标准但它无法衡量代码质量和可读性而这些很难自动评估。附言我试图分析为什么 Claude Code 使用更多代币似乎主要区别在于输入代币而非输出代币。换句话说克洛德的写作量并没有翻倍。日志表明Claude会反复在每回合向模型反馈更多上下文包括之前的消息、工具调用、命令输出和文件内容。比如有一次Claude游戏用了大约57.8万个输入标记但25回合中只有大约4.5万个输出标记。所以很可能的解释是克劳德的线索在多步代理运行中积累或计入了更大的提示侧历史。11. 麦克- DGX到目前为止我们讨论的所有设置都假设本地LLM运行在同一台机器上与编码线束相关。但是如果我们对编码代理的框架建立了信任想在主Mac上使用它而模型本身托管在另一台机器上比如DGX Spark会怎样在我看来最好的或最方便的设置是从Mac到DGX的SSH隧道。首先我建议你放弃Mac上的Ollama或者换 成下面的其他功能。11434假设我们在Mac上退出了Ollama应用请检查以下输出是否返回空值表示Ollama不可用curlhttp://127.0.0.1:11434/v1/models然后在Mac端的终端窗口里执行以下命令ssh-N-L11434:127.0.0.1:11434 rasbtDGX-Spark这个命令意味着我们作为用户 打开了 SSH 连接 你需要根据你的用户名和机器名进行调整。然后命令会将Mac的本地端口转发 到 DGX上因为 。请注意这是奥拉马的地址。DGX-Sparkrasbt11434127.0.0.1:11434-L 11434:127.0.0.1:11434终端运行 看起来像是悬挂着。这很正常。在使用Qwen代码、Codex或Claude代码时保持开启。按下 阻止隧道的按钮。ssh -N -L …Ctrl-C运行后在你的Mac上用这个测试看看Mac是否真的能访问DGX的ollama模型curlhttp://127.0.0.1:11434/v1/models如果返回了DGX型号你的Mac工具就可以像本地服务器一样使用DGX Ollama服务器。然后就像上面一样用Qwen代码和Codex。对于 Claude 通过 关键在于 Mac 端 命令必须看到隧道端点。如有需要ollama launch claudeollamaOLLAMA_HOSThttp://127.0.0.1:11434\ollama launch claude--modelqwen3.6:35b12. OpenClaw和Hermes怎么样我们重点关注Qwen代码、Codex和Claude代码因为它们最直接适合编码代理工作流程。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都非常非常强大足以胜任很多任务。而且通过 Pro 订阅它们的代币速度和 GPT 5.5 一样所以不一定会拖慢你的工作流程。在建立本地代理时除了模型本身最重要的考虑因素是我们想使用哪种线束。普遍的看法是模型通常更适合特定线束例如Qwen3.6在Qwen代码中可能比Claude代码更适合。不过基于小代理人的评估这未必完全正确这只是一个非常小的基准请持保留态度。所以如果你对其他背带更有肌肉记忆的感觉更熟悉比如Codex和Claude Code也许把模型放进那个背带试试也不错总之希望这篇文章对你有帮助也让你对尝试开放重量模型产生兴趣。它们每天都在变得更强大出于某种莫名其妙的原因就是在本地运行模型很有趣。