后端API网关模型推理服务AI Agent【免费下载链接】semantic-routerAn open, programmable decision layer for models and compute.项目地址https://gitcode.com/gh_mirrors/sem/semantic-router点击查看免费下载本篇技术指南聚焦 semantic-router 的决策层Decision在 v0.3 规范配置中信号Signal负责回答路由器检测到了什么而决策层回答路由器据此做什么——哪条路由命中、候选模型有哪些、是否启用推理、路由选定后运行哪些插件。读完本文你将掌握routing.decisions的完整配置语法、single / and / or / not / composite五种决策形态的选型与写法并理解决策引擎在源码层面的求值、排序与命中裁定原理可直接在仓库现有配置片段基础上搭建自己的路由策略。概览决策层在路由流水线中的位置决策Decision是 semantic-router 路由系统的判定中枢。其教程文档与 config/fragments/decision/ 下的布尔形态目录一一对应仓库中的可复用片段树既是文档的索引也是可直接照抄的配置资产。信号说明路由器检测到了什么决策说明路由器据此做什么。具体到一次请求决策层要产出四类答案哪条路由命中候选模型有哪些modelRefs是否启用推理use_reasoning路由选定后运行哪些插件plugins。在源码层面这一职责由 src/semantic-router/pkg/decision/engine.go 中的DecisionEngine承担。它持有[]config.Decision与规则、策略等输入对外暴露EvaluateDecisionsWithSignals/EvaluateDecisionsWithDiagnostics两个求值入口而决策本身的数据结构定义在 src/semantic-router/pkg/config/decision_config.go 的Decision结构体中Name、Priority、Rules、ModelRefs、Algorithm、Plugins等字段一一对应配置语法。主要优势可读性多个信号协作时仍能保持路由策略可读布尔逻辑显式、可 review。解耦将路由匹配与部署绑定、算法、插件解耦——决策只回答谁有资格不关心部署到哪个后端选哪个模型匹配后做什么。可复用直接映射到 config/fragments/decision/ 下可复用的片段目录配置片段可被多条路由、多个 recipe 引用。解决什么问题没有决策层时信号输出无法告诉路由器如何反应。团队容易把路由逻辑散落在临时 if、模型默认和插件 wiring 里——检测逻辑与路由行为混在一起策略难以审计改动牵一发动全身。决策层把命名信号变成清晰的路由策略带稳定优先级与候选模型信号只管检测决策层把检测到了什么翻译成该往哪条路走并且这种翻译是声明式、可版本化、可 review 的。何时使用决策层在以下情况使用decision/一条路由应由一个或多个信号激活同一模型策略要在多种信号组合下复用路由优先级重要多个决策同时命中时需要稳定的胜负裁定插件或算法应挂在已匹配的路由上而不是整台路由器。配置routing.decisions核心语法在 v0.3 中决策位于顶层routing.decisions。最小可用的单条件决策如下来源config/fragments/decision/single/domain-business.yamlrouting: decisions: - name: business_route description: Route business and management questions. priority: 110 rules: operator: AND conditions: - type: domain name: business modelRefs: - model: qwen2.5:3b use_reasoning: false逐字段说明字段含义说明name决策名稳定策略构件可被复用与审计引用description描述可选便于人读priority优先级整数越小越先被考虑多个决策命中时用于排序rules规则树operatorconditionscondition 引用信号类型与名称modelRefs[]候选模型列表每项含model、use_reasoning可选lora_name、weight等algorithm选择算法可选modelRefs有多个候选时用于在候选间做选择plugins路由局部插件可选匹配成功后的后处理从源码看rules在 decision_config.go 中被建模为递归的布尔表达式树RuleNode叶子节点TypeName可带Label/Predicate检查某个命名信号是否命中组合节点Operator∈AND/OR/NOT递归求值子节点。决策引擎的evalNode正是按这棵树的形状做短路求值engine.go。决策匹配与三块分离的部分决策匹配本身与以下部分保持分离各自有独立配置位置providers.models[]部署绑定。决策里的modelRefs引用的是模型逻辑名真正部署在哪个 provider / endpoint 由 providers 配置决定decision.algorithm在多个候选模型间选择。只有modelRefs出现多个候选时才需要见 算法教程decision.plugins匹配路由后的后处理例如语义缓存、system prompt 变更、安全执行见 插件教程。这种匹配、选择、执行三阶段分离使得模型选择演进换算法或路由局部行为调整挂/摘插件都不必改动决策规则本身。五种决策形态片段树与选型对照按下方形态目录顺序与片段树一致决策形态片段示例适用场景教程singleconfig/fragments/decision/single/domain-business.yaml单一决定性信号单条件决策andconfig/fragments/decision/and/urgent-business.yaml多个信号必须同时满足AND 决策orconfig/fragments/decision/or/business-or-law.yaml多种等价触发共用一路由OR 决策notconfig/fragments/decision/not/exclude-jailbreak.yaml显式排除或安全门控NOT 决策compositeconfig/fragments/decision/composite/priority-safe-escalation.yaml嵌套的真实策略组合决策下面逐一展开五种形态的写法与适用边界。single单条件决策在一个信号足以选定路由时使用。这是单一权威检测器路由最干净的入口决策形态最小、易读易审计在加入更多布尔逻辑前是很好的基线。典型场景一个领域信号即权威、一个安全信号应立即拦截、一个偏好信号选择专用模型。即使单条件也保持路由命名与可复用。若策略变复杂可升级为and/、or/或composite/而不改变外层配置结构。仓库中另一个单条件示例 domain-computer-science.yaml 展示了推理档位的写法routing: decisions: - name: computer-science-route description: Route computer science requests to the higher-reasoning model tier. priority: 100 rules: operator: AND conditions: - type: domain name: computer science modelRefs: - model: qwen3-32b use_reasoning: true lora_name: computer-science-expert注意这里额外出现了lora_namemodelRefs中每一项源码中的ModelRef结构体除model、use_reasoning外还支持lora_name与weight等可选字段可在命中该路由时加载对应 LoRA 专家模型。and多条件必须同时满足在多个信号必须全部匹配路由才成立时使用and/。AND是收窄、高置信路由的标准形态要求多个检测器同时命中降低误报适合升级与高端路由复合条件显式而不是藏在一个信号里。典型场景领域与紧急用语必须同时出现、领域与安全许可必须同时通过、偏好与复杂度在升级前应协同满足。routing: decisions: - name: urgent_business_route description: Match only when business intent and urgent language appear together. priority: 140 rules: operator: AND conditions: - type: domain name: business - type: keyword name: urgent_keywords modelRefs: - model: qwen2.5:3b use_reasoning: false源码层面AND 节点在evalAND中逐个求值子节点任一子节点不匹配则整条路由不命中且支持短路短路后其余子节点不再求值降低开销。当模型应仅在窄而高置信的流量片段上激活时使用AND。or等价触发共用一路由在多种等价信号匹配应导向同一路由时使用or/。没有OR时团队常为支持不同匹配条件而复制同一路由逻辑导致漂移与后续策略变更风险OR将等价触发合并为一条路由回退或共享策略路由更紧凑。典型场景两个领域共用同一模型策略、多种信号变体映射到同一回退路由、一个运维插件应对多种独立情况。routing: decisions: - name: business_or_law_route description: Share one route across either business or law traffic. priority: 100 rules: operator: OR conditions: - type: domain name: business - type: domain name: law modelRefs: - model: qwen2.5:3b use_reasoning: falsenot显式排除与安全门控在路由仅当存在风险或不允许的信号缺失时才匹配时使用not/。NOT是决策目录中最简单的排除规则负面策略显式适合安全门控与高端路由排除排除逻辑留在路由图中而不是藏到下游审计更容易因为被否定的信号有命名。典型场景必须排除已知越狱或含 PII 的流量、高端路由应避开不安全输入、升级前某冲突信号必须不存在。routing: decisions: - name: safe_only_route description: Match only when the known prompt-injection signal is absent. priority: 70 rules: operator: NOT conditions: - type: jailbreak name: prompt_injection modelRefs: - model: qwen2.5:3b use_reasoning: false注意这里的优先级取较低值70配合其他路由形成安全门语义。请谨慎使用NOT并保持被排除的信号显式否则决策难以审计。composite单路由内嵌套 AND / OR / NOT在策略需要单条路由内嵌套AND、OR、NOT时使用composite/。适合业务逻辑与安全逻辑必须共存的真实生产策略支持嵌套逻辑无需把策略压成不可读的扁平条件列表业务、运维与安全约束放在同一路由中复杂准入规则显式、可 review。典型场景领域路由需要紧急度或复杂度升级、生产安全策略必须排除不安全流量、一条路由在同一匹配树中结合业务与安全逻辑。routing: decisions: - name: priority_safe_escalation_route description: Combine AND, OR, and NOT for a realistic multi-signal routing case. priority: 160 rules: operator: AND conditions: - type: domain name: business - operator: OR conditions: - type: keyword name: urgent_keywords - type: complexity name: needs_reasoning:hard - operator: NOT conditions: - type: jailbreak name: prompt_injection modelRefs: - model: qwen2.5:3b use_reasoning: true这条策略的语义是请求必须属于 business 领域且含紧急关键词或复杂度被判定为 hard 级且未检测到 prompt injection才进入该高优先级升级路由命中后use_reasoning: true启用推理。这里name: needs_reasoning:hard中的:hard是信号名上的档位label后缀——信号定义在routing.signals中见 信号教程决策层只需引用其名称。深入原理决策引擎如何裁定胜负命中求值布尔树的递归求值当请求进入时各信号检测器先产出SignalMatches在 engine.go 中按信号类型分组保存如DomainRules、KeywordRules、JailbreakRules、ComplexityRules等随后DecisionEngine.evaluateDecisions遍历所有配置决策对每条决策的规则树做递归求值engine.go叶子节点通过matchesSignalType检查命名信号是否在SignalMatches中组合节点按AND/OR/NOT语义合并子节点结果命中时记录Confidence、MatchedRules、ConfidenceScored、CatchAll等信息。值得关注的一个工程细节决策引擎还支持on_unknown策略no_match/match/fail_request定义在 decision_config.go当某信号求值失败未扫描/出错时决定该决策按不匹配匹配还是直接拒绝请求处理这在安全敏感场景如 jailbreak 信号不可用时的 fail-closed非常关键。胜者裁定priority 与 confidence 两种策略多条决策可能同时命中。胜者裁定发生在selectBestDecisionsrc/semantic-router/pkg/decision/selection.go其排序规则如下若任一命中决策声明了tier则按 tier 硬性分层低 tier 优先CatchAll无条件兜底决策源码中通过IsCatchAll识别总是排在真实命中之后其余由routing.strategy决定取值仅两种见 recipes.gopriority默认按priority字段排序数值小者胜出confidence按命中置信度排序——但前提是所有候选的置信度属于同一 score kind例如都是分类器概率或都是向量相似度否则视为不可比较、退回 priority 排序。DecisionEngine构造时若未指定 strategy默认使用RoutingStrategyPriorityengine.go。仓库在src/semantic-router/pkg/decision/下提供了大量契约测试如 engine_contract_matrix_test.go、engine_empty_and_test.go、engine_decision_model_test.go覆盖 AND 空条件、tier 分层、score 谓词等边界可作为理解引擎行为的可执行文档。生产级示例DSL 中的决策表达决策层不仅存在于 YAML也映射到 DSL。仓库维护的balance配方 config/recipes/balance/recipe.dsl 展示了真实生产策略中的决策写法例如ROUTE premium_legal (description Premium-only route for high-value legal and compliance analysis.) { WHEN (domain(law) OR keyword(legal_risk_markers)) AND (embedding(premium_legal_analysis) OR projection(verification_required) OR complexity(legal_risk:medium) OR complexity(legal_risk:hard)) AND NOT (keyword(normative_topic_markers) AND keyword(argument_request_markers) AND NOT (keyword(legal_risk_markers) OR complexity(legal_risk:hard))) ... }可以看到DSL 的WHEN子句与 YAML 的rules布尔树是同一模型的两面domain(...)/keyword(...)/embedding(...)/complexity(...)/projection(...)是叶子信号引用括号内的嵌套布尔表达式直接对应AND/OR/NOT组合节点。DSL 与 YAML 可以互相编译仓库在 src/semantic-router/pkg/dsl/ 中提供了解析与反编译实现这意味着你可以用 DSL 编写可读性更强的策略再导出为规范 YAML 部署。下一步若modelRefs中有多个候选请配合 算法教程 掌握decision.algorithm的选型若路由需要选中后的行为缓存、RAG、安全、变更请求等请配合 插件教程想了解信号如何命名与产出domain、keyword、complexity、jailbreak 等被决策引用的检测器阅读 信号教程其中分区与派生路由档位routing.projections也是决策type: projection条件的输入来源完整公开约定见仓库根级 config/config.yaml可复用的决策片段全部位于 config/fragments/decision/生产级示例见 config/recipes/balance/config.yaml 与 config/recipes/balance/recipe.dsl。赞分享后端API网关模型推理服务AI Agent【免费下载链接】semantic-routerAn open, programmable decision layer for models and compute.项目地址https://gitcode.com/gh_mirrors/sem/semantic-router点击查看免费下载相关推荐semantic-router 信号层Signal完全指南把请求事实变成可复用路由决策semantic router 信号层Signal完全指南把请求事实变成可复用路由决策 导读 本文是 semantic router一个开放、可编程的模后端API网关模型推理服务AI Agentsemantic-router 信号体系Signal完全指南把请求事实变成可复用的路由决策基石semantic router 信号体系Signal完全指南把请求事实变成可复用的路由决策基石 在 semantic router 中Signal信号后端API网关模型推理服务AI Agentsemantic-router 事实核查信号路由fact_check实战指南配置、决策规则与幻觉防御semantic router 事实核查信号路由fact_check实战指南配置、决策规则与幻觉防御 本指南基于 Semantic Router 的 fa后端API网关模型推理服务AI Agent创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/10/14 0:14:05 · 阅读 1.2k semantic-router 决策层（Decision）实战指南：用布尔规则把信号变成可审计的路由策略
后端API网关模型推理服务AI Agent【免费下载链接】semantic-routerAn open, programmable decision layer for models and compute.项目地址https://gitcode.com/gh_mirrors/sem/semantic-router点击查看免费下载本篇技术指南聚焦 semantic-router 的决策层Decision在 v0.3 规范配置中信号Signal负责回答路由器检测到了什么而决策层回答路由器据此做什么——哪条路由命中、候选模型有哪些、是否启用推理、路由选定后运行哪些插件。读完本文你将掌握routing.decisions的完整配置语法、single / and / or / not / composite五种决策形态的选型与写法并理解决策引擎在源码层面的求值、排序与命中裁定原理可直接在仓库现有配置片段基础上搭建自己的路由策略。概览决策层在路由流水线中的位置决策Decision是 semantic-router 路由系统的判定中枢。其教程文档与 config/fragments/decision/ 下的布尔形态目录一一对应仓库中的可复用片段树既是文档的索引也是可直接照抄的配置资产。信号说明路由器检测到了什么决策说明路由器据此做什么。具体到一次请求决策层要产出四类答案哪条路由命中候选模型有哪些modelRefs是否启用推理use_reasoning路由选定后运行哪些插件plugins。在源码层面这一职责由 src/semantic-router/pkg/decision/engine.go 中的DecisionEngine承担。它持有[]config.Decision与规则、策略等输入对外暴露EvaluateDecisionsWithSignals/EvaluateDecisionsWithDiagnostics两个求值入口而决策本身的数据结构定义在 src/semantic-router/pkg/config/decision_config.go 的Decision结构体中Name、Priority、Rules、ModelRefs、Algorithm、Plugins等字段一一对应配置语法。主要优势可读性多个信号协作时仍能保持路由策略可读布尔逻辑显式、可 review。解耦将路由匹配与部署绑定、算法、插件解耦——决策只回答谁有资格不关心部署到哪个后端选哪个模型匹配后做什么。可复用直接映射到 config/fragments/decision/ 下可复用的片段目录配置片段可被多条路由、多个 recipe 引用。解决什么问题没有决策层时信号输出无法告诉路由器如何反应。团队容易把路由逻辑散落在临时 if、模型默认和插件 wiring 里——检测逻辑与路由行为混在一起策略难以审计改动牵一发动全身。决策层把命名信号变成清晰的路由策略带稳定优先级与候选模型信号只管检测决策层把检测到了什么翻译成该往哪条路走并且这种翻译是声明式、可版本化、可 review 的。何时使用决策层在以下情况使用decision/一条路由应由一个或多个信号激活同一模型策略要在多种信号组合下复用路由优先级重要多个决策同时命中时需要稳定的胜负裁定插件或算法应挂在已匹配的路由上而不是整台路由器。配置routing.decisions核心语法在 v0.3 中决策位于顶层routing.decisions。最小可用的单条件决策如下来源config/fragments/decision/single/domain-business.yamlrouting: decisions: - name: business_route description: Route business and management questions. priority: 110 rules: operator: AND conditions: - type: domain name: business modelRefs: - model: qwen2.5:3b use_reasoning: false逐字段说明字段含义说明name决策名稳定策略构件可被复用与审计引用description描述可选便于人读priority优先级整数越小越先被考虑多个决策命中时用于排序rules规则树operatorconditionscondition 引用信号类型与名称modelRefs[]候选模型列表每项含model、use_reasoning可选lora_name、weight等algorithm选择算法可选modelRefs有多个候选时用于在候选间做选择plugins路由局部插件可选匹配成功后的后处理从源码看rules在 decision_config.go 中被建模为递归的布尔表达式树RuleNode叶子节点TypeName可带Label/Predicate检查某个命名信号是否命中组合节点Operator∈AND/OR/NOT递归求值子节点。决策引擎的evalNode正是按这棵树的形状做短路求值engine.go。决策匹配与三块分离的部分决策匹配本身与以下部分保持分离各自有独立配置位置providers.models[]部署绑定。决策里的modelRefs引用的是模型逻辑名真正部署在哪个 provider / endpoint 由 providers 配置决定decision.algorithm在多个候选模型间选择。只有modelRefs出现多个候选时才需要见 算法教程decision.plugins匹配路由后的后处理例如语义缓存、system prompt 变更、安全执行见 插件教程。这种匹配、选择、执行三阶段分离使得模型选择演进换算法或路由局部行为调整挂/摘插件都不必改动决策规则本身。五种决策形态片段树与选型对照按下方形态目录顺序与片段树一致决策形态片段示例适用场景教程singleconfig/fragments/decision/single/domain-business.yaml单一决定性信号单条件决策andconfig/fragments/decision/and/urgent-business.yaml多个信号必须同时满足AND 决策orconfig/fragments/decision/or/business-or-law.yaml多种等价触发共用一路由OR 决策notconfig/fragments/decision/not/exclude-jailbreak.yaml显式排除或安全门控NOT 决策compositeconfig/fragments/decision/composite/priority-safe-escalation.yaml嵌套的真实策略组合决策下面逐一展开五种形态的写法与适用边界。single单条件决策在一个信号足以选定路由时使用。这是单一权威检测器路由最干净的入口决策形态最小、易读易审计在加入更多布尔逻辑前是很好的基线。典型场景一个领域信号即权威、一个安全信号应立即拦截、一个偏好信号选择专用模型。即使单条件也保持路由命名与可复用。若策略变复杂可升级为and/、or/或composite/而不改变外层配置结构。仓库中另一个单条件示例 domain-computer-science.yaml 展示了推理档位的写法routing: decisions: - name: computer-science-route description: Route computer science requests to the higher-reasoning model tier. priority: 100 rules: operator: AND conditions: - type: domain name: computer science modelRefs: - model: qwen3-32b use_reasoning: true lora_name: computer-science-expert注意这里额外出现了lora_namemodelRefs中每一项源码中的ModelRef结构体除model、use_reasoning外还支持lora_name与weight等可选字段可在命中该路由时加载对应 LoRA 专家模型。and多条件必须同时满足在多个信号必须全部匹配路由才成立时使用and/。AND是收窄、高置信路由的标准形态要求多个检测器同时命中降低误报适合升级与高端路由复合条件显式而不是藏在一个信号里。典型场景领域与紧急用语必须同时出现、领域与安全许可必须同时通过、偏好与复杂度在升级前应协同满足。routing: decisions: - name: urgent_business_route description: Match only when business intent and urgent language appear together. priority: 140 rules: operator: AND conditions: - type: domain name: business - type: keyword name: urgent_keywords modelRefs: - model: qwen2.5:3b use_reasoning: false源码层面AND 节点在evalAND中逐个求值子节点任一子节点不匹配则整条路由不命中且支持短路短路后其余子节点不再求值降低开销。当模型应仅在窄而高置信的流量片段上激活时使用AND。or等价触发共用一路由在多种等价信号匹配应导向同一路由时使用or/。没有OR时团队常为支持不同匹配条件而复制同一路由逻辑导致漂移与后续策略变更风险OR将等价触发合并为一条路由回退或共享策略路由更紧凑。典型场景两个领域共用同一模型策略、多种信号变体映射到同一回退路由、一个运维插件应对多种独立情况。routing: decisions: - name: business_or_law_route description: Share one route across either business or law traffic. priority: 100 rules: operator: OR conditions: - type: domain name: business - type: domain name: law modelRefs: - model: qwen2.5:3b use_reasoning: falsenot显式排除与安全门控在路由仅当存在风险或不允许的信号缺失时才匹配时使用not/。NOT是决策目录中最简单的排除规则负面策略显式适合安全门控与高端路由排除排除逻辑留在路由图中而不是藏到下游审计更容易因为被否定的信号有命名。典型场景必须排除已知越狱或含 PII 的流量、高端路由应避开不安全输入、升级前某冲突信号必须不存在。routing: decisions: - name: safe_only_route description: Match only when the known prompt-injection signal is absent. priority: 70 rules: operator: NOT conditions: - type: jailbreak name: prompt_injection modelRefs: - model: qwen2.5:3b use_reasoning: false注意这里的优先级取较低值70配合其他路由形成安全门语义。请谨慎使用NOT并保持被排除的信号显式否则决策难以审计。composite单路由内嵌套 AND / OR / NOT在策略需要单条路由内嵌套AND、OR、NOT时使用composite/。适合业务逻辑与安全逻辑必须共存的真实生产策略支持嵌套逻辑无需把策略压成不可读的扁平条件列表业务、运维与安全约束放在同一路由中复杂准入规则显式、可 review。典型场景领域路由需要紧急度或复杂度升级、生产安全策略必须排除不安全流量、一条路由在同一匹配树中结合业务与安全逻辑。routing: decisions: - name: priority_safe_escalation_route description: Combine AND, OR, and NOT for a realistic multi-signal routing case. priority: 160 rules: operator: AND conditions: - type: domain name: business - operator: OR conditions: - type: keyword name: urgent_keywords - type: complexity name: needs_reasoning:hard - operator: NOT conditions: - type: jailbreak name: prompt_injection modelRefs: - model: qwen2.5:3b use_reasoning: true这条策略的语义是请求必须属于 business 领域且含紧急关键词或复杂度被判定为 hard 级且未检测到 prompt injection才进入该高优先级升级路由命中后use_reasoning: true启用推理。这里name: needs_reasoning:hard中的:hard是信号名上的档位label后缀——信号定义在routing.signals中见 信号教程决策层只需引用其名称。深入原理决策引擎如何裁定胜负命中求值布尔树的递归求值当请求进入时各信号检测器先产出SignalMatches在 engine.go 中按信号类型分组保存如DomainRules、KeywordRules、JailbreakRules、ComplexityRules等随后DecisionEngine.evaluateDecisions遍历所有配置决策对每条决策的规则树做递归求值engine.go叶子节点通过matchesSignalType检查命名信号是否在SignalMatches中组合节点按AND/OR/NOT语义合并子节点结果命中时记录Confidence、MatchedRules、ConfidenceScored、CatchAll等信息。值得关注的一个工程细节决策引擎还支持on_unknown策略no_match/match/fail_request定义在 decision_config.go当某信号求值失败未扫描/出错时决定该决策按不匹配匹配还是直接拒绝请求处理这在安全敏感场景如 jailbreak 信号不可用时的 fail-closed非常关键。胜者裁定priority 与 confidence 两种策略多条决策可能同时命中。胜者裁定发生在selectBestDecisionsrc/semantic-router/pkg/decision/selection.go其排序规则如下若任一命中决策声明了tier则按 tier 硬性分层低 tier 优先CatchAll无条件兜底决策源码中通过IsCatchAll识别总是排在真实命中之后其余由routing.strategy决定取值仅两种见 recipes.gopriority默认按priority字段排序数值小者胜出confidence按命中置信度排序——但前提是所有候选的置信度属于同一 score kind例如都是分类器概率或都是向量相似度否则视为不可比较、退回 priority 排序。DecisionEngine构造时若未指定 strategy默认使用RoutingStrategyPriorityengine.go。仓库在src/semantic-router/pkg/decision/下提供了大量契约测试如 engine_contract_matrix_test.go、engine_empty_and_test.go、engine_decision_model_test.go覆盖 AND 空条件、tier 分层、score 谓词等边界可作为理解引擎行为的可执行文档。生产级示例DSL 中的决策表达决策层不仅存在于 YAML也映射到 DSL。仓库维护的balance配方 config/recipes/balance/recipe.dsl 展示了真实生产策略中的决策写法例如ROUTE premium_legal (description Premium-only route for high-value legal and compliance analysis.) { WHEN (domain(law) OR keyword(legal_risk_markers)) AND (embedding(premium_legal_analysis) OR projection(verification_required) OR complexity(legal_risk:medium) OR complexity(legal_risk:hard)) AND NOT (keyword(normative_topic_markers) AND keyword(argument_request_markers) AND NOT (keyword(legal_risk_markers) OR complexity(legal_risk:hard))) ... }可以看到DSL 的WHEN子句与 YAML 的rules布尔树是同一模型的两面domain(...)/keyword(...)/embedding(...)/complexity(...)/projection(...)是叶子信号引用括号内的嵌套布尔表达式直接对应AND/OR/NOT组合节点。DSL 与 YAML 可以互相编译仓库在 src/semantic-router/pkg/dsl/ 中提供了解析与反编译实现这意味着你可以用 DSL 编写可读性更强的策略再导出为规范 YAML 部署。下一步若modelRefs中有多个候选请配合 算法教程 掌握decision.algorithm的选型若路由需要选中后的行为缓存、RAG、安全、变更请求等请配合 插件教程想了解信号如何命名与产出domain、keyword、complexity、jailbreak 等被决策引用的检测器阅读 信号教程其中分区与派生路由档位routing.projections也是决策type: projection条件的输入来源完整公开约定见仓库根级 config/config.yaml可复用的决策片段全部位于 config/fragments/decision/生产级示例见 config/recipes/balance/config.yaml 与 config/recipes/balance/recipe.dsl。赞分享后端API网关模型推理服务AI Agent【免费下载链接】semantic-routerAn open, programmable decision layer for models and compute.项目地址https://gitcode.com/gh_mirrors/sem/semantic-router点击查看免费下载相关推荐semantic-router 信号层Signal完全指南把请求事实变成可复用路由决策semantic router 信号层Signal完全指南把请求事实变成可复用路由决策 导读 本文是 semantic router一个开放、可编程的模后端API网关模型推理服务AI Agentsemantic-router 信号体系Signal完全指南把请求事实变成可复用的路由决策基石semantic router 信号体系Signal完全指南把请求事实变成可复用的路由决策基石 在 semantic router 中Signal信号后端API网关模型推理服务AI Agentsemantic-router 事实核查信号路由fact_check实战指南配置、决策规则与幻觉防御semantic router 事实核查信号路由fact_check实战指南配置、决策规则与幻觉防御 本指南基于 Semantic Router 的 fa后端API网关模型推理服务AI Agent创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考