跟LangChain打交道这一年多我最大的感受是很多人被它琳琅满目的组件和抽象概念劝退总觉得要先读几十篇文档再动手。但实际上用LangChain接OpenAI的LLM写一个能跑的Python应用比你想的简单得多核心就三个单词——Prompt、Model、Parser再进阶一点加个Chain。这篇文章就是我给所有想快速上手的读者准备的一份速成课全程围绕用Python构建OpenAI LLM驱动应用的真实路径把那些文档里不会告诉你的弯路、坑和效率技巧一并交代清楚。无论你是写过几天Python还是完全从零开始照着敲一遍代码大概两个小时就能拥有第一个正经的LangChain应用。先说明一下这篇第一课适合谁你了解Python基础语法知道什么是API想用大模型能力做点实际东西但面对LangChain官方文档和琳琅满目的术语时有点懵。这一课我们从零开始先把最重要的四个概念用代码打通不会扯那些花哨的Agent和Memory那些放在后续课程里慢慢展开。1. 速成课认知LangChain拆解LLM应用的三板斧说起LangChain很多人第一反应是又一个AI框架。但如果你直接拿它和Flask、Spring这种Web框架类比那会走偏。LangChain更准确的定位是一套面向LLM应用开发的编排工具集——它的核心价值不是替你写模型而是让你把调用大模型这件事变成像拼积木一样可组合、可维护、可替换的过程。1.1 从裸写OpenAI API到用LangChain的真实差异先看一段没有LangChain时的Python代码这是很多初学者一开始会写的import openai import os openai.api_key os.getenv(OPENAI_API_KEY) def chat_with_gpt(prompt): response openai.ChatCompletion.create( modelgpt-4o-mini, messages[ {role: system, content: 你是一个乐于助人的助手}, {role: user, content: prompt} ], temperature0.7 ) return response.choices[0].message.content print(chat_with_gpt(介绍一下LangChain))这段代码单看没什么问题但它存在几个隐患一是messages结构完全手工维护prompt一变就得改调用逻辑二是输出取choices[0].message.content这一长串链式索引每次写都容易手滑三是你没法很方便地在调用模型前后插入额外处理比如格式化输出、多次重试、日志记录。用LangChain重写同样的逻辑from langchain_openai import ChatOpenAI from langchain_core.prompts import ChatPromptTemplate llm ChatOpenAI(modelgpt-4o-mini, temperature0.7) prompt ChatPromptTemplate.from_messages([ (system, 你是一个乐于助人的助手), (user, {input}) ]) chain prompt | llm result chain.invoke({input: 介绍一下LangChain}) print(result.content)注意区别在哪里prompt | llm这种管道符写法是LangChain 0.1之后主推的LCELLangChain Expression Language表达式语法。它把提示词模板和模型调用通过一个|符号组合成一个完整执行链。将来你想在中间加一个输出解析器只需要在管道后面再接一段chain prompt | llm | parser——操作逻辑和Unix管道一模一样极其直观。提示新版LangChain的ChatOpenAI从langchain_openai导入而不是旧的langchain.llms。早期教程里那种from langchain.llms import OpenAI的写法在新版中已经不建议使用如果你照着老教程装大概率会遇到ImportError。1.2 第一课只需要掌握四个核心概念LangChain的组件非常多什么Document Loaders、Vector Stores、Tools、Memory、Agents听着就头大。但第一课我建议大家只抓四个概念其他的先不管Chat Models负责和你选择的LLM打交道。你告诉它模型名、温度、API Key它帮你发请求、收响应。我们用的ChatOpenAI就是这类组件。Prompt Templates把提示词从硬编码字符串变成可填充的模板。用户输入的动态内容通过变量占位符注入不再需要每次拼接字符串。Output Parsers把模型返回的文本转成你需要的结构。比如从一大段话里提取出JSON、把回答整理成列表甚至直接映射成一个Python数据类对象。Chains把前面三个串起来的执行流程。可以是一行管道表达式也可以是多个步骤拼接的长管道。只要把这四个概念理解透LangChain的日常用法你已经掌握了七成。Memory记忆和Agents智能体本质上是Chain和工具的延伸等基础牢固之后再去碰会轻松得多。为什么我强调先只学四个因为学习框架最大的陷阱是过早接触过多抽象概念。我见过太多人被LangChain的生态地图吓退其实你真正每天写的代码用到的就是这几个核心类而已。2. 动手前准备Python环境、API Key和三个常踩的坑这一节没有高深理论但偏偏是很多人卡住最久的地方。我见过太多人在代码层面完全没问题最后卡在安装依赖和认证上所以这部分务必仔细看完。按照下面的顺序来十分钟内就能进入可以写代码的状态。2.1 环境搭建Python版本和虚拟环境LangChain对Python版本要求不算苛刻Python 3.9到3.12都能跑。但我在实测中建议用3.10或3.11因为3.12在某些依赖库尤其是一些涉及C扩展的包上偶尔会出兼容性问题而3.9以下版本则太老了逐渐被生态抛弃。我推荐使用venv创建独立环境否则你未来处理多个项目时依赖版本冲突会让人奔溃python -m venv .venv source .venv/bin/activate # Windows下是 .venv\Scripts\activate激活后用pip安装核心依赖注意是下面三个pip install langchain langchain-openai langchain-core大概率你还会用到python-dotenv来管理API Key以及pydantic来做结构化输出装LangChain时一般会带但建议确认一下pip install python-dotenv pydantic注意langchain-openai是新版LangChain中专门负责OpenAI模型接入的扩展包。langchain这个主包本身已经不再内置任何模型厂商的实现这是为了抽象解耦。初学时不用纠结设计哲学只需要知道装这两个所有OpenAI相关的功能就齐了。2.2 配置OpenAI API Key别把密钥写进代码截止到现在OpenAI的API调用都还是用API Key认证。获取方式很简单登录OpenAI平台进入API Keys页面创建一个新的密钥复制保存。需要强调的是这个密钥只完整显示一次丢失就得重新生成。有了Key之后我强烈建议你用环境变量管理而不是硬编码在Python文件里。在项目根目录创建一个.env文件OPENAI_API_KEYsk-xxxxxx然后在代码里只需要三行from dotenv import load_dotenv load_dotenv()ChatOpenAI在初始化时会自动读取名为OPENAI_API_KEY的环境变量不需要你手动传参。这一点很方便也避免了Key泄露进Git仓库的风险。如果你已经不小心把Key提交到公开仓库了别犹豫立刻去OpenAI后台把这个Key作废重新生成一个。关于API付费OpenAI对调用按token计费不同模型价格不同。新手阶段我推荐使用gpt-4o-mini它的价格是gpt-4o的几十分之一但日常任务的能力已经绰绰有余非常适合学习和跑Demo。等到逻辑验证通过再换成更强的模型不迟。2.3 三个新人必踩的坑版本、超时和默认参数环境这块我总结了三个高频问题提前给你打预防针一是安装版本冲突。如果你电脑上之前装过旧版LangChain或者照着某篇老博客装了一堆langchain-experimental之类的包就可能出现各种ImportError。最干净的办法是创建一个全新虚拟环境然后重新安装。如果问题依旧就pip install --upgrade langchain langchain-openai langchain-core把所有包升到最新。二是请求超时。默认情况下OpenAI接口在国外如果你的网络环境不太稳定代码会卡在漫长的连接等待中。不用急着想什么特殊方案合法合规的做法是配置合理超时参数llm ChatOpenAI( modelgpt-4o-mini, temperature0.7, max_retries2, # 失败重试次数 request_timeout30 # 单次请求超时时间单位秒 )三是max_tokens默认值问题。旧版OpenAI API中如果你不传max_tokens模型会按上下文窗口上限输出但某些模型和某些版本组合下不传会采用一个偏小的默认值导致中文内容输出到一半戛然而止。稳健的做法是显式设置max_tokens1024根据自己的需要调整。3. 第一个LangChain程序完成一次有人情味的对话环境准备好之后我们立刻开始写第一个完整程序。这一节不绕弯子从最基础的模型调用讲到提示词模板的封装让读者能直观感受LangChain的编码节奏。3.1 Chat Models的三种角色System、Human、AI调用OpenAI的模型本质上是把一段对话历史发给它。这个对话由不同角色的消息组成在LangChain里对应关系很清晰System Message系统消息设置模型的整体行为和人设。比如你是一个资深的Python开发导师回答要通俗易懂。系统消息通常在整个对话中只出现一次起纲领性作用。Human Message用户消息用户当前输入的内容。每次用户说话就是一条Human消息。AIMessageAI消息模型之前的回复。你把它放回对话历史里模型就知道之前聊过什么从而保持上下文连续。在LangChain中创建这些消息最简单的方式是用元组语法传入ChatPromptTemplatefrom langchain_core.prompts import ChatPromptTemplate prompt ChatPromptTemplate.from_messages([ (system, 你是一位语言简练的资深Python导师回答问题不超过200字。), (user, {input}) ])这套写法会把(system, ……)自动识别为SystemMessage(user, {input})识别为HumanMessage。{input}是占位符后续用字典传入真实内容。要理解为什么这么设计可以想象你在咖啡馆跟一个记性很好的朋友聊天你先告诉他我叫小明喜欢简洁的回答系统消息然后开口提问用户消息朋友的答复AI消息又会被记录在案下一轮继续聊的时候再发回去。这套消息机制就是LLM对话的基本协议LangChain只是把它封装成了人类可读的接口而已。3.2 Prompt Templates把提示词从字符串变成可复用的模板我见过不少初学者用f-string拼接提示词一开始觉得挺好用写多了就会发现到处都是f...一旦提示词变长可读性就崩了而且你无法在多个地方复用同一个提示词结构。LangChain的ChatPromptTemplate就是来解决这个问题的。核心特性有两个一是变量注入。在模板里用{变量名}作为占位符传参时只需要一个字典。比如上面那个例子prompt.invoke({input: 请用List[dict]返回LangChain的核心概念列表})模板会自动把输入填充进去返回一个完整的ChatPromptValue对象。二是模板复用。同一个模板可以生成多个不同的完整提示词。你在后台定义一次前端来什么请求都能套用。实际开发中我习惯把所有PromptTemplate集中放在一个prompts.py文件里这样提示词和业务逻辑分离修改提示词时不用翻代码对非程序员同事也更友好。这是一个很小的工程习惯但越到后期越能感受到它的价值。3.3 组合模型和模板完成第一个完整应用现在把前面所有东西组合起来完成一个完整的LangChain应用。这个应用做一件事接收用户输入的技术关键词让模型用通俗的语言讲解并限制在150字以内。from dotenv import load_dotenv load_dotenv() from langchain_openai import ChatOpenAI from langchain_core.prompts import ChatPromptTemplate # 1. 配置模型 llm ChatOpenAI( modelgpt-4o-mini, temperature0.3, max_tokens500 ) # 2. 定义提示词模板 prompt ChatPromptTemplate.from_messages([ (system, 你是一位技术讲师擅长用生活化类比解释复杂概念。回答不超过150字。), (user, 请解释一下什么是{concept}) ]) # 3. 用管道符构建执行链 chain prompt | llm # 4. 调用 response chain.invoke({concept: LangChain的PromptTemplate}) print(response.content)运行结果会是一段通俗的解释文字。这段代码虽然只有十几行但它已经是一个完整应用有模型配置、有提示词模板、有执行链、有调用入口。我来说下temperature0.3这个参数。temperature控制输出的随机性取值0到2越低越保守、越倾向确定性输出越高越发散和有创意。解释概念这种任务希望稳定准确用0.3比较合适如果是头脑风暴或写故事调到0.8甚至1.0都行。新手容易犯的错是不区分任务类型统一用默认值结果发现同一个问题每次回答都不一样其实不是模型坏了是你温度设太高了。4. 让模型输出变成结构化数据Output Parsers实战第一个程序能跑通之后很多人会陷入只会聊天的瓶颈——得到一个字符串但不知道怎么把它变成程序里的字典、列表、类对象。这一节我们要攻克的正是这个问题也是从写死Demo迈向做正经应用的关键一步。4.1 为什么需要Output Parser当一段文字需要变成一份数据LLM的输出永远是文本但你的业务逻辑想要的往往是结构化数据提取一份简历里的姓名、电话和技能列表把一条评论分类成正面/负面从一篇文章中抽取标题和摘要。这些场景的共同点是结果需要进入Python程序继续处理而一坨自然语言文本无法直接参与计算。最笨的办法是让模型以JSON格式输出然后你json.loads()它。听起来挺合理但实测会踩不少坑模型偶尔会在JSON前后加上解释性文字导致json.loads直接报错模型生成的JSON键名和你的类属性对不上还得写一堆映射代码模型生成的嵌套结构不稳定时而有字段时而无字段你的解析代码得写一堆if判断。Output Parser就是来解决这些问题的。它负责约束模型的输出格式并在代码层面把模型返回的文本自动解析成指定结构。一旦解析失败它会自动要求模型重新生成直到得到合法结果。4.2 第一个简单ParserStrOutputParser在所有Parser中StrOutputParser是最简单的无脑Parser。它的作用是什么都不做——把模型输出直接转成字符串。你可能会问模型输出本来就是字符串为什么要转这就要说回LangChain的管道机制了。ChatOpenAI返回的是一个AIMessage对象里面有content属性。如果你用chain prompt | llm最终invoke返回的确实是一个AIMessage。但如果你希望整条链的最终输出是一个纯净的字符串而不是一个对象就在管道后面加一个StrOutputParserfrom langchain_core.output_parsers import StrOutputParser chain prompt | llm | StrOutputParser() result chain.invoke({concept: LangChain的PromptTemplate}) print(result) # 直接是字符串别看这只是一个微小的变化它让输出类型和输入类型在整个链条中更统一也方便你在长管道里对字符串做后续字符串处理。我建议所有简单场景的Chain都默认加StrOutputParser这是一个好习惯。4.3 进阶用PydanticOutputParser定义结构现在进入重头戏让模型按你定义的Pydantic模型输出。什么是Pydantic简单说它让你用Python类定义数据结构长什么样LangChain再利用这个类去硬性约束LLM的输出。我先定义一个Pydantic类让模型把一条技术介绍拆成三个字段from pydantic import BaseModel, Field class TechConceptInfo(BaseModel): name: str Field(description概念名称) metaphor: str Field(description用于解释该概念的生活化类比) key_point: str Field(description核心要点一句话)然后用PydanticOutputParser配合提示词模板一起使用from langchain_core.output_parsers import PydanticOutputParser parser PydanticOutputParser(pydantic_objectTechConceptInfo) prompt ChatPromptTemplate.from_messages([ (system, 请根据用户的概念用提供的格式返回。 {format_instructions}), (user, 解释一下{concept}) ]) # 把Parser生成格式要求填充进模板 format_instructions parser.get_format_instructions() prompt_with_format prompt.partial(format_instructionsformat_instructions) chain prompt_with_format | llm | parser result chain.invoke({concept: LangChain}) print(result.name) print(result.metaphor) print(result.key_point)整个过程LangChain做了什么它会把TechConceptInfo类的字段定义翻译成一段很详细的JSON格式说明塞进format_instructions引导模型输出符合这个结构的JSON。parser收到输出后先尝试json.loads再用Pydantic做类型校验最终返回一个TechConceptInfo实例。你可能注意到了prompt.partial(format_instructionsformat_instructions)这个写法。它的作用是在模板渲染之前预先填充一个固定变量这样每次调用时只需要传concept一个变量。这个技巧在实际项目里非常好用因为格式说明通常是固定的没必要每次都重复传。4.4 更省事的时代方案with_structured_outputPydanticOutputParser是经典方案但如果你用的是新版langchain-openai有一个更简洁的推荐方案——model.with_structured_output()。它不需要像上面那样手动把格式说明塞进提示词而是直接把Pydantic类传给模型绑定方法from pydantic import BaseModel, Field from langchain_openai import ChatOpenAI class TechConceptInfo(BaseModel): name: str Field(description概念名称) metaphor: str Field(description生活化类比) key_point: str Field(description核心要点) model ChatOpenAI(modelgpt-4o-mini, temperature0.2) structured_model model.with_structured_output(TechConceptInfo) resp structured_model.invoke(请用结构化方式解释LangChain) print(resp.name) print(resp.metaphor) print(resp.key_point)这段代码可能是我日常用得最多的写法。with_structured_output基于模型的函数调用能力Function Calling你不需要在提示词里写format_instructions模型自己就知道要返回什么结构。代码少了三板斧出错概率也大幅下降。提示with_structured_output背后依赖OpenAI的Function Calling能力所以要求模型支持这个功能。gpt-4o-mini和gpt-4o都支持实测非常稳定。如果未来你想切换到其他厂商模型要先确认它也支持Function Calling否则还是老老实实用PydanticOutputParser。在实战中我建议优先用with_structured_output它简洁且稳健。但PydanticOutputParser依然是很好的理解底层机制的学习工具两者都值得掌握。5. 三行代码把任务拆成流水线LCEL语法与Chain串联把模型调用、提示词模板、解析器组合起来之后你就会开始遇到新的需求能不能让模型先做A任务再做B任务最后用C格式输出这一节就是教你如何用LangChain的表达式语法把多个任务串成流水线并让它们高效执行。5.1 理解LCEL管道符为什么它不是魔法你前面已经反复看到|这个管道符现在来说透它。prompt | llm | parser这行代码的语义是先把变量传入prompt生成消息再把消息交给llm调用模型最后把模型输出交给parser解析。每一步的输出就是下一步的输入。为什么选择管道符因为LLM应用的开发本质就是数据流的加工过程原材料用户输入经过多道工序模板/模型/解析最终产出成品结构化对象。Unix设计哲学里的管道用在这里几乎天衣无缝。你不需要去定义中间变量、不需要写一堆嵌套函数调用所有流程一目了然。用普通Python写同样的逻辑大概是这样的messages prompt.format(conceptLangChain) ai_message llm.invoke(messages) final_result parser.invoke(ai_message)这种写法也不算差但问题在于一旦你需要在这三步中间加错误处理、加缓存、加异步代码会变得冗长。而LCEL语法由于每一步都是标准接口框架层面就能提供统一的invoke、batch、stream、ainvoke等通用方法这才是它真正的价值所在。5.2 一次有代表性的流水线示例总结、翻译、提取关键词现在我们来串一条更长的链条演示三个模型调用如何协作。假设任务是这样的用户输入一篇英文技术文章的摘要系统需要先总结成一段中文再从总结中提取关键词最后把关键词和总结拼接成JSON格式。from langchain_openai import ChatOpenAI from langchain_core.prompts import ChatPromptTemplate from langchain_core.output_parsers import StrOutputParser from langchain_core.output_parsers import JsonOutputParser llm ChatOpenAI(modelgpt-4o-mini, temperature0.2) # 第一步总结 summarize_prompt ChatPromptTemplate.from_messages([ (system, 你是一个专业的英文技术编辑擅长提炼核心内容。), (user, 请将以下英文文本概括成一段150字以内的中文总结\n{text}) ]) # 第二步从总结中提取关键词 keywords_prompt ChatPromptTemplate.from_messages([ (system, 你是信息抽取专家。只输出关键词列表不要其他内容。), (user, 从这段中文总结提取3-5个关键词\n{summary}) ]) # 第三步把关键词和总结打包成JSON json_prompt ChatPromptTemplate.from_messages([ (system, 你是数据整理助手严格按JSON输出。), (user, 根据总结和关键词生成JSON包含summary和keywords两个字段。\n总结{final_summary}\n关键词{keywords}) ]) json_parser JsonOutputParser() chain ( summarize_prompt | llm | StrOutputParser() | (lambda summary: {summary: summary}) | keywords_prompt | llm | StrOutputParser() | (lambda keywords: {final_summary: ..., keywords: keywords}) | json_prompt | llm | json_parser )上面代码中我用了两处lambda来调整数据形状确保每一步传给下一步的变量模板能对齐。这是LangChain用管道串联多步骤时最核心的技巧——中间数据的形状管理。初学者容易在这里卡住上一步输出一个字符串下一步的模板需要的是一个字典对不上就报错。一个朴素的解决办法就是在该处加一段lambda把数据包装成字典再往下传。不过上面这个chain有一个效率问题第二步翻译和第三步提取其实依赖第一步的结果它们之间是严格串行的。如果某些分支彼此独立可以用RunnableParallel并行执行以节省时间。5.3 并行执行RunnableParallel的使用场景考虑另一个常见场景用户给了一段产品描述你想同时得到产品简介和宣传标语两段文本。这两个任务完全独立没有依赖关系串行跑两次模型调用纯属浪费时间。from langchain_core.runnables import RunnableParallel llm ChatOpenAI(modelgpt-4o-mini, temperature0.7) intro_prompt ChatPromptTemplate.from_template( 为{product}写一段30字以内的产品简介。 ) slogan_prompt ChatPromptTemplate.from_template( 为{product}写一句有冲击力的宣传标语。 ) chain RunnableParallel( introductionintro_prompt | llm | StrOutputParser(), sloganslogan_prompt | llm | StrOutputParser() ) result chain.invoke({product: 一款智能保温杯}) print(result[introduction]) print(result[slogan])RunnableParallel接受一个字典字典的每个value都是一条子链。在invoke时框架会同时发起两个模型请求底层是并发调用耗时取两者最大值而不是简单相加。这样做的一个很实用的场景是如果你需要多个助手角色同时处理同一份输入比如一个写正文、一个写标题、一个写摘要并行之后整个流程的响应时间会大幅缩短。5.4 第一课的边界什么时候不要硬用Chain学到这里你可能会产生一种冲动把一切都做成LCEL链。我得提醒一句链越长越难调试。如果一条链里出现三层以上模型调用任何一个中间节点的输出稍微不符合预期排查起来都会很费劲。而且每一步模型调用都在消耗token链过长既慢又贵。我的经验法则是两步以内的组合随意用管道两步以上考虑拆成多个独立链在业务代码里用普通Python串起来。LangChain的价值在于让每一步可组合、可替换而不是让你把整个应用写成一坨几千行的超级链。这个边界感值得在早期就建立起来。6. 速成课避坑实录四个我花时间最多的疑难杂症速成课最值钱的部分往往不在怎么跑通而在跑不通时怎么办。这一节把我自己踩过的、以及身边同事反复踩的坑集中列出来每一节都是一个真实的排查过程不是简单的答案罗列。6.1 版本错乱引发的一切ImportError现象from langchain_openai import ChatOpenAI报错ModuleNotFoundError: No module named langchain_openai或者from langchain.llms import OpenAI报类似错误。排查链先pip show langchain-openai看看装了没有再pip list看一堆包的版本是否混乱再回忆是不是看了2023年的老教程装的旧包。我当时的解决办法很简单从零开始重建环境pip uninstall langchain langchain-openai langchain-core -y pip install langchain langchain-openai langchain-core --upgrade如果你在Windows上遇到某些包编译报错优先升级pippython -m pip install --upgrade pip。另外注意langchain-community这个包里装了一堆第三方集成如果你不需要尽量别装它往往是版本冲突的源头之一。6.2 模型把JSON输出到最后截断了现象使用with_structured_output或者JsonOutputParser时偶发解析失败或者直接把输出截断在一半。排查过程第一次遇到时我先怀疑是Parser问题后来仔细看返回原始文本发现后半段竟然没输出完。我立刻意识到是max_tokens设得太小模型在生成JSON的过程中触发了长度上限导致JSON不完整Parser当然解析不了。解决把max_tokens从128改成512问题消失。经验是涉及JSON生成时max_tokens至少要给你预期JSON长度的两倍以上因为模型还要生成键名、花括号、逗号等额外字符。更稳妥的办法是用max_tokens1024起步不够再调。6.3 温度参数与胡说八道的边界现象模型在解释概念时偶发出现事实性错误甚至一本正经地给出不存在的API用法。原因分析temperature太高导致稳定性下降是原因之一但更重要的是——LLM本身就有幻觉倾向哪怕温度设为0也不是100%靠谱。我的建议对事实准确性要求高的任务比如提取、分类、结构化温度设为0或0.1优先创意生成任务可以放宽到0.7~0.9。另外一定要在System Prompt里加一句如果不确定请明确回答不知道比任何参数调优都实用。不要指望模型永远不会犯错你要做的是设计一个尽量不让错误发生的流程以及让错误显性化的验证逻辑。6.4 重试策略与配额限制便宜模型也怕限流现象请求偶发返回429Rate Limit或5xx错误。排查过程一开始我以为是网络问题但连续的请求日志显示报错多发生在同一时刻发起多个并发请求之后而单次请求正常。结合OpenAI的配额机制基本确认是被限流了。解决方案有两层。第一层是代码层面的重试机制ChatOpenAI自带max_retries参数llm ChatOpenAI( modelgpt-4o-mini, max_retries3, request_timeout30 )第二层是业务层面的并发控制如果你在RunnableParallel里同时发5个请求要注意你的账户并发限制不要把RunnableParallel用到极致。我后来写了个简单的信号量限制并发数实测稳定很多。这里多说一句OpenAI按token计费同样的代码如果写得太啰嗦成本会明显上升。新手阶段最容易忽略的是Prompt长度——一段2000字的System Prompt每次调用都收费虽然单价低但积少成多。如果整个应用承载量一大这会变成一笔真金白银的成本。优化思路是把提示词写精练常用知识从外部检索后按需注入而不是一股脑塞进System Prompt。这一课到这里应该够你亲手跑起来一个基于LangChain和OpenAI LLM的Python应用了。我强烈建议你现在就打开编辑器把第三、四、五节的代码按顺序敲一遍跑通一个完整版本再试着改改参数、换换Prompt、加加Parser。遇到问题回头对照第六节的排查思路大多数坑都能就地解决。我个人在实际操作中的体会是LangChain这种框架除非你真的把代码跑起来否则看再多文档都只是好像懂了。第一次用prompt | llm | parser跑出结构化输出的那一刻你才会真正理解为什么这个管道符号是一个如此漂亮的设计。下一课我会接着讲Memory和Agent——让应用能够记住多轮对话、具备自主调用工具的能力你可以把目前搭建的Chain当作跳板继续往这个方向延伸。