前言¶

做 Agent 类应用时，命理相关的功能往往不止一个模块：八字要排四柱，紫微要看命宫，奇门要看盘局。这些模块可能来自不同的上游接口，返回格式、校验口径并不统一。更麻烦的是回向规则——同一次推算里，主盘结果和校验结果对不上时，该信谁、该不该把结果给用户，往往只能靠各模块各自判断，规则散落在调用方。

下面介绍的 Skill 「命理推算网关」就是处理这件事的：它把多个命理模块的排盘接口和回向规则统一管控起来，并明确了哪个是权威基准、什么情况下允许降级、什么情况下必须阻断。

这是什么¶

「命理推算网关」是一个社区来源的通用 SKILL.md 格式 Skill，坐标 @user_bb5d057c/mingli-gateway，当前版本 1.0.0，由 user_bb5d057c 发布维护，分类为 ai-agent。

它解决的问题是：当一次命理推算同时涉及八字、紫微、奇门等模块时，用一套统一的规则决定哪个模块的结果可以作为主盘呈现、哪个只作校验、以及主盘不可用时能否用本地引擎兜底。

核心功能¶

根据官方简介，这个 Skill 的能力可以拆成三点：

1. 统一管控八字、紫微、奇门等命理模块的排盘接口与回向规则，调用方不需要自己维护一套跨模块的取舍逻辑。
2. 规定 aov-mingyu-api 为权威主盘与四柱校验基准。也就是说，八字四柱的校验口径以 aov-mingyu-api 为准，其他模块的结果与它对齐。
3. 内置本地 fallback 引擎策略。当 aov-mingyu-api 不稳定或缺失功能时，允许使用本地引擎兜底，但附带了严格的放行条件。

回向规则：降级允许，放行有条件¶

这一节是这个 Skill 最需要留意的部分，也是它和「随便加个 fallback」的做法的区别在于：

• 当 aov-mingyu-api 正常时，以它的结果作为主盘与四柱校验基准。
• 当 aov-mingyu-api 不稳定或缺失功能时，可以启用本地 fallback 引擎。
• 任何非 aov 来源的结果，只有在四柱与 aov-mingyu-api 严格对齐时，才可以向用户呈现。
• 对齐不成立时，该次结果视为失效并阻断，不向用户返回。

换句话说，fallback 不是「主盘挂了就用本地结果顶上」，而是「本地结果必须先通过 aov 口径的四柱校验，才有资格被呈现」。校验不通过就阻断，宁可不出结果，也不出一套口径不一致的盘。

安装与启用¶

官方地址：https://api.skillhub.cn/user_bb5d057c/mingli-gateway
SkillHub 页面：https://www.skillhub.cn/skills/user_bb5d057c/mingli-gateway

需要说明的是，撰写本文时上述两个地址均无法访问，因此安装命令、目录约定和配置字段未能从官方资料核实，这里不给出未经验证的命令。从元数据看，该 Skill 标记为 requires_api_key=false，即不要求提供 API Key。安装与启用方式请以官方页面的说明为准。

适用场景与注意¶

适合的场景：

• 同一 Agent 流程里需要同时调用八字、紫微、奇门等多个命理模块，希望回向规则集中管理，而不是分散在各调用方。
• 对四柱口径的一致性有要求，需要以 aov-mingyu-api 作为统一基准做校验。
• 希望在上游接口不稳定时有本地兜底路径，但不愿意接受「兜底结果直接呈现」这种做法。

需要注意的地方：

• 该 Skill 来源为 community，发布者 user_bb5d057c，使用前应自行确认上游 aov-mingyu-api 的可用性与授权方式。
• 阻断是设计上的默认行为：四柱与 aov-mingyu-api 对齐失败时不会返回结果。如果业务上无法接受「无结果」，需要在调用侧自行处理。
• 元数据显示安装数为 0，说明目前使用量极低，遇到问题时缺少社区验证案例，排障需要自己动手。

结尾¶

命理推算网关的价值不在于新增一个排盘能力，而在于把「谁主盘、谁校验、什么时候可以降级、什么时候必须阻断」这套规则固定下来，让调用方不必各自判断。如果你的 Agent 里同时跑着多个命理模块，并且关心结果口径是否一致，可以把它作为规则层引入。

官方地址：https://api.skillhub.cn/user_bb5d057c/mingli-gateway