用自然语言和脚本编排多阶段工作流，配置输入、Waker、人工确认、运行记录与自动触发。
WakerFlow 把一套已经验证过的工作方法编排成可重复运行的流程。每次运行先收集结构化输入，再按既定阶段调用指定 Waker，控制串行、并行、分支和人工确认，最后返回统一结果。它适合执行顺序和交付格式需要保持稳定的复杂工作，不是用来替代职责含糊、尚未验证的任务。
创建 WakerFlow 前，先让参与流程的 Waker 分别完成一次小范围任务，确认职责、工作目录、Skills、连接器和权限可用。流程只能稳定复用已经明确的工作方法。
通常先在对话中验证单个 Waker，再用 Group 验证多角色协作，最后把稳定步骤固化为 WakerFlow。只有一个 Waker、一个步骤且没有复杂输入时，不必额外编排流程。
入口： 左侧导航 →「能力与资源」→「WakerFlow」。列表页用于新建流程、查看参与的 Waker、打开已有流程和维护自动触发。
打开已有流程时，先查看名称、说明、参与的 Waker 和最近运行记录。不要只根据名称判断用途；输入字段、执行节点和最终返回值才决定流程实际行为。
生成结果不符合预期时，一次只调整一种问题，例如“把两个提取节点改为并行”“把审查节点改由测试 Waker 执行”或“新增发布前人工确认”。同时改动节点、输入和输出会增加验证难度。
WakerFlow 编辑器主要包含以下区域：
画布用于理解结构，脚本是实际执行定义。修改脚本后要再次检查画布和运行表单，确认三者仍然一致。
只把每次运行会变化的内容定义为输入字段。每个字段应包含清晰名称、类型、说明、是否必填和必要的默认值。
输入字段修改后，手动运行表单和引用该流程的自主工作都可能受影响。上线后的字段变更应逐一检查调用方。
多个 Waker 使用同一目录时，明确一个主要修改者，其余 Waker 只做分析或评审。否则并行节点可能覆盖同一文件。一个阶段内可以包含多个并行 Waker 节点；需要汇总时，把汇总放在后续阶段，不要让多个节点同时改最终文件。
最终
对象或数组类型的输入必须是合法 JSON。字段缺失、格式错误或类型不匹配时，页面会阻止提交或提示校验失败。
运行中可按以下状态判断下一步动作：
首次测试至少覆盖：正常输入、空值或缺失字段、异常输入、人工确认和一个 Waker 节点失败的情况。
运行详情中的信息用途不同：
配置摘要不是完整输入，业务日志也不是完整输出。要确认输入时看运行配置；要交付时看最终结果和实际产物；要定位节点问题时打开 Waker 对话。
等待输入不是失败。流程可能正在等待人工确认或必填信息。只有节点显示失败或流程终止时，才按错误定位。
「终止」只停止后续执行，不会撤销已经写入的文件、已经发送的消息或已经完成的外部操作。终止前先判断是否需要人工清理或回滚。
「重试」可能复用本次运行中已经完成的节点。只修复了临时故障且输入、脚本均未变化时可以重试；如果修改了输入、流程脚本或节点配置，应重新发起一次运行，避免沿用旧结果。
建议从首个异常节点开始：
流程脚本可能捕获节点错误并继续执行，因此总状态会显示“已完成”，同时标记“含 N 个失败”。这表示工作流引擎已结束，不表示所有业务步骤成功。验收时应同时检查总状态、失败计数、最终返回值和实际产物。
打开失败的 Action 节点后，重点核对节点名称、错误摘要、错误详情、输入参数和可用输出。Waker 节点或子流程中的失败也可能计入总数；如果页面没有完整节点详情，继续打开对应 Waker 对话或子流程执行记录。
失败的 Action 节点提供「基于该失败优化工作流」时，可以用它把节点错误和运行上下文带入编辑聊天。该操作只会预填一份优化请求草稿，不会自动发送或修改流程：
每次重要修改后保存一个可识别版本，并在说明中记录修改目的。
切换到「执行记录」后，左侧画布显示本次运行中每个阶段和 Waker 节点的状态，右侧运行记录按时间列出手动或自动运行。
WakerFlow 可以作为自主工作的执行对象。创建定时、事件或 API 触发时选择「运行 WakerFlow」，并为每个流程输入配置固定值或触发字段映射。
本页负责流程结构、输入输出和失败诊断；触发时机、运行限制和 API 接入方式在 《自主工作》 中配置。
上线前先手动运行成功，再用真实触发方式进行一次小范围验证。流程存在人工确认节点时，自动触发后会停在确认处，不会绕过人工决定。
什么时候使用 WakerFlow
| 工作方式 | 适合场景 | 主要特点 |
|---|---|---|
| 单 Waker 对话 | 任务仍在探索，需要频繁追问和调整 | 最灵活，先验证任务是否可行 |
| Group | 多位 Waker 围绕同一目标协作，由 Leader 动态分工 | 适合开放式协作和持续讨论 |
| WakerFlow | 阶段、依赖、输入和输出需要固定，多次运行应保持一致 | 执行路径明确，可并行、分支和保留人工确认 |
| 自主工作 | 一项稳定任务需要定时、事件或 API 触发 | 负责何时启动；执行对象可以是 Waker 或 WakerFlow |
打开 WakerFlow
入口： 左侧导航 →「能力与资源」→「WakerFlow」。列表页用于新建流程、查看参与的 Waker、打开已有流程和维护自动触发。
创建流程
- 点击「新建 WakerFlow」，进入空白画布。
- 在对话面板说明流程目标、每次运行需要提供的输入、处理阶段、Waker 分工、异常处理、人工确认和最终输出。
- 系统根据描述生成流程脚本、阶段和 Waker 节点。生成期间不要重复提交同一要求。
- 生成完成后重命名流程，并补充能说明适用范围和不适用范围的描述。
- 在画布中核对阶段顺序、并行关系和每个节点绑定的 Waker，再切到脚本和运行配置检查输入输出。
- 保存后执行一次手动测试；不要在首轮验证前添加自动触发。
理解编辑器
WakerFlow 编辑器主要包含以下区域：
| 区域 | 用途 |
|---|---|
| 画布 | 查看阶段、Waker 节点、并行关系和依赖 |
| 脚本 | 查看和编辑流程定义、输入输出及执行逻辑 |
| 对话面板 | 用自然语言创建或修改流程，查看生成过程 |
| 运行配置 | 查看手动运行需要填写的字段 |
| 版本历史 | 比较、恢复已经保存的流程版本 |
| 执行记录 | 查看每次运行的输入、节点状态和结果 |
修改已经生成的流程
- 点击阶段或 Waker 节点后，在对话面板写清要修改的对象和结果，例如“只调整阶段 02，把审查结论传给阶段 03”。
- 需要修改全局结构时，说明哪些阶段保留、哪些节点新增或删除，以及输入输出是否保持兼容。
- 直接编辑脚本后，先确认页面没有解析错误，再检查画布、运行配置和最终
return。 - 每次完成一组可验证的改动就保存版本，不要在一个未验证版本中连续堆叠多轮调整。
配置运行输入
只把每次运行会变化的内容定义为输入字段。每个字段应包含清晰名称、类型、说明、是否必填和必要的默认值。
| 配置 | 建议 |
|---|---|
| 字段名 | 使用稳定的英文标识，避免后续自动任务映射失效 |
| 显示说明 | 写清用户需要输入什么、格式是什么 |
| 必填 | 缺少该值就无法完成流程时设为必填 |
| 默认值 | 只用于安全、长期不变的值 |
| 敏感数据 | 不要把 Token、密码或客户隐私设为普通默认值 |
配置阶段和 Waker
- 阶段： 用于表达流程所处的业务步骤，例如“收集信息”“分析”“生成报告”。
- Waker 节点： 执行具体工作的节点。每个节点都应绑定一位职责清晰、当前环境可用的 Waker，并写明该节点的输入、任务和交付物。
- 并行： 互不依赖的工作可以并行，例如同时提取结论和待办。
- 串行： 后一步依赖前一步结果时按顺序执行。
- 分支： 根据结构化条件选择路径，并提供默认和异常处理。
- 人工确认： 在代码合并、发布、删除、外发或其他关键动作前暂停并请求决定。
| 项目 | 检查内容 |
|---|---|
| 节点名称 | 能否一眼看出这一步产出什么 |
| 任务说明 | 是否引用了需要的流程输入和上游结果 |
| 执行 Waker | 职责、运行设备和可用状态是否匹配 |
| 工作目录 | 是否包含正确项目，多个节点是否会并发写同一文件 |
| 交付给下游的结果 | 是否足够结构化，后续阶段能否直接使用 |
定义输出
最终 return 应返回业务使用者真正需要的结果，而不是只返回内部日志。
推荐包含：
- 业务结论或结构化字段。
- 生成文件、页面或外部对象的可访问位置。
- 验证结果、未解决问题和需要人工处理的事项。
return 最终结果。没有显式返回值时，运行仍可能显示成功，但最终结果可能是 null；需要交付的内容不能只写在业务日志里。
手动运行
- 点击「运行」。
- 在运行表单中填写必填字段，检查默认值是否适用于本次运行。
- 确认流程中的 Waker、项目、模型和连接器均可用。
- 启动后切换到「执行记录」，查看当前阶段和节点状态。
- 出现人工确认时，阅读流程提供的上下文、影响和选项，再提交决定。
- 运行结束后查看最终结果，并打开实际产物验收。
| 状态 | 含义 | 下一步 |
|---|---|---|
| 排队中 / 运行中 | 任务已创建并正在推进 | 长时间不变化时检查当前节点和服务状态 |
| 等待输入 | 正在等待人工回答或确认 | 打开运行详情并提交答案，不要当作失败处理 |
| 已完成 | 流程脚本已结束 | 验收最终结果、字段和实际产物 |
| 已完成 · 含 N 个失败 | 流程已结束，但一个或多个节点曾失败或返回失败结果 | 打开失败节点检查详情；不能只按“已完成”验收 |
| 失败 / 已终止 | 节点出错或运行被取消 | 从首个异常节点定位原因，修复后再运行 |
理解配置摘要、业务日志和最终结果
运行详情中的信息用途不同：
| 信息 | 来源 | 是否完整 | 用途 |
|---|---|---|---|
| 运行配置 | 启动时提交的字段和默认值 | 是 | 复现本次运行输入 |
| 配置摘要 | 系统从运行配置提取的概览 | 可能概括或截断 | 快速核对关键设置 |
| 节点状态 | 工作流引擎 | 反映执行状态 | 定位进行中、等待、成功或失败 |
| 业务日志 | 流程或 Waker 主动输出 | 只包含主动记录的内容 | 展示业务进展和关键判断 |
| Waker 对话 | 实际 Waker 聊天 | 包含该节点上下文 | 排查任务输入、工具调用和回复 |
| 最终结果 | 流程脚本的返回值 | 是正式返回 | 交付本次运行结果 |
处理等待和失败
等待输入不是失败。流程可能正在等待人工确认或必填信息。只有节点显示失败或流程终止时，才按错误定位。
「终止」只停止后续执行，不会撤销已经写入的文件、已经发送的消息或已经完成的外部操作。终止前先判断是否需要人工清理或回滚。
「重试」可能复用本次运行中已经完成的节点。只修复了临时故障且输入、脚本均未变化时可以重试；如果修改了输入、流程脚本或节点配置，应重新发起一次运行，避免沿用旧结果。
建议从首个异常节点开始：
- 检查该节点收到的输入是否正确。
- 检查该节点绑定的 Waker 是否启用、设备是否在线。
- 检查工作目录、Skill、连接器和权限。
- 检查脚本分支是否覆盖当前输入。
- 修复后用同一组测试输入重新运行。
识别“已完成但含失败”
流程脚本可能捕获节点错误并继续执行，因此总状态会显示“已完成”，同时标记“含 N 个失败”。这表示工作流引擎已结束，不表示所有业务步骤成功。验收时应同时检查总状态、失败计数、最终返回值和实际产物。
打开失败的 Action 节点后，重点核对节点名称、错误摘要、错误详情、输入参数和可用输出。Waker 节点或子流程中的失败也可能计入总数；如果页面没有完整节点详情，继续打开对应 Waker 对话或子流程执行记录。
从失败节点快捷优化
失败的 Action 节点提供「基于该失败优化工作流」时，可以用它把节点错误和运行上下文带入编辑聊天。该操作只会预填一份优化请求草稿，不会自动发送或修改流程：
- 先阅读草稿中的失败节点、错误和运行引用，删除不应带入的敏感输入。
- 补充期望行为、允许修改的阶段和验收条件。
- 发送后审阅生成的修改，保存为新版本。
- 使用同一组输入重新运行，并对比失败节点和最终产物。
使用版本历史
每次重要修改后保存一个可识别版本，并在说明中记录修改目的。
- 小改动后运行固定回归样例。
- 输入输出结构变化时检查所有自主工作和外部调用。
- 回滚后重新绑定可能已经删除或更换的 Waker、项目和连接器。
- 不要把版本历史当成运行记录；版本历史记录配置，执行记录记录任务运行。
根据执行记录继续优化
切换到「执行记录」后，左侧画布显示本次运行中每个阶段和 Waker 节点的状态，右侧运行记录按时间列出手动或自动运行。
- 先选择要分析的那次运行，不要默认只看最新一次。
- 从第一个失败或等待异常的 Waker 节点开始，打开节点结果和对应对话。
- 对比运行配置、配置摘要、业务日志和最终结果，判断是输入、节点任务、资源还是流程结构问题。
- 整体结构需要调整时点击「基于此次运行优化工作流」；单个 Action 节点失败时优先从节点详情使用快捷优化。两种入口都会先生成可编辑草稿，不会自动提交修改。
- 保存为新版本，用同一组输入重新运行，对比修复前后的节点状态和最终产物。
配置自动触发
WakerFlow 可以作为自主工作的执行对象。创建定时、事件或 API 触发时选择「运行 WakerFlow」，并为每个流程输入配置固定值或触发字段映射。
本页负责流程结构、输入输出和失败诊断；触发时机、运行限制和 API 接入方式在 《自主工作》 中配置。
上线前先手动运行成功，再用真实触发方式进行一次小范围验证。流程存在人工确认节点时，自动触发后会停在确认处，不会绕过人工决定。
上线与维护检查
- 名称、说明、输入和输出能够让新使用者理解。
- 每个 Waker 节点只承担清晰职责，执行 Waker 和资源均可用。
- 并行节点不会同时覆盖同一文件或外部对象。
- 高风险动作有人工确认和可执行的回滚方案。
- 正常、异常和空输入均已测试。
- 修改输入、脚本、Waker、连接器或权限后重新完成回归运行。