用本地Qwen3.6-27B替代Claude运行多智能体编排器两周

过去两周，我通过Ollama在单张3090上完全使用Qwen3.6-27B运行多智能体编排器。目标：检验本地模型能否替代Claude，作为主导/管理/子智能体循环中的推理层。以下是可行之处与失败之处。 设置： - RTX 3090，24GB显存 - Qwen3.6-27B，Q6_K量化（约22GB在GPU上），有效上下文32k - Ollama作为推理引擎 - 多智能体编排器，支持结构化JSON计划、计划审批模态框、子智能体完成后自动复审 - 在两个真实仓库的47个多步骤编码工作流上进行测试 可行之处（推理层）： - 计划生成。在这些任务上，Qwen3.6生成的多步骤计划大致与Claude相当。略显保守（较少出现未经请求的“让我顺便重构X”步骤），但在几次提示调整后，约95%的计划连贯且符合模式。剩余的5%可通过一次重新提示修复模式问题。 - 记忆提取。每6轮进行一次Mem0风格的事实提取，效果良好。Qwen提取了与Claude相同类型的事实（例如“用户不喜欢注释，除非是为了解释‘为什么’”），并清晰存储在Qdrant中。 - 子智能体输出的自动复审。用另一个Qwen实例复审第一个Qwen的代码，大约能捕获Claude在同一组代码中发现的60%的bug。不那么严厉，但仍然有用且免费。 失败之处： - 工具调用可靠性。在47个任务中，Qwen3.6的JSON工具调用输出约有12%的格式错误率。而Claude在相同工作负载下约为0.5%。这些错误并非格式错误的JSON，而是字段名错误、类型错误、幻觉出的工具签名。Outlines/严格输出模式减少了错误，但并未完全消除。 - 长上下文漂移。当累积的会话上下文超过约1.4万tokens时，Qwen开始忘记之前做出的决策（“你说用Postgres”——不，我说的正好相反）。实际硬限制约为1.2万tokens，之后必须进行积极的摘要并重置。 - 级联失败处理。当子智能体失败时，Claude的计划器通常能注意到并重新规划。而Qwen有时会直接生成后续步骤，假设子智能体已成功。在47次运行中出现了三次级联幻觉。在有计划门控的情况下并非灾难性，但如果没有门控则会是灾难性的。 反主流观点：Qwen3.6-27B如今作为本地多智能体系统的推理层是可行的，但绝不是可行的执行层。用它来生成计划，但要对每个工具调用进行门控。 实际启示：如果你在构建纯本地的智能体，你需要：（1）在工具调用边界施加结构化输出强制（outlines、lm-format-enforcer或推理引擎的语法模式）；（2）计划审批门控，使12%的格式错误不会触及实际文件写入；（3）失败重规划逻辑——模型本身不可信赖。12%的工具调用差距是需要弥合的指标。一旦Qwen3.6（或下一个本地模型）将此指标降至约2%，云推理在智能体循环中的必要性将迅速减弱。 声明：我测试所用的编排器是OpenYabby（openyabby.com），我构建了它。测试是诚实的，因为我真心想知道能否停止给Anthropic付费。