提示链 Prompt Chaining

Prompt Chaining

将复杂任务拆解为多个依序执行的 LLM 子调用,前一个子任务的结构化输出作为后一个子任务的输入,通过分而治之降低单次生成的错误率。

详细解释

Prompt Chaining(提示链 / 提示串联) 一句话定义:不要指望用一个 2000 字的巨型 Prompt 让 LLM 一步搞定「读邮件 → 分析意图 → 查订单库 → 生成个性化回复 → 生成客服工单摘要」这种 5 个子任务拧成一团的复杂流程;而是拆成 5 个独立的短 Prompt 依次调用,每个 Prompt 只做一件事,上一个的 JSON 输出是下一个的输入。巨型单 Prompt 的错误率是乘法关系——每个子任务错误率 5%,5 个子任务叠加后的整体正确率只有 0.95⁵ ≈ 77%;拆成链之后每个节点都能独立校验、独立重试、独立换模型,整体正确率能拉到 98% 以上。

Prompt Chaining 不是什么新鲜东西——早在 2023 年初 GPT-4 刚出来的时候,AutoGPT 那一波 Agent 框架的底层就是它;但它是所有企业 LLM 落地工程里最被低估的基础设施。很多团队花大量时间「润色一个超级 Prompt」,其实把那个超级 Prompt 拆成 3 段链,成本可能还低 20%(前 2 段可以用小模型跑),正确率直接涨 10 个点以上。

唯元智创 的 Workflow 引擎原生就是 Prompt Chaining 可视化编辑器:拖拽每个节点(LLM 调用 / 条件分支 / HTTP 请求 / 数据库查询),连线定义依赖关系,每个节点单独指定模型、温度、结构化输出 Schema、重试策略、失败降级路径。工程团队不用写代码就能把「用户消息进来 → 意图识别 → 分支 → 查知识库 → 生成回复 → 敏感词复审」的 6 步链搭出来,10 分钟上线。

Prompt Chaining 的四种典型模式(按复杂度递增)

模式结构适合场景注意点
① 线性链(Linear)A 输出 → B 输入 → C 输入,一根直线到底信息抽取 → 格式化 → 翻译 / 摘要 → 分类 → 打标签每个节点输出必须用 JSON Schema 严格约束,禁止自然语言传递(否则会有信息漂移)
② 分支链(Conditional)A 输出一个分类标签 → 根据标签走 B 或 C 或 D 分支意图识别路由 / 根据内容严重程度走不同回复策略 / 模型分级分支条件写在 JSON 的 next_step 字段里,由路由引擎判断,不要让 LLM 输出「我觉得应该走 B」这种自然语言
③ 扇出聚合链(Map-Reduce)A 输出 N 个子任务 → 并行跑 B1…BN → 汇总到 C 统一生成最终答案长文档分块总结 / 多数据源并行查询合并 / 多智能体分别写不同章节再拼报告扇出数量要有上限(通常 ≤10),聚合节点必须检查每个并行节点的成功状态,失败的跳过或重试
④ 循环链(Loop / Iterative)A 生成初稿 → B 评审给修改意见 → A 根据意见修改 → 重复 N 次或达标写作润色、代码生成+调试、复杂推理题自我纠错必须加最大迭代次数(通常 3 至 5 次)和「达标退出条件」(B 评审分数 ≥4/5),防止死循环

Prompt Chaining 设计的三个工程铁则

规则 1:每一步只干一件事,且每个节点的输入输出必须是结构化 JSON。千万不要「步骤 A 输出一段自然语言描述,步骤 B 从描述里再抽一遍信息」——步骤 A 输出的字段必须是步骤 B 需要的字段一一对应,信息每多经过一次自然语言描述就会引入 10% 左右的漂移和噪声。举个正确示范:步骤 A「意图识别」输出必须是 {intent: "refund", order_id: "12345", reason: "damaged", urgency: 3},步骤 B「查订单」直接用 order_id,而不是步骤 A 写「用户说他买的那个 XXX 订单号可能是 12345 吧想退款因为坏了」,步骤 B 再理解一遍。

