## 让 AI 帮你发布、运行、停止和排障

<!-- slot: 目标 -->
### 本章目标

看懂 Workflow 之后，下一步通常是把草稿变成可用版本、发起一次运行，并在等待或失败时决定怎么处理。你不需要记住后台命令，但必须让 AI 把“准备做什么、将影响谁、动作是否真的被接受”讲清楚。

学完本章，你将能够：

- 让 AI 区分草稿检查、发布、启动运行和停止请求，不把它们混成一个动作。
- 判断普通 Workflow 可以直接发布，还是由 Team 管理的可复用 Workflow 必须等待 Owner 审批。
- 在启动前确认精确版本、业务输入、通知位置和人工责任。
- 用发布编号、运行编号、状态和时间等可核验信息判断动作结果。
- 遇到等待、失败或停止时，先区分有回执的动作、Agent 声明和未知结果，再选择安全的下一步。

<!-- slot: 边界 -->
### 适用边界

- **覆盖**：通过对话发布当前草稿、启动一次手动运行、查看进展、请求停止和处理常见异常。
- **不覆盖**：让读者执行后台命令、阅读配置代码；定时自动运行已在第 9 章说明。
- **假设**：你已经用第 16 章的方法唯一定位 Workflow，并知道本次运行的业务目标。

发布、运行和停止是三个独立动作。发布成功不会自动启动运行；启动运行也不会自动采用以后新改的草稿。每次运行都会固定它启动时所选的已发布版本，所以后续发布新版本不会中途改变这次运行。

停止也不是“撤销”。只有当外部写入已经越过分发边界、但回执尚未收敛时，服务端才会拒绝停止：例如写入正处于分发中，或已经尝试分发却因响应丢失而等待稳定重试。消息已经送达并等待 Agent 回调时，运行仍然可以取消；一旦接受，这次运行会直接进入“已取消”终态，阻止后续编排，后到回调也不会继续推进它。

取消不会召回已经送达的消息，不会强制 Agent 停止手头工作，也不会撤销已经完成的建单或其他外部结果。团队仍要根据动作证据判断哪些结果需要人工撤回或补偿。

<!-- slot: 流程 -->
### 从草稿到一次可核验的运行

继续使用“每周项目风险汇总”。这一次，你准备发布已经检查过的草稿，并用本周项目更新发起运行：

