n8n Agents：让 AI 决定下一步，让工作流规定怎样执行

练习场景

审批页从服务端接收动作进度消息，用这些消息显示“待批准、正在执行、待确认结果”等状态。网络可能把消息重复发送或打乱到达顺序。你要设计事件归约器：把一批事件按规则变成可信显示状态。“归约”只计算状态；它不会替用户发送消息，也不会重做外部动作。

已知条件与要求

为自己的审批面板设计事件归约器，只计算显示状态，不负责发送外部请求，也不推断 n8n 内部实现。

1. 每次拟执行动作有唯一非空 operationId；动作的具体内容叫作 payload，例如要发送到哪里、发送什么文字；这些内容已由可信上游固定下来。内容改变就生成新 operationId。服务给每个操作独立产生从1开始连续递增的序号 seq。
2. 事件类型只有 proposed、approved、rejected、started、succeeded、failed、unknown、reconciled_success、reconciled_failure。proposed必须是seq=1；合法路径为proposed→approved或rejected；approved→started；started→succeeded、failed或unknown；unknown→reconciled_success或reconciled_failure。其余转移无效，末态不能再变化。failed只表示已确认未发生外部作用；超时归unknown。
3. 页面可能乱序收到事件。相同 operationId、seq 与内容重复应去重；同键不同内容要将该操作标记冲突，之后不再给它输出可信业务状态。首次发现冲突前可能已显示过旧状态，需要明确撤销其可信标记。
4. 对缺号事件先缓存；只按连续序号前进。非法转移标记冲突，不跳过错误继续归约；其他操作不受影响。重建时从空状态重放同一批事件，应得到同样的最终结果。
5. 假定整批最多 100,000 条事件，所有字段已经完成类型和大小校验。只处理实际收到的消息，不能从 1 逐个遍历到收到的最大 seq。例如只收到 seq=10 亿时，应先缓存它并等待缺失消息，而不是循环检查前面的 10 亿个序号。
6. 请说明数据结构、提交显示状态的时机、时间空间复杂度及至少三个最小反例，不写完整实现。

用这个情境检查你的方案

同一 operationId 按到达顺序收到 seq=3 started、seq=1 proposed、seq=2 approved，之后 seq=2 approved 又到一次。请说明每次页面可显示什么。再加入迟到的 seq=2 rejected：这不是普通重复，而是同一序号内容冲突，需要让用户知道旧显示已不可信。

需要交付什么

交付每个操作保存的状态、事件处理流程、允许转移表和逐事件推演。解释如何区分“还在等缺失消息”“真实结果未知”“记录冲突”；不要通过重新发送外部动作来修复显示状态。