多模型编排到底拆出哪些职责，我该往哪一层准备？

消息提到，Sakana AI 发布了 Fugu Max 和 Fugu Ultra v2，属于 Sakana Fugu 系列。Fugu 不是单一基础模型，而是一个学习型编排器，通过一个 API 把工作路由到其他模型池；Fugu Max 面向每美元最佳输出，Fugu Ultra v2 面向困难多步任务上的最高能力。

对求职者来说，这类产品把“编排”从工程细节推到了台前，但岗位并不会因此自动分成三类。更实用的做法是：读岗位描述时先判断它落在哪一层。编排层关心路由策略、成本与能力权衡、评测机制；模型层关心训练、微调与推理优化；应用层关心接口兼容、业务落地与方案取舍。同一句“熟悉多模型”，在三个层里含义完全不同。

假设一个模拟场景：团队要做一个客服问答功能。偏编排的做法是先判断问题类型，再路由到最精简的模型；偏应用的做法是直接选一个够用的模型，把精力放在提示词和业务规则上。两种做法没有绝对优劣，取决于团队对成本和延迟的容忍度。你要准备的，是能说清自己倾向哪一种、为什么。

面试时怎么核查团队是真做编排，还是只把多个模型 API 串起来？

只问“你们用了几家模型”几乎没有信息量。可以换成几个可核查的问题：路由决策是规则还是学习出来的？有没有按任务复杂度选择模型的机制？成本和质量之间怎么权衡、谁来拍板？评测集怎么维护、多久更新一次？

消息提到，Fugu Max 扩大可编排模型池并加入开源权重与专用模型，按任务路由到能解决该任务的最精简模型。这类描述可以作为提问的参照，但不要假定目标团队也这么做。如果对方答不出路由依据和评测方式，那更可能是把多个 API 串起来，而不是在做编排。

还要确认分工边界：编排策略由谁维护，模型选型由谁决定，出问题时谁负责。这些问题的答案，比产品名更能说明你入职后实际做什么。

如果目标岗位偏应用层，多模型编排能力该补到什么程度？

应用层求职者不必深入编排训练细节，但应能说清成本与能力权衡。消息提到，两个模型通过 OpenAI 兼容 API 提供，现有用户可一行切换；没有开放权重可自托管，且不在欧盟/欧洲经济区提供服务。这几点直接影响方案设计：能否自托管、地域是否可用、切换成本多高，都是应用层要提前确认的。

准备时，可以练习向目标岗位核查：团队是否依赖外部编排服务、有无地域限制、切换模型的成本由谁承担。这些问题的价值，不在于背答案，而在于帮你判断这份工作是否真的需要你补编排能力。

一个实际可做的小建议：挑一个你熟悉的业务场景，写下两种做法——自己选模型，还是交给编排层——并列出各自的成本、延迟和维护代价。带着这份对比去面试，比空谈“我关注多模型”更有说服力。