## 把成熟做法沉淀为团队 Workflow

一个成功案例常从某位同事的临时请求开始。只有当输入、责任、异常和收益经过重复验证，它才适合成为团队可复用资产。

Loop 中的 Team Workflow 不是另一套运行时对象。它是 Team 与一个 Plan 的持久关系；获批后仍通过普通的 PlanVersion、Invocation 和 Run 执行。把它当成“团队模板”时，最重要的不是收藏数量，而是让每个资产都有 Owner、批准版本和退出条件。

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

学完本章，你将能够：

- 判断一项做法何时适合沉淀为 Team Workflow，而不是继续直接讨论或使用一次性流程。
- 组织创建、评审、首次发布、版本更新、派生和退役的完整生命周期。
- 区分可编辑草稿、冻结审批内容、已批准版本和当前仍可执行版本。
- 为每个可复用 Workflow 指定业务 Owner、运营 Owner 与复审日期。

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

- **覆盖**：Team 拥有的可复用 Workflow，以及团队围绕它建立的资产管理约定。
- **不覆盖**：把每次动态 one-off Workflow 自动收入模板库，或让未获批准的草稿参与执行。
- **假设**：Team 有固定 Leader Agent 和 Owner，创作者能进入 Team 的 Workflows 页签，且已经用真实案例验证输入与异常路线。

一个 Team 可以拥有多个可复用 Workflow。创建关系和 Plan 只形成草稿，不代表发布。
只有首次批准后的版本才可被 Leader 作为团队 Workflow 选择；后来更新正在等待批准时，旧的已批准版本仍可执行，待审草稿不能提前替换它。

<!-- slot: 流程 -->
### 从案例到可复用资产

