Wenyi模型路由架构完整解析操作注册、档位路由与显式故障转移设计【免费下载链接】wenyi将被语言阻隔的作品带到读者的语言中。Bringing literature into your language.项目地址: https://gitcode.com/BigDawnGhost/wenyiWenyi文意是一个面向多语言小说翻译的开源项目其模型路由系统把每个翻译步骤该用哪个大模型这件事拆解为三个清晰的层次操作注册Operation Registry、档位路由Tier Routing与显式故障转移Explicit Failover。本文用通俗的方式带你理解这套架构为什么把模型选择和业务流程解耦能让翻译流水线在稳定性、成本与可维护性之间取得平衡。一、为什么需要模型路由一次完整的小说翻译并不是一次大模型调用而是一整条流水线语言检测、风格分析、章节摘要、正文翻译、标题翻译、润色、术语抽取、审阅与自动修复……每个步骤对模型的能力要求和成本敏感度都不同。如果把所有步骤都用同一个最强模型作为方案代价高昂如果全部用便宜模型质量无法保证。Wenyi 的答案是每一步骤都注册为一个命名操作每个操作绑定一个质量档位再由档位映射到具体的模型配置。二、第一层操作注册operations.py所有由模型驱动的流水线步骤都在 operations.py 中集中注册。注册表定义了 15 个操作例如language.detect检测源语言→ 绑定cheap档位analysis.style分析文风与人物→ 绑定strong档位synopsis.chapter章节摘要→ 绑定fast档位translation.body正文翻译→ 绑定strong档位review.verify证据验证审阅→ 绑定strong档位且标记为可续接会话注册阶段就完成了一连串严格校验校验规则设计意图操作 ID 必须是小写字母加下划线的两段式命名防止命名混乱保证全局唯一每个操作必须恰好指定默认档位或默认继承不允许一个操作既选档位又选继承继承链不允许成环避免路由解析无限递归未知操作直接抛错宁可在启动时报错也不静默挑选一个任意模型关键点注册表是不可变的。所有操作在程序启动时一次性验证并发布运行期不允许再修改——这意味着路由行为在任何一次运行中都完全可预测。部分操作还支持inherits继承例如autofix.verify直接继承review.verify的路由。当你在配置里单独为review.verify指定模型时自动修复阶段的验证操作会自动跟随无需重复配置。三、第二层档位路由strong / cheap / fast在 operations.py 中定义了三个固定档位TIERS (strong, cheap, fast)档位是产品语义模型是实现细节。配置文件中llm.tiers必须恰好定义这三个档位每个档位指向一个模型配置档案model profilestrong强模型档正文翻译、风格分析、证据验证等质量敏感步骤cheap廉价档语言检测、初轮审阅等大批量低成本步骤fast快速档章节摘要、术语抽取等高频轻量步骤这种分层带来的好处非常实际一键换模型想给全文翻译换一个更强的模型只需修改strong档指向的档案所有绑定该档位的操作同时生效。预设简化配置在 config.yaml 中只需写一行preset: deepseek即可展开为完整的供应商 模型 档位配置再按需覆盖个别操作。显式路由覆盖llm.routes下可为任一操作指定model具体档案或tier档位二者只能选其一配置时即被校验。配置解析逻辑位于 routing.py其resolve_routes函数会一次性编译出全部操作的路由且不涉及任何凭证、SDK 初始化或网络请求——这意味着我的配置到底会路由到哪些模型可以在启动前完全验证。四、第三层显式故障转移Failover当主模型请求失败时怎么办Wenyi 的设计答案是显式、白名单式的故障转移而非随便找个备用。4.1 只转移可重试的瞬时错误retrying.py 负责错误分类只有 408/409/429/5xx、连接超时、空响应等瞬时错误才具备转移资格TLS 证书错误、URL 配置错误等永久性错误会立即失败绝不浪费一次故障转移。4.2 路由中的 fallbacks 列表在 configuration.py 的RouteConfig中每条路由可以声明fallbacks——一组按顺序排列的备用模型档案。配置校验会确保备用模型真实存在、且不与主模型重复。router.py 的RoutedLLMClient在每次调用时冻结一条路由计划主模型 依次排列的备用模型。执行流程为请求主模型失败且错误可重试 → 发出llm_model_failover事件切换到下一备用全部耗尽或错误不可重试 → 向上抛出异常。每次尝试都会写入统一的事件与用量账本llm_request_scheduled/llm_request_started/llm_request_completed/llm_request_failed因此整条故障转移链路在界面上完全可见、可审计。4.3 一条重要的安全红线注意 routing.py 中的这条校验允许续接会话resumable conversation的操作禁止启用故障转移。像review.verify、review.arbitrate这类多轮证据验证操作中途换模型会让前半段用 A 模型、后半段用 B 模型的会话状态变得不可信。因此这类操作要么依赖单模型内的自动重试要么在会话层整体恢复——这是宁可中断重来不可静默换脑的保守设计。五、指纹与可观测性路由是可冻结的routing.py 中还有一组精巧的工具canonical_json SHA-256 生成的推理指纹fingerprint。每条路由都会得到唯一的provider_identity、model_identity和fingerprint它把供应商类型、端点、模型名、协议版本、参数选项全部纳入哈希。这带来两个实用能力变更检测改任何一个模型选项指纹立刻变化缓存与审阅历史可以据此判断当时的推理环境是否已改变快照留档inference_snapshot可以导出整份操作 → 主/备模型指纹快照随运行状态一起保存事后复盘时能精确还原每个步骤当时用的模型。六、供应商适配层注册制 选项保护模型供应商DeepSeek、OpenAI、Gemini、Ollama、vLLM、OpenRouter 等统一在 registry.py 中注册。每个供应商声明自己的客户端类与选项类注册阶段不实例化任何 SDK——校验配置和真正发请求被彻底分离。特别值得一提的是选项保护机制用户自定义的模型选项中禁止出现api_key、base_url、model、max_tokens等保留字段。这是为了防止某个配置项越权改写路由决策或凭证来源——路由归路由、凭证归凭证、协议归协议三者各守其界。七、小结三层架构如何协作层次核心文件回答的问题操作注册operations.py流水线有哪些模型步骤各自的默认档位与继承关系档位路由routing.py、configuration.py每个步骤最终落到哪个供应商、哪个模型显式故障转移router.py、retrying.py主模型挂了何时、按什么顺序切换到哪个备用整套架构的哲学可以概括为一句话把用哪个模型从业务流程代码中彻底剥离变成一份可校验、可编译、可指纹化、可审计的纯数据。对新手用户而言日常只需修改 config.yaml 里的档位指向与预设对进阶用户wenyi models list可以随时查看生效中的完整路由对维护者不可变注册表 启动时全量校验 运行期事件账本让每一次模型调用都有据可查。这也正是 Wenyi 能将被语言阻隔的作品稳定地带到读者的语言中的底层保障之一。【免费下载链接】wenyi将被语言阻隔的作品带到读者的语言中。Bringing literature into your language.项目地址: https://gitcode.com/BigDawnGhost/wenyi创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考