想象你是一家餐厅的主厨，周末晚上同时涌进五十桌客人。如果洗菜、切菜、炒菜、装盘、上菜全部压在你一个人身上，就算你有三头六臂也会手忙脚乱，菜品质量更是参差不齐。聪明的后厨绝不会这么做，而是把工作拆成一条动线：有人专门洗切，有人专门掌勺，有人专门摆盘，订单从传菜口一路流转，每道关卡只专注一件事。 用大模型处理复杂任务，道理一模一样。很多人习惯把需求写成一段又长又复杂的 Prompt，指望模型一口气“全能搞定”。可任务越复杂，单次调用越容易顾此失彼。Prompt 链正是为解决这个问题而生：把大任务拆成多个职责单一的小 Prompt，再按设计好的流程——串行、并行、条件、循环、路由——编排起来，让大模型像后厨不同工位一样各司其职。 本文我们就以这家“AI 餐厅”为线索，从链式思想讲起，逐步拆解五种核心模式，再看它们如何在 LangChain 与 LCEL 中落地，最后结合真实案例，帮你从“只会单点调用”成长为“能设计整条工作流”的 AI 应用开发者。

岗位关联

学会 Prompt 链与工作流设计，你就从“只会点火的厨子”升级为“设计后厨动线的主厨”，这是大模型应用从 Demo 走向生产的关键能力，也是 AI 应用工程师最核心的加分项。

目录
  1. 可视化演示
  2. 链式基础认知
  3. 串行链模式
  4. 并行与汇总
  5. 条件与路由
  6. 循环与迭代
  7. 框架实现
  8. 设计实战
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

动态演示Prompt链与工作流设计模的核心机制，通过采集/分析/决策/反馈四种模式展示关键概念与交互流程。

本节配有交互动效（进入视口后自动加载，约 3KB）。

Prompt链与工作流设计模：Prom Prompt链核心概念与工作流 串行链与并行链模式 核心机制可视化 Prompt链与工作流设计模整体架构与关键组件

链式基础认知

后厨要想接住五十桌的订单，靠的不是某位厨神的一手绝活，而是整条动线的设计。洗菜、切配、掌勺、装盘，每个岗位只认领一小块活儿，半成品在工位间流转，谁也不越界。Prompt 链的思路一模一样：与其指望一次调用解决所有问题，不如把任务拆成多步，让每一步只回答一个小问题。

为什么要拆？一次交代太多要求，人会漏，大模型同样会漏。你让模型“帮我分析数据并写周报还要做成 PPT 大纲”，它可能顾此失彼；但拆成“先总结数据趋势”、“再生成周报正文”、“最后提炼 PPT 大纲”三步，每步目标明确，质量立刻可控。

在技术上，Prompt 链就是把多个 Prompt 按预定逻辑串联起来的执行单元。它有三个核心要素：一是任务拆解，把目标分解成可独立验证的步骤；二是上下文传递，前一步的输出作为后一步的输入；三是可观测性，每一步的输出都能被记录和检查。用函数复合的语言描述，整条链可以写成：

把链想成后厨动线：切配区只接洗菜区递来的菜，掌勺区只接切配区递来的料，每站职责单一，整条动线才稳定。链式思维的核心从来不是“多用几次模型”，而是“让每一步都简单、可靠、可检查”。

Y=Pn∘Pn−1∘⋯∘P1(X)\displaystyle Y = P_n \circ P_{n-1} \circ \cdots \circ P_1(X)
这个公式把“链”浓缩成一个数学对象：X 是原始输入，P 是每一步的 Prompt 调用，∘ 表示依次串联，Y 是最终输出。
  1. 输入 X链的起点，一般是用户一句未加工的需求，比如“帮我分析这份销售数据并写一份周报”。
    X=用户原始输入\displaystyle X = \text{用户原始输入}
  2. 步骤 P_i第 i 个 Prompt 调用，每步携带自己的指令模板，只负责一个子任务。
    Pi=第 i 步的 Prompt 任务\displaystyle P_i = \text{第 } i \text{ 步的 Prompt 任务}
  3. 复合运算 ∘表示“从右往左串联”，即先执行右侧步骤，把输出喂给左侧步骤。
    (P2∘P1)(X)=P2(P1(X))\displaystyle (P_2 \circ P_1)(X) = P_2\bigl(P_1(X)\bigr)
  4. 最终输出 Y跑完整条链后的成品，是被层层加工过的结果。
    Y=链式处理后的最终结果\displaystyle Y = \text{链式处理后的最终结果}