![Team Workflow 生命周期：验证过的做法由 Leader 创建草稿，Team Owner 评审冻结内容；批准后形成不可变版本并进入使用，更新走新草稿和新审批，旧批准版继续可用；派生创建独立资产，退役取消待审并归档](../../media/chapters/fig-32-01-team-workflow-lifecycle.svg){#fig-32-team-workflow-lifecycle width=96%}

按下面的顺序管理：

1. **候选验证**：至少完成一次真实运行或受控回放，确认输入来源、人工决策、结果卡和恢复 Owner。
2. **指定 Owner**：业务 Owner 决定用途与退出条件；运营 Owner 维护证据、复审日期和故障处置。
3. **创建草稿**：从 Team 的 Workflows 页签发起，界面回到 Team Channel，并准备一条真实提及固定 Leader Agent 的草稿消息；人检查后再发送，系统不会自动发送。
4. **提交评审**：Leader 提交精确 Plan 修订与草稿修订。系统编译并冻结 source、layout、artifact、digest、申请人、审批人和发布选项。
5. **批准发布**：Team Owner 在 Approval Inbox 决定。批准发布冻结字节为新的不可变 PlanVersion；驳回进入修改状态，不发布。
6. **使用与复盘**：Leader 只能从已经批准且可执行的 Team Workflow 中选择；运行证据和业务结果进入周期复盘。
7. **更新或派生**：更新在原资产上形成新草稿和新审批；不同用途则创建独立资产，重新确定 Owner、输入与批准。
8. **退役**：Team Owner 删除 Team Workflow 时，待处理审批被取消，关联 Plan 被归档，Team 关系留下删除记录，不硬删版本和运行证据。

<!-- slot: 提示词 -->
### 复制这段资产化提示词

把方括号替换为真实信息，发给 Team 的固定 Leader Agent。它用于准备草稿，不替代 Owner 审批：

```text
请把下面这项已经验证的做法准备成 Team 可复用 Workflow 的草稿。
不要发布，也不要把一次性流程自动当成团队模板。

业务用途：[解决什么重复问题]
适用请求：[哪些请求可以选择它]
明确不适用：[哪些情况必须直接讨论或动态处理]
输入与权威来源：[字段、系统、时间基准]
业务 Owner：[member_ref 或 role_code]
运营 Owner：[member_ref 或 role_code]
必须由人决定的节点：[发布前与运行中分别说明]
结果证据：[Run 之外还要保存什么业务结果]
复审日期与退役条件：[具体日期、触发条件]

请先返回资产卡、角色表、异常表和待确认清单。
只有我确认草稿完整后，才提交给 Team Owner 审批。
若已有批准版本，说明本次是更新还是独立派生；等待批准期间不得让新草稿替换旧批准版。
```

### 资产卡应写清什么

| 项目 | 必须写清的内容 |
| --- | --- |
| 资产身份 | Team、Workflow 名称、业务用途与当前 Owner |
| 适用边界 | 可接受的请求、禁止用途和所需前置条件 |
| 输入合同 | 字段、类型、权威来源、缺失处理与最小披露 |
| 当前批准版 | 精确 PlanVersion、批准时间、审批人和语义证据 |
| 运行责任 | 调用者、运行时审批人、执行 Agent 与恢复 Owner |
| 结果证据 | Run、结果卡、外部回执和保存位置 |
| 更新策略 | 复审日期、变更触发条件和旧版本继续使用规则 |
| 退出条件 | 低使用、能力替代、风险不可接受或 Owner 缺失 |

<!-- slot: 配置 -->
### 版本、复制与派生规则

草稿可以继续编辑；已发布 PlanVersion 不在原地修改。
更新会在 Team Leader 授权下校验新的精确草稿并直接发布。编译失败不会替换最后一个已发布版本。

普通 Workspace Workflow 的复制动作会以当前草稿 source 与 layout 创建独立 Plan；它不会复制 Team 关系、审批历史、已发布版本、Schedule、Run 或外部授权。
因此团队把一个资产“复制给另一个用途”时，应把它视为派生：创建新的 Team Workflow，重新指定 Team Leader、数据边界和版本边界。不要建立“母模板更新后自动覆盖所有副本”的承诺，当前平台没有这种批量升级关系。

建议用以下规则决定更新还是派生：

- 业务目的、权威来源和主要责任人不变，只修正步骤或输入合同：更新原资产。
- 受众、数据分类、审批链或外部系统发生实质变化：创建独立派生。
- 只是一次例外请求：保持直接讨论或动态 one-off，不进入资产库。

<!-- slot: 发布 -->
### Team 发布与运行审批不是一回事

Team Leader 的直接发布回答“这份定义能否成为团队可复用版本”。它原子地校验 Team、Plan、draft 和 relation revision，编译 source，追加 immutable PlanVersion，并更新 current/default 指针；不会创建 generic Approval、pending proposal 或审批卡。

Run 内的 `request_approval` 回答“这一次具体业务动作能否继续”，仍由 Workflow Run effect 与 Run DecisionSink 负责。一个已发布的报销检查 Workflow，仍可能要求财务人员批准某一批付款；一次运行获批，也不能授权作者以后修改模板。

每次 Team 更新都会保留 source/layout、compiler digest、发布 actor 和 relation revision。已有 Run 使用启动时固定的 PlanVersion；更新 current/default 不会改写旧 Run。相同 client request 重试返回原版本，不同 payload 复用 request ID 则拒绝。

<!-- slot: 异常 -->
### 生命周期异常怎样处理

| 可见状态或现象 | 含义 | 安全处置 |
| --- | --- | --- |
| 正在生成或尚未发布 | 还没有可复用版本 | 继续完善草稿，不把它列为可执行候选 |
| 发布失败 | 没有形成新的不可变版本 | 保留草稿与旧版本，修正诊断后从同一 relation 重试 |
| 更新 revision 冲突 | 另一个调用已改变 Team/Plan/draft | 重新读取全部 revision，不要只把数字加一 |
| 已发布但仍有旧 Run | Run 固定在旧版本 | 继续按 pinned version 执行；新 Run 选择 current/default |
| Owner 离岗或职责不明 | 没人能承担 Team 发布责任 | 暂停更新，由 Team 重新指定当前 Leader |
| 已退役 | relation 留有 ownership tombstone，Plan 已归档 | 不恢复成无主资产；需要重启时按新资产创建 |

<!-- slot: 外部系统 -->
### 外部依赖也属于资产边界

资产卡只记录 App、Extension 与外部系统的用途、授权范围和证据位置，不保存 token 或密钥。
Leader 每次运行仍以当前实际 Catalog 和授权为准；模板描述不能凭空创造能力。

外部字段、权限或动作契约变化时，即使 Workflow source 没变，也要触发复审。
对高影响写入继续执行第 21 章的行动卡与结果不明门槛。

### 业务收益怎样衡量

模板库不是越大越好。每月至少观察：

- 被真实请求选择的次数，以及未被选择的资产数量。
- 使用批准资产后，准备时间和重复沟通是否下降。
- 因输入不匹配而转回直接讨论或动态处理的比例。
- 更新待审期间是否出现误用草稿、绕过审批或 Owner 缺失。
- 退役后是否仍有 Schedule、文档或团队习惯继续指向旧资产。

低使用不是自动删除理由。它可能是低频高价值流程，也可能是入口难找；由 Owner 结合风险和业务结果决定。

<!-- slot: 验收 -->
### 团队资产化验收

- [ ] 每个 Team Workflow 都有业务 Owner、运营 Owner、适用边界和复审日期。
- [ ] 创建只形成草稿；首次批准前不会被 Leader 当成可复用候选。
- [ ] 提交审批冻结精确草稿；批准后形成不可变版本。
- [ ] 更新待审时仍使用最后一个批准版，驳回不会替换它。
- [ ] 发布审批与每次 Run 的业务审批分别记录。
- [ ] 复制或派生不会继承 Team 关系、审批、Schedule、Run 或外部授权。
- [ ] 退役会取消待审、归档 Plan 并保留历史证据。
- [ ] 外部能力变化、Owner 缺失和长期未使用都有明确复审动作。

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

<!-- media: fig-32-01-team-workflow-lifecycle.svg -->
图 32-1 Team Workflow 从候选、草稿、审批、批准版本到更新、派生和退役的生命周期。

### 小结

可复用资产的核心是精确批准版本、明确 Owner 和可退出的生命周期。
草稿不等于发布，发布审批不等于运行审批，复制也不等于继承授权。

下一章将用指标卡回答：这些资产是否真的改善了业务，而不只是制造更多成功 Run。