自动换马为什么难：三道现实的坎

有个提问在圈子里传得挺开：为什么到现在还没人做一个 coding agent，能按任务在 Claude、Codex 和 Gemini 之间自动切换？

问题本身预设了一个美好的未来——"自动换马"。认真拆一下，会发现它没普及不是没人想到，而是三道现实的坎还没过去。

第一道，任务分类这步谁来做。自动切换的前提是先判断"这活该给谁"，而这个判断本身也是个模型调用：用便宜的分类器，分错了把难题丢给弱模型、任务直接翻车；用强模型先想一遍，那路由的成本已经花掉了，切换省下的钱未必抵得上。多数场景里，路由的开销和收益打平，自动就没有意义。

第二道，上下文搬家。每个模型的脾气不同——谁擅长长上下文、谁喜欢什么格式的指令、谁会在哪类任务上偷懒，这些"驾驶手册"是按模型写的。换模型意味着上下文重新对齐：参考示例要换、失败记录要翻译、连提示词的措辞习惯都可能要调。搬家成本高的时候，不如固定用一个。

第三道，账算不过来。今晚另一条刚讲过"够用线"：多数任务用不到旗舰，但真正省下钱的前提是你的任务分布足够清晰——知道自己每周有多少活落在哪一档，才配做自动分配。任务分布糊成一团的团队，手动挑都挑不明白，谈何自动。

不过这个方向并没有死，它在以更温和的形态落地。今天早些时候看过两块拼图：ECC 那套配置里，每个岗位 agent 都写明了"认得自己这行的主力模型"——那是把路由做进了岗位说明书，静态但可靠；Android Studio 的任选 agent 则把选择权交给了人，交互式的"按环节换"。

两块合起来，其实已经给出了短期答案：自动路由的完全体不好做，"按环节手动配、按岗位静态定"是现在就能跑的版本。

给被这个问题勾住的人一句落地的：别等完美的自动切换，先做一次任务盘点——把你最近两周的活按"推理重、速度快、上下文长"分成三堆，给每堆指定一个默认模型，用一周。一周后你会拿到自己的任务分布图，那时候再决定要不要自动化：分布清晰，上路由；分布模糊，先别碰。