小白程序员必看:LLM 应用开发的三种进阶时代,轻松掌握大模型开发
本文回顾了 LLM 应用开发的三个主要时代模型调用时代LangChain、流程编排时代LangGraph和系统构建时代Deep Agents。从简单的模型调用到复杂的流程编排再到完整的系统构建每个时代都代表了 AI 能力边界的扩展。文章详细介绍了每个时代的核心问题和解决方案并强调了理解这些演进对于解决实际问题和进行高效开发的重要性。LLM 应用开发的三个时代2022 年底ChatGPT 发布。开发者第一次意识到原来大模型可以这么用。但「能用」和「好用」之间隔着一条巨大的鸿沟。这条鸿沟不是模型能力是工程化——怎么把模型的「对话能力」变成「生产能力」。LangChain 的三年演进恰好映射了这条鸿沟被填平的全过程。不是框架在迭代是整个 LLM 应用开发范式在进化。从「调用模型」到「编排流程」到「构建系统」每一步都对应着 AI 能力边界的一次外扩。我跟你说这三年我踩的坑够写一本书。01 / chain第一阶段LangChain —— 模型调用时代我第一次接触 LangChain是因为一个 RAG 项目。那是 2023 年初我需要做一个「基于智慧政务的问答系统」。当时试过跑本地最后外接的文心一言。当时的 API 很原始——你发一段文本它回一段文本。消息历史自己管JSON 解析自己写异常处理自己兜。我学了整整半个月写了 300 行胶水代码加载 PDF、切分文本、调 OpenAI 的 Embedding API、把向量存进 Chroma、写检索逻辑、拼 prompt、处理格式错误、重试失败请求。代码能跑但丑。而且我隐隐觉得这些代码别人一定也写过。然后我看到了 LangChain 的 RAG 教程。from langchain import hub from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain_community.document_loaders import WebBaseLoader from langchain_community.vectorstores import Chroma from langchain_core.output_parsers import StrOutputParser from langchain_core.runnables import RunnablePassthrough from langchain_openai import ChatOpenAI, OpenAIEmbeddings # 加载文档 → 切分 → Embedding → 存向量库 loader WebBaseLoader(https://lilianweng.github.io/posts/2023-06-23-agent/) docs loader.load() splits RecursiveCharacterTextSplitter(chunk_size1000, chunk_overlap200).split_documents(docs) vectorstore Chroma.from_documents(documentssplits, embeddingOpenAIEmbeddings()) # 检索 生成用 | 符号像管道一样串起来 retriever vectorstore.as_retriever() prompt hub.pull(rlm/rag-prompt) llm ChatOpenAI(modelgpt-3.5-turbo, temperature0) rag_chain ( {context: retriever | format_docs, question: RunnablePassthrough()} | prompt | llm | StrOutputParser() ) rag_chain.invoke(What is Task Decomposition?)我第一次跑通这段代码的时候真的愣了一下。之前 300 行的活儿现在 10 行搞定。而且那个|符号——Unix 管道的感觉——让整个过程像流水一样自然。但问题很快来了。这个 RAG 只能回答「单次问题」。用户问一句系统答一句然后一切归零。如果用户接着问「刚才那个方法有什么缺点」——系统一脸茫然因为它根本不记得「刚才」发生了什么。更麻烦的是真实场景。一个客服 Agent 需要「理解问题 → 查订单 → 查库存 → 生成回复 → 确认解决」。一个研究 Agent 需要「搜索文献 → 读摘要 → 找相关论文 → 总结发现」。这些流程有分支、有循环、有状态共享。用链表达这些就像用面条编篮子——能编但丑且容易断。我跟你说我当时写到一个带分支的客服流程代码已经没法看了。if-else 嵌了三层状态存在全局变量里一个边界情况没处理好整个流程就崩了。2023 年底我坐在屏幕前盯着那团代码意识到一件事我需要的不只是「调用模型」而是「编排模型」。02 / graph第二阶段LangGraph —— 流程编排时代2024 年Agent 概念爆发。AutoGPT、BabyAGI、MetaGPT 轮番登场但都有一个共同问题跑不稳。Agent 不是「调用一次模型」就完事的。它是循环感知 → 决策 → 执行 → 反馈 → 再感知。这个循环可能跑 10 轮、100 轮中间任何一步出错整个流程就崩了。LangChain 团队推出 LangGraph核心洞察Agent 的执行路径不是链是图。但「图」这个词容易让人误解。LangGraph 不是让你画一张漂亮的流程图——它解决的是一个更底层的问题状态怎么管链的问题在于「无状态」。你调用一次得到一次输出然后一切归零。但真实世界的 Agent 需要记住「刚才查到了什么」「用户上次说了什么」「做到哪一步了」。这些信息不能存在变量里——变量在进程崩溃时就没了。LangGraph 的做法是把 Agent 的执行过程建模为状态机。from langgraph.graph import StateGraph, END from typing import TypedDict # 定义状态结构 class AgentState(TypedDict): messages: list # 对话历史 tool_calls: list # 已调用的工具 current_step: str # 当前执行到哪一步 # 定义节点每个节点是一个函数 def understand_intent(state: AgentState): # 分析用户意图决定下一步 return {current_step: route} def query_database(state: AgentState): # 查数据库 return {tool_calls: state[tool_calls] [db_query]} def call_api(state: AgentState): # 调外部 API return {tool_calls: state[tool_calls] [api_call]} def generate_response(state: AgentState): # 生成最终回复 return {messages: state[messages] [{role: assistant, content: ...}]} # 构建图 workflow StateGraph(AgentState) workflow.add_node(understand, understand_intent) workflow.add_node(query_db, query_database) workflow.add_node(call_api, call_api) workflow.add_node(generate, generate_response) # 定义边条件分支 workflow.add_conditional_edges( understand, lambda state: query_db if 订单 in str(state[messages]) else call_api ) workflow.add_edge(query_db, generate) workflow.add_edge(call_api, generate) workflow.add_edge(generate, END) # 编译并运行 app workflow.compile() result app.invoke({messages: [{role: user, content: 查我的订单}]})这段代码和链的本质区别链是「调用函数 A拿到结果传给函数 B再拿到结果传给函数 C」。每一步的输出是下一步的输入但中间没有「状态」这个概念——只有输入输出。图是「定义一组状态和状态之间的转移规则」。AgentState是一个全局状态对象所有节点读写同一个状态。节点 A 改了current_step节点 B 能读到。节点 C 失败了重启后状态还在能从断点继续。LangGraph 提供了什么持久化状态每个节点执行完状态自动保存。Agent 崩溃后重启能从断点继续不会「忘了刚才做到哪」。容错执行节点失败自动重试支持超时、熔断、降级。生产环境不再「一崩全崩」。人在回路关键决策点可以暂停等人类确认后再继续。适合钱和命有关的场景——医疗、金融、自动驾驶。时间旅行能回溯到任意历史状态查看「如果当时选了 B 而不是 A结果会怎样」。子图复杂流程可以拆成子图独立开发、独立测试、独立复用。本质Agent 工作流的「操作系统」。这个阶段AI 的能力边界从「单次调用」扩展到「多步流程」。Agent 可以完成更复杂的任务但仍然需要开发者自己拼搭记忆怎么管权限怎么控多 Agent 怎么协作我跟你说LangGraph 我用了三个月状态管理确实稳了但每新增一个功能——加个权限检查、接个外部 API、做个多 Agent 协作——都得自己写一堆样板代码。就像 Linux 内核很强但你想办公还得自己装桌面环境、浏览器、办公软件。2025 年初我又坐在屏幕前盯着那堆样板代码问了一个问题有没有一个模版啊03 / agent第三阶段Deep Agents —— 系统构建时代2025 年 7 月Deep Agents 发布。这次不是「再盖一层」是「重新设计」。LangChain 和 LangGraph 的能力被内化为底层Deep Agents 在上面构建了完整的 Agent 运行时。它提供了什么模型管理自动选择最优模型、负载均衡、降级策略。你不再关心「这个任务该用 GPT-4 还是 Claude」。上下文工程自动压缩历史、提取关键信息、管理 token 预算。长对话不再「前面说的全忘了」。子代理一个父 Agent 可以 spawn 多个子 Agent并行处理子任务最后汇总结果。权限控制细粒度的能力边界——这个 Agent 能访问哪些 API、能执行哪些操作、能花费多少 token。记忆与技能跨会话持久记忆 可复用技能库。Agent 越用越聪明而且聪明是可迁移的。沙箱与解释器代码执行隔离环境防止 Agent 的「试错」把生产环境搞崩。协议支持ACPAgent 通信协议、MCP模型上下文协议、A2AAgent 到 Agent。你的 Agent 终于能和其他 Agent 对话了——不是通过你转发微信是它们自己谈。我第一次跑通 A2A 的时候真的有点恍惚。一个 Agent 去查数据库一个 Agent 去调外部 API一个 Agent 负责生成回复。三个 Agent 自己协调、自己分工、自己汇总我在旁边看着日志滚动像个监工。本质Agent 的「应用框架」。这个阶段AI 的能力边界从「多步流程」扩展到「完备系统」。你部署的不是一个「调用模型的脚本」而是一个「能长期运行、自我进化、与其他系统协作」的智能体。04 / map一张图看懂三代演进维度LangChain (2022)LangGraph (2024)Deep Agents (2025)核心问题怎么调用模型怎么编排流程怎么构建系统抽象层级函数调用状态机应用框架状态管理无有持久化有自动容错能力无有重试/熔断有自动恢复多 Agent不支持子图原生支持记忆短期上下文短期 手动持久长期 自动管理权限无无细粒度控制适用场景简单问答复杂工作流生产级 Agent演进逻辑不是「后者取代前者」是「后者包含前者」。这三代不是换代是套娃。Deep Agents 里面裹着 LangGraphLangGraph 里面裹着 LangChain。每一层都解决上一层搞不定的新问题。说实话这个套娃结构我一开始也没想清楚。直到有一次我的 Deep Agents 出了问题排查到最后发现是 LangGraph 的状态没持久化——那一刻我才真正理解这三层的关系。05 / pattern一个更底层的规律AI 应用开发在分层LangChain 的三年演进其实是整个 AI 应用开发的分层缩影┌─────────────────────────────────────┐ │ Deep Agents — 应用框架层 │ │ 开箱即用的 Agent 系统 │ ├─────────────────────────────────────┤ │ LangGraph — 编排层 │ │ 状态管理、容错、子图 │ ├─────────────────────────────────────┤ │ LangChain — 抽象层 │ │ 模型调用、工具、消息 │ ├─────────────────────────────────────┤ │ LLM API — 基础设施层 │ │ OpenAI、Anthropic、Google │ └─────────────────────────────────────┘这个分层和云计算很像IaaS LLM API提供算力PaaS LangChain/LangGraph提供开发工具SaaS Deep Agents提供完整应用未来的开发者大概率只和 Deep Agents 这一层打交道。 就像今天的开发者很少直接操作 Linux 内核而是通过 Docker/Kubernetes 管理应用。但这不意味着底层不重要。恰恰相反理解 LangChain你知道「模型怎么调」理解 LangGraph你知道「状态怎么管」理解 Deep Agents你知道「系统怎么搭」三层都懂你才能在 Agent 半夜挂掉的时候定位到是「模型选错了」「状态没持久化」还是「权限配错了」。我跟你说这事儿我经历过。凌晨三点监控报警Agent 挂了。我迷迷糊糊爬起来先看日志——是模型 API 超时还是状态 checkpoint 丢了还是权限 token 过期了三层排查五分钟定位十分钟修复。06 / verdict判断你在哪一层如果你还在用 LangChain 写链没问题简单场景够用。如果你在用 LangGraph 构图很好你在解决真实世界的复杂问题。但如果你要做一个「7×24 小时运行、能记住用户、能自我进化、能和其他系统协作」的 AgentDeep Agents 是目前最完整的答案。不是因为它最新是因为它解决的问题最完整。坦率的讲我自己也还在摸索。Deep Agents 的文档还在快速迭代有些功能我到现在也没完全跑通。但方向是明确的——链不够用了不是因为链不好是因为你的问题已经超出链的表达能力。图不够用了不是因为图不好是因为你的需求已经超出图的封装层级。技术选型从来不是追新是匹配问题复杂度。LLM 应用开发的三个时代说到底是 AI 从「玩具」走向「工具」再走向「基础设施」的三级跳。LangChain 让 AI 能用。LangGraph 让 AI 能跑。Deep Agents 让 AI 能活。方法放这了。选哪一层看你解决什么问题。我自己我还在第二层和第三层之间反复横跳。有些场景链够用有些场景必须上图有些场景——比如我那个 7×24 的监控 Agent——已经离不开 Deep Agents 了。反正我觉得这三层都懂你才能在 Agent 半夜挂掉的时候知道是该换模型、补状态还是调权限。如何学习大模型 AI 由于新岗位的生产效率要优于被取代岗位的生产效率所以实际上整个社会的生产效率是提升的。但是具体到个人只能说是“最先掌握AI的人将会比较晚掌握AI的人有竞争优势”。这句话放在计算机、互联网、移动互联网的开局时期都是一样的道理。我在一线科技企业深耕十二载见证过太多因技术卡位而跃迁的案例。那些率先拥抱 AI 的同事早已在效率与薪资上形成代际优势我意识到有很多经验和知识值得分享给大家也可以通过我们的能力和经验解答大家在大模型的学习中的很多困惑。我们整理出这套AI 大模型突围资料包✅ 从零到一的 AI 学习路径图✅ 大模型调优实战手册附医疗/金融等大厂真实案例✅ 百度/阿里专家闭门录播课✅ 大模型当下最新行业报告✅ 真实大厂面试真题✅ 2026 最新岗位需求图谱所有资料 ⚡️ 朋友们如果有需要《AI大模型入门进阶学习资源包》下方扫码获取~① 全套AI大模型应用开发视频教程包含提示工程、RAG、LangChain、Agent、模型微调与部署、DeepSeek等技术点② 大模型系统化学习路线作为学习AI大模型技术的新手方向至关重要。 正确的学习路线可以为你节省时间少走弯路方向不对努力白费。这里我给大家准备了一份最科学最系统的学习成长路线图和学习规划带你从零基础入门到精通③ 大模型学习书籍文档学习AI大模型离不开书籍文档我精选了一系列大模型技术的书籍和学习文档电子版它们由领域内的顶尖专家撰写内容全面、深入、详尽为你学习大模型提供坚实的理论基础。④ AI大模型最新行业报告2025最新行业报告针对不同行业的现状、趋势、问题、机会等进行系统地调研和评估以了解哪些行业更适合引入大模型的技术和应用以及在哪些方面可以发挥大模型的优势。⑤ 大模型项目实战配套源码学以致用在项目实战中检验和巩固你所学到的知识同时为你找工作就业和职业发展打下坚实的基础。⑥ 大模型大厂面试真题面试不仅是技术的较量更需要充分的准备。在你已经掌握了大模型技术之后就需要开始准备面试我精心整理了一份大模型面试题库涵盖当前面试中可能遇到的各种技术问题让你在面试中游刃有余。以上资料如何领取为什么大家都在学大模型最近科技巨头英特尔宣布裁员2万人传统岗位不断缩减但AI相关技术岗疯狂扩招有3-5年经验大厂薪资就能给到50K*20薪不出1年“有AI项目经验”将成为投递简历的门槛。风口之下与其像“温水煮青蛙”一样坐等被行业淘汰不如先人一步掌握AI大模型原理应用技术项目实操经验“顺风”翻盘这些资料真的有用吗这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理现任上海殷泊信息科技CEO其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证服务航天科工、国家电网等1000企业以第一作者在IEEE Transactions发表论文50篇获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。资料内容涵盖了从入门到进阶的各类视频教程和实战项目无论你是小白还是有些技术基础的技术人员这份资料都绝对能帮助你提升薪资待遇转行大模型岗位。以上全套大模型资料如何领取