规则 2:链上 70% 的节点用便宜小模型,只把最关键的 1 至 2 个节点留给强模型。举一个典型客服链的模型分配:① 意图分类 → 8B 小模型(¥0.0002,100ms);② 提取订单号/手机号等槽位 → 8B 小模型(¥0.0002);③ 查数据库(不是 LLM);④ 生成回复草稿 → 70B 中模型(¥0.005);⑤ 安全合规复审 + 语气校准 → GPT-4o-mini(¥0.008)。整链下来 ¥0.013,对比「一个巨型 GPT-4o Prompt 全搞定」的 ¥0.08,成本是 1/6,正确率更高。

规则 3:每个节点独立做重试 + 降级 + 校验三件套。重试:输出 JSON 解析失败?自动换温度=0 再跑一次;校验:JSON 解析成功但 urgency 字段不在 1 至 5 范围内?自动打回重跑;降级:连续失败 2 次?不是让整条链报错,而是启用「降级节点」——比如意图识别降级成全量 FAQ 关键词匹配,或者直接转人工。每一层独立兜底,不要让一个节点挂了整链崩。

常见问题

Prompt Chaining 拆那么多步,总延迟会不会高到用户无法接受?
线性串行链的延迟确实是累加的,但有四个技巧可以把总延迟压到和单 Prompt 差不多:(1)能并行的绝不串行——意图识别、槽位提取、敏感词初判这三个完全独立,请求进来就三个并行同时跑,延迟取最大值而不是求和;(2)前面的小模型节点用最小规格 8B 模型 + 最高并发,延迟控制在 50 至 150ms 以内,比强模型的 500+ms 快得多;(3)流式设计——链的最后一步(生成回复给用户看的那一步)用 Streaming,把首 token 先推给用户,后面几个纯内部节点的延迟用户感知不到;(4)缓存——链的前几步(比如意图分类+槽位提取)的结果是确定性的,可以按输入问题的 hash 缓存 24 小时,重复问题 0ms 命中。实际案例:一个 5 步客服链上线前单 GPT-4o 首 token 780ms,上线后 5 步链首 token 520ms(因为前 3 步并行小模型只花了 200ms,第 4 步强模型开始流式输出),反而更快。
Prompt Chaining 和 LangGraph / CrewAI 这些 Agent 框架是什么关系?
一句话关系:Prompt Chaining 是底层原子能力(把 LLM 调用拆成步、连起来),Agent 框架是上层编排模式(给链加上记忆、工具调用、动态规划等能力)。更细区分:(1)普通 Prompt Chaining 是「静态的」——链的结构和步骤顺序是工程团队预先写死的,运行时不会变;Agent 框架(LangGraph、CrewAI、AutoGen)是「动态规划的」——链的下一步走哪条分支、要不要调工具、要不要循环,是由 LLM 在运行时自己决定的(比如 ReAct 模式的 Thought-Action-Observation 循环)。(2)落地建议:企业 90% 的生产工作流(客服、文档处理、报告生成等)其实是结构化的、固定的流程,用静态 Prompt Chaining 就够了——可控、可测、可兜底、成本低;只有 10% 真正需要「随机应变」的复杂场景(开放式研究、代码调试、需要多次试错的推理)才上动态 Agent 框架。很多团队一上来就 LangGraph,最后花了 3 个月调 Agent 不稳定性,不如先把 90% 的固定流程用静态链搞定,ROI 高得多。
链越来越长、节点越来越多,怎么调试和排查错误?
长链的可观测性是设计链的第一天就要做的,别等出了 bug 再补。每个链必须从诞生起就带以下 3 层可观测:(1)Trace 级——给每一次链的执行分配一个唯一 trace_id,每个节点的输入、输出、模型、token 消耗、延迟、是否重试、是否降级,全部结构化入库(推荐 OpenTelemetry 格式,接 LangSmith / Langfuse / Phoenix 这类 LLM Observability 平台),点一下 trace_id 就能看到整条链像瀑布图一样展开,哪一步慢了、哪一步输出奇怪一眼可见;(2)回放机制——一键「用当时的输入重新跑链」,而且可以指定「只重跑某个节点之后的所有步」(不用从头来),非常适合复现 bug 和试修复;(3)告警规则——某个节点连续 10 次 JSON 解析失败、某条链的总 token 超过历史均值 3 倍、某条降级路径触发率 >5%,这三个信号直接告警到飞书/钉钉,开发 5 分钟内感知。按这套做,链长到 20 个节点也不会混乱,排错时间从几小时降到几分钟。