副作用：通知、Webhook 与写回

副作用：改完之后向外发生的事

Action 改完对象，有时还要做两件事：告诉某个人，或者让另一个系统知道。这些不是对象上的修改，叫副作用：数据被送出了 Semantic。副作用有两类，通知与 Webhook。

副作用不在 Action 的事务里。事务保证的是对象上的编辑要么都成、要么都不成；通知发不出去，或外部请求失败，对象上的编辑仍可能已经生效。

通知

示例工厂里，暂停工单要通知质量负责人：人需要知道，但不必改任何数据，这是通知最典型的用法。收件人可以是固定的一批人、参数里指定的人，或对象属性里存的人；每人单独收到一份，而且只有看得见其中数据的人才会收到。

通知在所有编辑落地之后发出，但正文里引用的对象数据是编辑之前的状态。要让收件人看到最新状态，就在通知里带上对象的链接。

通知当前用模板渲染，不能用 Function 生成正文，也不能把组直接作为收件人。标题最多 250 个字符，正文最多 1,000 个字符，超长截断。缺省只要有一个收件人不合格，整个 Action 就不执行。配 notificationSettings.renderingSettings 为 anyNotificationRenderingCanFail，可以只发给合格的人。

Webhook：写回型与副作用型

写回型只保证一个方向：外部请求失败，Semantic 里就一个字也不改。反过来不成立：外部请求成功了，Semantic 里的修改仍可能失败，两边并不是一个事务。还有一条相关的规定：含外部调用的 Action 默认不自动重试，免得把同一个请求发两遍。

在 AIDC 里：配置通知与 writeback

ERP、MES、OA 缺省只读。Action 的改动落在 Semantic，下一次同步不会冲掉它。receive-material 可以只改本体（Ontology）里的采购订单和物料，也可以配置 writeback webhook 调用 ERP 的收货接口。源系统先接受，语义层才提交改动。

暂停工单可以直接在 Action 里配邮件通知。也可以用 Automate 监听 workOrder 变成 paused 后发邮件。下面保留后一种写法，展示应用清单里的 workflow 节选：

"workflow": {
  "input": { "work_order_no": { "type": "text", "required": true } },
  "trigger": {
    "change": {
      "type": "workOrder",
      "when": "=object.status == 'paused'",
      "cooldown": "1h",
      "input": { "work_order_no": "=object.workOrderNo" }
    }
  },
  "steps": [
    {
      "id": "mail",
      "kind": "notify",
      "title": "工单已暂停",
      "to": ["quality-lead@example.com"],
      "subject": "工单 {{ input.work_order_no }} 已暂停",
      "body": "请到 Semantic 里查看暂停原因。",
      "dedupe": "=input.work_order_no",
      "cooldown": "6h"
    }
  ]
}

notify 有几条规矩：收件人写死在清单里，最多 5 个，必须是本公司的账号（示例邮箱要换成真实账号）；dedupe 相同的通知在 cooldown 内只发一次；预演（preview）只给出内容，不真发。

副作用讲完了。下一节回到对象本身：一次修改留下哪些记录，出了错怎么查、怎么纠。