搭建本地编程 Agent 实战教程
Components of A Coding Agent
Sebastian Raschka, PhD·4月4日阅读全文1. 简介
我得承认，目前我日常主力仍在 Codex 和 Claude Code 之间轮换。这么做既是为了跟进那些不断涌现的新工具和功能，也是因为它们的套餐额度（尤其是 Codex）依然十分慷慨，让我暂时无需为成本担忧。 不过，我也有一段时间在使用本地方案进行测试。相比依赖专有云服务，拥有一套完全本地的环境并付诸使用，能给我带来某种独特的满足感。 无论如何，本地方案的吸引力正与日俱增。一方面在于成本，如果你有相应硬件，运行开销几乎可以忽略不计；另一方面是隐私。例如，在整理和处理我的发票时，我更倾向于让本地模型来摄取这些数据，而不是将其发送到 OpenAI 或 Anthropic。 顺带一提，鉴于 Anthropic 最近曾 限制其旗舰模型在 LLM 研究方面的性能，专有服务未来的限制可能会越来越严。因此，提前熟悉并掌握开放权重的替代方案作为备份，或许是明智之举。 除此以外，还有诸多类似的理由和应用场景。 你选择使用本地 LLM 和编程框架的动机可能包括：成本可预测且固定：一旦达到订阅套餐上限，你便不受 API 价格波动的影响。
可复现性：模型升级（例如 GPT 5.4 -> GPT 5.5 -> GPT 5.6）有时能更可靠地解决查询问题，但也可能打破现有的工作流。
离线使用：适用于经典的“飞行模式”场景（网速慢或无网），或是在没有 Starlink 订阅的森林小屋进行编码/写作闭关时。
2. 编程代理框架概览
大多数编码智能体框架（coding agent harnesses）遵循类似的设计原则，功能和特性也大同小异。不过，底层实现细节可能有所不同，且特定的 LLM 通常是针对某个特定框架优化的。当然，很多开源权重 LLM（例如 GLM 5.2）也能适配 Claude Code 等主流框架。
如果 LLM 开发者同时也开发了相应的编码框架，通常可以认为该模型是优先针对自家框架优化的（同时也兼顾其他框架）。
本文主要介绍使用 Qwen3.6 搭配 Qwen-Coder 编码客户端的方案。但稍后也会探讨使用本地 LLM 配合其他智能体框架的选项，例如 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 于 2026 年 5 月发布的论文《Polar: Agentic RL on Any Harness at Scale》（Polar: Agentic RL on Any Harness at Scale）中有一组基准测试数据表明，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 内存，在 M4 版 Mac Mini 和 DGX Spark 上都跑得相当流畅。
根据 Cohere 六月初公布的最新基准测试，它目前是该尺寸级别中最好的本地模型。
如上图所示，Qwen3.6 35B-A3B 在该尺寸级别的基准测试中除一项外全部领先。话虽如此，Qwen Code 是一个通用 harness，也支持其他类型的模型。比如，我们也可以在 Qwen Code 中接入 North Mini Code 或 Gemma 4。
在架构设计上，Qwen3.6 35B-A3B 模型采用了混合注意力机制，这与 Qwen3-Coder 和 Qwen3.5 相似。我在《超越标准 LLMs》一文中对此有更详细的介绍。
如果你不想使用 Qwen3.6，Cohere 的 North Mini Code 可能是目前该规模下最有趣且能力较强的替代方案。我将在下一节关于本地 LLM 配置中详细介绍这款模型。
3. 本地 LLM 配置
无论使用哪种代理框架（Qwen-Code、Codex 或 Claude Code），我们都必须首先配置好一个本地 LLM，例如 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 的 Metal 性能着色器，即专为搭载 Apple 芯片的 Mac 优化。在 Mac 上使用模型时，我强烈推荐优先选择 *-mlx 版本（如果有的话）。
在 Linux 机器上则使用非 MLX 版本：
ollama pull qwen3.6:35b下载完成后，可以通过 GUI 验证模型是否正常工作，也可以直接在命令行启动 Ollama。
输入 /bye 命令即可退出会话。
如前所述，目前 Qwen3.6 35B-A3B 模型最好的替代品是规模相近的 North Mini Code 1.0。
4. 简易速度性能评估
在决定将大语言模型（LLM）用作本地编码智能体之前，先进行快速的速度和质量评估通常是个不错的选择。就速度评估而言，我会关注 tokens/sec 性能。同时，我也会确保在（超长）上下文场景下该性能保持稳定，因为在智能体编码工作流中，我们通常处理的就是这类情况（与简单的聊天机器人不同）。
当然，我们也不希望内存成本失控。
你可以运行我的 ollama_speed_memory_bench.py 脚本来进行快速检查。简而言之，该脚本向 Ollama 模型发送不同的提示词（涵盖 1k 到 50k 词的篇幅），并默认要求生成最多 8k 个 token。它会报告一些简单的统计指标，包括基于 Ollama 提示评估指标得出的预填充（prefill）速度、基于输出 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请注意，这假设你已按照上一节的说明下载了相应的模型。另外，根据你的系统配置，如果内存少于 30 GB，你可能需要使用更小的模型，例如 gemma4:e2b，在长上下文下它最多占用约 8 GB 内存。当然，市面上还有许多更小的模型，但根据我的经验，它们作为本地编码智能体的效果相当糟糕。
需要注意的是，对于模型而言，macOS 上的 RSS 内存报告并不十分准确（尤其是使用 Metal 后端的 mlx 模型变体）。建议在运行期间同时关注 Ollama 的活动监视器内存占用情况。在此案例中，内存使用量在 20 到 29 GB 之间波动。
总而言之，在 50k 上下文长度下，Qwen3.6 和 North Mini Code 模型最多消耗 30 GB 内存，并能在较新的 Mac Mini 上以约 40 tok/sec 的速度生成输出，在 DGX 上则为 30 tok/sec。
以下是不同运行情况的可视化摘要。
另一个有趣的问题是 Qwen 35B-A3B 与大小相近的 Cohere North Mini 模型相比表现如何？如果我们考虑量化程度相似的模型（上文使用的是 Qwen3.6 默认设置），两者非常接近，尽管 North Mini 在整体表现上可能略胜一筹，如下所示。
总之，结论是：在我看来，本地跑 agent 只要速度超过 20-30 tok/sec 就相当够用了。这大致和 GPT 5.5 开启“high”推理的速度持平。上图的两个模型都轻松达到了这个门槛。
顺带一提，我个人几乎只在 DGX Spark 上跑 agent，一来不想让 Mac Mini 太烫，二来想留出内存给其他任务用。
当然，换别的框架（不用 Ollama）、调整量化方式、用 MTP 等手段还有进一步优化空间。但 Ollama 是个开箱即用的全能选手：几乎零配置，能轻松接入各类 coding agent 框架，切换、试用不同模型也非常简单。
5. 简单的基准性能评估
确认模型速度足够流畅之后，我建议再快速评估一下模型能力。标准化的基准测试很多，可以参考，也可以自己跑。
相关基准的分数通常能在模型的技术报告或模型主页上找到。另外我也常在 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 的成绩表示它基本可用，但在自主工具调用的可靠性上还不能完全信任。不过，如果搭配一个能约束行动、增加重试机制并提供更强项目上下文的 harness（运行时环境），它的实用性可能会有所提升。
另一方面，gemma4:e2b 得分 0/5 是一个强烈的信号，表明它并不太适合这类工具调用推理任务，即使它的速度很快。值得注意的是，这些失败并非单纯是格式问题，而是它选错了工具，比如在上下文已经足够充足的情况下还会请求澄清等。我大概不会把它当作编程 agent 的基座模型来使用，除非任务范围非常狭窄或约束极其严格。
6. Agent 代码库审计
在介绍了如此冗长的本地 LLM 环境搭建过程后，让我们回到本文的核心主题：coding agent 的 harness。如本文开头所述，我们将使用 qwen-code（https://github.com/QwenLM/qwen-code）这个 harness，因为 Qwen 系列模型是专门针对它优化的。
如果你用过 Claude Code，会发现它基本上就是同一个东西，只不过完全开源。后面的章节里我也会介绍如何把本地的 Qwen3.6 模型接入 Codex 和 Claude Code。
要注意，coding agent 框架本身的能力远不止一个 LLM。所以在“跑什么、跑在哪”这个问题上，我建议更加谨慎。比如，试用新的（编程）agent 时，我通常会：
先对（开源）agent 的代码库做一次审计。
在独立的硬件上运行（比如我的 DGX Spark），至少也要用独立的用户账号或虚拟环境。
审计时，我建议重点关注数据共享/外传行为、文件权限的默认影响范围，以及对 prompt injection 的基本防御能力。下图概括了主要要点。
本地模型服务引擎（如 Ollama）也有类似的安全顾虑。不过 coding agent 更需要警惕，因为它们可以直接读取你机器上的数据并操作文件。
做一次基础审计，我建议按以下步骤：
克隆代码库：
git clone https://github.com/QwenLM/qwen-code.git让你之前用过、信得过的 agent（比如 Codex 里的 GPT 5.5 或 Claude Code 里的 Opus 4.8）用一个聚焦的 prompt 来审查它。大致可以这样写：
我会在安装或在本机运行该 Agent 之前，对 ./qwen-code 进行审计。
只关注已安装 Agent 及其生成代码路径带来的实际本地机器风险：
安装脚本和包生命周期钩子
Agent 执行的 shell 命令
运行时的文件读写边界
密钥处理及环境变量继承
仓库文件、项目指令和工具输出如何影响 Agent
MCP、插件、扩展或工具集成
网络调用和遥测
安装后的更新机制
终端转义/输出处理
数据出境和数据驻留
除了安装所必需的网络下载外，检查当通过 Ollama 使用本地模型时，已安装的 Agent 是否可能将提示词、文件、遥测数据、日志、标识符或元数据发送到远程服务器。忽略云端模型的配置。
不要仅凭项目所有者推断风险。识别控制网络行为的具体端点、SDK、默认提供商、环境变量、默认配置和文档，包括任何在境外或第三方公司运营的端点。
不要进行广泛的代码风格审查，也不要重构。请产出：
带有文件/行号引用的高风险发现
中等风险关注点
网络/数据出境发现，包括任何境外、第三方或与中国的端点或默认设置
在审查完成前应避免运行的命令
能降低本地机器风险的设置或环境变量
简短建议：可在沙箱中测试、可安全使用、或不要运行
对每一项，说明它是编码 Agent 的预期行为，还是比 Codex 或 Claude Code 具有固有风险。
以下是主要发现的摘要（因为完整报告可能有些枯燥且对本文来说太长）：
本地执行 Qwen Code 可以通过其 shell 工具在机器上运行 shell 命令，但除非启用
--yolo等宽松模式，否则存在严格的审批控制。这对于编码智能体（coding agent）来说符合预期，也正是它实际有用的原因。但如果非沙箱运行或环境包含敏感信息，风险随之升高。数据外发 即使使用本地 Ollama，Qwen Code 仍可能向 Alibaba/Aliyun 端点发送使用遥测和元数据，除非禁用使用统计和遥测（下文详述）。相比纯本地方案风险更高：模型 prompt 可能保持本地，但会话 ID、工具元数据、模型信息和本地 base URL 元数据仍会离开机器。不过这一点在各类工具中都很常见（Codex 和 Claude 也如此）。
文件与密钥边界 工作区文件默认可读，写入通常需要审批，并含部分覆盖保护。这是良好的标准智能体实践。
提示词注入面 仓库指令、工具输出、MCP 工具、扩展和项目配置都可能影响智能体行为。通过上文提到的审批关卡可降低提示词注入攻击风险。这对编码智能体来说正常，但不可信仓库应默认视为敌对，因为它们可能诱导智能体读取文件、运行命令或通过已批准工具发送数据。
关于第 2 点的主要隐私顾虑，大多可以通过自定义 ~/.qwen/settings.json 解决，内容如下：
{
"privacy": {
"usageStatisticsEnabled": false
},
"general": {
"enableAutoUpdate": false
},
"telemetry": {
"enabled": false,
"logPrompts": false,
"includeSensitiveSpanAttributes": false
},
"disableAllHooks": true,
"mcpServers": {},
"artifact": {
"publisher": "local",
"autoOpen": false
}
}"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）。
如前所述，我更喜欢在单独的机器上实验和运行能读写本地文件的 coding agent（我用的是 DGX Spark，也可以是独立的 Mac 或 Linux 工作站）。或者退一步，在 VM 里运行，或者单独创建一个 macOS 或 Linux 用户账户，这也是个折中方案。
（有朋友说他们也会租服务器来折腾，比如 Linode 或 Heroku。不过，与其每月为一台性能还行的机器付托管费，我可能更愿意买一台 $200-500 的廉价硬件，甚至一台退役的旧笔记本，本地跑个 harness，然后通过 Ollama cloud models、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 命令后，选择“Custom Provider”（自定义提供方），如下图所示。
Ollama 采用 OpenAI API 标准。因此，按照屏幕上的设置向导，选择“OpenAI-compatible”（OpenAI 兼容）选项。
接下来，需要提供正在运行、用于服务本地 LLM 的 Ollama 应用的 API 端点。通常是本地的
http://127.0.0.1:11434默认填入该地址。由于这是兼容 OpenAI 的 Base URL，请输入 http://127.0.0.1:11434/v1（注意包含 /v1）。
http://127.0.0.1:11434/v1。接下来，将 ollama 作为自定义 Provider 名称填入。
ollama 输入为本地自定义 Provider 的 API Key 占位符。然后选择可用模型。这些是通过 ollama pull 下载的模型。可以输入单个模型，也可以用逗号分隔多个模型。通过 ollama list 可以核对已下载的模型列表。顺便一提，后续随时可以轻松添加更多模型（完成设置后会说明）。
即将完成。在第 5/6 步中，勾选“启用思维模式”。虽然这会消耗更多 Token，但显著提升的问题解决能力值得。
到这里基本就完成了。第 6 步只是一个确认环节，按回车即可。
恭喜，你现在应该已经搭建好一套完全本地化的 LLM 工作流了。用法和 Claude Code 基本一样，可以通过 / 命令使用各种功能。比如，可以用 /model 命令切换模型，如下所示。
/model 切换模型。顺便说一下，正如前面提到的，从 ollama 添加新模型相当简单。用 ollama pull 拉取新模型后，在 ~/qwen/settings.json 里加一条配置即可。具体做法是：把文件中已有的条目复制粘贴一份，然后把 "id" 和 "name" 改成对应的 Ollama 模型名。
~/qwen/settings.json 配置文件即可添加新的 ollama 模型。其中 "xxxxx" 就是 ollama 的模型名，比如 "nemotron-3-nano:30b"。另外，如果当初是通过 git clone 加本地构建的方式安装的 qwen-code，想定期更新的话，可以先从 GitHub 拉取最新快照，然后按如下方式更新：
# 进入本地 Qwen Code 源码目录
cd ~/Developer/qwen-code
# 从 GitHub 拉取最新更改
git pull
# 如果包文件有变动，安装或更新依赖
npm install
# 重新构建本地 CLI
npm run build
# 验证更新后的 CLI
qwen --version8. 评估代理能力
既然我们已经拥有了一个功能完备的本地编码代理，接下来的问题是：它的表现如何？能否真正满足我的任务需求？当然，现有基准测试可以参考，但我认为，最靠谱的方式还是把它融入你自己的工作流试用几天，以此判断它是否达标。
我建议整理一套小型任务集，反映你日常使用编码代理的典型场景。如果在某个项目中遇到特别棘手的任务，不妨将其加入这套任务集，以便日后评估新模型。
举个例子，我在 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 中的测试表现。
可见，Qwen3.6 和 North Mini Code 35B-A3B 模型均成功解决了这五个问题中的四个，而 Gemma 4 E2B 表现较差。出于好奇，我还加入了稍早一点的 Nemotron 3 Nano 模型。它的尺寸和计算性能与前文提到的 Qwen 及 North 系列模型相近，表现也同样出色。
9. Codex 配置
完成本地编码智能体的搭建（且文章已超 5000 字）后，这里本可以结束。不过作为补充，我也简要介绍了 Codex 和 Claude Code，以求完整。
据我所知，Codex 的图形界面不支持非 OpenAI 模型，但我们可以通过 Codex CLI 来运行 Ollama 模型。
如果你尚未安装 OpenAI Codex CLI，可以参照 qwen-code 的安装方式，从其开源 GitHub 仓库获取并安装： https://github.com/openai/codex （是的，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"
这样，我们仍然可以用 codex 启动常规的「Codex + GPT 5.5」模式，需要时再用 codex --profile ollama 切换到 Ollama 模型。
重新跑一遍 Agent 能力评估章节里的测试用例后，我意外地发现 Qwen3.6 在 Codex 中的表现竟然比它原生的 Qwen-Code coding harness 还要好，结果如下所示。
虽然这只是一小部分基准测试，但它说明把 Codex 作为通用的 coding agent harness，或许并不是个坏主意。
10. Claude Code 配置
当然，还有一个非常流行的 Claude Code agent 框架，我们可以用它来包裹本地的 LLM。尽管它广受欢迎且能力强大，但这可能是我对本地部署最不推荐的方案，因为其代码库是封闭的（proprietary）。这也意味着我们很难直接审查和/或禁用 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，让 Claude Code 框架使用 Ollama 模型运行。
顺便一提，Codex 也可以通过 ollama launch codex 实现类似功能。但就个人而言，我更倾向于之前讨论过的 codex --profile ollama 方式，因为它能让我对工作机制有更多洞察和掌控。
然而，作为用户，我感觉 Claude Code 生成解决方案所需的时间明显更长，其 token 用量可能也更高。因此，下面我额外查看了这三个框架的 token 使用情况。
可以看到，Claude Code 的平均 token 消耗量远高于其他两者，而 Codex 最少。
在 agent 能力小测中，Qwen 和 North Mini Code 模型同样拿到了 5/5 的满分，甚至连小巧的 Gemma 4 也表现不俗。
有趣的是，我们看到 token 消耗主要取决于 harness，而非 LLM 本身。也就是说，在所有能够（几乎）解决全部 5 个任务的三种 LLM 中，它们消耗的 token 数量基本一致（例如，在 Claude Code 中运行时，Qwen3.6 的 token 用量与 North Mini Code 和 Nemotron 3 Nano 大致相同）。只有 Gemma 4 消耗的 token 更少，但几乎也未能完成任何任务，原因可能在于其工具调用能力不足，导致任务过早中断。
作为参考，下方再次汇总了任务成功率。
总之，核心观点是：如果更多的 token 能让模型-harness 组合解决更多（且更复杂的）问题，那自然更好；但如果两个 harness 的任务成功率相同，而其中一个的 token 用量少 50%（例如 Codex 对比 Claude Code），这将是巨大的优势，因为它能让任务运行速度快一倍。
不过，这里有一个重要的前提：任务正确性是必要条件，但它并不能衡量代码质量和可读性，而这些指标很难通过自动化手段进行评估。
PS：我试着分析了一下为什么 Claude Code 消耗的 token 更多，看起来差距主要来自输入 token 而非输出 token。也就是说，Claude 并没有写多一倍的内容。日志显示，Claude 在多轮对话中不断把更多上下文喂回模型，包括之前的消息、工具调用、命令输出和文件内容。比如有一次 Claude 运行共用了约 57.8 万输入 token，但输出只有约 4500 token，分布在 25 轮里。所以比较合理的解释是：在多步骤的 agent 运行中，Claude 的 harness 会在提示词一侧积累或统计更大的历史上下文。
11. Mac <-> DGX
到目前为止，我们讨论的所有方案都假设本地 LLM 和 coding harness 跑在同一台机器上。
但如果你已经对 coding agent harness 有了足够的信任，想在自己的 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 的身份 SSH 连接到 DGX-Spark，请根据你自己的用户名和机器名做相应调整。由于指定了 -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:35b12. OpenClaw 和 Hermes 呢？
我们之所以重点介绍 Qwen Code、Codex 和 Claude Code，是因为它们与编码智能体工作流最为契合。OpenClaw 和 Hermes 同样能力强劲，但属于更通用的智能体框架。当你希望单个智能体能跨工具、应用、浏览器、终端进行协调，并处理运行时间更长的工作流时，这两者更为适用。
