模式矩阵 /模式白皮书/A3
ADPS Agent 设计模式白皮书
A3 · Prompt Chaining · 提示链
把一个复杂任务拆成一串小任务,每一步用一段独立的 prompt 跑,前一步的输出作为下一步的输入,串起来完成。
文档状态:本页为公开评审稿。模式定义与分类可供讨论和引用;未附来源链接的数字与应用示例只用于说明机制,不作为行业基准。
| 坐标 | 行动 Action × 链式 Chain(传) |
| 成本 | 中(拆成 N 段、N 次调用,但每段可用更便宜的模型摊薄) |
| 模式组 | 行动模式 |
| 模式简介 | 把一个复杂任务拆成一串小任务,每一步用一段独立的 prompt 跑,前一步的输出作为下一步的输入,串起来完成。 |
问题
一个 prompt 想一次干完所有事,往往哪件都做不透。某财经媒体的内容编辑 agent 第一版把校对、改写、统一风格、核查数字、起标题、写摘要、配图建议七件事写在一段提示里喂给模型,结果一篇稿子里"GMV 增长 35%"被改成了 53%——模型那一刻在"改写"模式而非"核对"模式,顺手就把数字看走了眼;越往后的任务越敷衍,配图建议永远是那三句套话。
Prompt Chaining 把大任务拆成几段独立的 prompt 串行处理,每段只干一件事、有自己的角色和最合适的模型、有自己的成功标准。它和单个超大 prompt 的区别,就是复杂度只能靠拆分降下来,塞进一个更大的盒子是降不下来的。
分类依据:行动 × 链式
- 纵轴 · 行动:一个 prompt 完不成的任务被拆成几段串行的 prompt,每一段都要触发一次模型调用或工具输出,落点是"做事"而不是单点"想事",所以属于行动模块。
- 横轴 · 链式:prompt1 → prompt2 → prompt3 是典型的线性 pipeline,前段输出即后段输入,既不是路由分流也不是图状依赖。它和规划-执行(A2)同属链式,区别在 A3 是纯直线、无 replan,A2 是 DAG、有 replan。
解决方案与机制
它的工程原型是 Unix 管道。cat data.csv | grep ERROR | sort | uniq -c 把几个单一职责的小程序靠 stdin/stdout 串起来,每个程序只读输入、写输出,不需要知道前后是谁。Prompt chain 是同一件事在 LLM 这一层的复刻,每一段 prompt 就是一个"小程序"。
比 Unix 管道多出来的那一层是闸门(gate)。Unix 程序匹配不到就空跑,LLM 却会自信地胡说,所以两段之间要插一段廉价的程序化检查——不是模型,是 Python 的 if 判断——不通过就重试或升级。研究员阶段写"找至少三篇参考",闸门就是 if len(refs) < 3,过关才往下流。
几个落地要点:
- 每段 prompt 用五件套结构:role、task、context、format、constraints,全部 wrap 在 XML 标签里。下一段的契约越显式,解析失败率越低,可靠性可测得约 8 到 15 个点的提升。
- 每段独立选模型:校对用便宜模型扛细节,创意改写用强模型,数字核查用中等模型加 thinking。把语言细节丢给便宜模型,能让总成本只比单 prompt 版多约 30%,而不是每步都用强模型的数倍。
- 闸门要带容差:写"恰好 500 词"会让 chain 永远卡死,要写成"450 到 550 词"加"必须包含三个论点"这样的范围加必要条件。
- 重试要回喂失败原因:把"上次哪里不达标"告诉模型,而不是瞎重跑,命中率才会涨。
Claude Code 把 chain 做出了三种工业形态:感知-推理-行动主循环里每个工具结果就是一节链节(隐式链);slash command 是预制链(/commit 是 status → diff → 推理 → 起草 → 提交的五步模板);SKILL.md 是可组合的链段(声明式定义多步流程,被嵌进更大的链里)。
适用条件
- 工作流有清晰阶段、阶段间能用一两行代码描述"什么算合格":内容编辑、合同审阅、客服工单分诊。生产里大部分团队最后落在 3 到 5 步。
- 要把工作流产品化成可复用入口:slash command 就是把领域专属工作流封装成预制链,用户一条命令触发整链,不用每次手写步骤。
- 需要可追溯、可信任的产出:整链 trace 留档,让业务方逆向看 agent 怎么从原稿一步步变到终稿。内容编辑案例里,trace 让编辑信任度从 42% 涨到 91%,比任何 prompt 工程都管用。
已知失效方式
- 信息饥饿:每一步只接收前一步的输出,第 3 步需要的信息在第 1 步出现过、但第 2 步没保留就丢了。chain 只传递前一步的输出,不会自动让早期信息流到后面。应对是另带一个所有步骤都能读的累积上下文对象(分布式系统里叫 saga context)。
- 闸门暴政:闸门设得太死永远过不去,"恰好 500 词"会无限拒绝 499 和 501,烧光 token 才发现。应对是范围加必要条件。
- 乘积效应被低估:单步通过率 95%、七步串起来整链通过率只剩约 70%。chain 越长,对单步通过率的要求越高。
- 第一个 prompt 的装配被忽略:生产 system prompt 通常由基础指令、用户身份、历史、当前任务、工具清单、风格、格式约束等多个数据源拼成,硬编成一坨长字符串会让最高频更新的那部分无法独立维护。
验证指标
- 整链成功率(健康区 >85%):任一步过不了闸门即算失败。低于 70% 通常是某步闸门太严或步骤间信息断了。注意按整链算,不按单步。
- 每步耗时 p99(健康区每步 p99 <3 倍中位数):chain 变慢时,这张分布图能最快找到拖后腿的那一步。
- 闸门重试分布(健康区 90% 一次过、9% 两次、1% 三次):某步重试率突然升高,几乎一定是闸门与模型当前能力不匹配。
参考实现
chain = [step1, step2, step3] # 每步自带 system_prompt + model + gate
current = initial_input
for step in chain:
for attempt in range(max_retry + 1):
result = step.run(current) # 调对应模型
若 result 过闸门:
current = result.output
break
elif 还能重试:
current += "[未达标: 原因。重试]" # 回喂失败原因
else:
return 失败(step, trace)
return 成功(current, total_tokens, trace)
工程落地要点:闸门带容差;trace 的 tokens 和耗时结构化落到日志系统;中途需要时主动取回原始输入做参照(如数字核查回到原稿,不让前面改写产生的版本污染数字)。
应用示例
财经媒体内容编辑 agent 第二版改成七步链:校对(便宜模型,闸门校验输出长度不低于输入 95%)、改写(强模型,保留作者风格)、统一风格、数字核查(中等模型加 thinking,关键设计是回到原稿做参照,闸门要求数字 100% 匹配原稿)、起标题(输出 3 个候选)、写摘要、配图建议(三类必齐)。每步独立选模型是为了控制成本。结果:数字核查准确率从 87% 涨到 99.4%,编辑信任度从 42% 涨到 91%,代价是单稿成本涨约 30%、延迟从 12 秒涨到 38 秒。这套模板可直接平移到合同审阅、医疗影像辅助、客服分诊——每步独立目标、独立模型、独立闸门。
相关模式
- 规划-执行(A2):一对对偶,一轻一重。A3 是直线,A2 是图。任务能画成 DAG(有并行、有跨步依赖)就用 A2,是一根直线就用 A3。生产里常见 A2 在外、A3 在内的混合形态。
- 工具调度(A1):嵌套关系而非替代。chain 的某一步内部可能调工具,那一步是 A1(在多个工具中选一个),但它发生在 chain 的某一节里。
- 护栏三明治(A4):chain 的闸门是同步的程序化检查,A4 的 hook 是套在工具调用前后的夹层。两者都是"让流程在卡点处可拦截"。
设计结论
只要你的系统跟 LLM 多轮对话,你其实已经在用 prompt chain 了,区别只在它是显式还是隐式——显式的链你能给每段配模型、加闸门、留 trace、replay 失败步骤,隐式的链你只能祈祷模型这次别翻车。
企业证据
当前没有与本模式绑定的公开评审案例。模式定义不因此视为已经获得企业验证。
案例收录要求说明业务约束、实现结构、已知失败和迁移边界。参见 贡献与评审规则。