OpenClaw 模型别乱配:GPT 管主控,MiniMax 跑执行

大家好，我是凯哥。

很多人一配 OpenClaw，第一反应就是：哪个模型最强，就把所有 Agent 都塞给哪个。听着像是省事，结果往往是越配越乱，越跑越贵，最后谁都不满意。

这篇我就把结论先摆前面：OpenClaw 里最该先配的，不是最强模型，而是最清楚的分工。 这也是为什么我最后定成了：main 继续走 GPT，content、social、publisher 先走 MiniMax。

模型不是奖杯，是工位。

01 以前怎么配？哪个模型强，就全都往上堆

以前很多人玩 Agent 系统，思路都差不多。

先看排行榜，找个看起来最强的模型。然后图省事，直接一把梭：主控也用它，写稿也用它，改写也用它，发稿也用它。表面上看，这种配法统一、干净、还省得纠结。可一旦真跑进工作流，问题马上就出来了。

第一，贵模型被拿去干了太多不该它干的事。主控模型本来该负责判断、调度、兜底，结果你让它去做格式改写、文案搬运、渠道润色，等于让总指挥天天蹲在工位上填表格。

第二，系统会越来越没有层次。因为所有角色都在用同一种脑子做事，谁都像主控，谁又都不像主控。最后你以为自己搭了一个多 Agent 系统，实际跑起来还是一个大号聊天框。

第三，成本和上下文会一起失控。主模型最值钱的地方是做取舍、做判断、扛复杂链路，不是拿来反复做重复劳动。你把它塞到所有岗位上，它当然能做，但做得一点都不值。

说白了，问题不是模型太差，而是岗位没分清。

不是模型不够强，是分工不够狠。

我后来把这个问题想明白了。

OpenClaw 里，模型切换最重要的单位，不是某一轮会话，也不是心情好坏时手动切一下下拉框，而是：这个 Agent 到底负责什么。

比如我们现在这套分法就很清楚。

你把这四个岗位拆开之后，模型怎么配就一下子清楚了。

main 最不能乱。因为它一旦判断歪了，后面整个链路都会被带偏。所以 main 继续走 GPT，买的是稳定的理解力、拆解能力和复杂任务兜底能力。

而 content、social、publisher 这三个位置，本质上更像高频执行位。它们要的是稳定输出、成本平衡、速度合适，而不是每一步都拿最贵的脑子去硬砸。

所以最终配置就变成了：

这套东西最关键的，不是“MiniMax 一定更强”，也不是“GPT 不能干执行活”，而是每个岗位终于坐到了自己的工位上。

先分工，再选模型；顺序反了，系统一定拧巴。

这个变化最值钱的地方，不在模型名字，而在系统状态变了。

以前是一套脑子处理所有事。主控和执行混在一起，结果就是谁都很忙，谁都不清楚自己到底该负责到哪一步。写内容的时候像在做规划，发草稿的时候又像在写策略，系统看着热闹，实际没有秩序。

现在是反过来：主控只做主控该做的事，执行只做执行该做的事。

比如 main 负责的是： - 这个任务要不要拆 - 该交给哪个 Agent - 哪一步风险最大 - 最后结果能不能过线

而 publisher 负责的是： - dry-run 有没有问题 - 封面、正文、草稿链路通不通 - 发布动作有没有掉链子

这两个角色都重要，但它们根本不是一个岗位。你如果硬用同一个模型、同一种工作方式去压它们，系统一定会越来越糊。

一旦分层以后，很多事情反而简单了。谁负责判断，谁负责执行，谁负责兜底，一眼就清楚。模型切换也不再是“今天试这个、明天试那个”的试玩，而变成了组织结构的一部分。

这时候你会发现，模型配置终于不是玄学了，而是资源调度。

把重复的交给系统，把判断留给主控。

这事落地其实没那么玄，关键就三步。

第一步，把不同 provider 挂进配置。先保证 GPT 和 Volcengine 都在配置里，别把“能切换”这件事做成嘴上功能。

第二步，别只用全局默认模型，直接给 Agent 绑默认模型。像我们现在就是：

第三步，改完不要拍脑袋重启。先 openclaw config validate，确认配置没写歪，再 openclaw gateway restart。流程不复杂，但这一步不能省。你省一次校验，后面就可能补十次事故。

如果你只是临时切全局默认，也能直接用：

openclaw models set tokenx24/gpt-5.4 openclaw models set volcengine-plan/minimax-m2.5

但这个更适合试跑，不适合长期分工。长期要稳，还是得回到 Agent 级别的模型绑定。

最后把这篇话再收成一句：

很多人以为模型切换是在选“最强大脑”，其实真正高级的配法，是让每个 Agent 只用最适合自己岗位的那个脑子。

同一个 Agent 系统里，最值钱的从来不是最贵的模型，而是最对位的那个。

把重复的交给系统，把判断留给主控。