无人值守的治理

没有人盯着时，是谁在动手

标准模型的规则很清楚：条件的评估用所有者的权限，Action 与模型逻辑效果以所有者的身份执行，通知按每个收件人自己的权限。所有者的账号被停用或删除，效果就不再运行。为了不依赖个人，可以让一个应用的服务用户当所有者：人员变动时自动化照跑，历史与权限跟着服务用户走。

组织级自动化有 owner：最后一次保存条件或效果的人。效果按其当前权限执行。应用工作流则以「提供方应用 × 成员角色」执行，只能使用提供方登记的类型和 Action。两者的执行身份不同。

下面的例子是应用工作流。它不能借用某个人的权限，只能用应用登记的能力。起草与批准应分开登记；要强制批准由人执行，还要让批准 Action 检查 authorKind 等于 human。两个应用的 semantic 段如下：

{
  "factory-ops": { "semantic": { "types": ["material", "purchaseOrder", "supplier"], "actions": ["create-purchase-order"] } },
  "purchasing-desk": { "semantic": { "types": ["purchaseOrder"], "actions": ["approve-purchase-order"] } }
}

自动化用 factory-ops，只能建草稿；采购员用 purchasing-desk，只能批准。自动化碰不到批准，因为它没有登记。

批准关口：把人放在对的位置

标准模型允许把模型产出的 Action 暂存成提案，等人审核后才执行。AIDC 目前还没有专门的待批准动作队列，用两样东西承担：草稿状态的对象，加一个只有人能用的批准 Action。

1. 只建草稿

   自动化写出 purchaseOrder，status 是 draft。

2. 通知采购员

   邮件带上草稿号和理由。

3. 人来批准

   采购员在 Nexus 应用或 /semantic 的 Actions 页执行 approve-purchase-order。提交条件检查 authorKind 等于 human，强制由人批准。这个条件暂时只支持 v1 接口、CLI 和 Semantic 界面；v2（OSDK）返回 403。

4. 留下记录

   批准写进 Action Log：谁、什么时候、改了什么。

关口放在草稿变订单之前。业务动作由获授权的业务角色批准；若只许人执行，Action 检查 authorKind 等于 human。本体（Ontology）提案按组织策略审核：review 只接受本组织 developer 的网页登录；yolo 还接受合格 Key，全部批准且检查通过后自动合并。

台阶的升降也是一道关口。谁决定把 ② 从「批准」升到「自动」？依据是证据：原样批准率、被改动率、事后的差错。决定的人要有名字，依据写进发布说明，也就是 aidc app publish 的 --notes。

停得下来

组织级自动化可在 Automate 暂停、恢复或手动运行。下面讨论应用工作流：它没有单独的暂停或过期开关，可用以下四种方式停下。

• 换版本：发布一个没有 trigger.change 和 trigger.schedule 的新版本，触发条件随之撤销，定时会取消登记；或用 aidc app rollback 回到更早的版本。正式发布只认开发者账号。
• 收走能力：让提供方应用发布一个不再登记那个 Action 的版本，工作流再跑到写入步骤，就会失败。
• 保险丝：计算分钟用完，数据变化与定时都不再开跑。它是被动的，而且整个应用一起停。
• 自己搭的软开关：一个小对象 automationSwitch，带 enabled 属性；每个工作流第一步读它，后面的步骤用 when 判断；人用一个 Action 改它，下一次运行就生效。这是你自己的设计，不是平台功能：运行仍会开始，仍占用计算分钟。

谁能按下「停」，本身就是治理问题。值班的人不一定是开发者：软开关的 Action 可以开放给更多角色，换版本则必须是开发者。

留痕，以及按需运行

出了事，要能回答四个问题：谁触发的，用谁的身份，改了什么，当时是哪一版规则。

最后一条，是整条路径的原则：按需运行。数据一变才做事，change 优先于轮询，定时只留给时间本身就是条件的事；没人看时不开长连接，不空转。自动化最贵的浪费，是「以防万一」而一直在跑。跑得少，要治理的也少。