平行执行、回圈步骤与条件判断：真正重要的 Workflow 模式

只是将 recipe 线性串接的 workflow——步骤 1 传递给步骤 2 再传递给步骤 3——能处理许多使用场景。但真实的业务流程会分支、回圈、同时执行多项任务、需要人工签核,并与外部系统互动。JieGou 的八种步骤类型让你能模拟这些模式。

Recipe 步骤:基本构建单元

Recipe 步骤执行单一 AI recipe,输入经过映射并产生结构化输出。这是任何 workflow 中的基本工作单元。

何时使用: 每当你需要 AI 执行任务时——提取资料、生成内容、分析输入、分类项目。

关键设计选择: 输入映射。每个输入栏位映射到一个来源:静态值、workflow 层级的输入、前一个步骤的输出,或回圈项目。映射 step_1.company_overview 表示「从步骤 1 的输出中取得 company_overview 栏位」。这就是资料在步骤之间流动的方式。

提示: 使用最便宜且能产生可接受输出的模型。不要在简单的格式化步骤使用 Opus,因为 Haiku 就能处理得很好。

条件步骤:分支逻辑

条件步骤评估一个值与比较条件,并分支到 thenSteps 或 elseSteps。

提供八种运算子:equals、not_equals、contains、not_contains、greater_than、less_than、is_empty、is_not_empty。

何时使用:

• 将合格与不合格的潜在客户导向不同路径
• 根据严重程度以不同方式处理错误
• 当资料缺失时跳过步骤
• 在昂贵的步骤前加上品质检查关卡

范例——发票处理:

步骤 1:提取发票资料
步骤 2:检查差异
步骤 3:条件 (discrepancy_count > 0)
  Then:送交主管审批
  Else:自动归档发票

条件使用 greater_than 检查 step_2.discrepancy_count 是否大于 0。不需要 AI 呼叫——这是纯逻辑运算。

提示: 在提取步骤后使用条件来验证 AI 是否确实找到你需要的资料。检查关键栏位的 is_not_empty 可防止下游步骤在资料不完整时执行。

回圈步骤:处理集合

回圈步骤遍历一个集合,对每个项目执行其巢状的 loopSteps。集合来源是前一个步骤输出的栏位——通常是阵列。

何时使用:

• 处理招聘批次中的每位候选人
• 分析发票中的每个项目
• 从内容计划为每个频道生成内容
• 审查合约中的每个条款

范例——批次候选人筛选:

步骤 1:解析候选人清单 → 输出 candidates[]
步骤 2:回圈遍历 candidates
  步骤 2.1:筛选履历(输入映射到 loop_item)
  步骤 2.2:生成面试问题(如果合格)

每次迭代透过 loop_item 映射获得当前项目。回圈将所有迭代输出聚合成单一结果。

提示: 保持回圈主体精简。如果你执行 50 次迭代,每次有 3 个 recipe 步骤,那就是 150 次 AI 呼叫。在回圈内使用最便宜且有效的模型。

平行步骤:并发执行

平行步骤使用 Promise.allSettled() 同时执行多个分支。每个分支是独立的步骤序列。所有分支同时开始;当所有分支完成(或失败)时,平行步骤完成。

何时使用:

• 同时为多个频道生成内容
• 执行彼此不依赖的独立分析
• 同时处理多个资料来源
• 加速步骤之间没有依赖关系的 workflow

范例——多频道内容生成:

步骤 1:分析部落格文章
步骤 2:平行
  分支 A:生成 LinkedIn 贴文
  分支 B:生成 Twitter 串文
  分支 C:生成电子报内容
  分支 D:生成电子邮件行销文案

分支 A 到 D 并发执行。每个分支在平行步骤开始时获得输出映射的快照——它们可以读取前一个步骤的资料,但在执行期间看不到彼此的输出。

关键行为: 如果分支 B 失败,分支 A、C 和 D 继续执行并正常完成。Promise.allSettled 意味着一个失败不会终止其他分支。平行步骤后,你可以检查哪些分支成功了。

提示: 平行步骤非常适合需要以多种方式处理相同输入的情况。速度提升显著——四个并发分支完成的时间与一个顺序步骤大致相同。

审批步骤:人工检查点

审批步骤暂停 workflow 并向审批者发送通知(通常是电子邮件)。只有当审批者采取行动时,workflow 才会继续:批准、拒绝或提供输入。

何时使用:

• 在发送面向客户的内容之前
• 在执行金融交易之前
• 在 AI 生成的分析影响业务决策之后
• 任何需要人工判断才能继续的时间点

范例——内容发布流程:

步骤 1:生成部落格草稿
步骤 2:审批(内容经理审查)
步骤 3:从已批准的草稿生成社群媒体贴文
步骤 4:审批(行销主管审查最终套件)

两个审批关卡:一个在草稿生成后,一个在发布前。内容经理可能拒绝草稿并提供回馈,导致 workflow 停止。或者他们批准,workflow 继续生成衍生内容。

限制: 审批步骤不能巢状在回圈或条件步骤内。它们在 workflow 的顶层或平行分支内运作。这是刻意的设计选择——在回圈迭代中途暂停会产生状态管理复杂性,很少有使用场景能证明这种复杂性是合理的。

