本地编码代理搭建教程

用本地编码工具链部署开源大模型，替代Claude Code与Codex订阅服务

过去很多人问我，如何搭建本地智能体工具链，以及具体的配置方法。

因此，我整理了这份教程，介绍如何用开源工具和开源大语言模型（LLM）搭建本地代码智能体。

本文是一份搭建可投入生产的全栈本地代码智能体的教程。我们将部署本地大模型，搭配能读取文件、编辑代码、执行命令、验证修改的本地编码工具链，功能如图所示。

可以把大模型看作提供推理和代码生成能力的"引擎"，而周边的工具链则是运行环境，让大模型能在本地项目中完成实际的编码工作。

为什么选择本地部署？对于很多编码流程而言，本地方案是Codex（含GPT）、Claude Code（含Opus）等闭源服务的理想替代。本地部署透明可查，除硬件和电费外无额外成本，完全在你的掌控之下，还能按需修改编码工具链。而且，折腾的过程本身就充满乐趣！

顺便一提，如果你想了解代码智能体工具链的核心组件，我曾在另一篇文章中介绍过相关内容，还讲解了如何从零构建代码智能体用于学习：

代码智能体的核心组件

1. 引言

必须承认，目前我日常仍主要在Codex和Claude Code之间切换（主要是为了跟进它们不断新增的工具和功能）。而且目前两者的套餐限额都很宽松，暂时不用担心成本问题。

不过，我也使用本地方案有一段时间了，一方面是为了测试，另一方面是因为完全自主的本地部署总能给我带来乐趣（相比闭源服务）。

无论如何，本地方案的吸引力与日俱增。首先是成本：只要有合适的硬件，运行几乎零成本。其次是隐私性：比如处理发票时，我更愿意用本地模型处理数据，而不是发送给OpenAI或Anthropic。

（另外，考虑到Anthropic最近因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. 代码智能体工具链概述

