1. 概率生成 ≠ 语义正确
LLM（以 OpenAI 的模型体系为代表）本质是在做：
给定上下文，生成条件概率最高的 token 序列
这带来一个根本特征：
-
优化目标：
P(文本 | 上下文) 最大 -
而不是：
语义一致性 / 逻辑完备性 / 可执行性
因此它"听起来合理"的来源是：
-
语料中"类似表达"出现频率高
-
模式（pattern）匹配成功
-
语言流畅性强
但这并不保证：
-
约束被满足（例如参数完整、格式正确）
-
状态一致（前后逻辑不冲突）
-
可被系统消费（machine-readable & executable）
换句话说：
LLM 在优化"语言分布"，而不是"运行语义"。
2. 为什么"高概率输出"在系统中是不可靠的
当 LLM 被嵌入到系统（Agent / 工具调用 / 工作流）时，问题立即暴露：
（1）隐式结构 → 不稳定
LLM 可以"隐式地"生成结构，例如：
-
JSON 看起来像 JSON
-
指令看起来像指令
但问题在于：
-
key 可能缺失
-
schema 不一致
-
类型错误
-
顺序漂移
这种现象常被称为：
"syntactic plausibility without structural guarantee"
（2）局部最优 → 全局失效
LLM 是逐 token 做局部最优决策：
-
当前 token 最合理
-
但未必对全局结构最优
例如：
-
提前关闭 JSON
-
多输出一个字段
-
忘记结束标志
这在系统执行时会直接导致：
-
parser 失败
-
tool call 失败
-
状态机中断
（3）缺乏"强约束执行语义"
传统软件系统依赖：
-
类型系统（Type System）
-
语法约束（Grammar）
-
状态机（FSM）
-
合同（Contract / Schema）
而 LLM：
-
不内生这些约束
-
只能"模仿"这些约束
结果就是：
它可以写出"像代码的代码"，但不保证"可执行代码"。
3. 为什么必须"显式约束结构"
显式结构的引入，本质是在补上 LLM 缺失的三类能力：
（1）从"语言概率"转向"语义确定性"
例如：
-
JSON Schema
-
function calling
-
DSL（领域专用语言）
作用是：
把"生成空间"压缩为"合法空间"
即：
-
不允许任意 token
-
只能在约束内生成
（2）把"解释责任"从人转移到系统
没有结构时：
-
人要理解 LLM 输出
-
人要判断是否可用
有结构后：
-
系统可以直接解析
-
自动验证合法性
这就是从：
human-readable → machine-executable
（3）建立"运行语义"
显式结构其实在做一件更本质的事：
把 LLM 输出嵌入到一个可执行语义模型中
例如一个典型 Agent 结构：
-
Intent（意图）
-
Action（动作）
-
Tool（工具）
-
Parameters（参数）
-
State（状态）
如果没有结构：
- 这些都是"文本里的影子"
如果有结构：
- 这些变成"系统中的对象"
4. 总结
LLM 的强项是"生成看起来对的东西"，而系统需要的是"保证一定对的东西"。
两者之间的鸿沟，只能靠：
显式结构 + 约束机制 来弥补
5. 运行语义化的软件系统
"运行语义化的软件系统是什么？"
这里可以直接给出一个更严格的结论：
所谓"运行语义化"，本质就是把 LLM 的概率生成结果，嵌入到一个"显式结构约束的执行系统"中。
也就是说：
-
LLM：负责"生成候选语义"
-
结构系统：负责"裁剪 + 验证 + 执行语义"
6. 一个工程化视角的对照
| 维度 | 纯 LLM 输出 | 显式结构约束后 |
|---|---|---|
| 正确性 | 概率性 | 可验证 |
| 稳定性 | 波动 | 收敛 |
| 可执行性 | 不确定 | 确定 |
| 可集成性 | 低 | 高 |
| 可扩展性 | 差 | 强 |
结论
如果不引入显式结构：
LLM 只能停留在"高级文本生成器"
而一旦引入结构约束：
它才成为"系统的一部分"，具备工程可用性