MindCarver Blog

MindCarver

MindCarver

技术服务于产品

Day22-Workflow基础

37分钟阅读

Day 22：Workflow 基础

学习目标

从今天开始进入 Week 4，主题是 Workflow、Agent 与 Tool Calling。前三个星期我们分别建立了 AI 全景认知、掌握了 API 调用和结构化输出、完成了 RAG 知识库系统的搭建。这一周要把这些能力串起来，让 AI 从”被动的问答工具”变成”能按流程执行任务的系统”。

今天的目标是理解 Workflow 的本质：什么是工作流、什么时候该用工作流而不是 Agent、怎么设计节点和状态传递、怎么处理异常和人工介入。学完这一天，你应该能画出一张清晰的行业分析 Workflow 流程图，并且说出每一个节点做什么、输入什么、输出什么、失败了怎么办。

核心概念

Workflow 的定义

Workflow，中文叫工作流，本质上就是”把一件复杂任务拆成一系列有序的步骤，每个步骤有明确的输入和输出，步骤之间按固定规则流转”。

想想工厂流水线。原材料进来，第一道工序切割，第二道工序打磨，第三道工序组装，第四道工序质检，最后包装出库。每道工序只做一件事，做完把半成品传给下一道。如果你把整条流水线看成一个整体，它就是一个 Workflow。

在 AI 应用里，Workflow 就是把”让 AI 做一件复杂的事”拆解成多个步骤，每个步骤可能调用一次大模型、可能查一次数据库、可能调一个外部 API，步骤之间按预定义的顺序执行。

Workflow 有三个核心特征。第一，流程是预定义的，不是动态决定的。你设计好了 6 个节点，它就一定走这 6 个节点，不会临时加一个节点或者跳过某个节点（除非条件分支允许）。第二，每个节点有明确的输入和输出格式。节点 A 的输出格式必须和节点 B 的输入格式匹配，否则链条就断了。第三，状态在节点之间传递。前一个节点的结果作为后一个节点的输入，整个链条共享一个状态上下文。

为什么 Workflow 这么重要？因为企业应用最怕的不是 AI 不够聪明，而是 AI 的行为不可预测。一个固定的流程能保证每次执行的结果在可控范围内，出了问题能定位到具体节点。这是企业客户愿意买单的前提。

Workflow 适用场景

不是所有场景都适合 Workflow。适合的场景有三个特征。

第一个特征是流程相对固定。比如”行业分析报告生成”，不管分析哪个行业，步骤都差不多：理解需求、收集信息、拆解行业、分析岗位、分析流程、生成报告。这种流程你可以提前设计好，每次按流程走就行。

第二个特征是步骤之间有明确的依赖关系。后一步必须等前一步完成才能开始，而且前一步的输出是后一步的输入。比如”岗位拆解”必须在”行业概览”之后，因为你需要先知道这个行业有哪些业务板块，才能拆出对应的关键岗位。

第三个特征是输出格式要求高。每一步都要产出结构化的结果，而不是一段自由文本。比如”AI 机会评分”这一步，必须输出一张打分表，包含场景名称、评分维度、分数、推荐优先级。这种结构化的中间产物是 Workflow 可靠运行的保障。

反过来说，哪些场景不适合 Workflow？如果任务需要 AI 自主判断下一步做什么、需要根据情况动态调整策略、需要跟外部环境反复交互，那就应该用 Agent 而不是 Workflow。我们在明天的内容里详细对比。

举个实际的例子。假设你给一家半导体企业做 AI 提效方案。你需要先了解这家企业的业务范围、组织架构、核心流程、痛点，然后才能提出方案。这个”诊断”过程本身就是一个 Workflow：企业概况收集 → 业务流程梳理 → 岗位任务拆解 → AI 机会识别 → 方案优先级排序 → 报告生成。每一步都有明确的产出，前后依赖关系清晰。

节点设计

节点是 Workflow 的基本组成单元。每个节点代表一个独立的处理步骤。

设计节点时，要回答五个问题：这个节点做什么？输入是什么？输出是什么？失败了怎么办？需要多长时间？

