别再把LLM当运行时：一份来自生产环境的反思

最近 Unmeshed 那篇《LLMs Are Not a Default Execution Engine》在 HN 和 X 上被反复转发，配合 dev.to 上另一篇《Why LLMs Can Never Be "Execution Entities"》一起看，基本能拼出 2026 上半年 AI 工程圈的一个共识：把大模型当脚本运行时，是过去两年最贵的一个错觉。

这个话题现在被拎出来讨论不是偶然。2025 年下半年到 2026 年初，一大批号称"AI Agent 平台"的产品陆续暴雷——不是模型不够强，是架构一开始就歪了。开发者把 LLM 放在了它不该在的位置：调度器、状态机、执行器。

先说结论：LLM 是决策器，不是执行器

这句话听起来像废话，但真正在写代码的时候，绝大多数人下意识就把它俩混为一谈了。

一个典型的反面案例长这样：用户说"帮我把上个月销售额超过 10 万的客户拉出来，发一封感谢邮件"，然后你写了个 Agent，把整个流程——查数据库、筛选、生成邮件文案、调用 SMTP——全部丢给一个 LLM，让它一边"思考"一边"执行"。跑三次，可能有两次是对的，第三次它自信满满地告诉你"邮件已发送"，实际上一封都没出去。

这不是模型幻觉的问题，是你让一个概率模型承担了确定性系统的职责。

为什么开发者会掉进这个坑

三个原因，按严重程度排序：

第一，Demo 太好看了。 2023-2024 那波 AutoGPT、BabyAGI 的演示视频，让人产生一种"只要 prompt 写得好，LLM 就能自己干活"的错觉。但 demo 场景和生产环境之间隔着一整个可靠性工程学科。

第二，工具调用（Function Calling）被过度神化了。 OpenAI 推出 function calling 的时候，很多人理解成"LLM 现在会执行代码了"。不，它只是会说出该调用哪个函数。真正的执行、重试、幂等、事务、回滚，一个都不归它管。

第三，Agent 框架的 API 设计有误导性。 很多框架把 agent.run(task) 包装得像一个普通函数调用，让开发者忘了这背后是一次不确定的、有状态漂移风险的推理过程。

LLM 到底不适合做什么

列一下，都是我自己或者身边团队踩过的坑：

• 长链路任务编排：超过 5 步的 workflow，靠 LLM 自己规划＋执行，成功率断崖式下跌。上下文越长，它越容易"忘记"最初的目标。
• 需要严格幂等的操作：付款、发邮件、写数据库。你没法保证同一个 prompt 跑两次不会执行两次。
• 状态管理：LLM 是无状态的。你以为它"记得"上一步，其实是你把上一步塞进 context 了。context 一长，它就开始编。
• 错误恢复：传统系统里 try/catch 是明确的，LLM 遇到错误可能会"编一个成功"给你看。
• 实时性要求高的场景：一次推理 2-5 秒，链路一长就是分钟级延迟。

arxiv 上那篇《Large Language Models Do Not Always Need Readable Language》也从另一个角度佐证了这件事——LLM 内部的"推理"其实并不需要人类可读的中间表示，你以为的 Chain-of-Thought 有时候只是事后合理化。这意味着你没法通过看它的思考过程来判断它是不是真的在正确执行。

正确的姿势：分层

那 LLM 到底该放在哪？答案很朴素：决策层，不是执行层。

一个健康的 AI 应用架构，大致是这样分工的：

1. LLM 层：理解意图、拆解任务、选择工具

这一层做的事情是把自然语言翻译成结构化指令。输入是用户说的话，输出是一个 JSON 或者一段 DSL，描述"接下来该干什么"。它只负责说，不负责做。

2. 编排层：确定性的 workflow engine

Temporal、Airflow、Prefect、Unmeshed 这类工具存在了几十年是有原因的。它们提供：

• 持久化状态
• 自动重试和退避
• 幂等保证
• 可观测性和审计
• 明确的错误边界

