从 LLM 到 Agentic AI：范式演进完整脉络

大模型“能用”与“好用”之间的工程鸿沟

过去两年。大语言模型几乎一夜之间进入开发者视野，Chat Completions 接口三行代码就能拼出一个会聊天的原型。但真正把模型搬进生产环境时工程师很快撞上同一道墙：

• 模型会说话 ≠ 能办事。
• 知识截止、工具缺失、状态失忆 成为首批痛点。

五阶段演进方法：每一步都在填坑

纯 LLM 的三大硬伤与 Agentic AI 的闭环结构

• 痛点一——知识截止：L​LM 的训练数据有明确截止线，任何截线之后的信息模型只能“装作知道”。RAG 阶段通过外部可检索知识库把最新信息注入 prompt，从根本规避此痛点。
• 痛点二——无法行动：L​LM 返回的是字符串，无法直接读写数据库或调外部 API。Function Calling 协议让模型把“想法”翻译成结构化调用请求；LangChain 的@tool装饰器正是把这层协议工程化。话说回来，
• 痛点三——无状态：L​LM 每次 invoke 都是独立请求。服务器不记得上一轮对话，老实说，若不自行维护消息列表，聊天机器人就会失忆。LangGraph 引入MessagesState/AddMessagesReducer,把对话记忆交给框架管理。
• 痛点四——输出不可靠：L​LM 输出的 JSON 常出现缺字段、类型错位或语义漂移。未加校验直接.json。在生产中极易触发JSONDecodeError,成为最常见的事故根源。话说回来，
• 闭环结构： 感知→规划→行动→反思 四段循环。 使得每一次 “观察” 都能反馈到 “规划”，形成自我纠错能力。LangGraph 中对应的是AddConditionalEdges + 循环边 + Checkpointer + Refiner 节点。
• No‑checkpointer 的 chatbot 每轮 invoke 都是失忆；只要给{thread_id} 配上InMemorySaver/SqliteSaver/PostgresSaver,同一使用者多轮对话即可自动恢复历史状态。
• If you forget to add reducer on  #messages# field,LangGraph will overwrite whole message history on each node execution – a classic source of “agent forgets previous steps”.
• The most common production incident is “tool call failed → agent retries forever → token bill skyrockets”. Proper routing and a max‑iteration guard are mandatory.

Agent 与 Workflow 的区分——为什么生产里几乎都是混合体？

⚠️**关键痛点** ：如果只用 Workflow，业务场景变化时需要频繁重新部署；如果只用 Agent，难以保证可审计性和成本可控。

**Workflow** ：开发者预先编排好节点和边，LLM 只负责在某几个节点里填充输出。 优点是可控、可审计、易测试； 缺点是任何意料之外的分支都需要重新部署。**Agent** ：模型自主决定下一节点、调哪个工具还有何时结束。按理说，优点是灵活适合开放场景；缺点是难以预测、token 消耗高且错误难复现。实际项目往往采用 **Hybrid**，例如客服程序的工单路由主干是固定 workflow。但每一步中的回复内容与升级判断交给 Agent 决策，实现了既可控又灵活。说起来，