拿”行业概览”这个节点举例。它做的事情是：给定一个行业名称，生成该行业的结构化概览，包括产业链结构、主要玩家、市场规模、发展趋势、核心技术。输入是一个字符串（行业名称）。输出是一个 JSON 对象，包含上述字段。失败的情况包括：行业名称模糊导致结果不准确、模型输出格式错误、模型调用超时。处理时间大约 10-20 秒。

节点设计有一个容易忽视的原则：粒度要适中。太粗了，一个节点做了三件事，出问题不好定位；太细了，节点太多，状态传递复杂度爆炸，维护成本高。一个好的经验是”一个节点做一件逻辑完整的事”。所谓逻辑完整，就是中间产物有自己的独立价值。比如”行业概览”就是一个逻辑完整的节点，它的输出可以单独拿出来看、单独存档、单独复用。

还有一种常见的做法是把节点分为两类：AI 节点和非 AI 节点。AI 节点调用大模型做生成或分析，非 AI 节点做数据处理、格式转换、条件判断、结果存储。一个健康的 Workflow 应该是两类节点混合的，不是所有节点都调模型。

输入输出设计

输入输出是节点之间衔接的桥梁。如果输入输出设计不好，整个 Workflow 就像用不同口径的管道拼水管，到处漏水。

输入设计要考虑三个层面。第一，必需字段和可选字段。比如”行业概览”节点的必需输入是行业名称，可选输入是关注的维度（比如只看技术趋势不看市场规模）。第二，字段类型。行业名称是字符串，关注维度是字符串数组，这要在设计时就定好。第三，输入来源。有的输入来自用户（第一个节点的输入），有的输入来自上一个节点的输出（后续节点的输入）。

输出设计同样要考虑三个层面。第一，输出的结构。推荐用 JSON Schema 定义，字段名、类型、是否必填都要明确。第二，输出的稳定性。同一个输入，多次运行，输出的结构应该一致。字段不能时有时无。第三，输出的下游兼容。输出格式一旦定下来，尽量不改。因为下游节点依赖这个格式，改了就可能连环出问题。

举个反面例子。假设”行业概览”节点有时候输出”key_players”字段，有时候不输出。下游的”岗位拆解”节点需要参考”key_players”来推断岗位，结果拿到空值就报错了。这就是输出不稳定导致的问题。

设计输入输出时，我建议给每个节点画一张表格：

字段名类型必填说明来源
industry_namestring是行业名称用户输入
focus_areasstring[]否关注维度用户输入
overviewobject是行业概览数据模型生成

这种表格既是设计文档，也是后续开发的依据。

条件分支

现实业务流程很少是一条直线走到尾的。很多时候需要根据上一步的结果决定下一步走哪条路。这就是条件分支。

条件分支在 Workflow 里表现为”判断节点”。判断节点不做实质性的数据处理，只做逻辑判断，然后决定后续走哪条路径。

常见的条件分支类型有三种。

第一种是质量判断。比如”行业概览”节点生成结果后，需要判断结果质量是否达标。如果概览信息太少（比如产业链描述不足 200 字），就触发重试或者换一种方式生成。如果质量达标，就继续下一步。

第二种是路径选择。比如根据行业类型选择不同的分析策略。半导体行业可能需要特别关注”工艺流程”和”良率数据”，而金融行业更关注”监管合规”和”风控流程”。判断节点识别行业类型后，把流程引到对应的分支上。

第三种是异常处理。如果某个节点失败了，条件分支决定是重试、跳过、还是中止整个 Workflow。这和错误处理紧密相关，后面专门讲。

条件分支设计的关键是”分支条件要明确、可判定”。不能是模糊的”如果结果不好就走另一条路”，而应该是具体的”如果 overview.description 的字数小于 200，则触发补充生成”。

状态传递

状态传递是 Workflow 的血液循环。每个节点的执行结果都需要传递给后续节点使用，整个 Workflow 也需要维护一个全局状态。

状态传递有两种模式。

