两种情况下，一个任务步骤需要被拆分出来：
\n通常有以下几种情况：
\n例如，自动回复客户咨询时，你希望先人工检查回复，再决定是否发送。可以安排为：
\n\n收到咨询 → AI 生成回复草稿 → 人工确认 → 发送。
拆分时可以参考以下规律：
\n再用同一批任务比较拆分前后的质量、耗时、费用和人工返工量。有改善且代价值得，就保留这种拆分。
\n例如，LangChain 用同一个模型测试100个零售客服任务，逐步加入其他领域的无关工具和说明，比较三种分工方式：
\n| 方案 | 怎样处理 |
|---|---|
| 不拆分 | 一个 Agent 接收所有领域的工具和说明，独自处理问题。 |
| 拆分后统一转述 | 不同领域由专门 Agent 处理，结果交给主管 Agent 转述给用户。 |
| 拆分后直接回复 | 问题交给对应领域的 Agent，由它直接回复用户。 |
当无关领域增多时，不拆分的方案表现明显下降；第三种方案的表现略优于第二种，消耗的 token 也更少。团队发现，主管转述容易改变原意，还增加一次生成，因此又给第二种方案加入直接转发回复的能力。
\n这个例子中，值得保留的拆分让每个 Agent 少接触无关工具和说明，同时减少不必要的转述。但仅加入一个无关领域时，不拆分反而略好：应根据测试结果选择方案，而不是默认拆开就更好。LangChain：不同分工方式的对照测试
" }, { "id": "course-agent-automation-topic-2", "title": "2. 为模型、程序和人分配工作", "url": "https://ai-knowledge-map.com/software/agents-automation/automation/#course-agent-automation-topic-2", "html": "并不是每个环节都适合交给agent处理，恰恰相反，程序比agent更加稳定，更加有保障。只有必须需要agent做的任务才需要安排agent。单agent结构也未必比多agent结构差。
\n| 基础结构 | 什么时候用 |
|---|---|
| 顺序执行 | 后一步需要前一步的结果。 |
| 条件分支 | 不同情况需要不同处理。 |
| 并行后汇总 | 多项工作互不依赖，最后需要共同使用结果。 |
| 逐项处理 | 对一批对象执行相同操作。 |
| 检查后循环 | 根据上一次结果决定是否继续处理。 |
| 失败后处理 | 某个步骤执行失败，需要重试、换方案、转人工或终止。 |
先列出这个环节可能犯什么错，再逐项选择检查方式：
\n同一个环节可以组合多种检查。Anthropic：检查方式的选择
\n例如，要检查“从邮件中提取活动信息”这个环节。原邮件是：
\n\n培训于2026年7月12日14:00—16:00举行，地点为A楼301。报名截止时间为7月10日。
模型却把活动日期提取成了7月10日。可以设计以下检查：
\n| 可能的错误 | 检查方式 | 具体规则 |
|---|---|---|
| 缺少日期、时间或地点 | 程序 | 检查规定字段是否齐全、是否为空。 |
| 日期不存在、结束时间早于开始时间 | 程序 | 解析日期时间，检查是否合法、开始时间是否早于结束时间。 |
| 把报名截止日期当成活动日期 | 模型 | 对照原邮件，判断各个日期表达的含义。 |
| 原邮件没有写地点 | 模型 | 标记“信息不足”，要求用户补充。 |
程序检查可以交给开发 Agent 实现，要求写具体：
\n\n接收提取结果，检查 title、start、end、location 四个字段是否齐全且非空；start 和 end 必须包含日期和时间，能够解析，且 start 早于 end。输出是否通过，以及每个问题对应的字段和原因。
语义检查可以增加一个 LLM 节点，使用以下提示词：
\n原邮件：{{原邮件}}\n提取结果：{{提取结果}}\n\n逐项核对活动名称、开始时间、结束时间和地点。\n区分活动时间、报名截止时间及其他日期。\n每个判断都要引用原邮件中的对应文字。\n原文未提供或存在歧义的信息，标记为“信息不足”，不要猜测。\n\n输出：\nstatus：通过 / 不通过 / 信息不足\nissues：问题字段、当前值、原文依据、应如何修改在 Dify 等可视化平台中，用代码节点执行程序检查，用 LLM 节点执行语义检查；将检查结果设为结构化输出，供后面的条件分支读取。Dify：LLM 节点与结构化输出
\n\n提取信息 → 程序检查 → 语义检查 → 通过后创建日程。
这个例子中的提取步骤只需调用模型，并配置三个输入：原邮件、上一次结果、检查反馈。第一次运行时，后两项为空；检查不通过时，工作流把上次结果和具体问题填入对应变量，再次调用这个模型步骤。提取提示词可以写成：
\n请从原邮件中提取活动名称、开始时间、结束时间和地点。\n\n原邮件：{{原邮件}}\n上一次结果：{{上一次结果}}\n检查反馈：{{检查反馈}}\n\n如果有检查反馈，请依据原邮件修正上一次结果。\n输出完整的提取结果。例如，检查反馈是：“start 日期为7月10日，但原文‘培训于2026年7月12日14:00—16:00举行’说明活动日期为7月12日，请修正。”模型收到这些输入后重新提取，结果再进入检查节点。循环由工作流控制，无须把提取步骤做成能自主行动的 Agent，也不需要单独开发“自我改进”功能。
\n原文信息不足，就询问用户。设置修改次数上限，例如最多修改2次，仍未通过则转人工。
\n如果被检查的步骤本身是固定程序，则按错误原因处理：
\n最后，用正确结果、缺失字段、非法日期、混淆截止日期和原文缺少信息的样例，检查这些路径是否走对。模型检查也可能漏错，尤其要测试“格式合法，但内容选错”的情况。
" }, { "id": "course-agent-automation-topic-5", "title": "5. 工作流案例", "url": "https://ai-knowledge-map.com/software/agents-automation/automation/#course-agent-automation-topic-5", "html": "以下案例根据官方教程改编，展示完整处理路径和关键设计选择。
\n任务：根据现有资料编写指南，先确认内容范围，再展开正文。
\nflowchart TD\n A[输入公司资料、读者和必需内容] --> B[模型生成大纲]\n B --> C{人工检查大纲}\n C -->|需要修改| D[指出缺漏或不需要的内容]\n D --> B\n C -->|确认| E[根据资料和确认后的大纲撰写正文]\n C -->|取消| F[结束]\n E --> G[核对事实、章节覆盖和资料缺口]\n G --> H[交付指南及待补充事项]这里拆分大纲，是因为用户希望先控制内容范围。确认后的大纲成为后续写作依据，可以减少全文写完后再调整结构的返工。
\n如果用户没有中间确认的需要，就应与一次生成全文比较，检查拆分是否实际改善结果。
\n\n任务：读取活动邮件，提取名称、时间、地点，检查后创建日程。
\nflowchart TD\n A[输入原邮件] --> B[模型提取结构化信息]\n B --> C[程序检查字段结构和日期格式]\n C -->|通过| D[模型对照原邮件核对含义]\n C -->|不通过| E[整理具体错误]\n D -->|有误| E\n D -->|原文信息不足| F[询问用户，补充后重新处理]\n D -->|通过| G[创建日程并核对返回结果]\n E --> H{是否还有修改次数}\n H -->|有| I[将原邮件、上次结果、反馈传回模型]\n I --> B\n H -->|没有| J[转人工处理]\n G --> K[报告创建结果]程序负责判断“字段能否被后续步骤使用”；模型辅助判断“提取的含义是否正确”。例如，7月10日是合法日期，但它可能只是报名截止日期。
\n提取结果应固定字段和格式。原文没有的信息允许标记为空，再进入补问路径，避免要求模型为了通过检查而猜测。
\n来源：Dify：结构化输出、LangChain：携带错误反馈重新生成。
\n任务：通过统一入口接收咨询，分别处理产品使用、订单查询和故障申报。
\nflowchart TD\n A[收到咨询] --> B[识别诉求类型和必要信息]\n B --> C{属于哪一类}\n C -->|产品使用| D[检索产品说明并回答]\n C -->|订单查询| E[取得订单标识并查询订单]\n C -->|故障申报| F[收集故障信息并创建工单]\n C -->|信息不足| G[返回需要补充的问题]\n C -->|不支持| H[说明处理范围或转人工]\n D --> I[核对依据与处理结果]\n E --> I\n F --> I\n I --> J[向客户回复]分类之后，各条路径使用自己的资料、工具和规则。订单查询步骤无需读取整套故障排查说明，故障申报也不应只套用普通问答提示词。
\n分类标准还应规定如何处理多个诉求：可以拆成几项分别办理，无法确定时先询问。
\n\n任务：读取报名信息，核对明确的报名条件，符合条件后登记。
\nflowchart TD\n A[收到报名材料] --> B[模型提取报名字段]\n B --> C{必要信息是否齐全}\n C -->|否| D[通过表单补充缺失信息]\n D --> C\n C -->|是| E[程序检查截止时间和报名资格]\n E -->|不符合| F[说明未满足的条件并结束]\n E -->|符合| G[写入报名记录]\n G --> H[核对登记结果]\n H --> I[返回成功结果或失败原因]模型负责读懂材料，程序负责执行已经确定的条件。姓名、联系方式缺失时先补充，资格不符合时则说明原因，两种情况进入不同路径。
\n这个结构适合条件明确的申请受理。需要负责人破例决定的情况，可以另设人工分支。
\n来源：改编自 IBM：资料提取、确定规则和表单补充。
\n任务：从指定课程资料中寻找依据，回答问题并附来源。
\nflowchart TD\n A[收到问题] --> B[检索课程资料]\n B --> C{资料能否支持回答}\n C -->|能| D[根据资料生成回答并附来源]\n D --> E[交付回答]\n C -->|不能| F{是否还有查询次数}\n F -->|有| G[分析缺口并调整检索词]\n G --> B\n F -->|没有| H[说明已找到的内容和未解决的问题]检索后需要判断资料是否真正支持回答。例如，找到了“报名流程”的章节，不代表找到了“是否允许延期报名”的规定。
\n补查应针对缺口调整查询。反复使用相同关键词，通常无法解决第一次检索遗漏的问题。
\n\n任务：根据文字、图片和文档，为多个平台生成不同版本的文案。
\nflowchart TD\n A[输入材料、目标平台、语言和风格] --> B[提取并检查目标平台列表]\n B -->|输入无效| C[提示修正并结束]\n B -->|有效| D[文档转为文字，图片单独读取]\n D --> E[整理共同事实和必要背景]\n E --> F[按平台分别执行，可并行]\n F --> G[读取该平台的内容规范]\n G --> H[结合共同事实生成文案]\n H --> I[收集各平台的结构化结果]\n I --> J[程序统一排版并交付]共同事实统一准备，平台差异分别处理。例如，同一个活动的日期应保持一致，但篇幅、语气和组织方式可以不同。
\n最后的排版有固定规则，交给模板或程序完成即可。各平台结果保留平台名称，便于对应和检查。
\n\n任务：整理多条反馈，统计各类问题数量，并生成总结。
\nflowchart TD\n A[输入反馈列表和固定分类标准] --> B[为每条反馈保留编号]\n B --> C[逐条提取问题并分类]\n C --> D{分类结果格式是否合法}\n D -->|否| E[有限修正，仍失败则记录待处理]\n D -->|是| F[保存编号、类别和原文依据]\n E --> G[收集全部处理状态]\n F --> G\n G --> H[程序统计有效记录和各类数量]\n H --> I[模型依据统计结果撰写总结]\n I --> J[交付统计、总结和待处理清单]这里把理解、计算和表达分开：模型判断反馈内容，程序计算数量，模型依据确定的统计结果写总结。
\n每条反馈保留编号，才能追查分类是否正确。失败记录单独列出，报告中明确实际统计了多少条，避免将部分结果当作完整统计。
\n来源：改编自 Dify：逐项处理、结果收集与失败处理。
\n任务：按照术语表翻译短文，检查后修正漏译、误译和术语错误。
\nflowchart TD\n A[输入原文、术语表和翻译要求] --> B[模型生成译文]\n B --> C[程序核对规定术语、数字等明确要求]\n C --> D[模型对照原文检查含义与遗漏]\n D --> E{是否存在必须修正的问题}\n E -->|没有| F[交付译文]\n E -->|有| G{是否还有修改次数}\n G -->|有| H[传入原文、译文和具体反馈进行修改]\n H --> C\n G -->|没有| I[交付当前译文及未解决问题]检查反馈应指出具体位置和依据，例如“第二段漏译了适用条件”，让修改步骤知道改什么。
\n修改后重新执行检查，确认原问题得到解决，也检查是否产生新问题。风格偏好应提前说明，避免不同检查轮次不断改变标准。
\n来源：改编自 Self-Refine：原始输入、已有输出与反馈共同参与修改。
\n任务：根据客户消息生成回复，获得批准后正式发送。
\nflowchart TD\n A[收到客户消息] --> B[查询必要资料]\n B --> C[生成回复草稿]\n C --> D[展示收件人、主题和正文供审核]\n D --> E{人工决定}\n E -->|批准| F[以审核时展示的参数发送]\n E -->|拒绝| G[取消发送并保留草稿]\n E -->|超时，按预设规则| H[保持待处理并通知]\n F --> I[核对发送结果]\n I --> J[报告成功或结果待核实]审核针对一次具体发送操作，因此需要展示收件人和正文。批准后执行的内容应与审核时一致；内容改变后应重新确认。
\n批准、拒绝由工具执行控制落实。超时保持待处理，是这个案例补充的处理规则。
\n来源：n8n：工具执行前的人工审核。
\n任务：调查一个范围明确的问题，产出带来源的简报。
\nflowchart TD\n A[输入问题、交付要求和查询上限] --> B[列出需要查清的事项]\n B --> C[选择当前要查的事项和检索方式]\n C --> D[搜索并读取原始来源]\n D --> E[记录证据、来源和未解决问题]\n E --> F{是否已有足够依据}\n F -->|有| G[综合结论并附来源]\n F -->|没有| H{是否还能继续查询}\n H -->|能| I[根据缺口或矛盾决定下一步]\n I --> C\n H -->|不能| J[整理已有结论并说明剩余缺口]\n G --> K[交付简报]\n J --> K这里固定的是调查的控制过程，具体搜索什么由实际结果决定。例如，发现两个来源的数字冲突，就进一步核对统计时间和口径。
\n下一步应依据已经读到的证据选择。达到查询上限时交代现有结论和缺口，避免为了交付完整答案而补写没有依据的内容。
\n" } ] }