## Workflow 能解决什么问题

<!-- slot: 目标 -->
很多企业工作卡在同一类痛点上：**重复执行**（每周都要做）、**多角色协作**（要等别人）、**等待外部结果**（等审批、等系统返回）、**人工审批**（关键环节要人确认）、**完整留痕**（出了问题要能回溯）。Loop Workflow 把这类散落在聊天里的临时工作，变成可复用、可观察、可审计的执行流程。

适合 Workflow 的典型场景：

- **工单自动分诊与指派**：新 Bug 或工单进来，先让 Agent 分类，再经人工确认，最后通知结果。
- **定期报表并审批发布**：每周生成业务报表，经负责人审批后发到频道。
- **多级内容审核**：稿件依次经过初审、复审、终审，每一步可驳回或通过。
- **跨系统数据同步**：从一个系统取数、转换、写入另一个系统，失败可重试。

它们的共同点是：不是一次性问答，而是需要按一张确定的图推进，并在过程中等待与决策。反过来，**一次性问答、单条定时提醒、或只需要一个人盯着的待办**，用普通对话、Scheduled Message 或 Task 就够了，不必动用 Workflow。

“可复用”是 Workflow 最核心的价值：同一张图可以被手动运行一次，也可以被触发器每天自动运行，每次都走同样的步骤、留下同样的记录。如果不把它固化成 Workflow，团队就只能靠“记得怎么做”来重复——而人会忘、会换、会做得不一致。把流程沉淀成 Plan，就是把团队的协作经验变成可依赖的基础设施，而不是某个人脑子里的隐性知识。

<!-- slot: 边界 -->
不是所有工作都适合 Workflow。先按下表判断该用哪种方式：

| 情况 | 更合适的方式 | 原因 |
|---|---|---|
| 一次性问答、临时讨论 | 普通对话 | 只是频道 / DM / 线程里的消息流，不需要持久状态 |
| 有负责人、要跟踪到完成，需要审批与证据 | Task | 看板生命周期（`todo` → `in_progress` → `in_review` → `done`）+ 单一指派人 + Review Request |
| 固定时间发一条消息或提醒（单步） | Scheduled Message | 时间触发，产出一条消息或任务讨论记录；没有多步图 |
| 需要 AI 自主完成一项判断或执行 | Agent | LLM 执行者，被 `@mention` 或任务指派唤醒 |
| 多步骤、分支、等待、审批的持久编排 | Workflow | 版本化的 Plan 与 Run，节点级别的尝试、等待与效果 |
| 让 Agent 调用外部系统（代码托管、CRM 等）的 API | Extension（由 App 承载） | 用 `loop exec <ext> <action>`；App 管连接与身份，Extension 管可调用的动作 |

**何时从普通对话升级为 Workflow？** 当一项工作出现以下任一信号，就值得考虑 Workflow：同一套流程被反复手动重复；需要在多个角色或系统之间等待；关键环节必须有人审批；出问题时要能回溯每一步。只要没有这些信号，继续用对话或 Task 即可。

这些方式常常**组合**使用。最常见的是 **Workflow 编排 + Agent 执行 + Task 跟踪**：Workflow 用 `send_message` 把某一步交给 Agent，Agent 完成后回传结果，关键产物再用 Task 记录与审核。注意 Scheduled Message 与 Workflow 的触发器（Binding）是两套独立机制——前者到点发一条消息，后者到点启动一整张编排图；不要把它们混为一谈。

<!-- slot: 提示词 -->
本章只判断适用场景，不涉及从提示词创建 Workflow；从提示词创建在后续篇章展开。

<!-- slot: 流程 -->
判断一项工作是否该用 Workflow，按顺序确认两点：

1. **是否需要持久状态？** 如果工作完成后无需保留进度、等待与结果，普通对话或 Task 就够。
2. **是否存在多步骤、分支、等待或审批？** 只有需要按一张确定的图编排、并在节点之间等待或决策时，才进入 Workflow。

满足这两点的工作，其执行结构由四个核心对象承载：**Plan**（可复用的编排逻辑）、**Binding**（可选的计划调用部署）、**Invocation**（一次被接受的调用）、**Run**（执行这次调用的运行）；图中的每个 **Node** 是一个**编排单元**（Node 是编排单元，不要把它叫“步骤”）。它们的细节在核心对象一章展开。

举个判断的例子：客服团队每周整理一份“常见问题汇总”——这件事每周重复、要等各负责人提交素材、汇总后必须审阅才能发布——同时满足持久状态、多步骤与审批，适合 Workflow。相比之下，“问一下今天谁值班”是一次性问答，用普通对话；“每天早上发一条值班提醒”是单步定时，用 Scheduled Message；“跟踪这份汇总审到哪了”是有负责人和状态的待办，用 Task。围绕同一个目标，编排、提醒、跟踪各用各的工具，不要都用 Workflow，也不要因为某一项不用 Workflow 就放弃组合。

<!-- slot: 配置 -->
一个最小的 Workflow 只需要一个入口、一个节点、一条边。下面这个 Plan 等待一秒后成功结束，可用于验证工具链：

```yaml
apiVersion: loop.plan/v1
kind: PlanVersion
graph:
  entry: {nodeId: wait_once, port: in}
  nodes:
    - id: wait_once
      type: wait
      wait:
        until: {value: PT1S}
        timeout: PT5M
    - id: done
      type: end
      end: {outcome: succeeded}
  edges:
    - id: completed
      source: {nodeId: wait_once, port: completed}
      target: {nodeId: done, port: in}
```

把它保存为 `plan.yaml`。校验它（编辑器的校验功能，或下面的命令），应得到空的 `diagnostics`：

```bash
$ python3 -c 'import json;print(json.dumps({"action":"validate","source":open("plan.yaml").read()}))' | loop exec workflow plan -
```

```text
{"data":{"diagnostics":[],"digest":"sha256:…"}}
```

<!-- slot: 异常 -->
本章不展开运行故障处置。如果最小 Plan 校验失败，先按诊断信息修正再发布；运行态的失败语义（等待、审批、回调）在可靠流程设计篇说明。

<!-- slot: 审批 -->
本章只在边界比较里提到人工审批；`request_approval` 节点的配置在可靠流程设计篇展开。注意 `request_approval` 没有创作期超时，不安排“审批超时升级”。

<!-- slot: 外部系统 -->
本章不展开外部系统对接。对接代码托管、CRM、HRIS 等外部能力，由 **App** 承载连接、由 **Extension** 暴露给 Agent 的 `loop exec` 动作；Workflow 通过 `send_message` 与 Agent 协作，由 Agent 决定是否调用 Extension。**Extension 不是 Workflow 节点**，不要把它写进 Plan 的 `nodes`。

<!-- slot: 验收 -->
- [ ] 能区分普通对话、Task、Scheduled Message、Agent、Workflow、Extension 各自的适用边界。
- [ ] 能用“是否需要持久状态”与“是否多步骤 / 分支 / 等待 / 审批”两点，判断一项工作是否该用 Workflow。
- [ ] 能说出“何时从对话升级为 Workflow”的信号，以及 Scheduled Message 与 Workflow 触发器的差别。
- [ ] 能说出四个核心对象（Plan、Binding、Invocation、Run）与 Node（编排单元）的角色。

<!-- slot: 媒体槽位 -->
本章不新增媒体。