串行链模式

流水线是后厨最朴素的形态：洗好的菜递到切配台，切好的料递到灶台，炒好的菜递到摆盘区。每一站只关心上一站递来的半成品，做完再传给下一站。串行链就是这种“一个接一个”的模式，它是所有工作流中最基础的一环。

在串行链里，数据像做菜一样被逐级加工：第 i+1 个 Prompt 的输入，必须是第 i 个 Prompt 的输出。中间状态 S_i 会不断累积前面的信息——比如先让模型生成大纲（S₁），再把大纲喂给它写初稿（S₂），最后用初稿润色（S₃），每一步都在前一步的地基上添砖加瓦。

串行链的优点是结构清晰、每步可单独调试，适合“选题→大纲→初稿→润色”这类有明确先后顺序的任务；缺点是延迟逐级叠加，而且前面一旦出错，后面会被“传染”。就像流水线上有个工位切坏了菜，后面的炒锅和摆盘都会被拖累，所以串行链的每一步都要做好输入校验。

Si+1=Pi+1(Si),S0=X\displaystyle S_{i+1} = P_{i+1}\bigl(S_i\bigr), \qquad S_0 = X
状态 S 携带到当前为止的所有信息，P 是当前这道工序，S₀ 即原始输入，层层代入直到链尾。
  1. 中间状态 S_i第 i 步处理完后的半成品，里面沉淀了此前全部步骤的“味道”。
    Si=第 i 步的中间输出\displaystyle S_i = \text{第 } i \text{ 步的中间输出}
  2. 下一步工序 P_{i+1}只消费 S_i 一份输入，不直接看原始需求，保证职责单一。
    Pi+1=串行链中的下一环节\displaystyle P_{i+1} = \text{串行链中的下一环节}
  3. 递归代入从 S₀ = X 开始逐层展开，最后一层即链的答案。
    S3=P3(P2(P1(X)))\displaystyle S_3 = P_3\Bigl(P_2\bigl(P_1(X)\bigr)\Bigr)
  4. 上下文累积越到链尾，S 里蕴含的信息越丰富，所以收尾步骤往往负责“定稿”。
    Si+1 包含 Si 的全部信息（信息递增）\displaystyle S_{i+1} \text{ 包含 } S_i \text{ 的全部信息（信息递增）}

并行与汇总

办婚宴时，后厨不会只用一口锅从中午炒到晚上。主厨会把八道菜分给四个灶头同时开火，最后统一起菜上桌。并行链就是这个思路：把互不依赖的子任务同时丢给模型，最后汇总。它专门对付“多个独立问题要同时回答”的场景，比如让模型分别总结三份文档，再把三份摘要合在一起。

并行的前提是子任务之间“不共享锅铲”——彼此独立、没有先后依赖。如果有依赖，就只能退回串行。并行之后通常还需要一个汇总步骤，把多路结果合并成最终答案，就像四条炒锅的菜最终都在传菜口汇合，由一位传菜员统一端出。

并行不是银弹：子任务有共享状态时必须串行，汇总本身也有成本。但用得对，它能把“逐篇处理 20 份文档”的半小时压缩成“20 篇同时处理 + 一次汇总”的几分钟——正如多灶同开时，起菜口要稳住，别让菜在托盘上凉了。

A=Ψ(R1,R2,…,Rn),Rj=Qj(X)\displaystyle A = \Psi\bigl(R_1, R_2, \ldots, R_n\bigr), \qquad R_j = Q_j(X)
Q 是并行的子任务，R 是各自的产出，Ψ 是汇总函数（拼接、投票或让模型统稿）。
  1. 并行任务 Q_j彼此独立的小 Prompt，可以同时执行，互不等待。
    Qj=第 j 个并行分支\displaystyle Q_j = \text{第 } j \text{ 个并行分支}
  2. 分支结果 R_j每个分支的局部产出，例如某篇文档的摘要。
    Rj=Qj(X)\displaystyle R_j = Q_j(X)
  3. 汇总函数 Ψ把多路结果合为一份，可以简单拼接，也可以让“总结模型”统一润色。
    Ψ(R1,…,Rn)=合并后的最终答案\displaystyle \Psi(R_1, \ldots, R_n) = \text{合并后的最终答案}
  4. 耗时收益并行阶段的时间取决于最慢的分支，而不是所有分支之和。
    T并行=max⁡jtj  ≪  ∑jtj\displaystyle T_{\text{并行}} = \max_j t_j \;\ll\; \sum_j t_j