第一种是线性传递。节点 A 的输出直接作为节点 B 的输入。这是最简单的模式，就像流水线上的传送带。比如”行业概览”的输出直接传给”岗位拆解”作为输入。

第二种是上下文传递。所有节点共享一个全局上下文，每个节点可以从上下文中读取需要的数据，也可以往上下文中写入新数据。这种模式更灵活，但也更复杂。比如”AI 机会评分”节点需要同时读取”行业概览”、“岗位拆解”、“流程拆解”三个节点的结果，这时候就需要从全局上下文中读取。

实际设计中，我推荐用全局上下文 + 节点输入映射的方式。全局上下文存储所有中间结果，每个节点在设计时指定自己需要从上下文的哪些字段读取数据。这样既灵活又可控。

状态传递有一个常见问题：上下文膨胀。随着 Workflow 执行，上下文越来越大，到了后面的节点，可能塞了几十个字段。这不仅浪费内存，还可能导致传给大模型的上下文超出 Token 限制。解决方法有两个：一是节点执行完后清理不再需要的中间数据；二是对传给模型的数据做压缩和摘要，只保留关键信息。

错误处理

错误处理是 Workflow 设计中最容易被忽视、却最容易出问题的环节。

Workflow 运行过程中可能遇到的错误分为四类。

第一类是模型调用错误。模型 API 超时、限流、返回空结果、返回格式错误。这类错误最常见，处理策略也最成熟：重试。设置最大重试次数（通常 3 次），每次重试之间加短暂等待，如果重试用完还是失败，则标记该节点为失败状态。

第二类是数据错误。节点的输出不符合预期格式、缺少必填字段、数据内容明显不合理。这类错误需要做输出校验，用 JSON Schema 或 Pydantic 检查输出结构。校验不通过时，可以尝试让模型修正输出，修正失败则标记节点失败。

第三类是逻辑错误。条件分支判断结果与预期不符、流程走到了不该走的路径。这类错误最隐蔽，通常是因为条件分支的判断条件设计不合理。需要通过日志和测试用例来排查。

第四类是系统错误。数据库连接失败、文件系统权限问题、网络中断。这类错误需要基础设施层面的监控和告警。

错误处理的设计原则是”每个节点都要有明确的失败策略”。失败策略包括：重试（最多几次）、跳过（跳过这个节点继续执行）、中止（整个 Workflow 停止）、降级（用简化版本的结果替代）、人工介入（通知人工处理）。不同节点、不同错误类型，失败策略应该不同。

人工审核节点

不是所有步骤都应该让 AI 自动完成。有些节点涉及重要判断、敏感数据或高风险决策，必须加入人工审核环节。

人工审核节点本质上是一个特殊的”暂停”节点。Workflow 执行到这个节点时自动暂停，等待人工输入。人工审核完成后，Workflow 根据审核结果继续执行。

哪些地方需要加人工审核？三个判断标准。第一，这个节点的结果如果出错，后果严重吗？比如”报告生成”节点，如果生成了一份错误的行业分析报告并自动发送给了客户，后果很严重，需要审核。第二，这个节点的判断涉及主观偏好吗？比如”AI 方案推荐”节点，不同客户对方案的偏好不同，AI 不一定能猜对，需要人工确认。第三，这个节点涉及敏感操作吗？比如”发送邮件”或”修改数据库”，这类操作执行后不可撤回，必须人工确认。

人工审核节点的设计需要考虑几个细节。审核界面要清晰展示当前节点的输入、输出、以及上下游节点的关键信息，让审核人能快速理解上下文。审核操作至少包括”通过”、“拒绝并修改”、“拒绝并中止”三个选项。审核结果要记录下来，包括审核人、审核时间、审核意见。这些记录是后续追溯和优化 Workflow 的重要数据。

概念关系图

