AI应用架构：如何让模型只猜，逻辑只准

当你在业务中引入大模型，却遭遇退款金额乱改、支付环节擅自"灵活"的情况，根源在于你将"严丝合缝"的逻辑与"概率猜测"的模型混为一谈。通过三层架构、路由策略及兜底机制，本文将阐述AI原生应用究竟该如何剥离确定性逻辑与概率性预测。

系统引入大模型初期或许令人欣喜，但随后便危机四伏。用户填写的退款金额被模型"优化"了，支付回调时它擅自省略了校验步骤，权限判断仅给出"大概率可行"。出事后，你不能将责任推卸给模型，因为是你亲手将其部署在了错误的场景中。

罪魁祸首并非模型不够智能，而是你将两种截然不同的本质——严苛的逻辑与概率的猜测——强行融合在了一起。

传统架构始终遵循确定性：输入A遵循规则输出B，全程可预测、可测试且易于回滚。而AI架构则是概率性的：输入A加上上下文后，模型推断出的可能是B、C或D，且每次结果不同。若将二者混入同一接口，无异于让保险公司与赌场共享收银台。

许多团队习惯给现有系统"覆盖一层AI"，例如在订单模块增加对话入口、客服模块接入LLM、数据面板嵌入问答。这种做法被称为AI-Added——如同在马车上加装发动机，车身骨架仍是马车，发动机仅在必要时"嗡嗡作响"。

AI-Native则是另一种思路：在设计之初便承认系统中存在概率性，并为此构建专门的结构。区别不在于是否接入模型，而在于架构是否将不确定性视为一等公民。若想将AI真正融入业务，必须采用AI-Native模式搭建，否则AI层仅是碰运气的彩蛋，随时面临被移除的风险。

对于AI原生应用，我习惯将其划分为三层：

逻辑层——负责处理必须精准的事务。支付、权限、审计、金额计算及状态流转等环节，一旦出错将引发事故、资金损失或违规。此层使用传统确定性代码，规则明确、易于单测且可追溯责任。它是系统的底线，绝不应接触模型。

概率层——仅处理可以模糊的内容。包括意图理解、语义搜索、内容摘要、个性化推荐及自然语言交互等。此类错误不致命，允许"偶尔不完美"。模型在此层发挥其特长，切勿期望其达到100%准确。

编排层——作为连接两者的粘合剂，往往被忽视。其职责是将用户请求路由至正确层级，决策何时信任概率层、何时回退至逻辑层兜底。编排层是AI原生应用的"中枢神经"，目前多采用LangGraph、CrewAI或自研状态机实现，核心职能为：任务拆解、路由分发及人工介入。

三层架构的核心原则在于：将必须精准的逻辑保留在逻辑层，将允许模糊的内容置于概率层，并让编排层负责划定两者间动态的边界。

许多人误以为"概率层"仅仅是调用模型API，这是最大的误区。若要概率层发挥实效，必须先回答三个问题：

第一，当模型不确定时，它是否知晓？最关键的问题是模型往往缺乏"我不懂"的诚实表达能力——它表面给出概率，实则与事实关联甚微。面对分布外的输入，其行为完全不可预测。因此，需在其外部增加一层判断机制，而非仅依赖其自我报告。

第二，规则的边界是否可靠？即便向模型灌输大量规则并宣称其为"宪法"，规则仍是软约束——理论上应遵守，实则未必每次可靠。规则集越庞大、任务越复杂，模型越易失效。指望用规则完全束缚模型，最终只会因规则堆积导致系统崩溃。软约束仅能辅助，绝不能作为地基。

第三，出现错误如何应对？概率层的错误属于常态而非异常。因此，必须配备兜底方案：主模型故障时自动切换备用模型或降级至逻辑层规则；置信度低于阈值时转人工处理；关键输出需经逻辑层校验。若无此fallback机制，概率层便是在业务中埋下定时炸弹。

具体到每个功能，如何界定边界？无需复杂的矩阵，只需反问一句：若此结果出错，是否会引发重大事故？

这种判断方法鲜有失灵。许多"AI误用"事故追根溯源，皆因同一错误：将本应严谨的环节交给了概率模型。

在AI时代，架构设计反而更需坚守原则。工具虽变聪明，但判断"何种事项不能交给概率"的能力，才是架构中真正的价值所在。切勿被模型的"智慧"迷惑——它越强大，你越需明确哪些领域应让其保持沉默。

唯有分离逻辑与概率，系统才敢真正接纳AI。若无法分离，便是在生产环境中不断投掷一颗每次结果不同且自以为是的骰子。