OpenFate Bazi MCP 实战：TypeScript 确定性引擎如何避免大模型直接计算八字

大语言模型擅长理解问题、组织语言和生成解释，但它并不适合直接执行需要严格一致性的历法与时间计算。

在开发 OpenFate 的过程中，我们遇到了一个典型问题：如果直接让大模型根据出生日期“计算”四柱八字，它往往能给出格式完整、语言流畅的结果，但结果不一定可复现，也未必遵循统一的历法、时区和换日规则。

为了解决这个问题，我们采用了“确定性计算在前，AI 解释在后”的架构，并通过 Model Context Protocol（MCP）把八字计算能力提供给 Claude、Cursor、Codex、Cline 等 AI Agent。

为什么不能让大模型直接计算八字

大语言模型的核心任务是根据上下文预测下一个 Token。它可以解释算法，却不应该被当作历法计算器。

八字排盘涉及多项需要明确规则的计算：

• 公历与农历日期转换
• 出生地时区和历史时间偏移
• 日柱换日边界
• 经度与真太阳时校正
• 年柱、月柱、日柱和时柱计算
• 十神、藏干、纳音、旬空与十二长生
• 大运起运日期、年龄和周期
• 地支之间的冲、合、刑、破、害等关系

如果这些步骤交给语言模型自由生成，即使输入完全相同，也可能得到不同结果。

更危险的是，错误结果通常看起来非常合理。用户看到的是一份语言通顺的回答，却无法判断底层计算是否正确。

OpenFate 的计算优先架构

OpenFate 将计算和解释拆分成两个独立层次：

用户输入 ↓ 输入验证与标准化 ↓ 确定性八字计算引擎 ↓ 结构化事实与计算元数据 ↓ MCP 工具调用 ↓ AI 根据已计算证据生成解释

在这个流程中，语言模型不负责猜测四柱。它只能读取计算引擎返回的结构化结果，并围绕这些证据进行说明。

概念代码可以简化为：

constnormalizedInput=validateAndNormalize(userInput);constchartFacts=awaitcallMcpTool('calculate_bazi_chart',normalizedInput,);constexplanation=awaitexplainWithAI({evidence:chartFacts,instruction:['只解释已经提供的计算结果','不要重新计算或修改四柱','没有证据时明确说明资料不足','不要输出保证性预测',],});

这样做的重点不是让 AI “更会算”，而是从架构上取消 AI 自行计算的权限。

为什么使用 MCP

MCP 是连接 AI Agent 与外部工具的开放协议。它允许模型先识别用户需求，再调用一个具有明确输入和输出 Schema 的工具。

OpenFate Bazi MCP 目前提供六个确定性工具：

calculate_bazi_chart detect_bazi_interactions calculate_true_solar_time reverse_bazi_to_solar_times get_openfate_bazi_policy get_openfate_bazi_resources

这些工具分别负责：

• 生成结构化四柱命盘
• 检测地支冲、合、三合、三会、刑、破和害
• 根据经度、时区与均时差计算真太阳时
• 根据已知四柱反查可能的公历时间候选
• 返回当前计算规则与边界
• 返回可供 Agent 使用的八字计算资源

反查工具返回的是候选时间，而不是未经验证的唯一答案。这类边界必须同时写入工具描述、Schema 和 Agent 使用说明，不能只依赖模型自行理解。

本地 stdio 架构

OpenFate Bazi MCP 通过 npm 发布，并使用本地stdio传输。安装命令为：

npx-y@openfate/bazi-mcp

MCP 客户端配置示例：

{"mcpServers":{"openfate-bazi":{"command":"npx","args":["-y","@openfate/bazi-mcp"]}}}

这种设计有两个重要优势：

1. 计算在本地 MCP 进程中完成，不要求把出生资料发送到额外的 OpenFate HTTP 计算接口。
2. Claude、Cursor、Codex 和其他兼容 MCP 的客户端可以使用同一套工具协议。

公开 MCP 服务器只负责事实计算，不包含私人报告逻辑、格局评分、用神策略或未来预测。计算层和产品解释层保持独立，能够减少职责混乱。

结构化结果包含什么

calculate_bazi_chart返回的不只是四组干支，还包括：

• 标准化后的公历、农历与实际计算时间
• 时区、换日规则和计算策略元数据
• 真太阳时是否启用及其校正结果
• 年、月、日、时四柱
• 十神与藏干
• 纳音、旬和旬空
• 十二长生
• 大运起运日期和时间差
• 每步大运对应的年份、年龄、干支与十神

这些字段可以被测试、比较和审计。语言模型只能在这个事实集合上进行解释，而不能静默替换底层数据。

如何保证结果可复现

确定性架构仍然需要严格测试。我们的验证重点包括：

1. 固定输入测试

相同的出生时间、时区、经度和计算选项，必须得到相同结果。

2. 边界时间测试

重点覆盖换日边界、跨时区、夏令时、午夜附近时间和真太阳时可能改变时柱的情况。

3. Schema 验证

MCP 工具的输入和输出都要通过结构验证。缺少必要字段时应明确失败，不能让模型补造数据。

4. 计算规则元数据

结果需要携带计算版本和策略信息。发生规则升级时，开发者才能知道差异来自哪里。

5. AI 边界测试

解释层不得修改四柱、创造不存在的计算事实，或把候选结果描述成确定结论。

MCP 工具描述同样重要

Agent 是否正确调用工具，不只取决于工具名称。

一个高质量的 MCP 工具描述需要说明：

• 工具具体解决什么问题
• 哪些情况下应该调用
• 哪些情况下不应该调用
• 每个参数的语义与限制
• 返回结果是事实、候选还是解释
• 是否存在外部副作用
• 哪些结果不能被视为保证

如果工具描述只写“计算八字”，模型仍然可能错误选择参数，或者误解返回结果。

因此，MCP 开发不只是把现有函数包一层协议，还需要重新审视工具边界、输入语义和模型可理解性。

这种架构不只适用于八字

“确定性计算 + AI 解释”是一种可以复用的 AI 产品架构。

它同样适用于：

• 财务指标计算
• 教育测评
• 法律条款检索
• 医疗信息整理
• 工程模拟
• 日历与时区工具
• 数据分析报告

凡是底层事实需要稳定、可复现和可审计的场景，都不应该让语言模型同时负责计算事实和解释事实。

更合理的职责划分是：

程序负责确定性事实 AI 负责语言、上下文与交互 验证层负责阻止越界输出

总结

在 OpenFate 的架构中，AI 并不是八字计算器。

确定性引擎负责历法、真太阳时、四柱、大运和地支关系；MCP 负责把这些能力以结构化工具提供给 AI Agent；语言模型只负责根据已经计算出的证据进行解释。

这套设计不能保证所有文化解释都具有客观唯一答案，但它可以保证一件更基础的事情：底层计算不由语言模型临场猜测。

OpenFate Bazi MCP 的安装方式、工具列表和开发者资料：

更多安装方式、MCP 配置和工具说明，请参考 OpenFate Bazi MCP 开发者文档。

本文讨论的是软件架构、历法计算与 AI 工具边界。相关输出用于技术研究、文化探索与个人反思，不构成医疗、法律、投资或其他专业建议，也不保证未来结果。