Workflow 整体结构
|
+-- 用户输入
|   |
|   v
+-- 节点 1：需求理解
|   |-- 输入：行业名称、需求描述
|   |-- 输出：结构化需求（JSON）
|   |-- 失败策略：重试 + 人工修正
|   |
|   v
+-- 节点 2：行业概览
|   |-- 输入：行业名称、关注维度
|   |-- 输出：行业概览（JSON）
|   |-- 条件分支：质量达标？ -> 是/否
|   |   |-- 否 -> 补充生成（子节点）
|   |   |-- 是 -> 继续
|   |
|   v
+-- 节点 3：岗位拆解
|   |-- 输入：行业概览
|   |-- 输出：岗位列表（JSON Array）
|   |
|   v
+-- 节点 4：流程拆解
|   |-- 输入：行业概览、岗位列表
|   |-- 输出：业务流程列表（JSON Array）
|   |
|   v
+-- 节点 5：AI 机会评分
|   |-- 输入：行业概览、岗位列表、流程列表
|   |-- 输出：AI 机会评分表（JSON）
|   |
|   v
+-- 节点 6：报告生成
|   |-- 输入：以上所有中间结果
|   |-- 输出：Markdown 报告
|   |
|   v
+-- [人工审核] <-- 审核节点（暂停，等待人工确认）
|   |
|   v
+-- 最终输出

全局状态上下文：
{
  "industry_name": "半导体",
  "requirement": {...},
  "overview": {...},
  "roles": [...],
  "processes": [...],
  "ai_opportunities": {...},
  "report": "...",
  "status": "awaiting_review"
}

实战分析

实战任务：设计行业分析 Workflow

指南要求设计一个行业分析 Workflow，包含需求理解、行业概览、岗位拆解、流程拆解、AI 机会评分、报告生成六个节点。下面逐一分析设计思路。

需求理解节点

这个节点的职责是把用户输入的自然语言需求转成结构化的任务描述。用户可能说”帮我分析一下半导体行业，看看哪里能用 AI”，也可能说得更具体”分析半导体封装测试环节的 AI 自动化机会”。这两种输入差异很大，需求理解节点要能把模糊需求标准化。

输出结构应该包含：行业名称（标准化后的）、分析范围（全行业还是某个细分环节）、关注重点（效率提升、成本降低、质量改进等）、输出要求（报告格式、详细程度）。

设计时要注意的坑：用户可能输入一个不存在的行业名称（比如把”芯片”说成”半导体”但实际想说的是”集成电路设计”）。需要让模型做一次标准化，把用户语言映射到标准行业分类上。

行业概览节点

输入是标准化后的需求描述，核心信息是行业名称和分析范围。这个节点调用大模型生成行业概览。

输出结构应该包含：产业链描述（上游、中游、下游各环节）、市场规模（总量和趋势）、主要玩家（头部企业）、技术特征（核心技术栈和发展方向）、监管环境、人才特征。

质量判断标准：产业链描述是否覆盖了上中下游？每个环节是否有具体说明（不是泛泛一句带过）？市场规模数据是否有数字（不是”很大”这种描述）？

如果质量不达标，触发补充生成子流程。补充生成不是重新来一遍，而是针对不达标的部分做定向补充。比如产业链下游描述太简略，就让模型专门补充下游环节的细节。

岗位拆解节点

这个节点需要基于行业概览，识别该行业的核心岗位，并分析每个岗位的任务结构。

输出结构应该是岗位数组，每个岗位包含：岗位名称、所属部门/环节、核心职责（3-5 条）、日常高频任务（5-10 条）、低价值高重复任务、高价值需要经验的任务、使用的主要系统和工具、痛点描述。

岗位数量控制在 5-15 个。太少不够全面，太多后面的流程拆解节点处理不过来。可以优先选择”重复性高、数据密集、跨系统操作多”的岗位，因为这类岗位的 AI 机会更大。

流程拆解节点

这个节点在岗位列表的基础上，进一步拆解出业务流程。

输出结构是流程数组，每个流程包含：流程名称、触发条件、参与角色、输入、输出、步骤列表（每一步的描述和耗时估算）、系统依赖、人工判断点、异常情况、错误率。

流程拆解的难点在于粒度控制。一个”客户投诉处理”流程，可以拆成 5 步，也可以拆成 20 步。太粗了看不出 AI 切入点，太细了信息过载。建议每个流程控制在 5-10 步。

