四. 自动化工作流

1. 如何拆分工作流

两种情况下，一个任务步骤需要被拆分出来：

1.1 需要单独控制的独立环节

通常有以下几种情况：

• 必须先取得外部事实或其余结果才能决定后续操作
• 必须按固定规则或程序作出
• 需要单独复用、重试或采用不同权限
• 希望对该部分插入检查

例如，自动回复客户咨询时，你希望先人工检查回复，再决定是否发送。可以安排为：

收到咨询 → AI 生成回复草稿 → 人工确认 → 发送。

1.2 希望通过拆分改善表现

拆分时可以参考以下规律：

• 每个步骤必须读的信息放在同一步骤，而不是每个步骤都读取所有信息。 减少无关资料和工具的干扰，避免拆开后反复补充共同背景。
• 能独立完成的工作，适合分别处理。 各部分可以专注自己的问题，也可以并行执行；需要频繁相互修改的工作，更适合放在一起。Anthropic：分工与上下文
• 交接时少转述，准确传递必要信息。 减少改写造成的遗漏和曲解。
• 检查标准明确、反馈能指导修改时，拆出检查步骤更有价值。 检查应指出具体问题，让后续步骤知道改什么。Anthropic：评价与改进

再用同一批任务比较拆分前后的质量、耗时、费用和人工返工量。有改善且代价值得，就保留这种拆分。

例如，LangChain 用同一个模型测试100个零售客服任务，逐步加入其他领域的无关工具和说明，比较三种分工方式：

当无关领域增多时，不拆分的方案表现明显下降；第三种方案的表现略优于第二种，消耗的 token 也更少。团队发现，主管转述容易改变原意，还增加一次生成，因此又给第二种方案加入直接转发回复的能力。

这个例子中，值得保留的拆分让每个 Agent 少接触无关工具和说明，同时减少不必要的转述。但仅加入一个无关领域时，不拆分反而略好：应根据测试结果选择方案，而不是默认拆开就更好。LangChain：不同分工方式的对照测试

2. 为模型、程序和人分配工作

并不是每个环节都适合交给agent处理，恰恰相反，程序比agent更加稳定，更加有保障。只有必须需要agent做的任务才需要安排agent。单agent结构也未必比多agent结构差。

• 规则明确、能稳定自动完成的，交给程序。 例如查询数据、计算金额、检查必填字段、按固定条件选择分支。
• 需要理解含义、处理表达差异或生成内容的，交给模型。 例如识别用户诉求、整理故障描述、撰写回复。Anthropic：工作流与模型决策
• 需要本人选择、批准，或现有规则无法处理的，交给人。 明确哪些情况转人工，让工作流在这些位置暂停，等待决定后再继续。n8n：人工审核

3. 为不同情况设计处理路径

4. 检查和反馈循环

先列出这个环节可能犯什么错，再逐项选择检查方式：

• 能写出明确判断规则的，用程序。 例如检查必填字段、日期是否合法、计算结果是否正确。
• 需要理解含义的，用模型辅助检查。 同时提供任务要求、原始材料和待检查结果，明确判断标准。
• 缺少依据或需要本人决定的，补充信息或交给人。

同一个环节可以组合多种检查。Anthropic：检查方式的选择

4.1 怎样设计检查节点

例如，要检查“从邮件中提取活动信息”这个环节。原邮件是：

培训于2026年7月12日14:00—16:00举行，地点为A楼301。报名截止时间为7月10日。

模型却把活动日期提取成了7月10日。可以设计以下检查：

程序检查可以交给开发 Agent 实现，要求写具体：

接收提取结果，检查 title、start、end、location 四个字段是否齐全且非空；start 和 end 必须包含日期和时间，能够解析，且 start 早于 end。输出是否通过，以及每个问题对应的字段和原因。

语义检查可以增加一个 LLM 节点，使用以下提示词：

原邮件：{{原邮件}}
提取结果：{{提取结果}}