条件与路由

客人下单时备注“不要香菜”“花生过敏”怎么办？后厨不能照单全做，必须有一位看单员根据订单内容分流：过敏单走无花生灶，微辣单走微辣灶，普通单走常规灶。条件与路由模式就是工作流里的“看单员”：先对输入做判断，再决定进入哪条分支。

判断可以由规则完成，比如“检查是否含'退款'关键词”；也可以由一个分类 Prompt 完成，让模型输出“退款/咨询/投诉”这种类别标签，再根据标签路由。后者被称为“软路由”，因为分类不是硬编码的，模型自己判断，泛化能力更强。

路由让复杂流程有了弹性：客服机器人先判断“是退货还是咨询”，再分别走不同话术；内容系统先判断“用户问的是价格还是功能”，再分派不同知识库。就像看单员不用细读备注就能分单——但前提是菜单得够清晰，兜底路径也得够稳。

c=arg⁡max⁡k∈{1,2,…,m}sk(X),then route to Pc\displaystyle c = \arg\max_{k \in \{1, 2, \ldots, m\}} s_k(X), \qquad \text{then route to } P_c
对每个候选分支打分 s，用 argmax 挑出最高分的编号 c，把输入派给第 c 号分支执行。
  1. 分支打分 s_k衡量“输入 X 属于第 k 类”的置信程度，分类 Prompt 会输出一组得分。
    sk(X)=输入 X 对分支 k 的匹配得分\displaystyle s_k(X) = \text{输入 } X \text{ 对分支 } k \text{ 的匹配得分}
  2. argmax 选择在 m 个候选分支里挑得分最高的下标 c。
    c=arg⁡max⁡ksk(X)\displaystyle c = \arg\max_k s_k(X)
  3. 路由派发把 X 交给第 c 号分支执行对应的 Prompt。
    X→routePc(X)\displaystyle X \xrightarrow{\text{route}} P_c(X)
  4. 兜底策略如果最高分依然低于阈值，则走默认分支，避免“强行分类”闹出笑话。
    if sc<sth, use Pdefault\displaystyle \text{if } s_c < s_{\text{th}}, \text{ use } P_{\text{default}}

循环与迭代

主厨端出一盘菜前，通常要试一下味道：淡了加盐，咸了就加点糖，再尝，差不多了才上桌。这个“尝—改—再尝”的过程，就是循环链的缩影。循环模式让模型反复迭代自己的输出，直到质量合格或达到轮次上限。

循环常用于两类场景：一是打磨类任务，比如“把这段话改得更有说服力”；二是校验类任务，比如“检查代码是否有 bug，有就修复再复检”。循环的关键不是“转多少圈”，而是“怎么判断可以停”——没有终止条件的循环，只会让 token 像后厨的燃气一样哗哗烧掉。

循环是“质量放大器”，但也可能放大噪声：没有客观标准时，模型可能越改越跑偏。好的循环链必须同时具备三个要素——明确的反馈、收敛判断、兜底上限，就像试菜要有一把准的勺子和一个“别再尝了”的闹钟。

Xt+1=R(Xt,F(Xt)),直到 Q(Xt)≥θ 或 t=Tmax⁡\displaystyle X_{t+1} = R\bigl(X_t, \mathcal{F}(X_t)\bigr), \quad \text{直到 } \mathcal{Q}(X_t) \ge \theta \text{ 或 } t = T_{\max}
R 是单轮修改动作，F 是质量反馈，Q 是质量评分，θ 是及格线，T_max 是轮次上限。
  1. 精炼函数 R一次修改操作，比如“重写这句话，让表达更简洁”。
    R=单轮优化 Prompt\displaystyle R = \text{单轮优化 Prompt}
  2. 反馈 F对当前版本的批注，比如“第一段冗长，第三段论据不足”。
    F(Xt)=第 t 轮的质量反馈\displaystyle \mathcal{F}(X_t) = \text{第 } t \text{ 轮的质量反馈}
  3. 质量收敛判断当质量评分达到及格线，说明可以停手。
    Q(Xt)≥θ  ⇒  达标，停止\displaystyle \mathcal{Q}(X_t) \ge \theta \;\Rightarrow\; \text{达标，停止}
  4. 轮次上限兜底无论质量如何，最多转 T_max 轮，防止死循环。
    t=Tmax⁡  ⇒  强制停止\displaystyle t = T_{\max} \;\Rightarrow\; \text{强制停止}