提示: 审批步骤可以包含可选的输入 schema。当审批者需要提供资料时使用此功能——修订注记、批准的预算金额、选定的选项——这些是下游步骤需要的。

写入知识库步骤:建立组织知识

写入知识库步骤捕获前一个步骤的输出并将其写入知识库文件。Workflow 立即继续——这是一个即发即忘的写入操作,不会阻塞执行。

何时使用:

• 储存支援工单解决方案,以便未来执行可以透过 RAG 引用它们
• 建立不断增长的已分析合约、会议摘要或研究简报库
• 建立 AI 生成输出的可搜寻记录,用于稽核或重复使用

范例——支援解决方案知识库:

步骤 1:分类工单(recipe)
步骤 2:草拟解决方案(recipe)
步骤 3:审批(支援主管审查)
步骤 4:写入知识库(将解决方案储存到「支援解决方案」知识库)
步骤 5:向客户发送回应(recipe)

解决方案获批准后,会写入知识库。未来的分类执行可以透过 RAG 检索类似的解决方案,使每个解决方案都比上一个更智慧。

提示: 将写入知识库步骤与自动情境知识库配对。当知识库连结到 recipe 或部门时,其文件会自动包含为未来执行的情境——无需手动连接。

交接步骤:人工通知但不阻塞

交接步骤向目标部门的使用者发送通知(电子邮件和应用程式内)。与审批步骤不同,交接不会暂停 workflow——它们提醒某人并继续执行。

何时使用:

• 在不停止流程的情况下将问题上报给另一个团队
• 通知部门工作已准备好供他们处理
• 提醒利害关系人 workflow 发现的事项

范例——事件检测与工程交接:

步骤 1:分析错误日志(recipe)
步骤 2:分类严重程度(recipe)
步骤 3:条件 (severity == "critical")
  Then:
    步骤 3a:交接给工程部(通知)
    步骤 3b:生成事件报告(recipe)
  Else:
    步骤 3c:记录到监控仪表板(recipe)

交接立即通知工程团队,但 workflow 不会等待他们回应——它在人工回应的同时继续生成事件报告。

提示: 对「仅供参考」的通知使用交接,对「请决定」使用审批。如果下游步骤依赖人工判断,使用审批。如果不依赖,交接能让事情继续进行。

浏览器操作步骤:与 Web 应用程式互动

浏览器操作步骤透过 JieGou 浏览器扩充功能执行 MCP 工具呼叫。它可以点击按钮、填写表单、读取页面内容、撷取萤幕截图,并与 Gmail、Slack、Jira 和其他 Web 应用程式中的平台特定功能互动。

何时使用:

• 根据 workflow 资料在内部工具中填写表单
• 从没有 API 的网页读取资料
• 为报告撷取仪表板的萤幕截图
• 与只有 Web 介面的旧系统互动

范例——潜在客户合格后更新 CRM:

步骤 1:研究潜在客户(recipe)
步骤 2:合格潜在客户(recipe)
步骤 3:浏览器操作(使用合格资料更新 Salesforce 记录)
步骤 4:浏览器操作(在 HubSpot 联络人新增注记)

浏览器扩充功能在专用的自动化视窗中执行,因此不会干扰你的活动浏览器工作阶段。范本参数将 workflow 资料映射到工具呼叫——{{step.step_2.qualification_score}} 成为填入 CRM 栏位的值。

提示: 浏览器操作步骤最适合最后一哩——将 AI 生成的资料推送到缺乏 API 存取的系统。对于具有 API 整合的系统(透过 MCP server,如 Salesforce、HubSpot、Jira),改用带有 MCP 工具的 recipe 步骤,因为它们更快且更可靠。

组合模式

最有效的 workflow 结合多种步骤类型:

具有平行外展的潜在客户处理:

步骤 1:研究潜在客户(recipe)
步骤 2:合格潜在客户(recipe)
步骤 3:条件 (qualification_score >= threshold)
  Then:
    步骤 3a:平行
      分支 A:草拟电子邮件(recipe)
      分支 B:草拟 LinkedIn 讯息(recipe)
    步骤 3b:销售审查(审批)
  Else:
    步骤 3c:封存潜在客户(recipe)

批次发票处理:

步骤 1:解析发票批次 → invoices[] (recipe)
步骤 2:回圈遍历 invoices
  步骤 2.1:提取资料(recipe)
  步骤 2.2:检查差异(recipe)
  步骤 2.3:条件 (has discrepancies)
    Then:标记为待审查(recipe)
    Else:标记为无问题(recipe)
步骤 3:生成摘要报告(recipe)
步骤 4:财务经理审批(审批)

这些模式自然地组合,因为每种步骤类型都有清晰的语义:recipe 执行 AI 工作,条件分支,回圈迭代,平行展开,审批暂停。

输入映射是黏合剂

步骤类型是动词。输入映射是连接组织。每个 recipe 步骤的输入映射到四个来源之一:

• static — 硬编码值
• workflow_input — 来自 workflow 顶层输入的值
• step_output — 来自前一个步骤输出的栏位(例如 step_1.summary)
• loop_item — 回圈迭代中的当前项目

正确设定输入映射是 workflow 设计中最重要的部分。JieGou 包含按名称和类型匹配栏位的自动映射,但手动审查和调整映射可确保资料正确流动。