引擎的每一道机制，为什么这样设计

设计的出发点：不是「能不能对」，是「错了怎么办」

把一个模型接进业务系统，今天已经是一件几个小时就能做完的事。真正的门槛在后面：接进去之后，你敢不敢让它的输出直接生效。

演示环境和生产环境的差别不在准确率，在错误的代价。演示里错一次是重跑一遍，生产里错一次是一笔运费、一笔坏账、一次错发到客户手上的包裹。一个每天做上千次决策的系统，哪怕只有百分之一的错误率，每天也有十次需要有人善后。

所以 Flyto Agent 的全部工程设计，回答的都是同一个问题：错了怎么办。

第一条边界：AI 负责决策，业务系统负责执行

这是整个引擎最重要的一条设计约束，也是我们和「让 AI 直连数据库」这条流行路线的分岔口：

AI 负责决策，业务系统的接口负责执行。AI 不直接写业务数据库。

理由有三条，每一条都来自实践而不是洁癖。

第一，自然语言到结构化语言的翻译，语义歧义无法根除。 让模型生成一条写库语句，你就得赌它对「这一单」「这个客户」「上个月」的理解和你完全一致。这个赌注在读取时输错了重来，在写入时输错了是事故。

第二，业务的不变量应该由业务系统自己守。 库存不能为负、金额精度不能丢、外键必须成立、状态机不能跳步——这些规则写在业务系统里已经守了很多年，绕过它直接写库，等于把守了多年的门拆掉。

第三，审计责任链必须清晰。 谁提出、谁批准、谁执行、系统校验了什么——每一环都要说得出。一条由模型直接写进数据库的记录，事后没有人能完整还原它是怎么来的。

上 AI 不等于把生产数据交给 AI。

场景中立的内核

Flyto Agent 的核心引擎不知道什么是仓库，也不知道什么是报价单。它只认识三样东西：场景的结构、决策的约束、以及结果的判定方式。

业务知识全部住在场景描述里。一份场景描述回答这些问题：

这个场景要做的判断是什么，输出的形态是什么；
输入有哪些，每一项的口径和取值边界在哪；
什么样的输出是绝对不允许的；
判断结果如何被验证，多久之后才能知道对错。

新场景以模块叠加的方式接入，而不是替换既有的东西。这意味着换场景的成本从「重新开发」降到「重新描述」，也意味着在一个场景里磨出来的工程保障，换个场景照样生效——不用每进入一个新领域就把信任重建一次。

决策暂存区：每个决策都是一条可审计的记录

引擎做出的每一次决策，不会直接变成生产系统里的一次写入，而是先落成暂存区里的一条记录，然后走一条明确的状态流转：

技术层校验先看形式——结构是否合法、数值是否落在可能的区间、有没有自相矛盾。这一层不需要理解业务，只需要知道什么是不可能的。

业务层校验再看语义——这个决策放在当前的业务上下文里说不说得通、有没有触碰不允许的边界。

两层都通过，决策才进入执行；执行由真正拥有写入权限的业务系统完成，并回写最终状态。任何一层不通过，决策停在暂存区，等人处理。

这条链路的意义是：任何一个决策，事后都能回答「它当时走到了哪一步、被谁挡下了、为什么」。

三层防御：让不确定性到不了生产

每一个模型交互点上，都有三层保护。原则只有一句：永远不假设模型会百分之百遵守指令。

指令层

约束模型该做什么、不该做什么。场景的规则、口径定义、禁止事项在这一层被写清楚，而不是指望模型「自己知道」。这一层解决的是方向性错误。

参数层

用接口和参数限制它能做什么。能调用哪些能力、取值范围到哪、哪些操作根本不提供入口——做不到的事情，比嘱咐它不要做，可靠得多。

兜底层

接住前两层漏掉的一切。当决策无法通过校验、置信度不足、或者遇到场景描述里没有覆盖的情况时，兜底层给出一个安全的默认答案：交还给人，或者退回既有规则。

这一层的设计原则很简单：系统的默认行为永远是「停下来」，不是「继续」。 一个不知道该怎么办的系统，最不该做的事就是猜。

