规则驱动的流程自动化执行日志，至少要能回答四个问题：这次执行为什么发生、做了什么、结果如何、由谁负责。围绕这个目标，日志应保留标识与关联、时间与耗时、执行主体、输入与输出、结果与异常、追溯与合规六类信息。字段数量可按流程复杂度增减，取舍标准是能否凭日志还原一次完整执行。
要点总览（TL;DR）
- 规则驱动的流程自动化执行日志应覆盖六类信息：标识与关联、时间与耗时、执行主体、输入与输出、结果与异常、追溯与合规。
- 字段取舍以能否还原一次执行为标准：为什么发生、做了什么、结果如何、由谁负责，四项有一项答不上来，字段就应保留。
- 采集按触发、节点执行、结束三阶段推进，同步写主记录、异步补详情，避免日志拖慢流程本身。
- 流程负责人定字段口径，开发实现写入与脱敏，运维负责监控告警，审计与合规确定留存期限和访问权限。
- 缺少唯一标识或错误码视为日志未完成；留存期限按业务与合规要求分级确定，脱敏在写入前完成。
一份可用的执行日志先定字段清单
字段清单建议先按六类分组，再逐项确定字段名、示例值、是否必填和用途。分组的意义在于让日志同时具备三种能力：定位（这次执行属于哪个流程、哪个业务对象）、解释（规则为什么这样判定、状态如何变化）、追责（谁触发、谁处理、失败后谁跟进）。只记录成功或失败结果，无法支撑问题排查；字段过多又会让写入和维护成本失控，因此必填项应集中在还原执行所必需的信息上。
| 分类 | 字段 | 示例值 | 是否必填 | 用途 |
|---|---|---|---|---|
| 标识与关联 | 执行实例ID | EXE-20251215-000871 | 必填 | 唯一标识一次执行，串联各节点记录 |
| 标识与关联 | 流程/规则ID与版本 | RULE-APPROVAL-01，v3 | 必填 | 区分规则变更前后的执行差异 |
| 标识与关联 | 触发来源 | 状态变更、定时任务、手动触发 | 必填 | 解释执行由什么事件引起 |
| 标识与关联 | 业务对象与关联工单 | 需求单 REQ-1042 | 必填 | 从业务对象反查执行记录 |
| 时间与耗时 | 触发时间 | 2025-12-15 10:02:11 | 必填 | 确定执行起点 |
| 时间与耗时 | 节点开始/结束时间 | 10:02:12 — 10:02:14 | 必填 | 定位耗时集中在哪个节点 |
| 时间与耗时 | 总耗时、等待时长 | 总耗时 46 秒，等待审批 31 秒 | 必填 | 区分系统处理与人工等待 |
| 执行主体 | 触发人/系统账号 | 张三；svc-automation | 必填 | 明确执行发起者 |
| 执行主体 | 审批或处理人、代理关系 | 李四（代王五审批） | 条件必填 | 还原人工介入环节的责任人 |
| 输入与输出 | 关键入参快照 | 优先级=高，类型=缺陷 | 必填 | 复现判定条件 |
| 输入与输出 | 规则判定结果 | 命中规则2，跳过规则3 | 必填 | 解释为什么执行了该动作 |
| 输入与输出 | 状态流转前后值 | 待处理 → 审批中 | 必填 | 核对业务状态是否按预期变化 |
| 结果与异常 | 最终状态 | 成功、失败、跳过、超时 | 必填 | 快速筛选异常执行 |
| 结果与异常 | 错误码与错误摘要 | E-4031，审批人缺失 | 失败时必填 | 支持分类统计与快速定位 |
| 结果与异常 | 重试次数与重试结果 | 重试2次，第2次成功 | 条件必填 | 判断失败是偶发还是持续 |
| 追溯与合规 | 日志级别 | INFO、WARN、ERROR | 必填 | 控制采集粒度与告警触发 |
| 追溯与合规 | 操作来源IP或终端 | 10.12.3.45 | 建议必填 | 支持安全审计 |
| 追溯与合规 | 留存期限、访问与导出记录 | 热存90天，归档1年 | 按制度 | 满足合规与审计要求 |
必填项的判断可以逐条自问：删掉这个字段，是否还能解释这次执行为什么发生、做了什么、结果如何、由谁负责。四项中有一项无法回答，该字段就应保留。字段命名保持稳定，规则版本变化时通过版本字段区分，避免直接改动字段含义导致历史日志无法比对。
按执行链路采集：从触发到结束的写入步骤
采集流程按触发、节点执行、结束三个阶段组织，每个阶段明确输入、动作、输出和完成标志。写入方式建议同步写主记录、异步补详情：触发时先落一条包含执行实例ID和关键标识的主记录，保证即使后续环节异常也有据可查；节点详情、入参快照等体量较大的内容异步写入，避免日志采集拖慢流程本身。
触发阶段
- 输入：触发事件、业务对象当前状态、命中的规则及版本。
- 动作：生成执行实例ID，写入触发来源、触发人、规则版本、业务对象与关联工单。
- 输出：一条可检索的主记录。
- 完成标志：凭执行实例ID能查到这次执行的起点和触发原因。
节点执行阶段
- 输入：节点入参、规则判定所需字段值。
- 动作：记录节点入参快照、判定结果、状态流转前后值、节点开始与结束时间；涉及人工审批的，记录处理人与代理关系。
- 输出：按节点排列的执行明细。
- 完成标志：每个节点的动作都能对应到具体判定依据。
结束阶段
- 输入：各节点执行结果、异常信息。
- 动作：写入最终状态、错误码与错误摘要、总耗时与等待时长、重试次数与重试结果。
- 输出：一条完整的执行记录。
- 完成标志：任一次执行都能凭日志还原全过程，包括失败原因和重试经过。
三个阶段共用同一个执行实例ID，是日志可还原的前提。若流程包含分支或并行节点，节点记录中应补充父节点或分支标识，避免明细顺序混乱。日志写入本身也应设置失败处理：主记录写入失败需要告警，详情写入失败可重试并记录补偿结果。
角色分工与交付物：谁定义字段、谁写日志、谁看日志
日志能否长期可用，取决于职责是否落到具体角色和交付物上。字段定义、代码实现、运行监控和合规管理分属不同角色，交接界面应通过文档和规范固定下来，避免字段随意增减或口径不一致。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 流程/规则负责人 | 定义关键业务字段、判定结果口径、状态流转规则 | 字段定义说明、规则版本变更记录 |
| 开发人员 | 实现字段写入、脱敏处理、错误码规范与异步补详情机制 | 日志写入代码与配置、错误码表、脱敏规则说明 |
| 运维人员 | 监控失败率、超时与重试情况，配置告警阈值 | 监控看板、告警规则、异常处理记录 |
| 审计与合规 | 确定留存期限、访问权限、导出审批流程 | 留存策略、权限矩阵、访问与导出审计记录 |
流程负责人变更规则时，应同步更新字段定义与版本号；开发人员新增字段需经过负责人确认，避免日志中出现无口径的字段。运维的告警规则应与错误码表对应，使告警能直接指向失败类型。审计角色定期抽查日志完整性与访问记录，抽查结果作为下一轮字段调整的依据。
在研发管理平台中承载自动化规则时，规则管理与执行记录可以放在同一套工作项和审批数据上。例如 ONES Automation 支持通过统一门户集中接收工单，并支持自定义处理流程与字段配置；其自动化规则由 Project 管理员在「配置中心」的「自动化规则」页面管理。规则触发后产生的状态流转和审批记录，可与工作项关联，便于按业务对象回查执行经过。具体日志字段与留存配置以产品实际能力为准。
示例：一条审批自动流转日志长什么样
以下为演示情景：某需求单优先级变更为“高”后，规则自动将其流转至审批中并通知审批人。示例仅用于说明字段填写方式，不代表任何产品的实际日志格式。
| 字段 | 填写内容 |
|---|---|
| 执行实例ID | EXE-20251215-000871 |
| 规则ID与版本 | RULE-APPROVAL-01，v3 |
| 触发来源 | 字段变更（优先级） |
| 业务对象 | 需求单 REQ-1042 |
| 触发人 | 张三 |
| 触发时间 | 2025-12-15 10:02:11 |
| 关键入参快照 | 优先级：中 → 高；模块：支付 |
| 规则判定结果 | 命中规则2（高优先级需审批），未命中规则3（低优先级自动关闭） |
| 状态流转 | 待处理 → 审批中 |
| 审批处理人 | 李四（代王五审批） |
| 节点耗时 | 流转 2 秒，等待审批 31 秒 |
| 最终状态 | 成功 |
| 错误码与摘要 | 无 |
| 重试情况 | 未重试 |
| 日志级别 | INFO |
| 操作来源 | 10.12.3.45 |
从样例可以提炼三条可迁移的规律：第一，入参快照保留变更前后的值，判定结果写明命中和未命中的规则，二者结合才能解释执行原因；第二，等待时长与系统处理时长分开记录，便于判断瓶颈在人工环节还是系统环节；第三，代理审批关系单独记录，避免责任归属只落在被代理人身上。该示例适用于规则驱动的审批流转场景，不涉及 AI 智能编排和接口对接层面的日志设计。
留存、脱敏与完成检查
留存策略按业务需要与合规要求分级。常用做法是近期日志热存，支持快速检索和问题排查；超过热存期的日志转入归档，保留查询能力但降低存储成本。留存期限由审计与合规角色结合业务影响确定，本文不给出统一数值。规则版本变更、重大故障相关的执行记录可单独标记，延长保留时间。
脱敏应在写入前完成。入参中的个人信息、账号密钥、业务敏感字段按敏感程度处理：密钥类信息不写入日志或仅保留掩码；个人信息按最小必要原则记录，必要时做哈希或部分遮蔽；业务敏感字段可只记录字段名和变更类型。脱敏规则由开发人员实现，流程负责人确认哪些字段属于敏感范围，审计角色抽查执行情况。
访问与导出同样需要留痕。日志查询、批量导出应记录操作人、时间、查询条件和导出范围，权限按角色分配，导出行为可设置审批。完成检查可按以下清单逐项核对：
- 字段齐全：六类信息均有对应字段，必填项无缺失。
- 可还原：随机抽取执行记录，能说明触发原因、执行动作、结果和责任人。
- 可检索：能按执行实例ID、业务对象、时间范围和最终状态查询。
- 权限受控：访问与导出均有权限校验和操作记录。
- 异常可告警：失败、超时、重试达到阈值时能触发告警并指向错误码。
- 脱敏有效：抽查日志内容，未出现明文密钥和超范围个人信息。
缺少唯一标识或错误码时，视为日志未完成，应先补齐再进入正式运行。其余检查项可按流程重要程度分批推进，但唯一标识、最终状态和错误码三项应在首版日志中具备。
常见问题
流程执行很频繁，全量记录入参快照会不会拖慢流程？
可以把写入拆成两层：触发时同步落一条主记录，只含执行实例ID、规则版本、触发来源、业务对象等轻量字段；入参快照、节点明细等体量较大的内容异步写入。这样即使详情写入延迟或失败，主记录仍能定位这次执行。异步写入需要配套重试和补偿记录，详情写入失败时留下痕迹，避免出现主记录存在而明细缺失却无人知晓的情况。
规则版本升级后，历史日志还能直接比对吗？
能比对的前提是日志中记录了规则ID与版本号，并且字段含义保持稳定。规则升级时新增字段可以接受，直接改变已有字段的含义会让新旧日志无法对照。建议在字段定义说明中记录每次变更的内容和生效时间，规则负责人变更规则时同步更新版本号。排查历史问题时，先按版本号确认当时生效的规则，再解读判定结果字段。
日志里的个人信息和密钥类内容应该怎么处理？
脱敏应在写入前完成，而不是查询时再遮蔽。密钥、令牌类信息建议不写入日志，或只保留掩码；个人信息按最小必要原则记录，必要时做哈希或部分遮蔽；业务敏感字段可以只记录字段名和变更类型，不记录具体值。哪些字段属于敏感范围由流程负责人确认，开发人员实现脱敏规则，审计角色定期抽查日志内容是否出现明文密钥或超范围个人信息。
失败重试多次的执行，日志应该记成一条还是多条？
建议以一次业务触发为一个执行实例，重试作为该实例内的过程记录，而不是每次重试都新开一条独立执行。日志中保留重试次数、每次重试的时间和结果，最终状态以最后一次结果为准，同时保留首次失败的错误码，便于区分偶发失败和持续失败。如果重试由新的触发事件引起，则另开执行实例，并通过关联字段指向原实例。
日志留存多久比较合适，有没有统一标准？
留存期限取决于业务影响和所在行业的合规要求，没有适用于所有团队的统一数值。常见做法是近期日志热存以支持快速检索和问题排查，超过热存期后转入归档，保留查询能力并降低存储成本。规则版本变更、重大故障相关的执行记录可以单独标记并延长保留时间。具体期限由审计与合规角色结合业务情况确定，并写入留存策略文档。
