从 Structured Output 到企业级 AI 架构——如何把 LLM 放进可控系统

这篇文章是企业级 Prompt 工程实战指南（下）：构建可复用 Prompt 架构平台的最上层架构的延伸，建议结合一起看。

一、问题的起点：LLM 到底是什么？

站在一线 AI 应用工程的视角，LLM 绝非业界部分人神化的"通用智能体"，其工程本质被严重忽略或者说夸大了。

它本质是：

一个基于大规模预训练语料的条件概率生成函数，本质可抽象为：f(input) → 概率值

早期我们这样用：

const text = await llm(prompt)

因为是概率输出，所以会有如下问题：

• 输出不稳定
• 格式不稳定、JSON 可能损坏
• 字段可能缺失
• 类型可能错误
• 模型升级后行为改变

这种纯 Prompt 驱动的调用方式，在生产环境中属于典型的"脆弱架构 "------无容错、无校验、无追溯，完全无法承载企业级场景的稳定性要求。

这阶段暂且可以叫：

Prompt Engineering 阶段

它仅能用于 Demo 验证、概念性验证（POC），但绝对无法支撑大规模、高可用、可追溯的企业级生产系统。

这里我再重复很重要的观点，企业需要的是稳定性 ，没有工程架构设计的简单大模型产出的东西只能用于 Demo 和 POC

二、Structured Output：第一道工程门槛

当模型支持：

response_format: { type: "json_schema" }

或者 tool calling，

我们可以把 LLM 从：

(prompt) => string

大模型返回 string:
名字：张三
年龄：28
职业：工程师

因为大模型返回的是随机字符串，所以就会有结构问题。你想像一下，如果大模型返回一段字符串，大概率那就得工程师通过正则去提取关键字符，大模型随机性很强，关键字符是会出错的，难度就会很高。

---

后来变成：

(input) => Promise<TypedObject>

大模型返回 TypedObject: {
  name: "张三",
  age: 28,
  job: "工程师"
}

所以说大模型从返回随机的字符串 ，变成了能约定的 API，也就是 JSON 格式的 TypedObject

这一步是LLM 从"Demo "走向"企业级"的关键拐点，也是工程化落地的核心门槛。

它带来四个工程能力：

• 输出空间收缩
• 类型可预测
• 可测试
• 可监控

标志着我们第一次可以把 LLM 接入：

• 类型系统
• 业务系统
• 监控体系

---

这里又延伸出了另一个问题：

Structured Output 仅解决了"模型输出可被系统解析"的结构问题。

它不解决：

• 业务正确性
• 事实正确性
• 权限问题
• 合规风险
• 审计问题

所以它是，必要条件，不是充分条件------脱离确定性约束的 Structured Output，依然是"可控的错误输出"，无法支撑企业级决策。

什么意思呢？大模型从返回字符串 变成了返回 JSON ，但不能保证 JSON 里面的 name 是对的，比如明明要返回 name: 张三 ，却返回了 name: 张二

简单来说 Structured Output 解决了大模型结构错误，但还有语义错误待解决

三、为什么单 Agent 架构在企业里会失败？

我们来延伸一下，不急着解决上面的语义错误。在很多团队在 AI 应用落地时，极易陷入"单 Agent 万能论"的误区，盲目追求"一站式智能"，设计出：

User → Super Agent → Everything

这个 Super Agent
  ↓
能理解需求
能自己规划
能调用工具
能执行流程
能自我修正

听起来很优雅。

问题是： 企业不是玩具场景，执行流程和自我修正决策的时候，出了事故谁背锅？ AI 背不了锅吧。

我大概列一下几个问题：

• 不可追溯
• 权限不清晰
• 不可分责
• 不可决策
• 高耦合黑盒

在互联网企业呆过的都知道，企业真正需要的是：

• 模块化
• 可回滚
• 可版本化
• 可追溯
• 可监控

这种"大而全"的单 Agent 架构，与企业级系统"可治理、可追溯、可容错"的核心诉求完全相悖，在实际落地中必然走向失控。

说到这，你们应该大概也能猜到了为什么我要延伸这个单 Agent 架构？解决这个单 Agent 架构的问题，就是解决大模型输出的语义问题的最佳工程化实现。

四、企业系统真正的核心

结合我多年的工作经验，企业业务系统的核心永远是质量优先，也就是"确定性底座"，即：

• 交付质量
• 规则（确定性约束）
• 流程（秩序）

LLM 最主要功能就是泛化能力，它不是决策层------它的价值是 "降低语义理解成本"，而非"替代系统做决策" ，这是企业级 AI架构的核心认知底线。

五、核心架构思想：企业级LLM可控的唯一路径

企业级LLM架构的核心设计原则，本质是"确定性外壳包裹概率内核------这是平衡LLM灵活性与系统可控性的唯一可行路径。

概率内核

• LLM
• 语义理解
• 推理
• 生成
• 模糊判断

优点：强语义表达、灵活的模糊推理能力，能快速解决传统系统难以处理的非结构化文本问题

缺点：输出非确定性、无法保证事实与业务正确性

确定性外壳

企业级系统的"安全底线"，也是 LLM 可控的核心保障，主要包括：

包括：

• API 校验
• Schema 验证
• 数据库
• 规则引擎
• 权限系统
• 风控
• 事务控制
• 审计日志
• 监控

其核心特点是同样输入 → 同样输出