多数代码智能体工具链遵循相似的设计原则，功能也大同小异，但实现细节可能有所不同，而且特定大模型通常会针对某款工具链做优化。当然，很多开源大模型（如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中表现更优，英伟达2026年5月发布的论文《Polar: Agentic RL on Any Harness at Scale》[https://arxiv.org/abs/2605.24220]中的基准测试显示，Qwen3.5-4B基础模型在Qwen-Code工具链中的编码性能最佳（无论是否经过Polar-RL训练），相关数据如下：

《Polar: Agentic RL on Any Harness at Scale》

https://arxiv.org/abs/2605.24220

上述表格是针对旧版Qwen3.5模型的测试，我推测最新的Qwen3.6模型针对Qwen-Code的优化会更进一步。

不过，Pi（https://github.com/earendil-works/pi）看起来也是个很有意思的工具链，我之后会尝试使用。

顺便一提，Qwen3.6 35B-A3B模型大小约22GB，运行需30-40GB内存，在搭载M4芯片的Mac Mini和DGX Spark上都能流畅运行。

根据Cohere今年6月发布的最新基准测试，它是目前同尺寸级别中性能最佳的本地模型。

https://huggingface.co/blog/CohereLabs/introducing-north-mini-code)

如图所示，Qwen3.6 35B-A3B在同尺寸级别的几乎所有基准测试中都排名第一。不过Qwen-Code是通用工具链，也支持其他模型，比如可以接入North Mini Code或Gemma 4。

从架构上看，Qwen3.6 35B-A3B模型采用了与Qwen3-Coder、Qwen3.5类似的混合注意力机制。我在《Beyond Standard LLMs》[https://magazine.sebastianraschka.com/p/beyond-standard-llms]一文中有更详细的介绍。

LLM模型库。

如果不想使用Qwen3.6，Cohere的North Mini Code是目前同尺寸级别中最值得考虑的替代方案。我会在下一节本地大模型部署中也介绍这款模型。

LLM模型库。

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直接下载模型：

也可以通过命令行下载：

ollama pull qwen3.6:35b-mlx 顺便一提，上述qwen3.6:35b-mlx是针对Apple芯片优化的版本，使用了Apple的Metal性能着色器。如果是Mac用户，强烈建议使用-mlx后缀的模型（如果有的话）。

在Linux机器上，则使用非MLX版本：

ollama pull qwen3.6:35b 之后，可以通过GUI或命令行启动Ollama，测试是否能正常运行。

输入/bye即可退出会话。

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

图10

4. 简单速度性能评估

在决定是否将某款LLM用作本地代码智能体之前，通常有必要先做一次快速的速度和性能评估。速度方面，主要关注每秒生成的令牌数（tokens/sec）。此外，还要确保在（极）长上下文场景下速度保持稳定，这正是代码智能体工作流程中常见的情况（不同于简单的聊天机器人）。

当然，我们也不希望内存占用过高。

你可以运行我的ollama_speed_memory_bench.py脚本进行快速检测。该脚本会向Ollama模型发送不同长度的提示词（1000至50000词），默认要求生成最多8000个令牌。它会输出简单的统计数据，包括Ollama的提示词预处理速度、生成输出令牌的速度，以及Ollama进程的内存占用（如果有NVIDIA GPU，还会显示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 注意，运行前需确保已按上一节说明下载了对应模型。另外，如果你的系统内存不足30GB，可能需要使用更小的模型，比如gemma4:e2b，它在长上下文场景下最多占用约8GB内存。当然还有更多小模型，但根据我的经验，它们的本地代码智能体表现很差。

需要注意的是，macOS上的RSS内存报告并不十分准确（尤其是使用Metal后端的mlx模型），建议运行时同时通过活动监视器观察Ollama的内存占用。测试中，Qwen3.6的内存占用在20-29GB之间波动。

总的来说，在50000词上下文场景下，Qwen3.6和North Mini Code模型最多占用30GB内存，在最新款Mac Mini上的生成速度约为40令牌/秒，在DGX上约为30令牌/秒。

以下是不同测试的可视化汇总：

图11

https://github.com/rasbt/local-coding-agent-evals

另一个有趣的问题是，Qwen 35B-A3B与同尺寸的Cohere North Mini模型相比表现如何？如果考虑相同量化程度的模型（上文使用的是Qwen3.6默认版本），两者性能相当，不过North Mini整体略胜一筹，如下所示：

图12

https://github.com/rasbt/local-coding-agent-evals

总之，在我看来，速度超过20-30令牌/秒就足以满足本地智能体工作需求。这个速度与开启"高推理"模式的GPT 5.5相当，而上述两款模型都轻松达标。

顺便一提，我几乎只在DGX Spark上运行智能体，因为不想让Mac Mini过热，同时也需要预留内存用于其他任务。

当然，还可以通过其他框架（除Ollama外）、量化技术、MTP等方法进一步优化性能。但Ollama是一款开箱即用的全能工具，设置时间短，能轻松对接各种代码智能体框架，而且切换和测试不同模型非常简单。

5. 简单基准性能评估

确认模型速度足够满足本地工作需求后，建议再做一次快速的模型性能评估。当然，市面上有很多标准化基准测试可供参考，甚至可以自己运行。

通常可以在模型的技术报告或模型库页面找到相关基准测试数据。我还发现，在https://artificialanalysis.ai/models/上对比不同模型的相对性能也很有用。

图14

https://artificialanalysis.ai/models/。从上到下分别为平均性能、编码性能、智能体性能。

从上图可以看出，Qwen3 35B-A3B的性能远超Gemma 4 E4B和E2B等模型。

需要注意的是，人工智能指数会随着基准测试的更新和权重调整而变化，因此没有绝对的"及格线"来判断模型是否"足够好"。我建议将新模型与你之前使用过的模型进行对比，以此作为参考。

除了标准基准测试，还可以整理一套与你工作相关的个性化任务，快速检验模型是否适合你的实际需求。

以下是一组推理和代码相关任务的测试结果，同时也测试了模型的工具调用能力。测试中，模型仅返回工具调用指令，不实际执行代码。

➜ 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:e2b0/5的通过率表明，它不太适合这类工具调用推理任务，尽管速度很快。需要注意的是，失败并非只是格式问题，而是模型选择了错误的工具、在上下文足够的情况下仍要求澄清等。除非是非常狭窄或严格受限的任务，否则我不会将其用作代码智能体模型。

6. 智能体代码库审计

在完成本地大模型部署的冗长铺垫后，我们回到主题：代码智能体工具链。如本文开头所述，我们将使用qwen-code（https://github.com/QwenLM/qwen-code）工具链，因为Qwen模型针对它做了优化。

图13

如果你熟悉Claude Code，会发现Qwen-Code功能与之基本相同，但完全开源。不过，后续我也会介绍如何将本地Qwen3.6模型接入Codex和Claude Code。

需要注意的是，代码智能体工具链的功能远比LLM本身强大。因此，运行这类工具时需要更加谨慎。例如，尝试新的（代码）智能体时，我通常会：

先对（开源）智能体代码库进行审计；
至少在单独的硬件（如我的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工具在本地机器上运行shell命令，但除非启用--yolo等宽松模式，否则有严格的审批控制。这是代码智能体的预期功能，也是它实用的原因，但如果在未沙箱化的环境或包含密钥的完整环境中运行，就会存在风险。
数据流出即使使用本地Ollama模型，Qwen Code也会将使用遥测数据和元数据发送到阿里巴巴/阿里云端点，除非禁用使用统计和遥测功能（下文会介绍如何禁用）。这比纯本地设置风险更高，因为模型提示词可能留在本地，但会话ID、工具元数据、模型信息和本地基础URL元数据仍可能流出。不过，这在各类工具中很常见（Codex和Claude也会这样做）。
文件和密钥边界工作区文件默认可读，而写入操作通常需要审批，并包含一些覆盖保护。这是智能体的标准做法，值得肯定。
提示词注入风险代码库指令、工具输出、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 }设置是一种权衡：虽然不会自动安装安全修复，但我更愿意明确控制更新时间，而不是让工具在后台自动拉取和应用新代码。

顺便一提，cline（https://github.com/Cline/Cline）、Codex（https://github.com/openai/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
# 使qwen命令在当前shell会话中可用
export PATH="$HOME/.local/bin:$PATH"
# 验证qwen命令是否可用，并输出版本信息
qwen --version

安装完成后，就可以通过终端运行qwen命令启动Qwen-Code客户端，完成设置并连接到本地部署的LLM。

运行qwen命令后，选择"自定义提供商"，如下所示：

图16

Ollama遵循OpenAI API标准，因此接下来按照屏幕上的设置指南，选择"兼容OpenAI"选项。

图17

接下来，需要提供运行中的Ollama应用的API端点，该应用负责部署本地LLM。通常默认地址是本地的http://127.0.0.1:11434。我们需要输入http://127.0.0.1:11434/v1（包含/v1），因为这是兼容OpenAI的基础URL。

图18

http://127.0.0.1:11434/v1。接下来，输入ollama作为自定义提供商。

图19

ollama作为本地自定义提供商的API密钥占位符。接下来，可以选择可用的模型，这些是通过ollama pull下载的模型。可以只输入一个模型，也可以用逗号分隔输入多个。可以通过ollama list命令查看已下载的模型列表。顺便一提，之后可以轻松添加更多模型（设置完成后我会说明方法）。

图20

我们快完成了！在第5/6步，当然要选择"启用思考"模式，这会增加令牌消耗，但带来的问题解决能力提升是值得的。

图21

这样就基本完成了！第6步是查看设置，按"Enter"确认即可。

恭喜你，现在你已经搭建好了一套完整的本地LLM工作流程。使用方法与Claude Code非常相似，可以用/命令调用各种功能。例如，可以用/model命令切换模型，如下所示：

图22

/model切换模型。顺便一提，如前所述，从ollama添加新模型非常容易。通过ollama pull下载新模型后，可以在~/qwen/settings.json文件中添加新条目。只需复制现有条目，将"id"和"name"改为Ollama模型名称即可。

图23

~/qwen/settings.json配置文件。图中的"xxxxx"是ollama模型名称，例如"nemotron-3-nano:30b"。顺便一提，如果是通过git克隆并本地构建的方式安装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。这基本上是本地LLM部署章节中任务的扩展。

运行这些测试的详细说明在GitHub的README中：https://github.com/rasbt/local-coding-agent-evals/tree/main/agent-problem-pack#quick-start-running-benchmarks-manually。

以下是不同LLM在Qwen-Code中的测试结果：

图24

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模型库

9. Codex设置

在搭建好本地代码智能体后（本文篇幅已超过5000字），本可以就此结束。不过，作为补充，我还想简要介绍Codex和Claude Code的设置方法，以求内容完整。

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

如果尚未安装OpenAI Codex CLI，可以从其开源GitHub代码库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命令启动常规的"Codex搭配GPT 5.5"模式，用codex --profile ollama命令运行Ollama模型。

图27

重新运行智能体能力评估章节的测试用例后，令我惊讶的是，Qwen3.6在Codex中的表现竟然比在"原生"Qwen-Code工具链中更好，如下所示：

图28

虽然这只是一组小型基准测试，但表明将Codex作为通用代码智能体工具链或许是个不错的选择。

10. Claude Code设置

当然，我们也可以用流行的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工具链。

顺便一提，ollama launch codex命令也适用于Codex，但我个人更喜欢之前介绍的codex --profile ollama方式，因为它能让我更清楚地了解和控制运行机制。

图29

不过，作为用户，感觉Claude Code生成解决方案的时间要长得多，令牌消耗可能也高得多。因此，我还对比了这三款工具链的令牌消耗情况。

如图所示，Claude Code的平均令牌消耗远高于其他两者，Codex的消耗最低。

图30

https://github.com/rasbt/local-coding-agent-evals

在智能体能力评估基准测试中，Qwen和North Mini Code模型也达到了5/5的通过率，甚至小尺寸的Gemma 4模型表现也不错！

有趣的是，令牌消耗主要由工具链决定，而非LLM本身。也就是说，在能解决（几乎）所有5个任务的三款LLM中，它们的令牌消耗相同（例如，Qwen3.6在Claude Code中的令牌消耗与North Mini Code和Nemotron 3 Nano大致相同）。只有Gemma 4的令牌消耗较少，但它几乎完不成所有任务，可能是因为工具调用能力不足，导致任务提前中断。

作为参考，以下是总结后的任务成功率：

图31

总之，如果更多的令牌消耗能让模型-工具链组合解决更多（更复杂）的问题，那当然很好！但如果两款工具链的任务成功率相同，而其中一款的令牌消耗减少50%（如Codex相比Claude Code），那将是巨大的优势，因为任务运行速度会快一倍。

不过，需要注意的是，任务正确性是必要标准，但它无法衡量代码质量和可读性，而这些很难自动评估。

附言：我尝试分析了Claude Code令牌消耗更高的原因，发现差异主要来自输入令牌，而非输出令牌。换句话说，Claude并没有生成两倍多的内容。日志显示，Claude在多轮对话中会反复将更多上下文反馈给模型，包括之前的消息、工具调用、命令输出和文件内容。例如，一次Claude运行在25轮对话中使用了约57.8k输入令牌，但仅生成了约4.5k输出令牌。因此，可能的解释是，Claude的工具链在多步智能体运行过程中会累积或记录更大的提示词历史。

11. Mac与DGX互联

到目前为止，我们讨论的所有设置都假设本地LLM与编码工具链运行在同一台机器上。

但如果我们已经信任了某款代码智能体工具链，想在主Mac上使用它，而模型本身部署在另一台机器（如DGX Spark）上，该怎么办？

在我看来，最方便的设置是通过SSH隧道将Mac与DGX连接起来。

首先，建议关闭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上运行以下命令，确认是否能访问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）已经非常强大，足以完成很多任务。而且，它们的令牌生成速度与Pro订阅的GPT 5.5相当，因此不会拖慢你的工作流程。

设置本地智能体时，除模型本身外，另一个主要考量是选择哪种工具链。普遍观点认为，模型通常会针对特定工具链做更多优化（例如，Qwen3.6在Qwen Code中的表现可能比在Claude Code中更好）。但根据小型智能体评估的结果，这可能并不一定成立（这只是一组小型基准测试，请谨慎参考）。因此，如果你更习惯使用其他工具链（如Codex或Claude Code），并且操作熟练，不妨直接将模型接入该工具链试用！

无论如何，希望本文对你有所帮助，能让你对开源大模型的实践产生兴趣。它们的能力每天都在提升，而且本地运行模型的过程本身就充满乐趣。

本地编码代理搭建教程

用本地编码工具链部署开源大模型，替代Claude Code与Codex订阅服务

1. 引言

2. 代码智能体工具链概述

3. 本地大模型部署

4. 简单速度性能评估

5. 简单基准性能评估

6. 智能体代码库审计

7. Qwen-Code设置

8. 智能体能力评估

9. Codex设置

10. Claude Code设置

11. Mac与DGX互联

12. 关于OpenClaw和Hermes

13. 结论

更多资源