写这篇东西，是因为我见过太多朋友拿到大模型 API 后，第一反应就是“流式输出接一下，prompt 堆一堆，完事”，结果做着做着就发现：需求一变，代码全得重写；逻辑一复杂，自己都绕不清；换个人维护，更是地狱难度。其实真不是你的代码能力不行，而是缺了“工作流”这层抽象。今天我不整那些虚的，直接从一个真实可跑的案例出发，把 LLM 工作流从头到尾拆给你看。这篇东西适合谁？刚接触大模型开发、被各种复杂 Agent 概念劝退的入门者，以及写了不少 demo 但始终觉得“差点意思”的准中级开发者。我会尽量说人话，把那些文档里不写的坑也一并填上。
1. 内容整体设计与思路拆解
1.1 为什么你的第一版 LLM 代码总是“僵的”
我先说个常见场景。假设你要做一个“客服工单分类+自动回复”的功能，第一反应是不是直接调接口，让模型返回一段话？真的这么干，第二天你就会收到三类反馈：回得不准、回得太泛、格式乱来。问题不在模型，在于你只做了“调用”，没有做“编排”。
工作流的核心思路，是把“和模型对话”这一个动作，拆成若干个职责单一、边界清晰的节点。比如输入清洗、意图识别、信息抽取、候选生成、规则校验、结果格式化。每个节点干一件事，节点之间有明确的输入输出契约。这样做的直接好处是：任何一个节点都能单独替换、单独测试、单独回退。
我见过一个最典型的反面案例，某开发者把五六个逻辑步骤全塞进一个超大 prompt 里，要求模型“先判断、再提取、再生成、顺便校对”。结果 prompt 超过两千字，模型漏步骤，他还怪模型不够聪明。这事儿搁在工作流里就是个笑话——你明明可以用三个节点、两次调用，把任务拆得清清楚楚，为什么非要让模型一口气“猜”完全程？
1.2 心智模型：把工作流当“加工流水线”
用一个月饼厂来做类比你就懂了。LLM 是那个“最厉害的和面师傅”，但你不能让和面师傅同时负责称糖、调馅、压模、包装。工作流就是这条流水线：传送带（状态管理）、工位（节点）、质检员（规则/校验）、返工通道（分支处理）。每个工位只处理一种形态的半成品，完成后传给下一个工位。
这个心智模型特别重要。因为一旦你脑子里有了“流水线”的概念，你设计系统的方式就彻底变了。你会开始关心：
- 每个节点拿到的输入是什么结构？
- 这个节点的产物，下一个节点能不能直接吃？
- 如果某个节点出错了，应该重试还是跳过，还是直接走降级路径？
这些思考，直接决定了你的应用是“能跑的 demo”还是“能上线的系统”。工作流不是框架强加给你的概念，本质上是你为了控制复杂度、降低维护成本，自然长出来的结构。
1.3 三个主流实现方式，怎么选
说到落地，我得把当前常见的三种方式摊开来讲清楚，你按需求选，没有绝对的好坏。
第一种是最土的：用 Python/Node 代码硬写状态机。定义几个函数，每个函数代表一个节点，函数之间手动传参。优点是完全可控、透明、没啥学习成本；缺点是一旦节点多了、分支复杂了，光传参就能传到你怀疑人生，而且没有可视化界面，别人接手全靠读代码硬啃。
第二种是用现成的编排框架。这类框架把节点、连线、状态管理都替你封装好，有的自带可视化画布、日志面板、人工审核接口。优点是开发效率高、上下手快、调试方便，适合从 demo 往工程化过渡。缺点是抽象层厚了，出了问题要往下钻框架源码，排查成本略高。
第三种是声明式配置。你用一个 JSON 或 YAML 文件定义跑出整个流程，运行器照着配置执行。这种的好处是“流程即配置”，改流程不改代码，尤其适合业务上需要频繁调整路径的场景。坏处是太动态的东西不好调试，出错时候你要脑补整个执行轨迹。
我个人给新手的建议是：先用代码硬写一版简单的，把流程跑通；然后迁到框架上，用它的可视化界面观察每一轮的输入输出；项目稳定后，再考虑要不要把公共流程抽象成声明式配置。这三级跳，每一级都有明确的收益，不会白用功。
2. 核心组件解析与实操要点
2.1 节点分割：到底该“一刀切”切在哪
这是新手最容易懵的地方。我给你的判断标准很简单：问自己一句话——“如果我把这段逻辑拿掉，换成写死的规则，主流程还能走通吗？”如果能，它就该被拆成一个独立节点；如果你发现拿掉之后整个流程就散了，那说明它和前后逻辑耦合太深，暂时不要强拆。
举个例子。在客服工单流程里，“判断工单是否来自 VIP 用户”完全可以先用一条规则（比如用户ID前缀）来做。这不丢人，反而很聪明。因为你用规则替代掉一次模型调用，不仅省了延迟和钱，还提高了确定性。只有规则覆盖不了的模糊场景，才值得让模型上。这个“规则优先、模型兜底”的思路，是工作流设计中性价比最高的一条准则。
还有一点容易被忽略：节点的粒度也要考虑“测试的方便程度”。理想情况下，每个节点的输入输出都是 json 这种结构化数据，你可以在调试器里直接喂一份历史样本，看这个节点单独跑对不对。一个节点如果输入依赖太多“上下文环境变量”，它基本就没法独立测了。
2.2 提示词模板：工作流里真正的“胶水层”
很多人以为提示词就是跟模型说说话。在单次对话里，这样想问题不大；但在工作流里，提示词是负责“装配上下文”的。模板必须做到：输入是结构化字段，输出也严格限定结构。
我常用的提示词结构是四段式：
第一段定义“角色边界”，但不是那种“你是顶级文案大师”的废话设定，而是明确它能用的信息和不能用的信息。
第二段放“当前请求的核心任务”，一句话，带明确动词：抽取、分类、改写、总结、判断。
第三段给“输入数据”，用 placeholders 占位，手写示例把格式立住。
第四段锁死“输出格式”，输出 JSON 的话，直接给 schema，甚至给一段符合 schema 的示例。这一步比什么都管用。
这里有个实操细节：输出格式的效验，千万别指望模型 100% 守规矩。哪怕你例子里写得像法律条文，它偶尔还是会跑偏。所以节点内部一定要加一层“宽松解析”：先尝试json.loads，失败就截取第一个{到最后一个}再试，再失败就标记为“解析失败”并让模型重来一次。这套兜底逻辑，能帮你省下大量手工修正的凌晨三点。
2.3 状态管理：数据在节点之间怎么安全流动
工作流执行起来，本质上是一份数据在节点之间流动。这个“数据”怎么装、怎么传，新手经常设计得一片混乱。最常见的问题就是所有节点共享一个大包里，每个节点各取所需，最后没人说得清这个字段到底是哪个节点改的。
我的建议是：按“阶段”逐步收束数据。什么意思？比如流程的前半段是做信息抽取的，那前半段所有节点只允许产生extracted_result这个字段下的子字段；到了生成回复的阶段，新节点只能读取extracted_result和原始请求体，生成的结果统一写到reply字段。
给数据划分“所有权”，谁写谁读有规矩，整个链路才可追溯。排查问题时候你才能快速定位：坏数据到底是在抽取段产生的，还是回复段产生的。这一点在工作流的工程化阶段至关重要，前期多花一分钟设计字段归属，后期能省你几小时的对日志时间。
2.4 工具调用：模型不能算的，交给工具做
我必须专门说一下工具调用这块，因为这是小白最容易别扭的地方。某些模型被调用时，本身可以输出“调用外部工具”的结构化指令，比如查询天气、查数据库、执行代码。很多人第一次接这个，会把所有期望都压在模型身上：既让它决定“要不要调工具”，又让它生成参数，还让它解读工具返回的结果。
以我实际体验，正确姿势是“把工具调用也节点化”。拆成三步：先有一个“意图判断”节点决定是否进入工具路径；再有一个“参数提取”节点从用户输入中整理出工具入参；工具执行完（这一步是传统代码干的，别碰模型）；最后把工具结果丢回给“结果解析”节点，让它把结构化输出翻译成人类语言。
这种拆分的目的，是把不确定因素隔离。模型的唯一不确定点收敛在“意图判断”和“参数提取”这两个小节点上，其余环节全是确定性的代码。你排查问题就从容了，哪个节点抽风一目了然，再也不用对着一个大模型调用黑盒干瞪眼，反复跑同一段 prompt 找问题。
3. 实操记录：从零搭一个“客服工单处理”工作流
3.1 项目背景与流程建模
为了让你看得更有体感，我不讲空泛概念了，直接带你过一遍我用工作流思路搭建的模拟项目 X：一个“客服工单分诊 + 回复建议生成”的系统原型。业务需求很简单：用户提交一条文字工单，系统自动对其分类、提取关键实体（商品名称、问题类型、订单号等）、判断用户情绪，最后生成一段可供人工审核的回复建议。
根据这个需求，我先把整个流程画成六个节点：
- 输入清洗
- 工单分类
- 实体抽取
- 情绪分析
- 回复建议生成
- 规则校验与格式化
这里第 2、3、4 三个节点其实可以并行，前提是它们共享同一个输入。为什么我没把它们合并成一个“大模型一次干完”？因为这三个任务输出结构完全不同，分类要的是「枚举值」，实体抽取要的是「嵌套字典」，情绪分析要的是「打分+关键词」。合并会让单个输出的 schema 变得臃肿，而且一旦某个任务的效果不好，你要重新写整段 prompt，影响面太大，拆分的好处是每个节点可以独立调优。
3.2 节点实现的关键代码（Python 示意）
先说输入清洗节点，这里没模型什么事，按规则来，干脆可靠。用户原始文本往往带大量无意义字符：表情、乱码、超长空格、邮箱电话等隐私信息。我们得把它清掉，只保留有效文本内容：
def clean_input(raw_text: str) -> dict: text = re.sub(r"\s+", " ", raw_text.strip()) text = re.sub(r"http\S+|www\.\S+", "[链接]", text) # 脱敏 URL text = re.sub(r"\b\d{11}\b", "[电话]", text) # 简单脱敏 return {"clean_text": text, "original_length": len(raw_text), "clean_length": len(text)}注意我串联了返回的字段，保留了原始长度信息。这个东西看似多余，实际上特别有用——后面排查工单时，如果发现清洗环节把有效信息误删了，你可以通过original_length和clean_length的对比判断清洗是否异常。这类“过程痕迹”字段在工作流里多留几个，debug 的时候会特别感谢当时的自己。
然后是工单分类节点，这一步就该模型上了。我用的 prom审 prompt 风格是“枚举值输出 + 置信度附带”。分类结果如果不是固定的枚举值，后续规则校验根本没法做。请让模型输出 JSON，并且一定要在 prompt 里给它一个具体的输出示例，哪怕只有一个，也比只给 schema 强得多：
CLASSIFY_PROMPT = """ 你是一个工单分类器，只做分类，不做别的。 从以下枚举值中选择最合适的一个：{categories} 用户工单：{clean_text} 请输出 JSON 格式：{"label": "枚举值", "confidence": 0.0-1.0} 参考示例：{"label": "售后", "confidence": 0.97} 只输出 JSON，不要输出解释。 """跑这个节点时候，我要提醒一个坑：一旦输出不是纯 JSON，不要急着改 prompt，心态放稳。先在节点外层加兜底解析，用我 2.2 节说过的“宽松解析法”。如果十次里有两次需要兜底，说明 prompt 的示例不够有代表性，再去打磨示例。如果一次都没有，又可能说明模型输出太收敛，你反而要测测它遇到边界输入的表现，防止过拟合到示例上。
情绪分析节点是三分法或五分法，不要做太细，我实测下来三分法（正向/中性/负向）在小样本上更稳。太细的颗粒度会造成边缘样本的随机抖动，你今天上线五档，明天就会因为“轻微负向”和“中度负向”的边界开始失眠。分数要的是相对值，不是绝对值，只要它能稳定区分情绪倾向的范围就够了。
实体抽取节点是输出格式最复杂的一个。我指名要一个嵌套 JSON，比如：
{ "entities": { "product": ["保温杯", "同款杯盖"], "order_id": ["20241012xxxx"], "issue_type": ["漏发", "破损"] } }如果模型没有按结构返回，你也不要太失望，这个情况其实正常。嵌套结构确实超出不少模型的稳定输出边界。我的对策是退一步，要求“平铺输出”，每个实体单独一行，格式是“类型\t值”，然后再用一个普通解析函数，把平铺结果转换成嵌套 JSON。这一步本质上是“把复杂度从模型侧转移到代码侧”，可靠性反而高了一半。你可以留心一下，工作流里很多输出格式问题，靠模型能力硬扛是下策，靠结构设计化解才是上策。
3.3 分支逻辑与人工审核闸门
前面几个节点的结果齐了，下一步就进入回复生成。但在生成之前，工作流里习惯性地设置一个“分诊闸门”：如果用户情绪是负向、且工单属于投诉类型，这个工单就会被强制拉高优先级，转入“人工优先处理”队列，而不是走自动生成回复的常规路径。
这个闸门正是工作流有意思的地方：它不是把模型当万能钥匙，而是知道自己哪一步该自动化、哪一步该“停下来喊人”。很多应用就是因为不敢“停下来”，硬要用模型自动处理一切，结果在低质量输出上收不住，用户口碑一夜崩塌。自动化和人工介入的边界，恰恰是你系统可靠性真正的护城河。
回复生成节点，我会给它传入三类信息：工单分类结果、抽取出的关键实体、情绪分析结果。同时，把人工审核者的角色写进 prompt。我做了个很蠢但很有用的改进：将回复历史中的好评案例直接放进去做 few-shot。不用多，三四条就够了，但模型输出风格的稳定性会有一个肉眼可见的提升。包括措辞的亲和度、落款的方式、不愿承诺的语气（话不说满），这些风格性特征吸收得奇快。
最后是规则校验节点，纯代码，但意义重大。这个节点负责检查回复里有没有敏感词（比如“绝对没问题”“保证管用”这种过度承诺）、有没有超过最大字数，以及必需元素（如身份说明、后续行动指引）是否齐备。校验不通过就直接打回重写或者转人工。这一步看着朴素，却是很多“半吊子” demo 从来没做过的，也是决定产品是否正经的分水岭。
3.4 参数选择的逻辑：温度、长度、模型
说到大模型调参，我的建议永远是围绕“这个节点的任务确定性有多高”来做决定。分类节点的温度我就设 0 或者接近 0，让输出尽可能确定；生成回复的温度我会设在 0.5 左右，保留一点语义多样性，但不会高到放飞自我。
具体到 max_tokens，只设一个“足够用的上限”。如果你的分类逻辑只需要输出一行 JSON，那设 500 都很宽裕，没必要给模型默认 4096，一旦模型放飞会白白产生大量无效输出。长度给得越宽，模型越容易啰嗦、越容易飘，优秀的工程实践是“刚刚够用再留 20% 余量”。
模型选型这件事，模板上我也会分层：简单分类、实体抽取选轻量 7B 甚至更小的模型就够；情绪分析也走轻量；回复生成这个对语义质量和语言组织能力要求最高的节点，单独选能力强的重量模型。这样组合下来，整体 token 成本能降一半以上，响应速度也有明显提升。
4. 常见问题与排查技巧实录
4.1 问题速查表：从现象定位根因
我把实际跑项目时踩过的坑整理成下面这张表，你如果遇到类似问题，可以直接按图索骥。
| 现象 | 常见根因 | 排查思路与解法 |
|---|---|---|
| 某个节点偶尔返回空值 | prompt 没给兜底逻辑，模型输出意外中断 | 检查该节点的输入字段是否为 null，增加“值缺省”处理；确认 max_tokens 是否太紧 |
| 输出 JSON 经常多几个字段 | 提示词里没有强约束“只输出这个结构” | 在 prompt 里加示例和“不得输出解释”约束，解析层做字段白名单过滤 |
| 流程偶发卡死/超时 | 大模型调用没有设置超时重试机制 | 每处调用套retry和timeout，比如三次重试、单次 20 秒上限 |
| 回复质量忽好忽坏 | 温度太高或 few-shot 样本不稳定 | 降温度到 0.5 以下；固化 few-shot 的候选顺序、内容 |
| 同一个输入跑两次结果不同 | 正常现象，模型非确定性 | 若业务要求高一致性，分类节点必须温度设为 0 并固定 seed |
| 流程半天不返回，也没有日志 | 节点太多，链路没有可观测性 | 给每个节点挂日志：入参摘要、出参摘要、耗时、token 用量 |
4.2 两个“玄学”级问题：上下文污染与分支爆炸
一个隐蔽的问题，是节点之间传递数据时造成的“上下文污染”。比如实体抽取节点本来只需要clean_text一个字段，但因为上游把整个原始请求传了下去，结果模型在抽取实体时被无关字段干扰，抽出了不在工单里出现过的“幽灵实体”。解法非常简单：每个节点在调用模型之前，先“精筛字段”，只把当前任务需要的字段拼接进 prompt，其他的坚决不传。这也再次说明工作流里“数据所有权”设计的意义。
另一个问题是“分支爆炸”。当你加了“用户是 VIP 吗”“情绪负向吗”“商品有没有库存”一堆判断之后，工作流会指数级增殖。这种事在集成阶段会大规模爆发，不要硬写 if-else 去压制。我的办法是：把多分支收敛为“策略表”。状态组合作为行，策略作为列，你填表来决定走哪个路径。表驱动的方式，让扩展分支的复杂度从“重写逻辑”降解成“新增一行配置”，非常适合需求隔三差五有微调的业务线。
4.3 排查实操：一次经典的“回复胡说八道”定位过程
给你看一段我真实排过的故障。现象：某天早上收到的工单，自动回复居然把买家称呼成“供应商”，而且还信誓旦旦地说“我们会在一个工作日内完成退款”。这显然是严重 bug。
我第一反应怀疑是回复生成节点的问题，马上打开日志，查看该节点的输入。结果发现，它收到的实体抽取结果里混入了一条"role": "供应商"的实体，来源是上一批工单数据清洗时，文本里本来就包含“供应商说……”的字样。问题出在两方面：实体抽取节点的输入不仅含当前工单内容，还带入了一个摘要字段，里面混了其他工单的数据；另外 prompt 也没有限制“只抽取当前工单中的实体”。
这个排查过程看起来不难，但如果你没有日志、没有节点间字段“所有权”意识，你会在回复生成节点上反复调 prom审、反复测试，消耗大量时间，却始终解决不了问题。我的体会特深：工作流给你的不仅是结构化的开发体验，更是一整套“让问题可定位”的工程能力。
4.4 关于重试与熔断，我补最后一课
节点调用大模型失败，很多时候不是模型垮了，而是网络抖动或限流。所以一个健壮的工作流必须定制重试策略。我的建议很具体：区分“可重试错误”和“不可重试错误”。超时、 429限流、5xx 这类服务端问题，就指数退避重试；如果错误信息直接指出“prompt 格式错误”或“请求参数非法”，那重试一百次也是白搭，直接走告警。
再往上一层则是熔断。如果你的工作流某个节点连续失败超过 5 次，可能不只是链路问题，而可能是上游依赖彻底不可用了。此时就别再傻傻打满重试了，果断走“降级模式”：比如工单直接转人工，而不是继续触发自动回复流程。这一点在实时性要求高的生产环境里，比提高模型精度更紧迫。
5. 进阶方向与维护心得
5.1 从“线性流程”到“有环流程”：迭代自救
前面聊的全部是“线性往下走”的流程，但在实际业务中，你常需要“不行就走回头路”。比如回复建议生成后，规则校验发现措辞不妥，你是直接转向人工，还是让它带上问题描述再重新生成一次？我的做法是允许重写两次，两次都不合格再转人工。
这就在流程里引入了“循环弧线”，框架大多会用“最大迭代次数”来控制死循环风险。那条循环弧线我也会专门打日志：为什么重写、改了什么 prompt 条件、结果是更好了还是更差了。积累几轮后你会发现，很多重写的触发，是因为前序节点提供的上下文不完整。这时候与其补强生成节点，不如回到根因，把前序抽取节点做扎实，这又是一轮良性迭代。
5.2 效果评估：别靠感觉攒 prompt
说到迭代，就必须提评估。我相信从这篇博文你去实践时，最常做的动作就是“改 prompt，跑几个例子，看看像不像”。这个方法初始可行，但是一旦流程复杂起来，你就没法靠肉眼验收了。我建议从第一天起就建一个“评测集”：把历史工单里比较典型的 50 条输入定下来，包含各种边界情况（超短文本、骂人的、中英混杂、带链接的）。
每次改动任何一个节点的 prompt 或流程结构，就把评测集完整过一遍，然后记录：分类准确率、实体抽取的精确率/召回率、情绪判断准确率、回复合规率。这个记录本就是你最宝贵的小型资产。我在这强烈推荐，别看它笨，但比任何“花哨的自动评估框架”都更适合起步阶段。等积累到几百条、上千条，你再去考虑更复杂的评估手段，心里也更有底。
5.3 让业务方看懂：工作流也是沟通工具
还有一个我个人的强烈体会：工作流画在纸上的那张图，虽然不涉及什么高深技术，但它是你和业务方之间最有效的沟通介质。业务方想看“某个环节是怎么处理的”，你指向那个节点，指着那张状态图就能讲清楚；他要改判定标准，就提出改哪个节点哪个字段，整个链路的影响面一眼就能看出来。
这可比你花半小时跟他解释“我们调了一个大模型接口，逻辑都在 prompt 里呃……”省心太多了。尤其当你从一个人开发变成多人协作时，工作流图还会自动变成团队的口径：谁的消息改动会影响后续哪些节点，一目了然。这层价值在起步阶段或许不突出，团队一扩张，你就知道它有多值钱。
6. 新手实践的三点忠告
6.1 从“最小闭环”开始，不要一口吃成胖子
我见过太多人一上来就搭一个豪华版：多智能体、记忆网络、RAG 检索、流式输出、完整前端。一个月过去了，核心的“分类+回复”还没跑利索。请相信，那种“先搭骨架再填血肉”的办法，在工作流开发里是不成立的。一定要先做最小闭环：一条线性流程，三个节点，跑出正确结果，再接复杂组件。
你要是听进去了，就从“输入清洗 + 分类 + 回复生成”这三节点起步，两三天内就跑通。跑通后再加实体抽取、再加情绪分析、再加规则校验。每加一个节点都意味着一次“可验证的增量”，这个过程的节奏感会让你非常踏实，也会让你对每一个组件的理解深得多。
6.2 把“可观测性”刻进基因
我前面反复提到日志，这里还要再加重一点：从第一行代码写起，就要想着“如果这个节点挂了，我怎么一眼看出来”。在实践中，我每个节点都会输出执行摘要：入参的关键字段、出参的关键字段、耗时、token 用量、当前节点名称。这些信息不需要花哨的分析平台，先落到本地日志文件定时刷新即可。
没有可观测性的大模型应用，就像没有仪表盘的飞机——你飞得再稳，也不知道油快没了。很多线上事故之所以排查难，最根本的原因不是模型能力不行，而是你手里根本没有“飞行记录仪”。别等出了问题才补日志，那会儿补什么都晚了。
6.3 尊重“慢即是快”
问一个扎心的问题：如果你用一个简单的正则就能做好的分类任务，你会不会因为“想学大模型技术”而强行让模型上？我见过太多这样的人，那是典型的“手里有锤子，看什么都是钉子”。工作流的存在意义，不是把所有逻辑都塞给模型，而是帮你找到“确定性逻辑”和“模型能力”之间的最佳配比。
该用规则的地方用规则，该用模型的地方用模型，该让人工介入的地方就大胆安排人工审核。这些边界想得越清楚，你的系统就越可靠，维护成本就越低。技术选型的好坏往往不在“用了多牛的模型”，而在“每一步都选对了处理方式”。
我的经验是：工作流的本质是“把大模型从屠龙技变成水电煤”。它的核心不是某一种框架、某一个工具，而是那一套控制复杂度、收敛不确定性、让团队协作顺畅的思维习惯。你不需要一次性掌握所有框架，只需要从一条流水线开始，把一个真实的小项目做扎实。等你做完第一个带工作流的项目再回头看，你就知道原来大模型应用开发，真的可以不那么难。
