不知道你有没有过这种经历好不容易把一次模型调用调试通了结果发现要做的事根本不止一步。拿我最近在做的一个自动化写作工具来说用户丢进来一个选题后面等着的是判断类型、生成大纲、分段扩写、调标题、写摘要……每一步都要重新拼一遍提示词再手动接上一步的输出。第一天写得很爽第三天就烦了。后来我把这些步骤全部换成了链Chain来处理代码反而比原来短了而且每一条业务支线都能单独测试、单独替换。这篇我就把链的核心用法整理出来最基础的 LLMChain、把固定步骤排成队的顺序链、以及让模型自己选路的路由链。如果你已经掌握了提示词模板和模型调用这篇就是帮你从“单次调用”迈到“多步骤流水线”的关键一课。1. 先想清楚链到底在解决什么问题1.1 没有链之前我的一天是这样过的很多人刚开始做 AI 应用写出来的代码长这样先调一次模型拿到结果存进变量再拼一个新的 prompt把变量塞进去再调一次模型。中间还要处理输出格式不对、模型返回空值、某个步骤想换个模型重试……整套逻辑散落在各个函数里牵一发动全身。我印象很深的是一次做内容分类加提取关键词的小工具。最初我用三步调用实现第一步让模型判断文章属于哪个分类第二步让模型提取关键词第三步把前两步结果整理成 JSON。功能确实跑通了但问题也来了每一步的输出格式稍微变一点后面步骤的 prompt 就要跟着改想在某一步之间插入一个人工确认环节几乎要把代码重写一遍。那段时间我一直在想能不能有一种方式把“一次模型调用”封装成一个标准单元然后像流水线一样自由拼接。链这个概念就是干这个的。它把一次完整的调用周期——输入、提示词渲染、模型调用、输出解析、结果传递——封装成一个可复用、可组合的单元。你不用再关心中间步骤怎么把变量传来传去只需要定义每一步做什么、输入输出叫什么名字剩下的交给链的调度逻辑。1.2 链是什么从单次调用到工作流水线用做饭来类比最直观。没有链的时候你是在厨房里自己跑着干切完菜把菜端到炒锅边上炒完菜把锅端到盘子边上装完盘再端到桌上。每一步都得亲力亲为地搬运半成品。有了链之后相当于你有了一条传送带。你只需要告诉传送带第一站是切菜第二站是炒菜第三站是装盘。传送带会自动把第一站的产物送到第二站第二站的产物送到第三站。你站在终点等着出餐就行。具体到技术层面一个链通常包含一个提示词模板负责把输入变量渲染成模型能理解的完整提示词一个模型实例负责执行推理一个输出解析器可选负责把模型返回的文本结构化成字段一组输入变量和输出变量的定义负责声明这个链对外暴露的接口一些扩展组件可选比如记忆模块、回调函数、重试逻辑。这些组合在一起就构成了一条可复用的“流水线工位”。1.3 三种链的定位LLMChain、顺序链、路由链这篇标题里的三种链正好覆盖了从简单到复杂的三种场景LLMChain 是最基础的“单体工位”。它解决的是“给定输入经过一次模型调用产出结果”这个最基本的单元问题。你可以把它理解成流水线上的一台单一功能的机器。顺序链解决的是“固定流程”的问题。当任务是天然线性的、先后顺序明确的比如先总结再翻译再润色就可以用顺序链把多个 LLMChain 串起来前一站的输出自动变成后一站的输入。路由链解决的是“分支选择”的问题。当任务需要根据输入内容动态决定走哪条处理路径比如用户问退货问题走退货流程、问改地址问题走修改流程就可以用路由链。它让模型先当“调度员”再根据调度结果把任务分发给不同的下游链。我在实际项目里的体会是能拆成固定步骤的优先用顺序链步骤之间需要动态选择的用路由链而无论哪种链底层都用 LLMChain 作为执行单元。三种链不是互斥的而是互相嵌套、层层组合的关系。2. LLMChain所有链的基建2.1 一个最基础的 LLMChain 怎么拆LLMChain 是整套链体系里最基础的构件。它的核心职责可以概括成一句话把你传入的字段按照提示词模板渲染成提示词交给模型再把模型返回的文本解析成你想要的结构。假设我要做一个“把口语表达改写成书面语”的链。常规写法大概是这样from langchain.prompts import PromptTemplate from langchain.chains import LLMChain # 假设 llm 是前面章节里我们已经配置好的模型实例 # 不同供应商的接入方式不同但从链的角度看llm 都是一个黑盒调用单元 rewrite_prompt PromptTemplate( input_variables[scene, draft], template 你是一名专业的文字编辑请把下面的口语化表达改写成书面语。 使用场景{scene} 原始内容{draft} 要求 1. 保持原意不变 2. 语气正式逻辑清晰 3. 直接输出改写后的内容不要解释 ) rewrite_chain LLMChain( llmllm, promptrewrite_prompt, output_keypolished_text, verboseTrue ) result rewrite_chain.run( scene给客户的正式邮件, draft那啥我们把价格再降点你看行不行 ) print(result[polished_text])这里面有几个关键点值得细看。第一输入变量是通过input_variables声明的。如果你在模板里写了{scene}但忘了在input_variables里声明框架会报错反过来你声明了某个变量但调用的时候没传也会报错。这个机制看起来啰嗦实际是保护它确保每个链的输入输出都是显式定义的组装大链时才能追踪数据流。第二output_key是给输出结果命名的。很多人一开始不设置它直接用返回的text字段。但在顺序链里output_key就是后一个链能拿到的变量名命名是否清晰直接决定了链路好不好读。第三verboseTrue在我调试阶段几乎必开。它会把每次调用的完整提示词和模型原始输出打到控制台。这个习惯救了我很多次。很多链的逻辑错误其实根本不是代码问题而是你塞进模型的 prompt 根本不是你脑子里想的那样。开了 verbose 一眼就能看出来。2.2 给链挂上记忆和输出解析LLMChain 的另一个价值在于它天然支持挂载额外组件。最常见的是记忆模块和输出解析器。记忆模块解决的是“多轮对话”问题。如果只是单次调用每次会话上下文都从零开始如果要做聊天机器人就需要把历史对话保存下来在每次调用时拼进 prompt。from langchain.memory import ConversationBufferMemory memory ConversationBufferMemory( memory_keychat_history, return_messagesFalse ) chat_chain LLMChain( llmllm, promptchat_prompt, # 模板里包含 chat_history、input 等变量 memorymemory, verboseTrue ) chat_chain.run(input你好我叫小明) chat_chain.run(input你还记得我叫什么吗)这里有个容易踩的坑记忆模块是否生效取决于你的提示词模板里有没有使用对应的 memory_key 变量。如果你在模板里没有写{chat_history}记忆注入得再多也是白搭。我在初学阶段就经常出现“聊了两轮之后模型完全失忆”的情况最后发现居然只是因为模板里忘了放变量。输出解析器解决的是“模型返回格式不固定”的问题。比如我想让模型返回 JSON但模型偶尔会多输出几句解释或者把 JSON 包在代码块标记里。这时候用一个StructuredOutputParser配合 Pydantic 模型能做格式校验和自动修正。from langchain.output_parsers import PydanticOutputParser from pydantic import BaseModel, Field class ArticleInfo(BaseModel): title: str Field(description文章标题) keywords: list[str] Field(description关键词列表) parser PydanticOutputParser(pydantic_objectArticleInfo) prompt PromptTemplate( template根据文章内容提取信息。\n{format_instructions}\n文章内容{article}, input_variables[article], partial_variables{format_instructions: parser.get_format_instructions()} ) chain LLMChain(llmllm, promptprompt, output_parserparser)加了输出解析器之后chain.run()返回的就不再是纯字符串而是结构化的字段。这对后面接顺序链特别重要因为下一个链往往需要上一个链输出里的某个具体字段如果上一个链吐出来一大段文本下个链还得自己解析链路就脏了。2.3 LLMChain 真正该被记住的三个细节用久了之后我发现LLMChain 的代码很简单真正值钱的是下面三个细节。第一变量命名要全局一致。写单条链的时候变量名随意一点问题不大但一旦开始组装顺序链input_variables、output_key、模板里的占位符、调用时传的字段名这四者必须完全对得上。我吃过最大的亏就是给变量起名太随意结果链一多根本分不清哪个是哪个。现在我的习惯是所有变量名都以下划线连接并且明确前缀比如source_text、polished_text、final_title。第二单链也要先单独测。很多人习惯把所有链写完再统一调试结果出问题根本不知道是哪一步。我的做法是每个 LLMChain 先独立run()一次确认输入输出符合预期再往顺序链里放。一个链没测好组装出来的大链一定不好查。第三尽量在链内部就把格式问题解决掉。输出解析器、正则清理、默认值兜底这些脏活累活应该放在链内完成。宁可让链的执行逻辑长一点也不要让下游链去猜上游输出的格式。链和链之间传递的应该是干净的、确认过的字段。3. 顺序链把固定步骤排成队3.1 SimpleSequentialChain 与 SequentialChain 的区别顺序链是最直观的组合方式适合那些流程天然线性的任务。在使用它之前得先搞清楚框架里两个关键类的区别SimpleSequentialChain和SequentialChain。SimpleSequentialChain适合简单的“前一个输出就是后一个输入”的场景。整条链只接收一个输入字段产出一个输出字段中间不关心任何中间变量。比如“先把中文翻译成英文再把英文翻译成日文”每个链的输入输出都是纯文本直接串起来就行。from langchain.chains import SimpleSequentialChain chain_one LLMChain( llmllm, prompttranslate_prompt_zh_to_en, output_keyenglish_text ) chain_two LLMChain( llmllm, prompttranslate_prompt_en_to_jp, output_keyjapanese_text ) overall_chain SimpleSequentialChain( chains[chain_one, chain_two], verboseTrue ) result overall_chain.run(今天天气真好)SequentialChain则适合多输入多输出的场景。你不仅要让每个链拿到输入字段还希望某些中间结果能保留到最后。它要求你显式地声明哪些是输入变量、哪些是输出变量并做好字段映射。from langchain.chains import SequentialChain chain_one LLMChain(...) chain_two LLMChain(...) overall_chain SequentialChain( chains[chain_one, chain_two], input_variables[product_name, target_audience], output_variables[title, post_content], verboseTrue )一句话总结单进单出选 Simple多进多出选 Sequential。我自己的习惯是除非非常确定整条链路只有一个输入一个输出否则直接用SequentialChain。多写几个变量声明换来的是清晰的数据流控制权。3.2 多输入多输出用变量映射把步骤接起来很多新手在顺序链上卡住并不是不会写链而是搞不清“变量映射”这件事。这里我拿一个“产品文案生成流水线”来拆解。整个流程设计成四步第一步根据产品名和目标人群提炼产品核心卖点第二步根据卖点和人群生成一段面向用户的销售文案第三步把销售文案改写成一个适合发社交媒体的短标题第四步把标题和文案组合成最终发布内容。如果每一步都用单独的 LLMChain 写然后在SequentialChain的input_variables和output_variables里做全量声明数据流的走向大概是这样的# 链一提取卖点 feat_chain LLMChain( llmllm, promptfeature_prompt, # 输入product_name, target_audience output_keycore_features ) # 链二生成销售文案 copy_chain LLMChain( llmllm, promptcopy_prompt, # 输入product_name, target_audience, core_features output_keysales_copy ) # 链三生成标题 headline_chain LLMChain( llmllm, promptheadline_prompt, # 输入sales_copy output_keyheadline ) # 链四组装发布内容 compose_chain LLMChain( llmllm, promptcompose_prompt, # 输入headline, sales_copy output_keyfinal_post ) final_chain SequentialChain( chains[feat_chain, copy_chain, headline_chain, compose_chain], input_variables[product_name, target_audience], output_variables[headline, final_post], verboseTrue )注意看这里的关键设计SequentialChain的输入变量是所有链共同需要的外部输入也就是product_name和target_audience输出变量是你最终想从整条流水线里拿到的字段也就是headline和final_post。中间产生的core_features、sales_copy虽然在链之间传递了但如果没有放进output_variables外部是无法直接访问的。这其实是个好消息——当你不想把一堆中间产物暴露给调用方时可以把它当作一种封装。我在最初写这类链时最糊涂的一点就是以为必须在input_variables里把每一步的所有输入都写进去。后来我把它理解成“这是整条流水线的对外接口”只有外部需要传入的字段才写在input_variables里只有调用方想要拿到的结果才写在output_variables里。内部中间变量属于链自身的实现细节框架会自动传递不需要对外声明。3.3 顺序链的隐患延迟、Token 和中间状态顺序链用起来方便但有三件事我建议你在设计阶段就想清楚不然上线了容易头疼。第一是延迟叠加。每一步 LLM 调用至少要一两秒四步顺序链跑完就是七八秒起步。如果你的业务对时延敏感得考虑是不是真的要四步都调用模型能不能把某几步合并进一个提示词里让模型一次完成。我在一个项目里就是先用了顺序链后来发现整个流程耗时太长不得不把两个链合并成一个复合提示词。第二是 Token 成本。顺序链的每一步都会重新调用模型每一步的输入又包含上一步的输出所以越靠后的步骤prompt 越长Token 消耗越大。如果你的链有循环或者会重复执行成本会指数级上升。建议在verbose模式下观察每一步的实际 Token 数心里有个数。第三是中间状态不可控。顺序链的中间产物虽然会自动传递但如果某一步模型输出不规范后续步骤会因为“吃不干净”而上行出错。我遇到过的情况是某一步模型偶尔会在正文前面加一句“好的根据你的要求我为你生成如下内容”这看似无害但到了下一步做结构化解析时这行废话就会被当成正经内容导致整个结果变形。解决办法是在输出解析器里加清理规则把这类套话直接过滤掉。4. 路由链让模型来决定走哪条路4.1 路由链的工作原理固定流程的问题解决了下一个新问题就出现了如果流程不是固定的而是要根据输入内容动态选择不同路径呢最常见的场景是客服工单。用户说“我要退货”得走退货流程用户说“帮我改下收货地址”得走修改流程用户说“我的快递到哪了”得走查物流流程。三个流程的处理逻辑完全不同。如果只用顺序链每条路径都得从头到尾跑一遍既浪费又混乱。这时候就该上路由链了。路由链的工作机制可以用一句话概括先用一个分类性质的 LLM 调用判断输入属于哪条路径再根据判断结果把任务交给对应的下游链去执行。它的结构通常包含三个部分路由判断器一个特殊的 LLM 链输入是用户的原始内容输出是一个路由决定。这个决定包含两个信息目标链的名称以及传给目标链的输入参数目标链集合一组预先写好的链每个链对应一种业务分支兜底链当路由判断器无法确定走哪条路时或者匹配不到任何目标链时用来兜底处理的链。整个流程在程序里看起来像是一个字典查找路由判断器返回一个 key程序拿这个 key 去字典里找对应的链找到就调用找不到就走兜底。4.2 实现一个工单路由 Demo看代码会比看概念更清楚。这里我实现一个简化版的电商工单路由系统只包含退货、修改地址、查物流三个分支from langchain.chains import LLMChain, LLMRouterChain from langchain.chains.router import MultiRouteChain from langchain.chains.router.llm_router import RouterOutputParser, LLMRouterPrompt # 三个业务分支 returns_chain LLMChain(llmllm, promptreturns_prompt) address_chain LLMChain(llmllm, promptaddress_prompt) tracking_chain LLMChain(llmllm, prompttracking_prompt) # 路由判断器 router_prompt LLMRouterPrompt( input_variables[input], output_parserRouterOutputParser(), ) router_chain LLMRouterChain( llmllm, promptrouter_prompt, verboseTrue ) # 组装总路由 multi_route_chain MultiRouteChain( router_chainrouter_chain, destination_chains{ returns: returns_chain, address_change: address_chain, tracking: tracking_chain, }, default_chaindefault_chain, # 兜底链处理识别不了的问题 verboseTrue ) result multi_route_chain.run(我想退货鞋子尺码买大了)这段代码里最重要的一点是路由判断器返回的目标名称必须和destination_chains字典里的 key 完全一致。实际开发中模型不一定每次都能给出精确匹配的名称所以RouterOutputParser里通常会做一定程度的格式化把模型输出规范成标准键名。但即便如此还是会出现匹配失败的情况这也是为什么必须有default_chain兜底。从实现原理上看路由链本质上就是把“分类”和“执行”拆分成了两个阶段。分类阶段是一次轻量级的模型调用只负责判断意图执行阶段才是真正处理业务逻辑的链。这样设计的好处是新增一个业务分支时只需要加一条新链并在destination_chains里注册一个 key不需要改动其他分支的代码。4.3 路由链最容易踩的三个坑我实际用路由链搭建过几个系统下面这三个坑基本每次都遇到提前写在这里帮你避雷。第一个坑是目标名称匹配不稳定。路由判断器用的是模型输出而模型对名称的还原能力有限。你配置的 key 是address_change模型可能返回address_change也可能返回change_address、address modification。一旦匹配不上任务就会误入兜底链。我的解决办法有两条一是给路由 prompt 加格式说明和少量示例明确告诉模型“可选的名称只有这三种必须原样返回其中一个”二是尽早加兜底逻辑兜底链不是摆设它是最后一道防线。第二个坑是输入参数传递缺失。有些路由分支不仅需要原始输入还需要额外的上下文信息。比如判定了“退货”分支之后退货流程可能还需要用户的订单号。如果在路由阶段没有把这些额外信息传进去下游链就会因为缺参数而报错。设计路由链时要提前想清楚每条分支链需要哪些入参这些入参是全部取自用户原始输入还是部分来自外部系统查询。第三个坑是过度依赖模型做分类。路由判断本身就有一定随机性同样的输入模型两次判断可能不一样。如果你的业务对分支选择的准确性要求很高建议不要只靠模型自由判断而是先在代码层做规则初筛。比如用户输入里包含“退货”“退款”“尺码”等关键词直接走退货分支规则没命中再去调用模型判断。这种“规则兜底 模型判断”的混合策略实测下来比纯路由链稳定很多。5. 实战一条“AI写作用流水线”的完整落地5.1 场景定义与链路设计讲完三种链的单独用法现在把它们组合在一起做一个完整的落地案例。这个例子贴近我实际做过的内容工具场景用户输入一个选题系统自动生成一篇结构完整的短文。先定义整体需求用户输入是一段话比如“如何用 Python 做自动化报表”系统需要先判断内容类型是偏教程还是偏观点输出还是偏资讯速递不同类型决定后续写法不一样确定类型后走对应的写作流程生成大纲、分节扩写、生成标题、生成摘要。这个场景天然适合“路由链 顺序链”的组合。外部先套一个路由链判断内容类型每种类型内部再挂一条顺序链执行从大纲到成文的一系列固定步骤。链路设计图可以用文字描述如下用户输入 ↓ 路由判断LLM→ 分支选择 ↓ ↓ 教程写作流程大纲 → 章节扩写 → 标题 → 摘要 观点写作流程论点 → 论证段落 → 标题 → 摘要 资讯写作流程要素提取 → 通稿成文 → 标题 → 摘要5.2 先做路由再跑顺序子链代码实现上工作分两步。第一步先建好内部的顺序链第二步再创建路由链把顺序链挂载上去。先实现教程分支的顺序链。这里我只写一个子链的骨架完整实现每个分支的代码会比较长但结构完全一样。# 教程分支大纲 → 扩写 → 标题 → 摘要 outline_chain LLMChain( llmllm, prompttutorial_outline_prompt, # 输入topic output_keyoutline ) writing_chain LLMChain( llmllm, prompttutorial_writing_prompt, # 输入topic, outline output_keyarticle_body ) title_chain LLMChain( llmllm, prompttutorial_title_prompt, # 输入article_body output_keyarticle_title ) summary_chain LLMChain( llmllm, prompttutorial_summary_prompt, # 输入article_body, article_title output_keyarticle_summary ) tutorial_chain SequentialChain( chains[outline_chain, writing_chain, title_chain, summary_chain], input_variables[topic], output_variables[article_body, article_title, article_summary], verboseTrue )观点分支和资讯分支的写法类似只是内部提示词不同。写完之后就是把这三条顺序链作为“目的地”套进路由链from langchain.chains.router import MultiRouteChain writing_router MultiRouteChain( router_chainrouter_chain, # 负责判断内容类型 destination_chains{ tutorial: tutorial_chain, opinion: opinion_chain, news: news_chain, }, default_chaindefault_chain, verboseTrue )最终调用方只需要一行result writing_router.run(如何用 Python 做自动化报表)调用方不需要关心系统内部是先判断类型还是先大纲后扩写也不需要关心每个分支里的具体链结构。这对业务代码的封装特别友好——前端拿到这个接口只认输入输出内部链路随便调整只要保持接口不变就行。5.3 运行一次观察中间产物在实际跑这条流水线时我建议开着verboseTrue观察一次完整的执行过程。你会看到几个明显的阶段第一个输出是路由判断器的分类结果模型会输出一个类似“tutorial”的目标名称紧接着进入tutorial_chain按顺序执行四个子链每一步都会打印出当前链收到了哪些输入、生成了哪些输出最终返回的 result 里只包含你在output_variables里声明的字段比如article_body、article_title、article_summary。这个观察习惯价值很大。有一次我发现某个选题的内容类型判断不稳定同样的输入有时候走教程分支有时候走资讯分支。打开 verbose 之后才发现问题出在路由 prompt 的示例太少模型对“教程”和“资讯”的边界理解不清晰。我在路由 prompt 里各加了两个正反例之后判断稳定了很多。另外中间产物对调试也很有用。如果最终文章质量不行可以逐段检查是大纲本身就偏了还是扩写环节模型没吃透大纲还是标题生成环节把文章主体理解歪了。因为每一步的输入输出都暴露出去了定位问题就快了。6. 排查记录与经验速查6.1 我平时排查链问题的方法链路一旦搭起来出问题时的第一反应不应该是去读代码而是先看数据流。我常用的排查顺序是第一步关掉所有干扰项把模型换成延迟低、输出稳定的版本避免把模型随机性问题和技术问题混在一起第二步开 verbose单条链单条链地看输入输出。重点看每个链实际收到的输入变量是否和你以为的一样第三步检查模板渲染结果。框架在你执行链之前会把模板和变量渲染成完整提示词这一步最容易暴露变量名写错、变量缺失等问题第四步把长链拆短。不要指望一条二十层的大链一次跑通先截成两段三段的子链分别测测通了再组装。这个方法帮我解决过非常多“玄学”问题。大多数 AI 应用里的 bug最后被发现都是数据流的问题而不是模型“蠢”。6.2 高频问题速查表问题现象可能原因解决思路提示词里写了{var}但执行时报变量未定义模板里的占位符没有在input_variables里声明或调用时没传该字段检查模板占位符和input_variables是否一致调用时补齐所有必填字段顺序链执行后拿不到某个中间环节的输出中间字段没有写入最终的output_variables把你需要的结果变量加到output_variables列表里路由链总是走兜底分支路由判断器返回的名称与destination_chains的 key 不一致给路由 prompt 加严格格式说明和示例检查RouterOutputParser的格式化规则下游链拿到的输入是一长段文字而不是结构化的字段上游链没有装配输出解析器给上游 LLMChain 加 Pydantic 输出解析器或返回值清理逻辑整条链路响应太慢链步骤过多每一步都在调用模型评估是否能合并步骤把不涉及推理的环节用普通代码替代模型偶尔会在输出前加“好的我为你生成如下内容”之类的话模型自身的输出习惯问题在下游链的输入处理中加清理规则或在提示词里明确要求不要输出任何废话这张表是我在实际项目中被坑过多次之后整理出来的照着排查基本能省掉大半时间。6.3 组装链路时我的三个习惯最后分享三个我养成很久的习惯它们不解决某个具体 bug但能让整条链路更健壮。第一个习惯给每条链取有业务含义的名字。链多了之后日志里全是 chain_1、chain_2 会让你崩溃。我每条链都会用name参数显式指定比如feat_extract_chain、copy_writing_chain排查问题时一眼定位。第二个习惯中间结果做缓存。顺序链中某些步骤可能被反复调用比如路由判断的结果。如果业务对成本敏感可以考虑把路由判断结果缓存起来同一输入在指定时间内不必重复分类。这个优化在调用量大时非常有效。第三个习惯把链和业务代码之间的边界划清楚。链只负责“输入变量到输出变量的映射”具体的业务逻辑如数据库查询、外部 API 调用、条件判断应该写在链的外部或者以工具函数形式注入。这样既不会把链写得臃肿将来替换模型供应商时也更方便。写在最后的体会说点个人层面的感受。刚开始用链的时候我动不动就想把所有逻辑都塞进链里觉得链路越长越“高级”。后来发现完全不是这么回事。链的核心价值不是让你追求复杂的嵌套结构而是让你把模型调用的边界画清楚哪些步骤交给模型、哪些步骤走普通代码、哪些地方需要模型做判断、哪些地方需要固定顺序执行。我现在接到一个新的自动化任务不会上来就写代码而是先拿纸把步骤画出来标清楚每一步的输入输出再决定哪些用 LLMChain、哪些串成顺序链、哪些地方必须加路由。把链路拆得足够小调试的时候才知道锅该甩给谁。这个思路比记住任何 API 参数都管用。如果你也在做类似的多步骤 AI 应用建议先拿一个最简单的场景练手比如从“一句话选题”到“一段短文”先写三条独立的 LLMChain再串成顺序链最后加一个路由判断。三十分钟跑通之后你对链的理解会上一个台阶。