提示链设计实战：从单次Prompt到工程化智能体执行流

先说个翻车现场。有一次我想让智能体帮我分析一批产品反馈于是直接甩给它一句话“请生成一份用户反馈分析报告”。模型确实给了我一份报告但里面的结论自相矛盾优先级判断离谱甚至把两个渠道的反馈混在了一起。后来我换成了一条三步提示链先清洗归并再做归因分析最后生成建议。同一份数据同一个模型结果从“不能看”变成了“可以直接进周报”。差距在哪里不在模型智商在执行流设计。所谓智能体执行流就是把一个复杂目标拆解成若干步骤确定每一步的输入、输出、判断标准和失败处理方式让模型在每个时刻只负责一小块任务。而提示链模式是其中最简单也最好用的一种流水线方案前一步的输出经过校验后作为下一步的输入像工厂产线一样逐级加工。这篇笔记我会完整记录我拆执行流、搭提示链的过程也会把那些只有真正跑过才会遇到的坑一起讲清楚。适合正在学习智能体开发、尤其是想从“单个Prompt调用”往“工程化智能体”过渡的读者。1. 同样一个模型为什么跑一遍流程就像换了个人1.1 一次调用塞太多指令模型必然顾此失彼很多人把智能体当成一个更大的对话框丢一堆背景、需求、格式要求进去然后期待模型一口气给出成品。这个思路在简单任务上没问题可一旦任务超过两三个维度表现就开始崩。原因不玄学当前主流模型的注意力分布并不均匀长上下文里中间部分的信息本来就容易被“漏读”。你让它在同一时刻判断用户情绪、归类主题、生成优先级还要遵守JSON格式它每一步都能做但合在一起就会互相挤占注意力最后输出顾此失彼。这个现象在业内有个直观说法lost in the middle。位置靠后的指令模型记得牢靠中间的内容容易被当成噪音忽略。所以当你的单次Prompt里既有业务背景、又有输出格式、还有若干条限定条件时模型很难真正兼顾。靠“把Prompt写得更好”能改善一些但天花板很低。更务实的思路是别让模型在同一时间负担这么多事把任务按自然边界切开一次只让它做一个小决定。1.2 执行流本质上在管理四样东西我理解的执行流并不是要把代码写成多么复杂的状态机它只需要回答四个问题回答清楚了执行流就立起来了。第一任务切成哪些环节每个环节的输入和产物分别是什么。第二环节之间是严格串行还是某些环节可以并行、可以跳过。第三哪些判断交给模型哪些判断交给规则。模型擅长模糊分类与语义理解不擅长精确计算和格式强制。第四某一步失败后怎么处理是重试是换措辞还是直接降级到等待人工介入。把这些想清楚并用代码固定下来就得到一个可观察、可修改、可复用的执行流。我做过一个用来给用户反馈做分类质检的模拟项目X一开始也是给一个“全能Prompt”处理效果飘忽不定后来我把任务拆成五个环节每个环节只让模型做一个判断效果立刻稳定下来。这件事给我的启发是模型的能力边界没有变变的是我们把任务切到多小、在哪个节点做校验、失败后怎么兜底。2. 提示链模式拆到底一条流水线为什么会让模型更稳2.1 什么叫提示链就是“串起来”提示链模式英文常叫Prompt Chaining是我认为最值得先掌握的执行流基础形态。一句话描述把任务拆成若干环节每个环节都用一段独立的提示词环节A的输出经过校验后变成环节B的输入一环套一环直到产出最终结果。它很像工厂里的流水线每个工位只拧一颗螺丝不关心整台车长什么样但所有工位加在一起就是一条完整产线。举例来说以前让模型“把一段产品文案改写得更活泼然后提取里面提到的三个关键卖点再写一条推广摘要”这就是三个不同性质的任务改写需要开放的创造力提取需要精确的语义匹配摘要需要概括能力。揉在一个Prompt里模型容易把“卖点提取”做成了“卖点改写”。拆成链之后第一步只做改写第二步拿到改完的文案做结构化提取第三步只读前两步的产物生成摘要。每一步的职责清晰模型自然不容易串台。2.2 提示链比单次大提示词更稳的三个底层原因第一上下文变短了。每一步的Prompt里只保留与当前任务相关的信息注意力不会被无关内容分散。比如第二步提取卖点时只需要前一步的“正文”字段不需要原始需求和背景说明书。第二中间产物可以被单独验证。以前一个超长Prompt跑完如果结果错了你得从头排查是哪里理解偏了。拆成链之后第五步错了可以直接回放第五步输入输出都看得见定位问题的时间大幅缩短。这对工程化迭代太重要了。第三链中每一环可以单独调模型、调温度、调参数。我常常在前几步用速度快的小模型做信息抽取只在最后生成建议这种需要创造力的环节用更强的模型。这种“混搭”在单个大Prompt里是做不到的。2.3 一张表看清提示链和单次大提示词的差异对比维度提示链模式单次大提示词上下文负载每一步只加载局部信息负载轻全部信息塞进一次上下文负载重出错定位按环节回放即可定位快只能整体重跑排查靠猜步骤可复用性单个环节可以被其他链路复用整个Prompt高度耦合难复用中间检查点每步都可以插入校验或人工确认必须等全部生成结束才能检查成本控制可以把简单步骤交给小模型通常只能用同一个模型延迟表现多一次调用就有多一次网络耗时单次请求延迟低提示链不是没有代价它把一次大请求拆成了多次小请求网络延迟变高整体Token消耗也可能增加。但换来的稳定性和可维护性在多数业务场景里远比那点延迟更有价值。2.4 提示链和“无限套娃”的分界线输出契约写提示链最常见的误区是把它做成套娃每个环节都让模型输出一大段自由文本然后把整段文本原封不动丢给下一环。这样做表面上也是“链”但信息越来越臃肿模型在下一环又要重新理解一遍上百句话注意力负担根本没有降低稳定性自然也没有提升。真正的提示链每一环都必须定义清晰的输出契约字段名、格式、取值集合、必填项。下游只读取契约里约定的字段不会吃进来一堆无关表达。我把这套要求叫“窄进窄出”输入只保留必要信息输出只产出规定结构。没有契约的链是在传递噪音而不是在传递信息。3. 完整实操手写一条用户反馈分类与质检的提示链3.1 场景与目标把散乱用户反馈变成可用情报我先定义一下模拟项目X的背景。某个内容团队每天会从问卷、站内留言、客服聊天三条渠道收到大量用户反馈文本很口语化夹杂emoji、错别字和长短句。团队想知道三件事用户到底在抱怨什么问题、情绪有多强烈、这件事值不值得赶紧处理。最朴素的实现是把每条反馈直接丢给模型问“这是什么问题着急吗”结果噪声很大。于是我把任务拆成五步做成一条提示链。五步分别是输入标准化、主题归纳、情感与优先级识别、行动建议生成、最终格式校验。拆完之后我明显感觉每一步的压力都小了第一步只做清洗第二步只看标准文本做分类第三步接收分类结果做判断第四步负责给出行动建议第五步做收口检查。每步一个决策点模型不需要“想太多”。3.2 为什么拆成五步而不是两步或十步我试着解释一下当时的取舍。如果只拆两步也就是“先分类再建议”那么分类这一步要同时判断主题类型还要识别情绪和优先级本质上还是一个复杂任务稳定性的提升有限。如果拆成十步又会把“主题归纳”拆成“是否涉及功能问题”“是否涉及内容体验”等多个并列分类链条变长后级联错误和延迟都会上升性价比不高。五步是比较舒服的分界线前三步都是明确的判断动作第四步是生成动作第五步是校验动作。判断、生成、校验各司其职。判断环节让模型输出结构化字段生成环节允许模型发挥校验环节则用规则加一次轻量LLM调用收尾。每多拆一步都是在用更稳定的规则或模型调用去换掉上一个环节里“模糊的大判断”。3.3 每步提示词与输出结构的设计细节第一步输入标准化。系统提示词大意是你是用户反馈清洗员把输入整理成结构化JSON字段包括source、raw_text、normalized_text。normalized_text需要修正明显错别字、去掉多余emoji但不改变原意。{ source: 工单渠道, raw_text: 每次更新后打开都卡死真的要气疯了, normalized_text: 每次更新后打开应用都卡死用户情绪非常激动。 }第二步主题归纳。这里只接收source和normalized_text输出topic字段取值从“功能稳定性”“内容体验”“账户安全”“付费相关”“其他”中选一个并给出reason。注意提示词里我刻意没有让模型自己发明主题标签选项固定归类结果才可聚合。第三步情感与优先级识别。输入是topic与normalized_text输出两个字段sentiment取negative、neutral或positivepriority取P0、P1或P2。我给了一个极简的判定规则P0表示有资金风险或大批量用户受影响P1表示体验严重受损但范围可控P2为一般性建议并要求模型输出判定依据。第四步行动建议生成。这一步把前三步的结论汇总进去要求输出格式为Markdown段落包含“问题定性”“证据引用”“建议动作”三个部分。这里允许模型自然语言发挥同时我要求它必须引用原始反馈里的具体句子作为证据目的是阻止它凭空发挥。第五步格式校验。用一个轻量模型检查第四步输出是否包含所有必填部分是否引用了真实证据同时在JSON外面包一层校验结果供程序决定是否放行。这一步也会顺带修正Markdown格式问题。3.4 用一段控制代码把五步串起来我习惯用一个非常薄的执行器来串整条链。这里我抽象了一个chat函数实际使用时替换成你们环境里的模型SDK即可。import json import re from llm_client import chat # 换成你使用的模型服务SDK def extract_json(text: str) - dict: 从模型回复中提取JSON对象带一点容错。 match re.search(r\{.*\}, text, re.S) if not match: raise ValueError(no json found) return json.loads(match.group(0)) def run_feedback_chain(raw_text: str, source: str) - dict: # 第1步输入标准化 sys1 你是用户反馈清洗员。把输入整理为JSON字段为source、raw_text、normalized_text。 out1 extract_json(chat(sys1, fsource{source}\nraw_text{raw_text}, temperature0)) # 第2步主题归纳 sys2 你是反馈分类专家。只输出JSONtopic与reason。topic必选其一功能稳定性/内容体验/账户安全/付费相关/其他。 out2 extract_json(chat(sys2, fnormalized_text{out1[normalized_text]}, temperature0)) # 第3步情感与优先级 sys3 你是优先级评估员。只输出JSONsentiment与priority。priority规则P0为资金风险或大范围影响P1为严重体验受损且范围可控P2为一般建议。 out3 extract_json(chat(sys3, ftopic{out2[topic]}\ntext{out1[normalized_text]}, temperature0)) # 第4步行动建议 sys4 你是运营策略助手。输出Markdown包含问题定性、证据引用、建议动作三部分。证据必须引用原始反馈原文。 out4 chat(sys4, ftopic{out2[topic]}\nsentiment{out3[sentiment]}\npriority{out3[priority]}\nnormalized_text{out1[normalized_text]}, temperature0.4) # 第5步格式校验 sys5 你是质量检查员。检查内容是否包含问题定性、证据引用、建议动作。只输出JSONpassed与fixes。 out5 extract_json(chat(sys5, out4, temperature0)) return { step1: out1, step2: out2, step3: out3, step4: out4, step5: out5, }这段代码并不复杂核心思想是每一步的输入都严格限定在上一步产出的必要字段而不是把所有历史结果一股脑传给下一环。step1产出的normalized_text只给第二步到第四步用原始噪音文本不进入后续上下文。这样即使原始反馈写得乱七八糟模型每一步看到的文本都相对干净。3.5 在链上留一个“人审”接口链式执行全程自动化有一个问题中间环节的判断错误会被下游放大。尤其P0优先级这类高成本判断模型错了代价很高。我的处理是在第三步和第四步之间插入一个人工确认点程序把topic、sentiment、priority渲染成一张核对卡片运营人员扫一眼确认无误才放行到建议生成。并不是所有环节都需要人参与。对批量大、时效性强的反馈我默认只对P0和P1做人工复核P2直接走全自动。这个“分级审核”的思路很管用既保住了高风险任务的准确率又没有把所有任务都拖进人工泥潭。4. 提示链设计时三个绕不过去的决策点4.1 拆链粒度拆到“一个动作”还是“一个判断”拆链没有标准答案但有一条经验很明确如果一个环节里同时包含多个不同的认知动作那它就还不够简单。比如“判断反馈是否属于付费问题并给出处理建议”这里既有分类判断又有策略生成最好拆开。反过来说如果只是把文本转成另一种格式那没必要多拆一次省一次网络调用更划算。我自己的经验是一个提示链里的LLM调用数量尽量不要超过七个。超过这个数整条链的级联错误率会明显上升排查难度也变大。如果任务确实很复杂宁可中间让一个人工步骤或一个前序规则模板切一刀也不要用超级长链硬扛。4.2 信息传递的最小化原则与关键约束重申提示链每一步的输入都要“最小化”只有当前环节真正需要的字段才传过去。看起来像是多写了几行代码但实际效果很好模型不会被无关字段带偏。关键约束还要在链上下文中不断重申。拿我的例子来说第四步生成建议时我会再次强调“证据必须引用原始反馈原文”尽管第二步已经做过主题判断。因为模型并不知道你的最终产物要求每进一次新上下文它都需要重新知道边界。如果链中间丢了一个关键限定条件下游就会开始胡说。信息传递问题比Prompt本身写得好不好更容易成为隐患调试时要优先检查这一步。4.3 失败重试与降级把异常也设计进链路模型输出不可能永远符合预期哪怕给了JSON Schema它偶尔也会在JSON里夹带解释文字。所以每一环后面都应该有解析与校验逻辑而不只是在代码里做一次json.loads就完事。我常用的方案是温度降到0或接近0给一个符合输出结构的few-shot示例解析失败时重组一次Prompt让模型“只输出JSON”重试最多三次。三次仍然失败就不该继续走下去了。这时候最稳妥的降级方式是把当前反馈标记为“待人工”连同已知的结构化字段一起推给运营处理。在业务上一次被标记为待人工的损耗远小于一版严重误判的P0建议带来的风险。5. 不必死磕提示链执行流的其他模式与选型参考5.1 路由模式先分诊再进不同的链提示链解决的是“一条产线”的问题但现实业务往往需要“多条产线”。这时候可以在链前面加一个路由环节先用规则或一次轻量LLM调用判断这条输入适合走哪条链。比如用户反馈里退费申请、内容投诉、技术故障这三类问题需要的后续处理链完全不同硬塞进一条链只会互相拖累。路由本身也可以看作一个非常短的链它的输出不是最终答案而是“目标链标识符”。我通常让路由输出一个固定枚举值程序根据枚举值分发到不同执行流。这个模式在多业务入口的系统里几乎是刚需。5.2 扇出与汇总让多个视角并行干活有些任务不适合串行链比如要给一段文案打多个维度的分主题质量、风险程度、吸引程度互不相同。把多个维度塞进一个Prompt里让模型“一次性打分”分数之间容易互相污染。更稳的做法是扇出把同一份输入复制给多个评价节点并行执行每个节点只负责一个维度最后用一个汇总节点把结果合并成报告。扇出模式下各评价节点是并行的延迟比串行链低不少代价是上下文总Token消耗会变多。它适合“多个独立评价”场景不适合“后一步依赖前一步产出”的强序列任务。5.3 循环与反思从“一条道走到黑”变成“往返打磨”提示链是开环的一次跑完就结束。但在写文案、写代码、做复杂规划时第一版结果通常不够好。这时候可以引入循环与反思模式先让模型产出一版结果再让一个“评审角色”对它挑毛病把问题列表给原始生成器让它重新修改。这个循环可以跑固定的次数也可以跑到质检通过为止。对比提示链循环的核心是“反馈回路”。有些任务可以先跑一条粗链最后加一轮自我反思效果往往比盲目拉长链路更好。但这个模式成本最高评判节点每循环一次都是完整调用要设置好最大轮数防止模型陷入无限自嗨。5.4 模式选型速查表任务特征推荐模式典型场景注意点步骤依赖强、产物明确提示链数据清洗、分类质检、报告生成控制链长每步加契约输入类型差异大路由多渠道客服工单、通用入口路由枚举要稳定多维度独立评估扇出与汇总内容合规检查、文案多维评分注意总Token成本需要不断打磨生成结果循环与反思长文案写作、方案设计必须设最大轮数步骤需要人确认链分级审核高风险财务审批、医学建议人工节点要尽量少选型不用教条。我见过很多实际链路是混搭的先路由分流再进提示链加工最后补一轮反思作为质量闸门。核心判断标准只有一个每一步是不是足够窄、足够清晰。6. 链式执行的真实深坑与一套可复用的调试链路6.1 上游JSON一漂移后面的环节全部遭殃我最开始跑五步链时翻车最频繁的地方是第一步。模型偶尔会在JSON前面加一句“好的我来清洗这段文本”然后我的解析器就炸了。虽然重试机制能兜底但每重试一次整条链的延迟就多一次调用。后来我用三层防线把这个坑填平第一系统提示词里明确规定“不要输出任何解释性文字只输出JSON对象”第二给两条few-shot示例让模型照葫芦画瓢第三解析器做宽松匹配实在取不到就触发重试。温度务必调到0对结构化输出任务来说模型的一点“个性”全都是副作用。6.2 信息在链路里一层层衰减最终答非所问链式结构有一个隐蔽问题每一步都在对信息做有损压缩。最开始那句话里有“用户3天前已经申请过一次退款但被拒绝”经过标准化、主题归纳之后这个关键背景可能在新生成的reason里彻底消失第四步生成建议时只能基于残缺信息给出错误方案。我的解决办法是“关键证据只读伴随”原始反馈原文作为一个独立字段跟着整条链一直走每一步都可以引用它但每一步都无权改写它。分类结论只负责提供观点原始证据负责提供事实。这样即使某个中间判断偏了一点最终建议还能回到原文里对齐大大减少了答非所问的概率。6.3 给链路装观测仪表trace、token、输入摘要缺一不可拆成链之后会有一个新的烦恼以前是一次调用日志里随便看一眼就完事现在是五六个调用串在一起出问题了根本不知道是第几个环节坏掉。我强烈建议从第一天就给执行链加观测字段每一步都记录trace_id、环节名、输入摘要、输出摘要、耗时、Token数。这个习惯帮我在线上问题排查时省下大量时间。单步回放也是调试利器把某一条线上出问题的trace_id拿出来把对应环节的输入原样复制到调试环境里重跑看看是输入已经脏了还是模型这次抽风了。这一步能立刻区分“上游污染”和“单点质量”两类问题。6.4 成本和延迟的体感账五步一次任务要花多少五步链跑一次每步平均消耗1000到2000 Token一次完整任务下来就是5000到10000 Token比单次大Prompt明显更多。延迟也会叠加每一步都是一次完整网络请求。所以在生产环境里我会做三件事控制成本能用规则或正则处理的简单清洗绝不调用模型对固定分类任务用更小的模型只有生成建议步骤才用大模型结果级缓存遇到完全相同的反馈文本直接返回历史结果。这里也解释了一个反直觉的现象很多人以为拆链只会增加成本但实际生产中单次大Prompt因为效果不稳往往要反复重跑好几遍才能得到可用结果累计成本反而更高。链的“确定性”本身就是一种节约。最后分享一点个人体会。我每次搭执行流习惯先在聊天框里把“人工流程”完整走一遍把每一步的判断动作和产物记下来再决定哪里值得变成链的一环。提示链模式教给我的不是“多调几次模型就更厉害”而是让模型的每次调用都只干它最擅长的那一件小事并且给这件事套一个清晰可校验的边界。后面如果继续做多智能体协作、工具调用编排这套“先拆流程再谈智能”的思路依然会贯穿始终。