六、完整实战：自动付款审批系统

举一个 AI 付款审批系统的例子，拆解真实业务场景的架构落地细节，数据已经脱敏------这是典型的"确定性外壳+概率内核"落地案例。

用户提交：

给 ABC 公司 打 80 万做市场推广。

目标：

AI 系统自动判断是否批准付款。

---

Step 1：API 入口校验（确定性）

目的：

• 防垃圾
• 防恶意
• 防重复

检查：

• 必填字段
• 类型
• 权限
• 幂等
• 速率限制

如果失败：

→ 直接拒绝

LLM 根本不会被调用。

原则：企业级AI架构的核心优化方向之一，就是"前置拦截无效请求"，越早拦截，系统成本越低、安全性越高

---

Step 2：LLM 结构化抽取（概率层）

如果用户提交的是自由文本：

LLM 负责提取：

{
  "amount": 800000,
  "vendor": "ABC 公司",
  "purpose": "Marketing"
}

这一步解决：

语义 → 结构

但它可能出错------即使开启 Structured Output，模型仍可能出现字段偏差、语义误解（如将"80万"识别为"8万"），这是由其概率本质决定的。

所以：

• 必须结构约束
• 必须记录日志
• 必须允许重试

---

Step 3：Schema 校验（确定性）

目的：

• 验证字段合法
• 类型正确
• 范围正确

例如：

• amount > 0
• currency 长度 3
• 不允许多余字段

注意：

即使使用 structured output，也必须进行系统级二次校验------这是很多团队容易忽略的细节，也是导致系统失控的常见隐患。

因为：

• 模型是外部系统，不能完全信赖
• 版本会变
• 需要系统级权威校验

在 node.js 中常见用到 zod 去做 scheme 校验,大致如下

const APISchema = z.object({
  request_id: z.string().min(1),
  submitter_id: z.string().min(1),
  amount: z.number().gt(0),
  currency: z.string().length(3).optional(),
  vendor: z.string().min(1)
});

---

Step 4：数据库事实查证（确定性）

LLM 不知道：

• 合同是否过期
• 是否超预算
• 对方是否在黑名单
• 是否重复付款

必须查数据库。

业务数据库才是真相来源，而不是大模型

企业级系统的"真相唯一来源",必须是结构化数据库，而非模型的生成结果，切记、切记、切记

Step 5：规则引擎（确定性决策）

设立不同的规则，规则示例：

• amount > 50000 → 需要审批人审批
• 合同过期 → 拒绝
• 黑名单 → 拒绝
• 风险分高 → 人工复核

规则必须：

• 可日志化
• 可解释
• 可追溯

模型不应该做最终裁决------企业级决策的核心是"可解释、可追溯"，而模型的概率性决定了其无法承担最终决策职责，这是企业 AI 架构的核心底线。

Step 6：风控

负责：

• 合规检查
• 权限越界
• 黑白名单
• 高风险阻断

风控是企业级系统的"最后一道安全防线"，负责拦截合规、安全类致命风险，

Step 7：决策写数据库 & 执行

只有在：

• 规则通过
• 风控 允许

才：

• 写审批结果
• 写审计日志
• 触发付款

必须：具备完整的事务与容错机制，即

• 幂等
• 流程事务的终止和恢复数据
• 全链路 trace

七、为什么层看起来多，但不能删？

可能到这，有些人会提出疑问：

"这些层是不是重复？"

看似重复，实则各层承担着不同的"信任边界"和"风险防控职责"，关注点差异：

层	关注点
API 校验	网络边界
Schema 校验	数据结构
DB 查证	事实
规则引擎	业务逻辑
风控	安全合规
执行层	事务或者人工处理

它们是企业级系统中不同层级的"信任边界"，每一层都在解决特定的风险问题，理论上是缺一不可。

我个人觉得以下三个是不能合并：

• DB 查证
• 风控
• 执行事务层

其他的根据业务大小，随意组合、扩展、删减，我也是提供了我的思路，欢迎有其他思路的在评论区留言！

八、最终架构形态：企业级 LLM 可控的标准范式

结合前面的实战案例，Structured Output 的真正价值的是：

让 LLM 成为可接入工程系统的组件

而不是：

让 LLM 变成决策中心

---

经过多个项目落地验证，稳定、可控的企业 AI 架构，必然是"确定性底座优先"，而非"模型优先"，其标准形态为：

数据库 （事实真相）
    ↓
规则引擎（约束）
    ↓
工作流（秩序）
    ↓
LLM（语义增强）

而不是"模型主导"的反范式（这是很多团队落地失败的核心原因）：

LLM
  ↓
数据库 / 规则 / 流程

这两种架构的区别不是技术，而是：

控制权在确定性系统，还是在概率模型

企业永远选择前者。

九、核心思维和结论

很多团队做企业AI，陷入了"唯模型论"的误区，认为：

让模型变的更加聪明是正确的路

而真正的企业级 AI 架构思维，恰恰相反：

让系统变可控

所以，企业级 AI 项目工程化架构牢记下面几点

• Structured Output 是工程化第一步
• 单 Agent 在企业级必然失控
• LLM 必须运行在确定性外壳内
• 决策必须由规则系统掌控
• 模型负责理解，不负责统治和决策

试想一下，当你的系统调用量从每天 100 次变成 100 万次时，

哪怕 0.1% 的错误率， 每天就是 1000 次异常，这锅你敢接吗？