框架实现

后厨从一家店扩张到二十家连锁，靠老师傅人盯人是不行的。得把动线画成标准图纸，把水管、燃气、传菜口做成统一规格，让任何厨师拿到图纸就能上手。LangChain 和 LCEL 就是 Prompt 链世界的“标准图纸与预制管道”。

LangChain 把工作流拆成可复用的组件：ChatPromptTemplate 负责提示模板，ChatModel 负责模型调用，OutputParser 负责输出解析，它们都能用管道符 | 直接拼接。LCEL（LangChain Expression Language）是这套拼接语法，它让一条链变得像流水线图纸一样一目了然：

除了模板、模型、解析器，LangChain 还内置了 RunnableSequence、RunnableParallel、RunnableBranch、RunnablePassthrough 等“配件”，分别对应串行、并行、分支、透传。正如标准管道让连锁后厨快速复制，框架让 Prompt 链从“手工作坊”走向“工业化生产”。

chain=p1∣m∣p2∣m,chain.invoke(x)=m(p2(m(p1(x))))\displaystyle \text{chain} = p_1 \mid m \mid p_2 \mid m, \qquad \text{chain.invoke}(x) = m\Bigl(p_2\bigl(m(p_1(x))\bigr)\Bigr)
p 是提示模板，m 是模型，| 表示“把左端输出接给右端输入”，invoke 是整条链的启动入口。
  1. 模板 p带占位符的 Prompt 骨架，运行时再填入具体内容。
    p=可复用的提示模板\displaystyle p = \text{可复用的提示模板}
  2. 模型 m对输入执行一次大模型调用，返回模型生成文本。
    m=一次大模型 inference\displaystyle m = \text{一次大模型 inference}
  3. 管道符 |LCEL 的核心符号，表示左端输出接入右端输入，链式组合成新 Runnable。
    a∣b=b(a(⋅))\displaystyle a \mid b = b\bigl(a(\cdot)\bigr)
  4. invoke 入口把整条管道从首到尾执行一遍，得到最终结果。
    invoke(x)=整链求值\displaystyle \text{invoke}(x) = \text{整链求值}

设计实战

开新餐厅前，主厨会在开业前夜做一次全流程彩排：画动线图、定岗位、算翻台时间、演练爆单场景。设计一个复杂工作流同样是这个套路：先在纸上画流程图，再动手写代码。

设计方法论可以浓缩为三步：第一步，把大目标拆成有依赖关系的子任务，画出 DAG（有向无环图）；第二步，为每条边定义“接口契约”——上一节点的输出字段，正好是下一节点需要的输入字段；第三步，逐节点单步验证，再整链联调。复杂工作流往往不是单一模式，而是多种模式的组合：

一个真实的复杂工作流，往往是“串行框架 + 局部并行 + 关键节点路由 + 质检循环”的组合拳。比如研报问答机器人：并行摘要 20 篇研报 → 路由区分问题类型 → 检索后串行生成回答 → 循环质检。画好这张图，餐厅就成功了一半——剩下的，就是把每个工位的“菜谱”写好，并随时准备复盘优化。

Ttotal=∑i∈串行ti+max⁡j∈并行tj+toverhead\displaystyle T_{\text{total}} = \sum_{i \in \text{串行}} t_i + \max_{j \in \text{并行}} t_j + t_{\text{overhead}}
总耗时 = 串行环节逐个相加 + 并行环节取最长的那条 + 路由、解析等调度开销。
  1. 串行环节求和必须排队执行的步骤，时间逐个累加，没有捷径。
    ∑iti=串行步骤耗时之和\displaystyle \sum_i t_i = \text{串行步骤耗时之和}
  2. 并行环节取最大同时执行的灶头，最慢的那口锅决定何时齐菜。
    max⁡jtj=并行步骤最长耗时\displaystyle \max_j t_j = \text{并行步骤最长耗时}
  3. 调度开销路由判断、JSON 解析、网络握手等“看不见的时间”。
    toverhead=框架与网络开销\displaystyle t_{\text{overhead}} = \text{框架与网络开销}
  4. 成本估算token 花费约等于各步输入与输出长度之和，链越长越费钱。
    Tokens≈∑i(∣inputi∣+∣outputi∣)\displaystyle \text{Tokens} \approx \sum_i \left( \lvert \text{input}_i \rvert + \lvert \text{output}_i \rvert \right)

