别把LLM当默认执行引擎：认清能力边界，构建稳健AI架构

一个被误解的技术定位

随着大语言模型（LLM）能力的持续提升，越来越多的开发者和产品经理开始把它视为「万能」的执行引擎——无论是数据处理、逻辑运算，还是流程编排，似乎都可以塞进一个提示词让模型搞定。然而，这种思路正在引发一系列隐蔽而代价高昂的问题。

Hacker News 上一篇题为《LLMs Are Not a Default Execution Engine》的讨论，正是对这一趋势的冷静反思。其核心论点直指要害：LLM 是强大的语言理解与生成工具，但它不应被默认当作确定性的计算与执行系统。

这个区分看似简单，却是当前许多 AI 应用架构走弯路的根源。当我们把一个概率性的、非确定的语言模型硬塞进本应由确定性代码承担的执行角色时，系统的可靠性、成本与可维护性都会付出沉重代价。

执行引擎与语言模型的本质差异

确定性 vs 概率性

传统执行引擎——无论是数据库查询、脚本运行还是业务规则引擎——都具有确定性：相同的输入必然产生相同的输出，这是软件工程可靠性的基石。

LLM 本质上是概率模型。其底层基于 Transformer 架构，通过自回归方式预测下一个 token 的概率分布。即便将温度（temperature）设为 0 采用贪婪解码，模型输出仍受浮点运算精度、批处理顺序乃至硬件差异的影响，在不同部署环境下可能产生不一致的结果。更隐蔽的风险在于，模型供应商的版本迭代（如从 GPT-4 升级到 GPT-4o）会悄然改变模型行为基线——这对依赖确定性输出的生产系统而言是难以管控的隐患。让 LLM 完成「把这两个数相加」「判断这条记录是否符合规则」之类的任务，看似能得到正确结果，但在边界情况下的稳定性永远无法保证。

成本与延迟的量级差异

一次简单的算术运算，用代码执行是微秒级、几乎零成本的操作；而调用 LLM 完成同样的任务，则意味着网络往返、token 计费和数百毫秒乃至数秒的延迟。当这类调用被嵌入高频循环或批处理流程时，成本会以指数级放大。

把 LLM 当默认执行引擎，无异于用一台昂贵的通用推理机去做本该交给计算器的工作。

LLM 真正擅长的角色

那么，LLM 究竟应该被放在什么位置？答案是：它应作为「解释层」和「编排层」，而非「执行层」。

意图理解与任务分解

LLM 的核心价值在于处理模糊、非结构化的输入——理解用户的自然语言意图，将其转化为结构化的指令或调用计划。这正是它区别于传统程序的独特之处。

合理的 AI 架构设计应该是：LLM 负责「理解要做什么」，再把具体的「怎么做」交给确定性的工具、函数或 API。**工具调用（tool calling）**正是这一理念的工程化实现——该范式由 OpenAI 于 2023 年在 GPT-4 中正式引入后迅速成为行业标准：LLM 输出结构化的函数调用意图（JSON 格式），由外部系统实际执行并将结果回传模型，从而将模型角色严格限定在「决策」层面。在此基础上发展出的 Agent 架构（如 ReAct、AutoGen、LangGraph 等）进一步形式化了「感知-推理-行动」循环，使 LLM 专注于规划与编排，将数据库查询、API 调用、代码执行等确定性操作委托给专用工具——这正是当下 Agent 架构兴起的根本逻辑。

生成而非计算

在文本摘要、内容创作、代码生成、语义分类等本身带有「生成」或「判断」属性的任务上，LLM 是无可替代的。这些任务没有唯一正确答案，能够容忍一定的概率性，恰好是模型的舒适区。

关键在于识别任务的性质：如果一个任务存在唯一正确答案，且可以用几行代码稳定实现，那就不该交给 LLM。

AI架构设计的实践启示

让 LLM 输出计划，而非直接结果

一个成熟的设计模式是：不要让 LLM 直接给出最终答案，而是让它输出可被验证、可被执行的「计划」或「结构化调用」。例如，与其让模型直接返回一个统计数字，不如让它生成一段 SQL 查询或调用规范，再交由数据库真正执行。

这种「LLM 编排 + 代码执行」的分层架构，既保留了自然语言交互的灵活性，又守住了执行环节的确定性与可审计性。

建立验证与回退机制

即便在编排层，LLM 的输出也需要校验。生成的调用参数是否合法、执行计划是否可行，都应有确定性的校验逻辑兜底。当模型输出不可信时，系统必须有明确的回退路径，而不是盲目信任。

警惕「提示词万能主义」

当前不少团队陷入一种误区：遇到问题就先想「能不能写个 prompt 解决」。这种「提示词万能主义」往往掩盖了本可用传统工程手段更廉价、更可靠解决的问题。技术选型的第一步，应当是判断问题是否真的需要 LLM 的语言能力。

回归工程理性

这场讨论戳中了 AI 应用落地中一个普遍存在的认知盲区。在 LLM 能力光环的笼罩下，我们很容易高估其适用边界，将它当作解决一切问题的默认手段。

真正成熟的 AI 工程实践，恰恰体现在知道什么时候不用 LLM。把语言模型放在它擅长的理解与编排位置，把确定性任务交还给可靠的代码，才能构建出既智能又稳健的系统。

LLM 是卓越的「大脑」，但不该被逼着去当「计算器」。认清这一能力边界，是从「玩 AI」走向「用好 AI」的关键一步。