先记住这个答案
适用标准是任务可被干净地分解为固定序列且每个中间输出都能被代码验证。典型如先写大纲检查后写正文。设计时保持每个 LLM 调用只做窄任务，用 if 条件决定继续或重试；若需要模型自主规划路径或步骤数量不定，应改用 Agent。链式用额外延迟换取单步精度的提升，因此先可用简单单次调用衡量底线，不足再引入。
- 任务必须先能拆成固定顺序且可检查的子步骤
- 中间每一步都要有程序化审查点防止错误累积
- 步骤数量或路径随输入变化时不应使用链式
链式处理与检查点作用机制
Prompt Chaining 的本质是把一个复杂请求切成多个连续 LLM 调用，后一个调用的输入完全来自前一个调用的输出。每步之间，开发者可插入程序化 gate：检查某种字段存在、数量范围或规则冲突；失败时返回前一步要求修正或按既定分支重试，从而避免无效输出继续向下传播。
这种结构之所以能提高准确率，是因为模型每次只需面向很小的子目标，例如“生成大纲”和“根据大纲写正文”各自聚焦一个动作，比一次输出完整文档更少分心。检查点不是模型自动完成的，而是由外部确定性代码接管，只有满足阈值才进入下一环节，这让行为变得可观察和可回退，而非一个黑盒长 prompt。
营销博客生成：先列大纲再成稿
假设需求是从一个产品标题出发写出 800 字推广文。步骤一让 LLM 只生成章节大纲，格式要求为 JSON 数组，每项含 heading 和 subpoints。步骤二用代码解析该 JSON，校验章节数在 3–6 之间、每个 heading 非空，并且首条必须包含产品名关键词。如果校验不通过，程序不调用第二步，而是带着错误原因让 LLM 重写大纲，最多重试两次。
只有在大纲检查全部通过时才将其注入第二步。第二步要求 LLM 严格按照大纲写正文，再以字符数阈值检查最终长度是否达标；不达标则输出错误并触发上层处理。通过此例，输入是产品标题，约束是固定章数范围、必需词存在，决策在每层程序判断中进行，减少无效调用和长输出中途断裂的可能性。
链式失效的边界与处理
当子任务的顺序或内容无法预先列出，例如用户提问“帮我调研竞品并形成报告”，需要先检索哪些信息、是否要追加提问都可能随时变化时，固定链就失去意义。同时，如果子步骤的合格标准只能用模糊语言描述而无法写成算法，强制用 gate 会引发频繁误判，模型重写也可能无济于事。此时宁可放弃链式改让 Agent 自己规划，或仅在关键节点加入人工复核。
另一个风险是错误累积尚未被检查点拦住的微小偏差会逐级放大，使终稿离题。加之链式多次调用增加昂贵时延，若业务对延迟敏感，应在测量结果后决定是否值得。官方的倾向是先从最简单的一次调用加示例做起，只有在问题明确且能被固定拆解时才增加链条，始终以可量化评测作为引入复杂度的依据。
容易答错的地方
- “多步任务就应链式化”
- 不成立。链式要求子任务顺序固定且每步可自动检查。若子任务间依赖动态、需模型决定下一步，例如搜索分析任务，硬套链式只会增加断点；此时应评估使用 Agent，而不是先链式再重构。
- “框架默认就是链式的实现”
- 框架虽串起多次调用，但会自动隐藏中间 prompt 与原始回复，掩盖了 gate 缺失或错误分支，调测更困难。官方建议直接用 API 写链式代码，能看见每层输入输出和重试条件，也可按需保留框架而不让抽象遮蔽判断逻辑。
面试官还会怎么问？
链式中的 gate 通常用什么规则检查？
最常见的是解析结构化输出中的必填字段是否存在、枚举值是否合法、数量范围是否合格，也可用数值比较或与用户约束匹配。由于要可判定，才让前一步命今要求输出 JSON 或明确格式，gate 失败则返回提示给模型重试，而不是让进程继续。
链式和 Evaluator-Optimizer 循环有什么关键差异？
链式的步骤预先定死且串行推进，后一步处理前一步产物；Evaluator-Optimizer 则对同一个生成结果反复评改，可视为环形反馈。链式用于固定流水线，Optimizer 用于需要迭代润色且评价标准明确的任务，如翻译或文档精修。
若中间步骤失败，应该直接重启还是只重试当前步？
优先只重试当前步骤。把失败原因与上一步输出重新组合发给同一 LLM，要求它修正后重走该 gate，并限制重试次数如 2 次；避免整链重启浪费 token。若多次失败则输出错误诊断或降级到人工处理，保证可观测。
参考资料
示例用于理解所注明的运行环境与边界；延伸学习可结合原文中的更多案例。