每一次变更都留下名字
37 类审计事件覆盖工作流、部署、审批、权限与成员的完整生命周期。它们在变更发生的当下就被记录，而不是事后从应用日志里还原。
37 类事件，覆盖编辑、部署、审批、权限与成员，并附带操作者、时间戳和内容。
会被记录的内容
- 按工作流的变更历史 — 创建、更新、删除和部署在工作流层面被记录，节点、连线和转换脚本则逐个记录。当某个工作流行为突变时，导致变化的那次编辑在历史里，而不在谁的记忆里。
- 部署与审批轨迹 — 一次部署的完整生命周期都会被审计——已规划、已执行、已完成或已取消——它所做的各项资源变更会通过部署 ID 关联回去。审批则记录谁在何时放行了暂停中的运行。
- 访问与成员事件 — 邀请、移除、角色变更和权限变更本身就是审计事件。审计人员真正会问的问题——三月份谁能访问这个工作区、又是谁授予的——由记录回答，而不是靠一张当前状态的截图。
- 不只是成功，还有人的判断 — 当有人把一次失败标记为已知且可接受，或者动用了被锁定工作流的重试豁免，这个判断同样会被记录下来。这些是普通执行日志会彻底丢失的、需要权限且产生成本的决定。
平台能力
- 37: 审计事件类型
- 操作者 + 时间: 附加在每一条记录事件上
- 可配置: 按工作区设置的保留期
审计日志具体记录什么？
涵盖五个领域的 37 种事件类型：工作流与节点编辑、执行结果、部署、审批以及访问变更。每条事件都带有操作者、时间戳，以及描述该次变更的脱敏内容。
我能查出某个具体变更是哪次部署造成的吗？
可以。资源级事件会带上产生它的部署 ID，因此一次部署与它影响到的一切会作为一组关联记录呈现，而不是两份需要你按时间戳去对齐的独立列表。
审计历史会保留多久？
保留策略按工作区配置，提供标准和延长两种以天为单位的窗口，而执行清理的那次扫描本身也是一条被审计的事件。因此“什么在何时被删除”的记录会在删除之后依然留存。