Workbuddy 的模型路由怎么配置？Base URL、模型名和主备规则该按什么顺序填？

Workbuddy 配置模型路由按「通道—模型—规则」三步走：先在模型服务设置里新增一个 OpenAI 兼容通道，填好 Base URL 与 API Key；再把要用的模型名逐个登记；最后在路由规则里指定默认模型、备选顺序和超时重试，保存后用一次低成本的短请求验证连通与计费即可生效。只使用单个模型、单个 Key 的场景不需要这套流程。 Workbuddy 里的路由由通道、模型、规则三个相互引用的对象组成，并非一个开关，少配一层请求就会落到默认通道或直接失败。通道保存地址与鉴权信息，模型是通道下的可选项，规则决定按什么条件挑哪一个。实际排障中大量问题都来自模型没登记却先写了规则，结果规则保存成功、调用时才报模型不存在。 Base URL 要填到服务商文档给出的版本根路径，多数 OpenAI 兼容中转以 /v1 结尾，客户端会自动拼接 /chat/completions。多填一层路径会返回 404，而部分自建网关本身不带 /v1，直接照抄示例同样连不通。稳妥做法是先用客户端内置的测试按钮或一次模型列表请求确认根路径可用，再回头保存通道。 一个通道只放一个 Key，并按开发、测试、生产分环境建 Key，可以避免同一密钥在多环境混用造成限流相互挤占、费用无法归因。密钥不要写进前端代码或共享脚本；轮换时先新增再删除，保留旧 Key 一段时间，防止正在跑的定时任务突然全部鉴权失败。 登记的模型名必须与中转侧返回的名称完全一致，大小写和版本后缀都要对上。按业务起别名时要映射到真实模型名，不要直接把别名当模型名提交，否则调用侧看到的是模型不存在而非参数错误。把模型名错误与密钥错误分开排查，能省掉大量反复重填的时间。 路由规则按任务类型分层最实用：长文本总结走上下文长的模型，短问答走便宜且响应快的模型，代码补全走专用模型，每条规则至少配一个备选，主模型返回限流或超时时自动切换。对输出确定性要求高的场景，例如结构化抽取后直接写库，不建议开自动兜底，不同模型的格式遵循度不一致，切换后反而增加清洗与校验成本。 并发上限、单请求超时、重试次数三个参数要一起确定，重试次数设得过高会在限流时成倍放大请求量，延迟和费用同步上涨。可行做法是把超时设成业务能接受的上限，重试只对限流和 5xx 生效，参数类 4xx 错误直接失败不重试，避免用重试掩盖配置问题。 首次验证用 max_tokens 很小的短请求，比对返回的 token 用量与账单口径是否一致。按量计费下成本由输入长度、输出长度和调用次数共同决定，路由把请求分给不同模型时单位成本会变化，因此规则里最好标注每个模型的价格档位，便于事后核对哪条规则在推高成本。 新通道上线先接一个小入口或一小部分流量，观察一段时间错误率和延迟再逐步放大，不要一次性全量切换。回滚方式是把规则里的默认通道改回原值，不要直接删除通道，删除会让历史密钥与调用日志一起丢失，事后定位问题就没了依据。 错误码可以按 401、404、429、400 的顺序对照排查：401 查密钥是否失效或带空格，404 查 Base URL 路径与模型名，429 查并发与限流，400 多半是请求参数或模型版本不匹配。按这个顺序查比逐项重填配置快得多，也能避免把限流问题误判成密钥问题。 配置完成后按四项验收：测试连通、核对用量、验证主备切换、确认回滚路径。四项都过再放量，任何一项缺失都会在上游波动时暴露成线上故障。路由的价值在于把模型差异和故障隔离开，配置复杂度必须换来确定性，否则不如直连单一模型。 对首字延迟不敏感的离线批处理任务，不必为低延迟额外准备备选模型，多一条规则就多一份维护成本。反过来，面向终端用户的实时问答，主备切换和超时阈值才是必须项，规则可以少，但兜底不能省。配置粒度应当跟着业务对稳定性的真实要求走，而不是把能开的选项全部打开。