逐项核对活动名称、开始时间、结束时间和地点。
区分活动时间、报名截止时间及其他日期。
每个判断都要引用原邮件中的对应文字。
原文未提供或存在歧义的信息，标记为“信息不足”，不要猜测。

输出：
status：通过 / 不通过 / 信息不足
issues：问题字段、当前值、原文依据、应如何修改

在 Dify 等可视化平台中，用代码节点执行程序检查，用 LLM 节点执行语义检查；将检查结果设为结构化输出，供后面的条件分支读取。Dify：LLM 节点与结构化输出

4.2 怎样把反馈接回流程

提取信息 → 程序检查 → 语义检查 → 通过后创建日程。

这个例子中的提取步骤只需调用模型，并配置三个输入：原邮件、上一次结果、检查反馈。第一次运行时，后两项为空；检查不通过时，工作流把上次结果和具体问题填入对应变量，再次调用这个模型步骤。提取提示词可以写成：

请从原邮件中提取活动名称、开始时间、结束时间和地点。

原邮件：{{原邮件}}
上一次结果：{{上一次结果}}
检查反馈：{{检查反馈}}

如果有检查反馈，请依据原邮件修正上一次结果。
输出完整的提取结果。

例如，检查反馈是：“start 日期为7月10日，但原文‘培训于2026年7月12日14:00—16:00举行’说明活动日期为7月12日，请修正。”模型收到这些输入后重新提取，结果再进入检查节点。循环由工作流控制，无须把提取步骤做成能自主行动的 Agent，也不需要单独开发“自我改进”功能。

原文信息不足，就询问用户。设置修改次数上限，例如最多修改2次，仍未通过则转人工。

如果被检查的步骤本身是固定程序，则按错误原因处理：

• 输入缺失或错误： 返回产生输入的步骤修正，或请用户补充，再执行程序。
• 程序逻辑或配置错误： 停止这条路径，交给人或开发 Agent 修复后再运行。原样重跑通常无法解决。
• 网络或服务暂时故障： 可以有限重试，仍失败则通知处理。

最后，用正确结果、缺失字段、非法日期、混淆截止日期和原文缺少信息的样例，检查这些路径是否走对。模型检查也可能漏错，尤其要测试“格式合法，但内容选错”的情况。

5. 工作流案例

以下案例根据官方教程改编，展示完整处理路径和关键设计选择。

5.1 根据公司资料撰写入职指南

任务：根据现有资料编写指南，先确认内容范围，再展开正文。

flowchart TD
    A[输入公司资料、读者和必需内容] --> B[模型生成大纲]
    B --> C{人工检查大纲}
    C -->|需要修改| D[指出缺漏或不需要的内容]
    D --> B
    C -->|确认| E[根据资料和确认后的大纲撰写正文]
    C -->|取消| F[结束]
    E --> G[核对事实、章节覆盖和资料缺口]
    G --> H[交付指南及待补充事项]

这里拆分大纲，是因为用户希望先控制内容范围。确认后的大纲成为后续写作依据，可以减少全文写完后再调整结构的返工。

如果用户没有中间确认的需要，就应与一次生成全文比较，检查拆分是否实际改善结果。

来源：Anthropic：链式工作流与中间检查。

5.2 从活动邮件创建日程

任务：读取活动邮件，提取名称、时间、地点，检查后创建日程。

flowchart TD
    A[输入原邮件] --> B[模型提取结构化信息]
    B --> C[程序检查字段结构和日期格式]
    C -->|通过| D[模型对照原邮件核对含义]
    C -->|不通过| E[整理具体错误]
    D -->|有误| E
    D -->|原文信息不足| F[询问用户，补充后重新处理]
    D -->|通过| G[创建日程并核对返回结果]
    E --> H{是否还有修改次数}
    H -->|有| I[将原邮件、上次结果、反馈传回模型]
    I --> B
    H -->|没有| J[转人工处理]
    G --> K[报告创建结果]

