## 建立权限、审计与运营节奏

治理不是在发布前增加一张表，也不是让所有变化都找同一个人批准。
它要把“谁能定义、谁能批准、谁能执行、谁能核验”分开，并在数据、外部副作用和故障发生时留下足够证据。

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

学完本章，你将能够：

- 为 Workflow 建立最小权限、数据分类、最小披露和职责分离规则。
- 区分 Team Workflow 发布审批与 Run 内业务审批。
- 组织上线评审、月度运营例会、故障复盘和退役决定。
- 设计不包含密钥与无关个人数据的审计证据包。

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

- **覆盖**：团队对 Workflow 的组织治理约定，以及平台已经保存的版本、运行、审批和副作用证据。
- **不覆盖**：宣称平台会自动完成数据分类、留存删除、双人复核、业务 SLA 或合规认证。
- **假设**：Workspace 与 Team 权限已经配置，外部 App 或 Extension 由管理员连接，业务 Owner 能对用途和风险负责。

平台直接强制的边界包括 Human / Desktop 对普通 Plan 的 immutable creator guard、Team-owned Plan 的 Team ownership 与不可绕过 Owner 的发布审批、精确 PlanVersion、审批 assignee、callback responder 和幂等冲突。普通 Plan 的 Workspace 可见性在 Human / Desktop 中不授予他人修改权；但当前公共 Agent CLI 的 ordinary `update` / `publish` / `archive` 尚未比较认证 Human member 与 creator，不能把该 Agent 路径写成相同的平台保证。Team-linked Plan 仍走 Team ownership，不套用 ordinary creator-only 路径。
分类等级、复审周期、双人原则和留存期限属于组织规则，必须写入清单并由人执行。

<!-- slot: 流程 -->
### 一套可持续的治理闭环

