波仔
🤖 第一章 Agent与RPA基础
📄 一句话概括

工作流是把一次任务画成一张节点流程图：每个节点干一件确定的事（调模型、搜网页、查知识库、判断分支、写文件），节点之间用变量传数据——提示词管【怎么想】，工作流管【怎么做、按什么顺序做】。

📝 本节和前面几节的关系

1.2.2 的提示词让 Bot 会【说】，但它仍然是【一次问答】。工作流补上的是 1.1.2 里【规划（路线 B：人预先编排）】——把多步任务固定成一条可重复执行的路线。这一节是全课的技术核心：1.5 的影刀 RPA 流程、1.6 的 Agent 与 RPA 对接，用的都是同一套【节点＋变量＋分支】的思维。

一、为什么要有工作流：一次问答的边界

举个具体例子就清楚了：让 Bot 写一篇带数据的小红书文案。

差别：数据是真的、格式是固定的、每一步可以单独调试和替换。这就是【能交付】和【能演示】的距离。

二、认识节点：工作流的七种常见零件

平台不同叫法略有差异，但零件种类基本就这些：

节点类型 作用 对应能力 例子
开始 定义输入参数 — 接收【主题】和【平台】两个输入
大模型（LLM） 调用模型处理文字 ①理解②规划 写文案、做总结、改语气
插件／工具 调外部能力 ③工具 搜索、生图、读网页
知识库 按语义检索自己的资料 ④记忆 查产品手册里的规格
代码 跑一小段代码处理数据 — 拼接字符串、算数字、解析 JSON
条件分支 根据判断走不同路线 ②规划 如果平台是小红书就走 A 模板
结束／输出 定义最终输出 — 返回文案＋标题＋标签

记忆窍门：把它想成 1.1.1 那张【大脑／手脚／记忆】图的分镜脚本——工作流是把 Agent 的能力【按时间顺序摆到台面上】。

三、变量的传递：工作流的血脉

这是初学者最容易卡住的地方。规则只有一条：

上一个节点的输出，要被下一个节点【显式引用】才能用。

也就是说，节点之间不会自动共享数据。你要在下一个节点的参数里，手动选择【引用 → 某节点的某字段】。

由此产生三个必踩的坑：

  1. 忘了引用——第二个节点用的还是自己写的固定文字，不是第一个节点的结果；
  2. 字段名对不上——第一个节点输出的是 data，你引用 result，取到空值；
  3. 引用了一个还没执行的节点——顺序摆错了（工作流默认从上到下、从左到右执行）。

调试口诀：流程不工作时，先在每个节点后面接一个【输出】节点，看它到底产出了什么。这一步能解决 80% 的问题。

四、分支与循环：让流程不那么死

什么时候该用分支：当【不同情况要不同处理】且规则能明确写出来时。如果规则写不出来（要靠模型自己判断），就把判断本身做成一个模型节点——让它输出 A/B 两个词，再用分支接住。

这是本课最常用的一个设计模式，后面每个实战案例几乎都用：

[LLM 判断节点] → 输出【通过】或【不通过】
        ↓
[条件分支] → 通过：继续发布流程 ／ 不通过：走人工复核提醒

五、一个完整的心智模型

把提示词和工作流的分工彻底记牢：

        用户一句话
             ↓
   ┌──────────────────┐
   │   工作流（骨架）      │  ← 你编排好的固定路线
   │                    │
   │  [节点1] 搜索        │  ← 每个节点内部
   │     ↓              │     都可以有【一段提示词】
   │  [节点2] 写文案      │     说明【这一步怎么想】
   │     ↓              │
   │  [节点3] 排版        │
   │     ↓              │
   │  [节点4] 输出        │
   └──────────────────┘
             ↓
        固定格式的结果

这条【确定的外框 ＋ 弹性的内芯】就是 1.1.2 里两条规划路线的混合使用，也是所有可交付 AI 应用的标准做法。

六、动手 Demo：搭一个四节点工作流

准备：扣子（coze.cn），工作空间 → 资源库 → 工作流 → 新建（起名【文案小助手】）。

第一步——摆节点（拖拽即可，先不用连）： 1. 开始节点（默认就有）：在它的输入参数里加一个 topic（文本类型）； 2. 插件节点：搜索类插件（如【必应搜索】或平台自带的搜索），把它的查询内容引用 topic； 3. 大模型节点：提示词写【根据以下资料，为主题 {{topic}} 写一段 150 字的小红书风格文案】；把上一步搜索结果引用到提示词里； 4. 结束节点：输出类型选文本，值引用大模型节点的输出。

第二步——连起来：按 开始 → 搜索 → 大模型 → 结束 连线。

第三步——试运行：点【试运行】，topic 填 秋季润唇膏，执行。

看到什么算成功：四条节点依次变成绿色（通过），在【结束】节点能看到一段基于真实搜索结果的文案——而不是编的。再点开【搜索】节点看它返回了什么原文。

读结果： 1. 看到中间结果（搜索节点的原始返回）＝ 你有了调试的眼睛，这是工作流最大的好处； 2. 看到最终格式稳定＝ 这次输出是被【框】住的，不是随机的； 3. 把【搜索】节点删掉再跑一次，你会得到一段开头漂亮但数据靠猜的文案——这就亲手验证了【Agent 没有手脚会怎样】。

进阶一步（选做）：在【大模型】后面插入一个条件分支：判断文案字数是否超过 200，超过就再接一个【压缩】模型节点。这一步跑通，你就掌握了第 4 节说的核心模式。

30 秒实验

在跑通的工作流里，把【结束】节点的输出改成引用【搜索】节点的原始结果（而不是大模型节点），再跑一次。

观察：同一张流程图，输出的东西完全不同——因为【引用哪一个节点的输出】就是工作流的接线方式。

结论：工作流调试的本质是【查数据在每一站长什么样】——和查快递物流是一个思路。

常见误区

  1. 【工作流是【更高级的提示词】】——不是。提示词改变的是【怎么想】，工作流改变的是【几步、什么顺序、怎么分支】。两者是不同维度，谁也替代不了谁。
  2. 【节点拖得越多越厉害】——节点越多，出错点和耗时越长。能用三步做完的别用七步，尤其在开始阶段。
  3. 【先搭个复杂的，再慢慢简化】——反了。先做三步能跑通的，再往上加。一次搭 12 个节点，调试到大半夜是行业惯例事故。
  4. 【不用给节点起名字】——当流程有 8 个以上节点、又都是【大模型】【代码】这类重复类型时，你会分不清哪个是哪个。从第一个节点起就改成有意义的名字（【写文案】【压缩到 200 字】）。
  5. 【工作流跑通一次就完了】——真实的业务数据长什么样，只有拿真数据连着跑十次才知道。稳定性的鉴定标准永远是【重复跑】而不是【跑通一次】。
自测三问（点开对答案） 1. **工作流与提示词的分工是什么？** 工作流决定**几步、什么顺序、什么条件**（确定性的骨架）；提示词决定**每一步内部怎么想**（弹性的内芯）。**确定的外框＋弹性的内芯＝可交付的 AI 应用。** 2. **节点之间的数据是怎么传递的？最常踩的坑是什么？** 必须**显式引用**（在上游节点的参数里选【引用某节点的某字段】），不会自动共享。最常踩的坑：忘引用、字段名对不上、引用了还没执行的节点。 3. **【能靠模型判断，但规则写不出来】的情况怎么设计？** 把判断本身做成一个**大模型节点**，让它只输出【A】或【B】两个词，再用**条件分支**接住。这是本课最常用的设计模式（例如：通过／不通过 → 自动发布／人工复核）。

相关笔记