「不校验」必须是一个明写的选择

工程上有一类事故特别隐蔽：你以为审核开着，其实它没开。

所以引擎不允许「没有校验器」这种状态存在。如果某个环节确实不需要校验，必须显式地接上一个「永远通过」的校验器——于是它出现在配置里、出现在日志里、出现在任何一次审计中。

跳过检查可以，但它必须是一个有人签过字的决定，不能是一个没人注意到的默认值。

决策留痕：可复核，才谈得上可改进

每一个决策都会记录它的输入、依据和当时的上下文。

这件事的价值不在追责，在于让讨论从「我觉得」回到「当时的记录是」。出了问题能回放整个决策过程，看清是哪一步的假设不成立——是输入数据脏了，是场景描述漏了一种情况，还是判断逻辑本身有偏差。

没有留痕的系统，改进只能靠猜。你只知道结果不对，不知道该改哪里，于是下一版还是不对。

反向论证与反事实对照

对代价高、不可逆的决策，引擎要求先产出一份结构化的反面论证：这个结论隐含了哪些没说出口的假设，什么情况下它会失败，为什么在权衡之后仍然选它。这份论证和决策一起留痕，而不是停留在某个人的脑子里。

哪些动作需要走这一步，由使用方按风险自行指定——不是所有决策都值得付这个成本，但值得付的那些，不能靠人的自觉。

在这份论证之上，引擎保留「如果换一个条件会怎样」的对照分析。这既是复核手段（这个决策相比其他选项好在哪），也是持续改进的样本来源（哪一类条件下判断系统性偏了）。

影子环境与灰度：上线不是一次赌博

引擎需要多轮推演才能得出结论时，中间过程的写操作落在一个与生产同构的影子环境里，按会话隔离，会话结束即清理。推演过程完全碰不到生产数据；推演的结论要生效，仍然要走暂存区和校验那条正路。影子环境永远不会被直接并进生产。

新的决策逻辑上线前，先在影子模式下运行：拿真实数据做真实决策，但结果不生效，只与人的判断或既有规则做比对。比对达标之后，才进入灰度放量：先接管一小部分决策，观察真实结果，逐步扩大范围。

这个流程听起来慢，但它换来一件很重要的事——任何一次上线都不需要赌。你在放量之前就已经知道它大概会怎么表现，而不是上线之后祈祷。

熔断与回退

决策质量出现异常时，引擎自动熔断，回退到人工或既有规则，并进入冷却，不让同一个错误被规模化地重放。

触发熔断的不只是「报错」。更常见的情况是模型没有报错，但输出的分布悄悄变了——某一类决策突然集中到一个选项上，或者置信度整体下滑。这些信号在留痕数据上是看得见的，引擎据此主动踩刹车。

能自动退回去，是敢往前走的前提。

多模型可插拔，支持私有化推理

Flyto Agent 支持多家大模型服务与本地部署模型共存，按场景的成本、延迟和质量要求选配，不被任何一家绑定。

我们同时具备本地化推理与领域知识蒸馏的能力。对数据敏感度高的场景，推理可以完全在企业自己的网络内完成，数据不出内网。

新能力以叠加的方式接入，而不是替换：升级引擎、更换底层模型，不需要把已有场景的集成重做一遍。对于一个要跑十年的业务系统，这一点比「当前用的是哪个模型」重要得多。

一个决策的一生

把上面的机制串起来，一次决策是这样走完的：

输入结构化——现场数据按场景描述归一成引擎可理解的结构，口径在这一步就被统一。
决策与依据——引擎给出决策，同时给出依据和置信度；高风险动作附带反向论证。
暂存与双层校验——技术层校验形式，业务层校验语义；不通过则停下等人。
由业务系统执行——引擎不写生产库，写入由拥有权限的业务系统完成并回写状态。
留痕与对照——决策过程、实际结果与反事实分析一并入库，成为下一轮改进的样本。

这个循环每跑一次，场景描述就更准一点。引擎的能力不来自某一次调优，来自这个循环跑过的次数。