在上一篇中我们讨论了一个核心问题为什么不能让大语言模型直接计算八字答案并不复杂LLM 擅长语言理解和生成但对于历法、时间边界、真太阳时、四柱等要求严格一致性的计算它并不是一个可靠的确定性计算器。因此 OpenFate 采用了确定性计算 ↓ 结构化数据 ↓ MCP Tool ↓ AI Agent ↓ 自然语言解释但在实际开发 AI Agent 时我们很快遇到了第二个问题即使底层数据已经算对了怎么保证 AI 不在解释过程中偷偷“改掉”这些数据这实际上是很多 AI 产品都会遇到的问题。你可以拥有完全正确的数据库、API 和计算引擎但只要最后把大量数据塞进 Prompt然后告诉模型请根据这些资料回答用户的问题。模型依然可能忽略某些字段错误关联两个字段把候选结果描述成确定结果自己补充不存在的数据把“解释”变成新的“计算”在多轮对话后偏离原始事实因此在 OpenFate 的 Agent 架构里我们逐渐把重点从单纯的 Prompt Engineering 转向另一个方向Schema-first Evidence-first也就是先定义 AI 可以看到什么、可以做什么再考虑它应该怎么说。一、Prompt 不是权限系统很多 AI 应用最开始都会依赖 Prompt 限制模型。例如不要修改用户的八字。 不要重新计算四柱。 只能根据提供的数据解释。 如果资料不足请明确说明。这些规则当然有用。但问题是Prompt 本质上只是自然语言指令不是一个真正的权限系统。模型看到{yearPillar:辛巳,monthPillar:甲午,dayPillar:丙寅,hourPillar:己丑}之后它理论上仍然可以输出你的日柱是丁卯……即使系统 Prompt 明确告诉它不能这么做。因此一个可靠的 Agent 架构不能只依赖“请不要犯错”而应该尽量让错误“从系统结构上更难发生”二、把事实和解释彻底分开OpenFate 的一个基本原则是Facts ! Interpretation例如{dayPillar:丙寅,dayMaster:丙,timezone:Asia/Shanghai,trueSolarTimeApplied:true}这些属于FACT而丙火在这个命盘结构中可以从……属于INTERPRETATION两者必须分开。更进一步我们还可以把输出划分成FACT DERIVED_FACT INTERPRETATION UNKNOWN例如{type:FACT,field:dayPillar,value:丙寅}这是计算引擎直接输出的事实。而{type:DERIVED_FACT,field:interaction,value:寅申冲}可能来自另一个确定性 interaction detector。至于这种结构在传统命理语境中通常会被如何解释才进入 AI 层。这种拆分有一个非常重要的意义AI 不再是事实的来源而只是事实的消费者。三、Evidence Layer让每个结论知道自己从哪里来如果 AI 只是拿到一大段 JSON它仍然可能错误理解。因此一个更稳定的方法是增加一层Evidence Layer例如用户问我的日主是什么Agent 不需要重新分析整个命盘。系统可以直接给它{question:我的日主是什么,evidence:[{source:calculate_bazi_chart,field:dayMaster,value:丙}]}然后 AI 的任务变成把 evidence 解释成人能读懂的语言。而不是重新理解整个八字然后自己找答案。两者看起来差不多但系统可靠性完全不同。四、为什么结构化 Evidence 比长 Prompt 更可靠假设