编排已更新 2026-06-21 · 版本 1.0
提示词链式调用
提示词链式调用（Prompt Chaining）将任务分解为固定的 LLM 调用序列，其中每一步都基于上一步的输出进行处理。它以少许延迟为代价换取极高的准确性和控制力，是最简单的流式工作流模式：只要任务可以清晰地拆分为有序的子任务，即可使用该模式。
证据: 行业观察置信度: 高来源: 行业观察来源: 论文
问题
要求单个提示词同时完成多项任务会导致输出质量下降、难以控制，且在出错时难以调试。
适用场景
当任务可以分解为清晰、有序的子任务序列（例如：先列大纲，再起草，最后编辑），且每一步都受益于上一步的结果时，请使用提示词链式调用。
解决方案
将任务拆分为离散的步骤，每步运行一次 LLM 调用，并将每次的输出传递给下一步。可以选择在步骤之间添加程序化检查（网关），以便在继续之前验证中间结果。
由于每次调用都专注于一项工作，提示词会更简单，输出更可靠，且失败会被定位到特定步骤，便于检查和修复。
组件
有序步骤每步提示词步骤间网关/验证步骤间传递的状态
优势
- 通过让每次调用专注于一项工作来提高准确性。
- 更易于调试——失败会被定位到具体步骤。
- 验证网关可以捕获步骤之间的错误。
风险
- 顺序调用会导致更高的总延迟。
- 如果不进行检查，错误可能会在链条中向下累积。
- 步骤过多会增加成本和脆弱性。
不适用场景
- 当任务足够简单，单次调用即可完成时。
- 当子任务相互独立时——请改用并行化。
- 当执行路径无法预先确定时——请使用智能体循环（agent loop）。
技术
LangGraphOpenAI Agents SDKClaude Agent SDKWorkflow engines
示例
- 生成大纲，然后撰写每个章节，最后修改语气。
- 提取结构化字段，然后对其进行验证，最后进行总结。
- 翻译文档，然后对照原文检查译文。
KPI
- 端到端成功率
- 产生正确最终结果的链条比例；错误会在各个步骤之间累积。
- 单步错误率
- 每个环节的失败率——一个可靠性为 95% 的步骤在链式调用五次后，端到端可靠性约为 77%。
- 总延迟与成本
- 链条中每次调用的总和；步骤越多，两者的消耗就越大。
- 恢复率
- 失败的中间步骤被捕获并纠正（而不是默默向下传播）的频率。
已观测到的失效模式
- 错误传播：链条前期的错误会破坏所有下游步骤。
- 随着链条变长，延迟和成本不断累积。
- 当某一步的输出格式与下一步预期的输入不匹配时，会导致脆弱的交接。
- 跨步骤丢失上下文，导致后面的环节忘记了前面设置的约束。
经验教训
- 在步骤之间进行验证或网关检查，以便在错误传播之前将其捕获。
- 在任务允许的范围内尽可能缩短链条；每增加一个步骤都会使失败概率成倍增加。
- 固定每一步的输出契约，以免交接过程默默中断。
- 将链式调用用于真正的顺序工作；对于独立的步骤，请改用并行化。
常见问题
- 提示词链式调用与智能体（agent）有什么区别？
- 提示词链式调用遵循固定的、预定义的顺序。而智能体则动态决定自己的步骤。当执行路径预先已知时，优先选择链式调用。
- 我应该在什么时候在步骤之间添加网关？
- 每当中间结果在继续之前必须满足某个条件时——这可以防止错误在链条中向下传播。
- 链式调用会增加成本吗？
- 是的，会略微增加——更多的调用意味着更多的 Token 和延迟——但对于多步骤任务，可靠性的提升通常利大于弊。