AI 应用场景

客服工单智能流转

阶段：工作流编排 / 多模式链路

解决的问题：传统客服靠人工判断工单分类、紧急度和归属部门，速度慢且标准不一。用 Prompt 链搭建“分类→路由→起草→质检”流水线，把重复判断交给模型，人员只处理疑难件。

具体案例：某电商平台用串行链做意图分类，用条件路由把“退款/物流/售后”分别派给不同话术分支，在退单 QA 环节用循环链反复校验话术合规性。接入后工单分类准确率从 78% 提升到 93%，平均响应时间从 15 分钟降到 2 分钟。

内容创作流水线

阶段：串行链 + 并行链组合

解决的问题：一篇公众号长文从选题到发布要经历大纲、初稿、润色、多平台改写，单次生成质量不稳。用链把每个环节变成独立工位，质量可控且可复用。

具体案例：某新媒体团队用串行链“选题→大纲→初稿→润色”生成主文案，再用并行链同时改写出微博、小红书、知乎三个平台版本，产出时间从 4 小时缩至 30 分钟。

多文档问答机器人

阶段：并行 + 路由 + 循环

解决的问题：20 份研报动辄十几万字，硬塞进一个 Prompt 既不现实也容易丢细节。先并行摘要、再路由检索、最后循环质检，是 RAG 场景的典型工作流。

具体案例：某券商内部问答机器人将 20 篇研报并行摘要成一个摘要库，路由模块判断问题是“数据类”还是“观点类”，再走不同检索分支，回答末尾用循环校验引用是否准确。

Python 演示

python74 行
# -*- coding: utf-8 -*-"""Mini prompt-chain workflow engine: serial, parallel, route, loop.""" import re  def llm_sim(task, text):    """Simulate an LLM call with a simple rule-based reply."""    if task == "outline":        return "1. background\n2. method\n3. conclusion"    if task == "draft":        return text + " : split big task into small steps."    if task == "polish":        if text.endswith("(final)"):            return text        return re.sub(r"\s+", " ", text).strip() + " (final)"    if task == "summary":        return text[:12] + "..."    return text  def serial_chain(seed, tasks):    """Serial chain: output of one step is the input of the next."""    cur = seed    for name in tasks:        cur = llm_sim(name, cur)    return cur  def parallel_merge(items, task):    """Parallel chain: handle independent items, then merge."""    parts = [llm_sim(task, it) for it in items]    return " | ".join(parts)  def route(query, routes):    """Router: dispatch query to a branch by keyword mapping."""    for key, task in routes.items():        if key in query:            return llm_sim(task, query)    return llm_sim("summary", query)  def loop_refine(text, max_round=3):    """Loop chain: polish repeatedly until converged or limit reached."""    prev = ""    for _ in range(max_round):        text = llm_sim("polish", text)        if text == prev:            break        prev = text    return text  def main():    # serial: outline -> draft -> polish    result = serial_chain("Prompt chain design", ["outline", "draft", "polish"])    print("Serial output:\n" + result + "\n")     # parallel: summarize three branches independently, then merge    merged = parallel_merge(["serial", "parallel", "router"], "summary")    print("Parallel merged: " + merged + "\n")     # router: dispatch to the draft branch    routed = route("how to build a router", {"router": "draft", "loop": "polish"})    print("Route dispatched: " + routed + "\n")     # loop: refine until converged    final = loop_refine("workflow draft")    print("Loop refined: " + final)  if __name__ == "__main__":    main()
目的：用不到 70 行实现一个无外部依赖的 Prompt 链引擎，覆盖串行、并行、路由、循环四种模式，可离线运行验证工作流设计思路。
  1. cur = llm_sim(name, cur)串行链的心脏：当前输出立刻变成下一步输入，对应公式 S_{i+1} = P(S_i)。
  2. def serial_chain(seed, tasks):定义串行链：传入种子输入和任务名清单，按序执行。
  3. parts = [llm_sim(task, it) for it in items]并行核心：列表推导让每个元素独立处理，互不等待。
  4. return " | ".join(parts)汇总阶段：把多路结果拼接成一份文本，模拟并行后的聚合。
  5. for key, task in routes.items():路由表遍历：按关键词映射决定请求分发去向。
  6. if key in query:命中关键词即分发；未命中则走兜底摘要分支。
  7. if text == prev: break循环终止条件：输出不再变化说明已收敛，停止迭代。
  8. for _ in range(max_round):轮次上限兜底，防止循环链无限消耗 token。