AI 机会评分节点

这个节点是整个 Workflow 的价值核心。它要基于前面所有节点的结果，识别 AI 应用机会并评分。

评分维度建议用以下指标：高频程度（这个场景发生频率有多高）、信息密度（涉及多少数据和文档）、人力成本（人工处理需要多少时间）、决策复杂度（需要多少经验判断）、数据可得性（需要的数据是否已经存在系统中）、风险等级（做错了后果有多严重）。

每个维度 1-5 分，综合加权得到总分。按总分排序，输出 Top 5 推荐场景。

这个节点的输出直接决定了报告的质量和可执行性。设计时要特别注意：评分依据要透明，每个场景的每个维度打分都要有理由。这样客户看到报告时能理解为什么这些场景被推荐。

报告生成节点

把前面所有节点的结果整合成一份结构化的 Markdown 报告。

报告结构建议：摘要（一段话说清楚行业现状和 Top 3 AI 机会）、行业概览、岗位分析、流程分析、AI 机会评分表、推荐方案（每个推荐场景的具体 AI 方案描述）、实施路线图（分阶段建议）、风险提示。

报告生成节点的输入是前面所有节点的输出，数据量可能很大。需要做信息压缩，只保留关键结论和数据点。不要把所有中间过程都塞进报告里。

方法论总结

设计 Workflow 的通用方法论可以总结为四步。

第一步，拆任务。把最终目标拆成若干个逻辑步骤。拆的方法是问自己”要完成这件事，我需要先知道什么？然后做什么？“一直拆到每个步骤都有明确的、可独立完成的任务。

第二步，定输入输出。给每个步骤定义输入格式和输出格式。格式要用 JSON Schema 描述，字段名、类型、必填性都要明确。

第三步，画流程图。把所有步骤按依赖关系连起来，标上条件分支和人工审核节点。画完之后问自己三个问题：有没有哪个步骤可以并行？有没有哪个步骤可以省略？有没有哪个步骤需要拆分？

第四步，加防护。给每个节点加上错误处理策略，给关键节点加上质量检查和人工审核。问自己”这个节点最可能怎么出错？出错后最坏后果是什么？“

当日产物说明

今天的产物有三个。

《行业分析 Workflow 图》

这是一张完整的流程图，展示从用户输入到最终报告的全流程。每个节点用方框表示，节点之间用箭头连接，条件分支用菱形表示，人工审核用特殊标记。图的旁边标注每个节点的预估耗时和关键依赖。

这张图的质量标准是：拿给一个不了解项目的人看，他能看懂整个流程是怎么运转的。不需要解释就能理解每个节点做什么、节点之间怎么衔接。

《Workflow 节点说明》

这是一个文档，每个节点一页，详细说明该节点的功能、输入、输出、失败策略、质量标准。

质量标准：格式统一、信息完整、没有模糊描述。比如不能写”如果质量不好就重试”，要写”如果 overview.industry_chain 的字段数少于 3，则触发补充生成，最多补充 2 次”。

《节点输入输出表》

这是一张汇总表格，列出所有节点的输入字段和输出字段，包括字段名、类型、是否必填、来源/去向。

质量标准：表格的每一行都能在 Workflow 图上找到对应的节点和箭头。字段类型用标准类型（string、number、boolean、array、object）描述，不使用模糊类型。

常见误区与避坑

误区一：Workflow 越复杂越好

很多人觉得节点越多、分支越细，Workflow 越强大。实际情况恰恰相反。节点越多，出错概率越高，调试越困难，维护成本越大。一个好的 Workflow 应该用最少的节点完成目标。如果某个节点的输出没有被任何后续节点使用，删掉它。如果两个相邻节点可以合并成一个逻辑完整的步骤，合并它们。

误区二：每个节点都调大模型

大模型调用是成本最高、耗时最长、最不稳定的环节。如果一个节点的逻辑可以用规则处理（比如数据格式转换、条件判断），就不要调模型。把模型调用留给真正需要理解和生成的节点。一个 Workflow 里超过一半的节点在调模型，通常意味着设计有问题。

