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