常见误区

误区“我写一个很长的 Prompt 把所有要求塞进去，效果和串行链一样，干嘛还要链？”

正解链的价值不在“长”，而在中间状态可见、可校验、可分支。就像后厨把二十道工序全塞给一个厨子，他记不住；分成工位后每步只专注一件事，哪个环节出问题一眼就能查到。长 Prompt 一旦中段理解偏差，整锅菜都要倒掉重来，而链可以精准定位到出错的那一步。

为何常见：单次调用直观简单，且早期大模型能力弱时链式调用的成本高，人们习惯了“一把梭”。

误区“多拆几步肯定更精准，我把每个句子都拆成一个 Prompt。”

正解每一步都引入一次模型调用，延迟、token 成本和出错概率会线性叠加。就像流水线工位太多，物料搬运时间反而超过加工时间。适度拆解的标准是：每步有独立目标、输入输出格式明确、能被单独验证，满足这些就够，不必追求极致粒度。

为何常见：教程常强调“拆解”，初学者误以为“拆”是目的而非手段，忽略了拆解带来的开销。

误区“我把所有步骤都改成并行，速度一定翻倍。”

正解并行只对相互独立的子任务有效，有依赖时必须串行；并行还要付出合并与调度的开销。后厨如果让一个灶台同时炒宫保鸡丁和清蒸鱼，反而互相干扰。正确做法是先画出依赖图，识别出真正可以并行的孤岛，再局部并行。

为何常见：把“并行”当成性能银弹，忽略了任务依赖关系和汇总成本。

误区“分类逻辑必须用代码硬编码，否则模型不可控。”

正解更稳的做法是先用一个分类 Prompt 做“软路由”（让模型输出 JSON 类别或置信分），再用薄薄一层代码接住结果。就像看单员用经验和菜单知识分单，而不是把每张菜单的配料规则背成代码。软路由对用户措辞的鲁棒性远高于正则匹配。

为何常见：工程师习惯确定性逻辑，对模型输出的不确定性心存恐惧，担心“模型乱分类”。

误区“只要多让模型改几轮，输出必然越来越好。”

正解没有明确质量指标和终止条件的循环，可能越改越差或原地打转，白白消耗 token。试菜需要“淡了加盐”这种可判断的反馈，如果连咸淡标准都没有，反复搅拌只会把菜做坏。循环必须配套质量评分、收敛判断和轮次上限三件套。

为何常见：把“迭代”当作万能增强器，忽略了无反馈的迭代只是随机游走。

面试题

Q1. 关于 Prompt 链的核心思想，下列说法正确的是？

单选题 · easy

  • A.让多个模型聊天直到停止
  • B.用代码写死所有输出格式
  • C.拆成小提示词按序执行← 正确答案
  • D.一个超长提示词干完所有事

答案：C。Prompt 链的核心是任务拆解与编排。A 是多个模型闲聊，不是有目标的链式工作流；B 把格式写死忽略了模型生成能力；D 是“一把梭”的长 Prompt 思维。C 正确体现了“拆小步、传输出”的链式思想，如同后厨把整桌宴席拆成多个工位。

Q2. 串行链中，后一个 Prompt 的输入来自哪里？

单选题 · easy

  • A.用户的原始问题
  • B.前一个提示词的输出← 正确答案
  • C.随机生成的占位文本
  • D.数据库里的全部记录

答案：B。串行链中每个环节只消费上一环节的输出 S_i，本环节的输出又成为下一环节输入。A 只有第一步才使用用户原始问题；C、D 与串行链无关。就像切配区只接过洗菜区递来的菜，而不是直接去菜地。

Q3. 以下哪个场景最适合使用并行链？

单选题 · mid

  • A.第二步强依赖第一步结果
  • B.子任务相互独立可同步处理← 正确答案
  • C.所有任务必须严格按顺序执行
  • D.输出必须固定为 JSON 格式