把 LLM 生成的"计划"交给这一层去跑，出问题能查、能重放、能补偿。

3. 工具层：真正干活的代码

数据库查询、API 调用、文件操作，就是普通的函数，写单元测试、加监控、跑 CI。跟 LLM 没关系。

4. 反馈层：把执行结果喂回 LLM

执行完一步，把结果（成功/失败/数据）作为新的上下文交给 LLM，让它决定下一步。关键是每次 LLM 调用之间的状态是由编排层持有的，不是塞在 context 里的。

一个具体的对比

错误的做法：

user_query -> LLM(带着一堆 tools)
              -> 自己规划
              -> 自己调用工具
              -> 自己判断是否完成
              -> 自己重试
              -> 返回结果

正确的做法：

user_query -> LLM(planner) -> 输出结构化 plan
                          -> Workflow Engine 接管
                             -> Step 1: 执行 -> 结果持久化
                             -> Step 2: 执行 -> 出错 -> 自动重试
                             -> Step 3: 需要判断 -> 再调 LLM(judge)
                             -> ...
                          -> 返回聚合结果

差别在哪？第一种，LLM 是主循环。第二种，LLM 是一个被反复调用的纯函数，主循环在你自己手里。

关于"Agent"这个词的滥用

2025 年整年，"Agent" 被卖成了一个筐，什么都能往里装。但真正在生产环境跑得好的 Agent 系统，本质上都是加了 LLM 决策节点的传统 workflow。

Anthropic 去年那篇《Building Effective Agents》其实已经说得很清楚：绝大多数场景，你需要的不是 Agent，是 Workflow。只有当任务真的开放到无法预先编排的时候，才需要让 LLM 拿主循环。而且即便这种情况，你也得给它加护栏——步数上限、成本上限、人工审核点。

成本视角：这不只是可靠性问题

还有一个经常被忽略的点：把 LLM 当执行引擎，账单会爆炸。

一个 10 步的任务，如果每步都要 LLM 自己规划、自己反思、自己决定下一步，一次任务可能就是几十次 API 调用。同样的任务，如果 LLM 只在关键决策点被调用（比如开头规划一次、中间遇到分支判断一次、结尾总结一次），成本能降一个数量级。

这也是为什么现在越来越多团队开始做模型分层：便宜快的模型做常规判断，贵的模型只用在最关键的决策上。像 OpenAI Hub 这种聚合平台的价值就在这里——一个 Key 同时调 GPT-5、Claude 4.5、Gemini 2.5、DeepSeek V4，在编排层里根据不同节点的复杂度动态切换，不用为每家单独接入和维护鉴权。国内直连也省掉了一层网络问题的排查成本。

给正在做 AI 应用的开发者三条建议

1. 在写第一行 prompt 之前，先画架构图。想清楚哪些是确定性的、哪些是需要 LLM 判断的。前者用代码，后者用模型。

2. 把 LLM 调用当成外部 API 来对待：会失败、会超时、会返回意料之外的东西。做超时、重试、降级、缓存，一个都不能少。

3. 警惕"让 LLM 自己搞定"的诱惑。每次你想这么干的时候，问自己：这个流程如果失败了，我能不能定位到具体哪一步？如果答案是"不能"，就别这么写。

写在最后

2026 年了，AI 工程正在从"炫技"进入"活下来"的阶段。那些还在用 LLM 当主循环、当运行时、当万能胶水的项目，正在被更朴素但更靠谱的架构慢慢取代。

模型会越来越强，但"强"不等于"可靠"，更不等于"确定"。软件工程几十年积累下来的那些东西——状态机、事务、幂等、可观测性——不会因为 LLM 出现就作废，反而更重要了。

把 LLM 用在它擅长的地方，把执行留给擅长执行的系统。这不是保守，这是常识。

参考来源

• WangRongsheng/awesome-LLM-resources - GitHub：全球 LLM 资源汇总，包含 Agent、推理、MCP 等主题的持续更新，适合系统性了解生态现状。