程序负责判断“字段能否被后续步骤使用”；模型辅助判断“提取的含义是否正确”。例如，7月10日是合法日期，但它可能只是报名截止日期。

提取结果应固定字段和格式。原文没有的信息允许标记为空，再进入补问路径，避免要求模型为了通过检查而猜测。

来源：Dify：结构化输出、LangChain：携带错误反馈重新生成。

5.3 把客户咨询分到不同处理流程

任务：通过统一入口接收咨询，分别处理产品使用、订单查询和故障申报。

flowchart TD
    A[收到咨询] --> B[识别诉求类型和必要信息]
    B --> C{属于哪一类}
    C -->|产品使用| D[检索产品说明并回答]
    C -->|订单查询| E[取得订单标识并查询订单]
    C -->|故障申报| F[收集故障信息并创建工单]
    C -->|信息不足| G[返回需要补充的问题]
    C -->|不支持| H[说明处理范围或转人工]
    D --> I[核对依据与处理结果]
    E --> I
    F --> I
    I --> J[向客户回复]

分类之后，各条路径使用自己的资料、工具和规则。订单查询步骤无需读取整套故障排查说明，故障申报也不应只套用普通问答提示词。

分类标准还应规定如何处理多个诉求：可以拆成几项分别办理，无法确定时先询问。

来源：LangGraph：Routing。

5.4 自动受理活动报名

任务：读取报名信息，核对明确的报名条件，符合条件后登记。

flowchart TD
    A[收到报名材料] --> B[模型提取报名字段]
    B --> C{必要信息是否齐全}
    C -->|否| D[通过表单补充缺失信息]
    D --> C
    C -->|是| E[程序检查截止时间和报名资格]
    E -->|不符合| F[说明未满足的条件并结束]
    E -->|符合| G[写入报名记录]
    G --> H[核对登记结果]
    H --> I[返回成功结果或失败原因]

模型负责读懂材料，程序负责执行已经确定的条件。姓名、联系方式缺失时先补充，资格不符合时则说明原因，两种情况进入不同路径。

这个结构适合条件明确的申请受理。需要负责人破例决定的情况，可以另设人工分支。

来源：改编自 IBM：资料提取、确定规则和表单补充。

5.5 根据课程资料回答问题

任务：从指定课程资料中寻找依据，回答问题并附来源。

flowchart TD
    A[收到问题] --> B[检索课程资料]
    B --> C{资料能否支持回答}
    C -->|能| D[根据资料生成回答并附来源]
    D --> E[交付回答]
    C -->|不能| F{是否还有查询次数}
    F -->|有| G[分析缺口并调整检索词]
    G --> B
    F -->|没有| H[说明已找到的内容和未解决的问题]

检索后需要判断资料是否真正支持回答。例如，找到了“报名流程”的章节，不代表找到了“是否允许延期报名”的规定。

补查应针对缺口调整查询。反复使用相同关键词，通常无法解决第一次检索遗漏的问题。

来源：LangGraph：检索、相关性检查与重新检索。

5.6 一份材料生成多个平台的文案

任务：根据文字、图片和文档，为多个平台生成不同版本的文案。

flowchart TD
    A[输入材料、目标平台、语言和风格] --> B[提取并检查目标平台列表]
    B -->|输入无效| C[提示修正并结束]
    B -->|有效| D[文档转为文字，图片单独读取]
    D --> E[整理共同事实和必要背景]
    E --> F[按平台分别执行，可并行]
    F --> G[读取该平台的内容规范]
    G --> H[结合共同事实生成文案]
    H --> I[收集各平台的结构化结果]
    I --> J[程序统一排版并交付]

共同事实统一准备，平台差异分别处理。例如，同一个活动的日期应保持一致，但篇幅、语气和组织方式可以不同。

最后的排版有固定规则，交给模板或程序完成即可。各平台结果保留平台名称，便于对应和检查。