答案：B。并行链的前提是子任务相互独立、无共享状态。A 强依赖必须串行；C 顺序执行失去了并行意义；D 是否固定格式与并行无关。好比宴席上四道不相干的菜可以同时开火，而“先洗菜再炒菜”就只能排队。

Q4. 工作流中判断输入该走哪个分支，最推荐的做法是？

单选题 · mid

  • A.用正则硬编码匹配全部关键词
  • B.用分类提示词做软路由判断← 正确答案
  • C.随机选择一个分支执行任务
  • D.把所有分支按顺序都跑一遍

答案：B。软路由用分类 Prompt 输出结构化结果（如 JSON 类别），比正则硬编码更鲁棒，能覆盖未预见的表达。A 正则难以穷尽说法；C 随机选择不可控；D 全执行浪费 token。看单员用经验分单，而不是背死板规则。

Q5. 关于循环链的终止条件，以下哪种做法是错误的？

单选题 · mid

  • A.达到最大迭代轮次之后停止
  • B.质量评分超过预设阈值后停止
  • C.连续两轮输出完全相同时停止
  • D.用户不喊停就无限循环下去← 正确答案

答案：D。循环终止条件必须明确：轮次上限、质量达标、输出收敛都是合理标准。D 无上限循环会无限消耗 token，属于设计缺陷。后厨试菜总得有个“行了”的标准，否则菜永远上不了桌。

Q6. 一条链含 3 个串行步骤各需 1 秒，其后 2 个并行分支各需 2 秒，最后 1 个串行步骤需 1 秒，总耗时约多少？

单选题 · hard

  • A.3 秒
  • B.4 秒← 正确答案
  • C.6 秒
  • D.8 秒

答案：B。总耗时 = 串行前置 1 秒 + 并行阶段 2 秒（两个分支并发，取最大）+ 串行收尾 1 秒 = 4 秒。A 忽略了前置与收尾；C、D 错误地把并行时间逐个累加。并行阶段取 max 而不是 sum，这是工作流延迟估算的核心。

Q7. LCEL 表达式 chain = prompt | model 中管道符的含义是？

单选题 · hard

  • A.按位或的位运算符号
  • B.HTML 元素选择器语法
  • C.左侧输出流向右侧模型← 正确答案
  • D.数据库外键连接符号

答案：C。LCEL 的 | 是管道（RunnableSequence），把左端 Runnable 的输出接给右端 Runnable 的输入。A 是位运算误导；B、D 为无关干扰。prompt | model 相当于后厨里“传菜口→炒锅”的固定管道，一份模板配一个模型。

Q8. 以下哪些属于 Prompt 链的常见设计模式？

多选题 · easy

  • A.串行链模式← 正确答案
  • B.并行链模式← 正确答案
  • C.循环链模式← 正确答案
  • D.数据库索引优化

答案：ABC。串行、并行、循环都是本文讲解的链式模式，加上条件路由共五种。D 数据库索引属于存储优化，与 Prompt 链无关。多选题要求完整选出所有正确项。

Q9. 复杂工作流设计中，能有效降低延迟和成本的做法有？

多选题 · mid

  • A.独立子任务改为并行处理← 正确答案
  • B.合并不必要的中转输出步骤← 正确答案
  • C.无条件延长整条链的长度
  • D.给每个分支配置兜底超时← 正确答案

答案：ABD。A 并行化能显著降低延迟；B 减少无价值的中转调用可同时降延迟和 token 成本；D 超时兜底防卡死。C 无脑加长链反而增加延迟和成本。就像后厨既要多灶齐开，也要精简传菜环节，还要给每口锅设个时限。

Q10. 我要设计“20 篇行业研报自动问答”工作流，以下做法正确的是？

多选题 · extreme

  • A.逐步执行并校验每一步的输出← 正确答案
  • B.每步定义清晰的输入输出格式← 正确答案
  • C.关键分支配置默认兜底输出← 正确答案
  • D.全链路采用一个超长 Prompt 一次性处理

答案：ABC。多文档场景应遵循“并行摘要→路由→循环质检”的组合拳，A 保证中间结果可控，B 让节点间顺畅衔接，C 防止分支识别失败时系统崩溃。D 超长输入易超上下文窗口且细节丢失，违背任务拆解原则。这就像大型宴会后厨：各灶备菜、按桌分菜、试菜把关，才是正解。