![发布与运行主路径：AI 先展示发布行动卡，由人确认发布；Human / Desktop 对普通 Workflow 执行 immutable creator guard，当前 Agent CLI 不比较 member 与 creator，Team Workflow 等 Owner 审批；只有取得可核验的精确版本后，才再由人确认是否启动运行](../../media/chapters/fig-17-01-publish-and-run.svg){#fig-17-publish-and-run width=96%}

主路径有两次不同的人工确认：第一次决定是否发布，第二次决定是否真的创建运行；如果之后要求停止，还需要另行确认。即使你在一开始说“帮我发布并运行”，AI 也应分别展示发布对象和运行输入，避免把一次模糊同意扩大成两个高影响动作。

“等待”不是失败。它可能表示正在等指定 Agent 提交，或等审批人决定。AI 可以解释当前代表性的步骤，但在并行流程中，这不一定是全部正在进行的工作，不能把一张状态卡当成完整执行清单。
Team 发布提案在 Owner 通过前还不是新版本。如果此前已有批准版本，旧版本可能仍可运行；它不能被当成本次待审批内容，也不能用来证明新内容已经发布。

停止属于另一条运营路线。只有人看过动作证据并确认后，AI 才提交停止请求；能否停止由服务端在提交时决定：

![停止与恢复路线：人提出停止，AI 分级展示动作证据，人确认后 AI 提交请求；服务端可取消已送达并等待 Agent 回调的运行，只有外部写入可能已发生而回执尚未收敛时才拒绝；取消不召回消息、不强制 Agent 停工、不撤销外部结果，后到回调也不再推进已取消运行](../../media/chapters/fig-17-02-stop-and-recover.svg){#fig-17-stop-and-recover width=96%}

<!-- slot: 提示词 -->
### 复制这段运营提示词

把方括号替换为真实信息，最好提供页面链接而不是只写名称：

```text
请帮我安全地发布并运行下面这个 Workflow。所有后台操作由你完成，但每个高影响动作都要先等我明确确认。

Workflow 页面链接：[链接]
本次业务目标：[要得到什么结果]
本次运行输入：[时间范围、项目、member_ref / role_code 或其他必要受控令牌；不要写原始姓名]
结果发到哪里：[频道、任务或其他接收位置]
谁可以确认发布：[Human / Desktop 中普通 Workflow 的 immutable creator，或 Team Workflow 的 Team Owner 角色代号]
新版本是否成为以后默认选择：[是 / 否 / 待确认]
谁负责运行中的业务审批：[member_ref / role_code]
何时应该考虑停止：[明确条件]

请按下面顺序处理：
1. 先唯一定位 Workflow；遇到同名、链接失效或无权限就停止，不要猜。
2. 重新读取当前草稿和管理关系，说明你本次实际读到的来源。不要根据历史消息虚构版本差异。
3. 发布前展示行动卡：Workflow 身份、当前草稿标识、是否由 Team 管理、审批路线、新版本是否成为以后默认选择、预期通知位置和主要风险。默认选择不明确时先解释影响，等我决定。
4. 普通未关联 Team 的 Workflow 在 Human / Desktop 中仅 immutable creator 可确认后直接发布；其他成员即使可见也不得修改或发布。当前 Agent CLI 没有 member→creator 比较：不要把我的自报身份或 Agent 命令成功当成 creator 授权，无法转到受支持的 Human / Desktop creator surface 时就停止。由 Team 管理的可复用 Workflow 必须按 Team ownership 提交 Owner 审批，不得绕过。
5. 普通 Workflow 从同步发布响应返回新版本的不可变 ID 和发布时间。Team 提交成功后，先返回审批请求编号和审批状态；待审批或被驳回时明确写“本次提案尚无新版本”。Owner 通过后只能报告该 Approval 的决定终态；当前公共 surface 不展示它生成的 `publishedVersionId`，不得用 Current / Default、聚合状态或时间顺序推断，更不得自动把某个版本冒充本次提案。映射未知时停止，等受支持的持久查询 surface。
6. 启动前再展示运行卡：将使用的精确已发布版本、本次输入、人工等待点和最终接收位置。再次等我确认。
7. 启动成功后返回运行编号、接受时间和当前状态。查看进展时用业务语言说明正在等谁；不要把代表性当前步骤说成全部并行工作。
8. 失败时把动作分成三类：“有平台或第三方回执可核验”“仅由 Agent 声称”“结果未知”。没有回执时只写“可能已经发生”，不得声称清单完整，也不要自动重试。
9. 我要求停止时，先按同样三类展示动作证据；等我确认后再提交停止请求。成功时返回服务端的“已取消”终态和取消时间，并说明取消不召回已送达消息、不强制 Agent 停工、不撤销外部结果，后到回调也不会继续推进这次运行。消息已送达并等待 Agent 回调时仍可取消；只有外部写入可能已经发生而回执尚未收敛时，停止才会被拒绝。被拒绝时不要虚构具体外部结果，也不要自动重试。
10. 发布、提交审批、启动或停止中的任何一次请求如果没有明确响应，先核对当前版本、审批请求、运行或取消状态。无法取得可核验结果时停止并让我判断；不要把“没有回复”当作失败后重新操作。

任何时候发现草稿、审批人、输入或接收位置在我确认后发生变化，都停止并请我重新确认。
```

这段提示词的重点不是让 AI 多问问题，而是为发布、运行和停止各建立一道清楚的确认边界。

### AI 和人分别做什么

| 角色 | 负责什么 | 不能代替谁 |
| --- | --- | --- |
| 你 | 提供业务输入、接收位置和停止条件；确认行动卡 | 不需要处理后台命令 |
| AI 助手 | 重新读取状态、展示行动卡、执行已确认动作、翻译状态 | 不能扩大授权，也不能把自述当成功证据 |
| Team Owner | 决定 Team 管理的可复用 Workflow 是否发布 | 不能被发起人或 AI 绕过 |
| 运行中的审批人 | 对本次业务内容通过或驳回 | 不决定 Workflow 是否成为团队版本 |
| 指定 Agent | 完成分配给它的工作并按约定提交 | 不替业务审批人拍板 |

<!-- slot: 配置 -->
### 行动前只看两张卡

发布前，让 AI 展示一张**发布行动卡**：

1. **唯一身份**：页面链接、所属范围和当前草稿标识。
2. **管理关系**：普通未关联 Team，还是由 Team 管理。
3. **发布路线**：Human / Desktop ordinary creator guard、当前 Agent CLI 的授权缺口，还是提交 Team Owner 审批。
4. **可见影响**：谁以后可以使用这个版本，本次是否把它设为以后默认选择。
5. **变更保护**：如果草稿在确认后又被修改，停止并重新确认。

“是否成为默认选择”没有答案时，AI 必须先解释：以后未明确指定版本的运行可能会受这个选择影响，然后等待人决定。

启动前，再展示一张**运行行动卡**：

1. **精确版本**：本次运行固定使用哪个已发布版本。
2. **业务输入**：项目、时间范围、`member_ref` / `role_code` 等受控身份是否完整；原始姓名不进入 authoring / runtime payload。
3. **人工等待**：运行中可能等待哪个 Agent 或审批人。
4. **最终去向**：消息、报告或任务会发到哪里。
5. **停止影响**：哪些外部可见动作发生后无法靠停止撤销。

卡片有任何一项不清楚，都不要把“继续”理解为同意。

<!-- slot: 审批 -->
### 三种人工决定不要混在一起

1. **发布决定**：Human / Desktop 对普通未关联 Team 的 Workflow 校验创建时冻结的 immutable creator；当前 Agent CLI 未实施 member→creator 比较，不能作为等价授权 surface。由 Team 管理的可复用 Workflow 必须按 Team ownership 由 Owner 审批。
2. **运行决定**：启动一次运行会消费本次输入，并可能发送通知或创建外部结果，应由发起人确认精确版本和影响范围。
3. **流程内决定**：运行到人工审批点后，由指定业务审批人决定通过或驳回。

停止是第四种运营决定。AI 应先把动作证据分成“已核验、仅有 Agent 声明、结果未知”，再由人确认是否提交停止请求。它不能因为检测到失败、等待过久或用户暂时离线就自行停止。消息已送达并等待 Agent 回调时，服务端仍可接受取消；只有外部写入越过分发边界而回执未收敛时才会拒绝。被拒绝后应等待稳定重试或回执把结果收敛，再次取得人的决定。

<!-- slot: 异常 -->
### 看到这些情况时怎么处理

| 你看到的现象 | 先判断什么 | 安全的下一步 |
| --- | --- | --- |
| 确认后提示草稿已变化 | 可能有其他人并发修改 | 重新读取并展示新的行动卡，不覆盖对方修改 |
| Team 提交后没有新版本 | 本次提交只是待 Owner 决定的提案 | 核对审批请求编号和状态；旧批准版本即使可运行，也不能冒充本次新内容 |
| 运行一直显示等待 | 可能正在等 Agent 或业务审批人 | 说明当前等待责任和团队约定时限，不默认通过 |
| 状态卡只显示一个当前步骤 | 并行工作可能没有全部显示在这张摘要里 | 结合运行记录说明已知事实，不宣称它是完整清单 |
| 发布、审批提交、启动或停止没有明确响应 | 网络中断不等于请求失败 | 先核对对应版本、审批请求、运行或取消状态；无法核实时停止并请人判断 |
| 运行失败 | 某一步无法继续，或走到设计好的失败结束 | 分级列出动作证据、失败位置和可选恢复方式，由人选择 |
| 消息已送达，运行正在等 Agent 回调 | 送达后的等待不属于不可取消的分发窗口 | 人确认后仍可请求停止；接受后不召回消息或强制 Agent 停工，后到回调不再推进运行 |
| 停止请求因写入回执未收敛而被拒绝 | 外部写入正处于分发中，或已尝试分发后因响应丢失而等待稳定重试 | 等重试或回执收敛，核对结果后再次请人决定；不要猜写入是否已经成功 |
| 运行已显示“已取消”，但外部结果仍存在 | 这些结果在取消前已经完成 | 不把取消当成撤销；按需要人工撤回或补偿 |
| 运行已经成功或失败 | 它已经是终态 | 不再发送停止请求；需要重做时创建一次新的、可识别的运行 |

排障顺序始终是：先找唯一运行 → 确认精确版本 → 区分已核验动作、Agent 声明和未知结果 → 判断正在等谁 → 最后决定重试、停止还是人工补偿。

### AI 应该返回哪些可见结果

每次发布或提交审批后，结果卡至少包含：

| 项目 | 应显示什么 |
| --- | --- |
| Workflow 身份 | 页面链接与所属范围 |
| 发布路线 | 直接发布，或 Owner 审批及其结果 |
| 审批回执 | Team 提案的审批请求编号和审批状态；普通直接发布不需要此项 |
| 新发布版本 | 普通直接发布显示同步响应里的不可变版本 ID 和发布时间；Team 审批只能显示 Approval 决定终态，当前公共 surface 的 Approval→版本映射写“未知”，不得推断 ID |
| 既有版本 | 若旧批准版本仍可运行，明确它不是本次新内容 |
| 动作结果 | 普通直接发布可写“已发布”；Team 写已批准、待审批、被驳回或失败，并把“批准”与“已取得精确版本映射”分开 |
| 下一步 | 普通直接发布可在核对同步版本 ID 后启动；Team 映射未知时等待受支持的查询 surface，或按驳回意见修改 |

运行开始后，结果卡至少包含：

| 项目 | 应显示什么 |
| --- | --- |
| 运行身份 | 可核验的运行编号和接受时间 |
| 固定版本 | 这次运行实际使用的已发布版本 |
| 输入摘要 | 本次项目、时间范围和接收位置 |
| 当前责任 | 正在执行、等待 Agent、等待审批人或已经终止 |
| 动作证据 | 分列有回执可核验、仅由 Agent 声称和结果未知；不得宣称是完整清单 |
| 安全下一步 | 继续等待、人工处理、停止、补偿或新建运行 |

停止结果卡要么给出服务端返回的“已取消”终态和取消时间，要么明确写出停止因外部写入越过分发边界、回执尚未收敛而被拒绝。消息已送达并等待 Agent 回调不是停止冲突；若此时取消成功，结果卡还要写明消息不会被召回、Agent 不会被强制停工、外部结果不会自动撤销，后到回调也不会继续推进已取消运行。外部动作仍按“已核验、仅有声明、结果未知”分列；停止冲突不能证明具体外部结果。只有 AI 的一句“已经停止”不能代替这些可核验状态。

<!-- slot: 外部系统 -->
### 外部系统

本例的可见动作仍是向 Loop 项目频道发送摘要。若运行中的 Agent 还会建外部工单、更新代码托管状态或调用其他系统，启动卡必须提前列出这些动作。

停止 Workflow 不会自动撤销外部系统中的结果。即使运行在消息已送达、等待 Agent 回调时成功取消，平台也不会召回消息或强制 Agent 停工；它只保证后到回调不再推进已取消运行。第 18 章会先说明如何让已授权 Agent 接收代码托管活动并通知团队；后续章节再讨论对外动作的重复保护、对账和补偿。

### 业务收益怎样衡量

选择一项每周真实运行的 Workflow，连续记录至少四周或八次发布与运行操作：

- 从“准备发布”到拿到可用版本所需时间。
- 因版本、输入或接收位置确认不清造成的误运行次数，目标为 0。
- 等待超过团队约定时限后，能在 10 分钟内找到责任人的比例。
- 失败后在重试前完成动作证据分级的比例，目标为 100%。
- 停止后需要人工撤回或补偿的结果数量，是否逐步下降。

样本不足时只保留记录，不宣称已经达到 0% 或 100%，也不判断趋势。这些指标衡量的是团队运营是否更清楚，不是平台自动承诺的服务等级。

<!-- slot: 验收 -->
### 如何判断这套方法可以投入日常使用

- [ ] 发布、启动运行和停止都分别等待明确确认，不用一次模糊同意覆盖多个动作。
- [ ] 能区分普通未关联 Team 的直接发布与 Team 管理 Workflow 的 Owner 审批。
- [ ] 每次运行都能说明实际使用的精确已发布版本。
- [ ] 发布后有不可变版本 ID，启动后有运行编号、接受时间和状态，而不是只有 AI 自述。
- [ ] 等待时能指出责任角色；代表性当前步骤不会被误解成完整并行清单。
- [ ] 失败或停止前会区分有回执、仅有 Agent 声明和未知结果，不盲目重试，也不承诺自动撤销外部结果。
- [ ] 能区分写入回执未收敛的停止冲突与已送达等待 Agent 回调的可取消状态，并说明取消不召回消息、不强制停工、不撤销外部结果。
- [ ] 团队能用耗时、误运行、责任识别和补偿数量衡量收益。

<!-- slot: 媒体槽位 -->
### 媒体槽位

<!-- media: fig-17-01-publish-and-run.svg -->
图 17-1 两张行动卡：发布前确认管理关系与审批路线，运行前确认精确版本、输入和接收位置。

<!-- media: fig-17-02-stop-and-recover.svg -->
图 17-2 停止与恢复卡：已送达等待回调仍可取消、写入回执未收敛时发生冲突，以及哪些既有结果需要人工补偿。

### 小结

用 AI 运营 Workflow 的关键，不是把所有动作压缩成一句“帮我跑一下”，而是让发布、运行和停止各自有明确对象、人工确认和可核验结果。每次运行固定精确版本；等待时说明责任；失败或停止时先区分有回执、仅有声明和未知结果。这样才能在降低操作门槛的同时，保留业务可控性。

下一章会把同样的方法用于代码托管活动：让已授权 Agent 接收事件、筛选高信号变化并通知团队，而不是让订阅直接替你启动 Workflow。