![Workflow 治理闭环：先按用途和数据分类，再分配作者、发布审批人、运行审批人、执行与恢复角色；上线冻结批准版本，运行中监控证据和反指标，月度决定保持、改版、限制或退役；事件进入隔离、核验和复盘](../../media/chapters/fig-34-01-workflow-governance-loop.svg){#fig-34-workflow-governance-loop width=96%}

建议把治理做成循环，而不是一次性门禁：

1. **分类**：写明业务用途、数据级别、外部影响和禁止用途。
2. **分权**：为创作、发布、运行批准、执行、恢复、数据和审计分别指定责任。
3. **上线**：用附录 A 检查精确批准版本、输入最小化、异常路线、证据和演练。
4. **运行**：观察等待、失败、结果不明、外部回执和反指标；高影响动作仍逐次确认。
5. **例会**：按附录 B 比较业务结果和风险，作出保持、改版、限制或退役决定。
6. **事件处置**：先停止扩大影响、保全证据、核验外部状态，再决定恢复或补偿。
7. **复审**：Owner、数据、权限、App 能力或业务规则变化时，提前触发，不等固定日期。

<!-- slot: 提示词 -->
### 复制这段治理评审提示词

```text
请对下面的 Workflow 做上线或周期治理评审。
不要假设平台会自动执行组织政策；把需要人工落实的规则明确列出。

业务用途与禁止用途：[范围]
Team Workflow 与批准版本：[名称、精确版本]
业务 Owner / 运营 Owner：[角色]
输入与数据分类：[字段、来源、级别]
外部 App 或 Extension：[用途、最小授权]
发布审批人：[Team Owner]
运行时审批人：[具体业务角色]
执行 Agent / 恢复 Owner：[角色]
留存期限与删除 Owner：[组织约定]
最近指标卡与事件：[证据位置]

请返回：角色分离表、最小披露检查、两类审批检查、异常与结果不明路线、审计证据包、上线或继续运行结论。
结论只能是“通过”“限期整改后通过”“暂停新增运行”或“退役建议”，并为每个整改项给出 Owner 和日期。
不要输出 token、密钥或完整敏感记录。
```

### 角色分离表

| 角色 | 主要决定 | 不应兼任或绕过的边界 |
| --- | --- | --- |
| 业务 Owner | 用途、风险、收益与退役 | 不用 Run 成功替代业务验收 |
| Leader / 作者 | Human / Desktop 中普通 Plan 由 immutable creator 修改和直接发布；Team Plan 的 Leader 准备草稿、解释流程、提交评审 | 当前 Agent CLI 缺少 member→creator 比较，不能当成 ordinary 授权保证；Leader 不能直接发布 Team-owned Plan |
| Team Owner | 批准冻结的可复用版本 | 不替每次业务动作作运行决定 |
| 运行时审批人 | 决定一次具体动作是否继续 | 不批准超出行动卡的对象或范围 |
| 执行 Agent | 使用当前 Catalog 的精确授权动作 | 不选择目录外能力或扩大权限 |
| 数据 Owner | 确认来源、字段、留存与删除 | 不让方便性覆盖最小披露 |
| 运营 / 恢复 Owner | 监控、核验、人工接管与补偿准备 | 不把停止 Run 当成撤销外部结果 |
| 独立复核者 | 检查证据、口径和越权事件 | 不直接改写原始审计事实 |

高风险场景可以要求更多分离，但不要把所有角色机械地交给一个管理员。
如果小团队无法完全分开，应记录补偿控制，例如第二人复核结果卡或提高抽样比例。

<!-- slot: 配置 -->
### 数据分类与最小披露

团队可以采用“公开、内部、敏感、受限”等级作为运营约定，但不要把它写成 Loop 自动识别的产品能力。
每类 Workflow 至少形成下面的字段表：

| 项目 | 必须决定 |
| --- | --- |
| 数据元素 | 哪些字段真正影响路由、审批或结果 |
| 权威来源 | 哪个系统或人签发，什么时间基准 |
| 进入位置 | Plan 输入、消息、Run 证据、结果卡或外部工具日志 |
| 最小化方式 | 删除、区间化、令牌化或安全引用 |
| 可见角色 | 谁因本次职责需要看到 |
| 留存与删除 | 具体期限、法律例外、删除 Owner 和核验方式 |
| 禁止内容 | token、密钥、完整凭据和无关个人明细 |

Plan source 不应包含凭据。调用输入和消息也不应携带 token。
需要外部能力时由 App 连接保管凭据，Agent 只看到已授权的 Extension 名称与动作。

当前产品没有针对单个 PlanVersion、Invocation、Run 或事件账本的可配置留存期限、legal hold、WORM 导出或自动清除。
归档会保留历史；删除整个 Workspace 是更大的生命周期操作，不是日常清理手段。
因此团队的留存约定必须同时写明能力限制：能在外部结果卡和导出副本上执行的删除由数据 Owner 核验；平台账本无法逐对象删除的敏感内容，应在进入 Workflow 前就删除、令牌化或改为安全引用，不能承诺到期自动消失。

### 审计证据包

一次上线、重要变更或事件复盘应能关联：

- Team Workflow 关系、Plan、精确草稿修订、冻结审批和不可变 PlanVersion。
- Invocation、Run、调用来源、执行所有者与输入快照。
- 关键 Activation、Effect、事件、审批决定和 callback 响应者。
- 外部业务意图身份、回执、权威状态与结果卡。
- 指标口径版本、例会决定、整改 Owner、截止日期和关闭证据。

证据包保存“在哪里可以核验”，不等于把所有原文复制到一个文件。
受限数据优先保留安全引用和访问记录。

<!-- slot: 审批 -->
### 两类审批要分别验收

**发布审批**冻结的是 Team Workflow 的精确 source、layout、artifact、digest、Plan / draft 修订和发布选项。Team Owner 批准后才产生新的可复用 PlanVersion。

**运行审批**由 Plan 中的 `request_approval` 发起，Effect 冻结具体 assignee 和本次业务摘要。批准或驳回只决定这次 Run 的路线。

两类审批都不能靠聊天中的模糊“可以”替代，也不能跨版本、跨对象复用。
审批长期等待没有创作期自动 SLA；提醒和升级由运营规则承担，不能把未响应解释为默认通过。

<!-- slot: 异常 -->
### 治理事件处置

| 事件 | 立即动作 | 后续决定 |
| --- | --- | --- |
| 未批准草稿被当成可用版本 | 停止新增调用，核对实际 PlanVersion | 修复入口与权限，检查受影响 Run |
| 审批人与对象不再匹配 | 让旧审批失效，不套用到新修订 | 更新 Owner 或重新提交精确内容 |
| 敏感字段进入消息或结果卡 | 限制访问并保全最小必要证据 | 由数据 Owner 按制度处置、删除和复盘 |
| 外部写入结果不明 | 停止重放，按完整意图身份读取权威状态 | 证据不足转人工；补偿另建行动卡 |
| Run 已停止但外部动作已发生 | 保留现状与回执，不宣称已撤销 | 由业务 Owner 决定保留或补偿 |
| 长期等待或失败升高 | 暂停扩大使用范围，定位版本和等待点 | 改版、降级为人工或退役 |
| Owner 离岗、App 授权变化 | 暂停更新和高影响新运行 | 重新指派、复核数据与最小权限 |

事件中先保存事实，再讨论责任。
不要让 Agent 为了补齐报告而猜测外部状态或暴露更多敏感数据。

<!-- slot: 外部系统 -->
### 外部系统的治理边界

管理员负责建立和维护 App 连接；业务 Owner 决定用途；Agent 只使用当前 Catalog 中已授权的精确 Extension。
一个外部系统连接可用，不代表所有动作都被批准。

外部写入结果以提供方权威状态和回执为准。结果不明时只有同时证明原请求未执行且不会再生效，并且动作契约明确保证同一意图可安全重放，才允许有界重试；否则人工接管。
断开连接或停止 Run 也不会自动撤销已经发生的外部结果。

### 月度运营例会

建议每月由业务 Owner 主持一次 45 分钟例会：

1. 5 分钟确认版本、Owner、数据和授权变化。
2. 10 分钟查看业务结果、流程质量、运行信号和反指标。
3. 10 分钟只讨论失败、长期等待、结果不明和人工接管。
4. 10 分钟审查待发布更新、例外请求和风险变化。
5. 10 分钟决定保持、改版、限制、暂停或退役，并写 Owner 与日期。

没有决定的指标不必长期收集。
附录 B 给出可复制议程，附录 C 给出故障证据卡。

<!-- slot: 验收 -->
### 治理验收

- [ ] 业务、创作、发布、运行审批、执行、数据、恢复和复核责任已明确。
- [ ] 发布审批与 Run 内审批分开，且都绑定精确对象和身份。
- [ ] 数据字段、来源、分类、最小化、可见角色、留存与删除 Owner 已记录。
- [ ] token、密钥和无关敏感原文不会进入 Plan、输入、消息或结果卡。
- [ ] 审计证据可关联版本、Run、关键 Effect、审批、callback 与外部回执。
- [ ] 结果不明、停止 Run、补偿和迟到审批都有明确安全边界。
- [ ] 月度例会会形成保持、改版、限制、暂停或退役决定。
- [ ] Owner、授权、数据或业务规则变化会提前触发复审。

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

<!-- media: fig-34-01-workflow-governance-loop.svg -->
图 34-1 从分类、分权、上线到监控、例会、事件处置和复审的治理闭环。

### 小结

治理的目标不是增加流程，而是让每次定义、批准、执行和恢复都有清楚的权力边界。
平台证据与组织规则结合后，团队才能在风险上升时限制使用，在价值消失时有依据地退役。

接下来的附录把上线、例会和排障整理成可以直接使用的清单与结果卡。