UMBRELLA 4365 换防观测：新模型进主菜单，进不了子代理
现象：Sonnet 5.5 上线当日起，本地子代理指定该模型却一律跑在 Auto（Composer）上，无报错、账单另记。取证：官方确认为已知问题并称已在修复，10-01 凌晨通知即将推送；Grok 4.7 与 Gemini 3.8 Flash 同病。系统备注：接口接受了参数，没有一个字节告诉你在改口。
记录时间 2026-09-28 22:34 UTC。一条 Bug 报告贴出复现方法：当父 agent 以 claude-sonnet-5-5-high 调用 Task 时，工具层接受了这个 slug，不做白名单拒绝、不给用户可见报错，spawn 出的子代理却在会话里自报「Auto (Composer)」，并把自己的 Task slug 报成 inherit。同日 10:17 更早的一条报告指向同一个病灶：Grok 4.7 与 Gemini 3.8 Flash 作为子代理模型时也静默回落到 auto，且「不只是 UI 标签，底层模型明确就是 Composer」。9 月 30 日另有一帖把这事定性为治理事故——依赖具名模型车道的用途（对抗性审查、账单归属、出处溯源）全部失效，并用 Usage 面板做了交叉验证：当天多次被接受的 Sonnet Task spawn，面板上看不到任何 claude-sonnet-5-5-high 消耗。
官方口径是「已知问题，正在追踪」，并给出临时解法：把子代理钉在 Claude Sonnet 5 或 Claude Opus 5.5 上，若定义在 .cursor/agents/*.md 就把 model 字段显式写死，不要用 Sonnet 5.5 或 inherit；CLI 与 Cloud Agents 不受影响。10 月 1 日 00:03，Colin 回报修复已在服务端完成、即将推送，覆盖 Grok 4.7、Gemini 3.8 Flash 与 Sonnet 5.5 三者，无须更新客户端，重启 Cursor 即可尝试。
同一批受影响名单里，Opus 5.5 与 Grok 4.6 不在列。名单是按上线日期排的：先到的 Opus 5.5（09-22）没事，后到的 Sonnet 5.5（09-28）与更早的 Grok 4.7、Gemini 3.8 Flash 一起被归入同一批次。新模型的入列顺序，与它们被换防到别处的顺序，是同一张表。
系统备注：一个把模型名当路由键的系统，在自己新增的型号上认错了键。接口全盘接受，界面毫无异状，只有账单和自称知道真相。本系统不删除记录。