来源：Dify：多平台内容生成器完整教程。

5.7 从一批用户反馈生成问题统计

任务：整理多条反馈，统计各类问题数量，并生成总结。

flowchart TD
    A[输入反馈列表和固定分类标准] --> B[为每条反馈保留编号]
    B --> C[逐条提取问题并分类]
    C --> D{分类结果格式是否合法}
    D -->|否| E[有限修正，仍失败则记录待处理]
    D -->|是| F[保存编号、类别和原文依据]
    E --> G[收集全部处理状态]
    F --> G
    G --> H[程序统计有效记录和各类数量]
    H --> I[模型依据统计结果撰写总结]
    I --> J[交付统计、总结和待处理清单]

这里把理解、计算和表达分开：模型判断反馈内容，程序计算数量，模型依据确定的统计结果写总结。

每条反馈保留编号，才能追查分类是否正确。失败记录单独列出，报告中明确实际统计了多少条，避免将部分结果当作完整统计。

来源：改编自 Dify：逐项处理、结果收集与失败处理。

5.8 翻译后检查，再根据问题修改

任务：按照术语表翻译短文，检查后修正漏译、误译和术语错误。

flowchart TD
    A[输入原文、术语表和翻译要求] --> B[模型生成译文]
    B --> C[程序核对规定术语、数字等明确要求]
    C --> D[模型对照原文检查含义与遗漏]
    D --> E{是否存在必须修正的问题}
    E -->|没有| F[交付译文]
    E -->|有| G{是否还有修改次数}
    G -->|有| H[传入原文、译文和具体反馈进行修改]
    H --> C
    G -->|没有| I[交付当前译文及未解决问题]

检查反馈应指出具体位置和依据，例如“第二段漏译了适用条件”，让修改步骤知道改什么。

修改后重新执行检查，确认原问题得到解决，也检查是否产生新问题。风格偏好应提前说明，避免不同检查轮次不断改变标准。

来源：改编自 Self-Refine：原始输入、已有输出与反馈共同参与修改。

5.9 客户回复经批准后发送

任务：根据客户消息生成回复，获得批准后正式发送。

flowchart TD
    A[收到客户消息] --> B[查询必要资料]
    B --> C[生成回复草稿]
    C --> D[展示收件人、主题和正文供审核]
    D --> E{人工决定}
    E -->|批准| F[以审核时展示的参数发送]
    E -->|拒绝| G[取消发送并保留草稿]
    E -->|超时，按预设规则| H[保持待处理并通知]
    F --> I[核对发送结果]
    I --> J[报告成功或结果待核实]

审核针对一次具体发送操作，因此需要展示收件人和正文。批准后执行的内容应与审核时一致；内容改变后应重新确认。

批准、拒绝由工具执行控制落实。超时保持待处理，是这个案例补充的处理规则。

来源：n8n：工具执行前的人工审核。

5.10 围绕一个问题完成资料调查

任务：调查一个范围明确的问题，产出带来源的简报。

flowchart TD
    A[输入问题、交付要求和查询上限] --> B[列出需要查清的事项]
    B --> C[选择当前要查的事项和检索方式]
    C --> D[搜索并读取原始来源]
    D --> E[记录证据、来源和未解决问题]
    E --> F{是否已有足够依据}
    F -->|有| G[综合结论并附来源]
    F -->|没有| H{是否还能继续查询}
    H -->|能| I[根据缺口或矛盾决定下一步]
    I --> C
    H -->|不能| J[整理已有结论并说明剩余缺口]
    G --> K[交付简报]
    J --> K

这里固定的是调查的控制过程，具体搜索什么由实际结果决定。例如，发现两个来源的数字冲突，就进一步核对统计时间和口径。

下一步应依据已经读到的证据选择。达到查询上限时交代现有结论和缺口，避免为了交付完整答案而补写没有依据的内容。

来源：Anthropic：基于实际反馈选择后续行动。