我的LLM三路编排实战
先说个反直觉的结论：本地模型能不能顶替 Claude Code？直接用 Ollama 跑对话绝对不行，但给它套个 Agent 框架，效果能接近 Sonnet 级别。
我在 M1 Max (64GB 统一内存) 上实测，之前的 Qwen 2.5-Coder 32B 面对多步骤的工具调用（Tool Calling）还是有点吃力。后来我换成了 Qwen3-Coder-Next（MoE 架构，总参数 80B，激活参数 3B）。这玩意儿 Q4 量化后占用内存大约 49GB，虽然把 64GB 内存压榨得差不多了，但编码能力终于达到了能作为“二号位”的水平，而不是单纯的补全插件。
关键在于，你不能直接用 ollama run，因为那不是 Agent 循环。我给它套了 OpenCode，让本地模型具备了读取仓库、规划路径和多文件编辑的能力，这样它的工作流才和 Claude Code 保持一致。
为了让这三个 AI 助手（Claude Code, OpenAI Codex CLI, 本地 OpenCode+Qwen）在同一个项目里并行工作且互不干扰，我写了一个简单的协调器 agent-orchestra。
这里分享几个具体的实操细节，避坑指南：
一、 解决文件冲突：Git Worktrees 是神
如果三个 Agent 同时改一个文件，Git 冲突能让你崩溃。我的解法是给每个任务分配独立的 Git worktree（工作树）。每个 Agent 在自己的分支和独立目录下操作，完全物理隔离。
二、 调度逻辑：纯 Python 实现
我写了一个约 250 行的 orchestrate.py，没用任何第三方库，直接用 stdlib。它支持 add（加入任务）、run（执行）、review（评审）、merge（合并）等子命令。
# 核心调度逻辑伪代码
import subprocess
def dispatch_task(agent_name, task_desc):
# 1. 创建独立 worktree
branch_name = f"agent-{agent_name}-{task_id}"
subprocess.run(["git", "worktree", "add", f"./worktrees/{branch_name}", branch_name])
# 2. 调用对应 Agent 执行命令
if agent_name == "local":
cmd = f"opencode '{task_desc}'"
elif agent_name == "claude":
cmd = f"claude-code '{task_desc}'"
subprocess.run(cmd, shell=True, cwd=f"./worktrees/{branch_name}")三、 强制的人工审核机制
绝对不要设置自动合并（Auto-merge）。我把每个 Agent 都当成一个“速度快但不稳定”的初级开发人员。所有改动必须先 git commit 到各自的分支，然后状态标记为 review，由我手动对比 diff 决定是否合并。
四、 内存并发限制
本地模型由于内存限制，并发数必须设为 1（concurrency_cap: 1），否则 Ollama 会因为内存溢出导致响应时间从 2 秒暴增到 20 秒，甚至直接崩溃。而 Claude 和 Codex 是 API 调用，可以多开。
这里有个踩坑细节：最开始我把 worktrees 放在目标仓库内部，结果导致 git status 出现大量未跟踪文件的噪音。最后的解法是将 agent-orchestra 作为一个独立的全局工具安装，在外部调用，保持项目根目录的绝对干净。
原本我想给这套方案配个可视化界面，差点选了 Vibe Kanban，结果点进 GitHub 发现 README 第一行就写着 "sunsetting"（项目已停止维护）。最后我换成了 Claude Squad，它的底层逻辑同样是 tmux + worktree，跟我的架构契合度最高。
目前这套工作流跑起来后，我的开发节奏不再被单一模型的额度限制，这种“多模型赛马”的感觉确实比死等额度刷新要爽得多。