误区三：忽视输出校验

很多初学者设计 Workflow 时只关注”节点做什么”，不关注”输出是否正确”。结果运行时，上游节点输出了一个格式错误的结果，下游节点拿着错误数据继续跑，最后产出一堆垃圾。每个节点的输出都要做格式校验，不通过就拦截，不要让错误向后传播。

误区四：不加人工审核

全自动的 Workflow 看起来很酷，但在企业场景中风险极高。至少在最终输出节点前加一个人工审核。前期可以多加几个审核点，等 Workflow 运行稳定了再逐步减少。

误区五：状态传递设计混乱

有的设计者把所有中间数据都塞进全局上下文，不做清理和整理。到后面节点拿数据时，不知道该用哪个字段，甚至出现字段名冲突。建议给全局上下文的 key 做命名规范，比如用”节点名.字段名”的格式（overview.industry_chain、roles.role_list），避免混乱。

延伸思考

Workflow 和 Agent 的边界在哪里？这是明天要深入讨论的问题。今天先建立一个直觉：Workflow 是”计划好的流程”，Agent 是”能自己决定流程的系统”。Workflow 更可控、更可预测，适合标准化程度高的任务；Agent 更灵活、更智能，适合需要判断和应变的任务。

在实际项目中，Workflow 和 Agent 经常混合使用。大框架用 Workflow 控制，某些需要灵活处理的节点用 Agent。比如”行业概览”用 Workflow 节点就行，但”AI 方案设计”可能需要 Agent 根据不同行业灵活选择分析策略。

另外，今天设计的行业分析 Workflow 就是 Week 4 最终项目”多 Agent 行业研究系统”的基础。后面几天学的 Agent、Tool Calling、Multi-Agent 都是在这个 Workflow 基础上增强的。先有扎实的 Workflow 设计能力，后面才能做好 Agent 系统。

从与 Week 3 的衔接来看，Workflow 中的某些节点可以引入 RAG 能力。比如”行业概览”节点，除了让模型凭知识生成，还可以从知识库中检索相关行业报告，把检索结果作为上下文提供给模型，提高准确性。这就是 RAG 和 Workflow 的结合点。

自测问题

  1. Workflow 的三个核心特征是什么？请用自己的话解释。

  2. 举一个不适合用 Workflow 而适合用 Agent 的场景，说明原因。

  3. 设计节点时，“粒度适中”的标准是什么？什么样的粒度算适中？

  4. 如果”行业概览”节点的输出偶尔缺少”key_players”字段，下游节点会出什么问题？怎么解决？

  5. 条件分支的判断条件应该满足什么要求？为什么不能是模糊的？

  6. 状态传递中”上下文膨胀”是什么意思？会导致什么问题？怎么解决？

  7. 错误处理有哪四类错误？每类错误举一个具体例子。

  8. 哪些地方应该加人工审核节点？判断标准是什么？

  9. 为什么不能让 Workflow 中的每个节点都调用大模型？

  10. 设计一个”客户需求分析”Workflow，至少包含 4 个节点，描述每个节点的输入、输出、失败策略。

关键词

  • Workflow（工作流）：把复杂任务拆成有序步骤，按预定义规则执行的处理模式
  • Node（节点）：Workflow 中的独立处理步骤，有明确的输入和输出
  • 条件分支：根据上一步结果决定下一步走哪条路径的逻辑判断
  • 状态传递：节点之间共享和传递数据的方式，包括线性传递和上下文传递
  • 错误处理：对 Workflow 执行过程中各类错误的检测和应对策略
  • 人工审核节点：Workflow 中暂停等待人工确认的特殊节点
  • 输入输出设计：定义每个节点接收什么数据、产出什么数据的规范
  • 全局上下文：Workflow 中所有节点共享的数据存储空间
  • 失败策略：节点执行失败时的处理方式，包括重试、跳过、中止、降级
  • 质量判断：对节点输出质量的自动评估，用于决定是否触发重试或补充生成

关系图谱