在高风险、低置信度或需要主观判断的电商抠图场景中分割模型之外通常还要引入人工确认。检测模型会给框、标签、分数。分数不足、漏检或框选不准时继续调用模型未必能满足业务验收标准人可能需要看图、勾选或补框。问题是等待人工操作动辄几十秒到几分钟用户可能把页面切走再回来API 进程也可能在这期间重启。如果你还按传统接口来——创建任务的线程里await user.click()或者拿 HTTP 长轮询把连接挂住——Ingress 超时、worker 扩容、浏览器休眠都会把已经跑完的检测结果打回原点。模型钱花了框也没了用户刷新看到的是空白。业务侧其实只要三件事检测一结束前端立刻弹出审核面板候选框还在人离开十分钟、服务翻过一轮打开同一个任务还能接着审用户点提交之后不会因为双击、重放、版本过期把同一单推两次这篇文章以一套落地实现为例讨论如何把人审建模为显式状态、如何持久化断点、如何原子消费 pause以及何时适合或不适合超时自动推进。它是一种偏向强一致、低容错的高风险审核流程工程选择并非所有异步任务或工作流的标准答案。适用场景已有异步任务实践准备把检测、标注、内容审核这类「模型跑完还得等人」的流程接入生产链路。先说结论本文方案让执行器专注模型计算将「等人」放在控制面。若采用 Temporal、Camunda 等具备持久化等待语义的工作流引擎也可以由引擎承载等待节点关键是等待状态不能只存在于单个进程内存。人审发生在控制面。检测报告一落地控制面写候选框、创建一个 pause、把任务迁到WAITING_USER_SELECTION然后通过查询接口和 SSE 把面板推给前端。用户提交走 HTTP不走消息队列。在本文实现里pause 被持久化到 Redis而不是留在某次 API 响应或进程内存中。Redis 适合低延迟状态访问如果要求强审计、长期留存、跨区域容灾或更严格的一致性查询关系数据库或工作流引擎往往更合适。关键不是必须用 Redis而是等待态必须落到独立存储。在本文的高风险审核场景里任务从「等人」推进到「继续跑」只接受显式干预接口。对于低风险、可回滚、已获得用户授权的场景也可以配置超时默认动作但要记录策略版本、触发原因并提供补偿路径。提交要幂等pause 要一次性消费。token 对不上、版本过期、pause 已经不是 WAITING全部 409把最新快照还给前端让它重画面板。为什么不建议在普通请求里等人假设创建接口是这样的app.post(/jobs)asyncdefcreate(image):boxesawaitdetect(image)# 20sapprovedawaitwait_for_user(boxes)# 用户可能去倒杯水resultsawaitsegment(approved)returnresults这条请求在网关上挂着。Nginx 60 秒掐掉Uvicorn 一重启检测结果没地方放。更糟的是用户刷新会再开一单检测再跑一遍账单翻倍两套框对不上。异步化之后创建接口的语义变成一句话系统已经受理图片并开始检测。调用方通过job_id查询进度进入审核阶段后再获取候选框并提交选择。所以创建返回的成功指的是下单成功不是抠完了更不是人审过了。更准确地说返回成功意味着任务已被系统接收并进入可追踪状态而不是业务处理已经完成。建议响应里拆开accepted是下单status才是任务跑到哪。整体长什么样可以记这张图调用方 POST /jobs 立刻返回 job_id ▼ 控制面 写 RedisCREATED 投递 DETECT_SUBJECTS ▼ 执行器 跑检测模型 回调报告 ▼ 控制面 写 box_list 创建 pauseWAITING 状态 → WAITING_USER_SELECTION SSE 推 active_pause ▼ 调用方 看图、勾选、补框 POST /interventions ▼ 控制面 原子消费 pause 按 diff 决定下一跳 空列表 → EMPTY_SELECTION 有手工框 → 先命名校验 全是自动框 → 直接进分割 ▼ 调用方 GET /results 或 被 SSE 叫醒控制面干四件事鉴权、拥有状态、创建/消费 pause、裁决下一跳。执行器只干一件事消费节点命令、调模型、打报告。换句话说控制面拥有状态机和审核语义执行器只回传节点结果不直接决定业务终态。执行器不要sleep等人也不要自己改任务状态控制面也不应通过阻塞线程、长事务或同步 RPC 一直挂住等待人工输入。等待只能表现为被持久化的挂起状态。状态粒度取决于业务语义如果状态只有排队、检测、处理、成功、失败前端很快会遇到两个未定义问题用户提交空列表算成功还是失败手工框未通过命名是整单结束还是返回修订后来枚举长成这样CREATED DETECTING WAITING_USER_SELECTION # 第一轮等人勾选 / 补框 VALIDATING_MANUAL_BOXES # 手工框拿去命名 WAITING_BOX_BATCH_REVISION # 第二轮等人问题框重画 PROCESSING_APPROVED_SUBJECTS FINALIZING_RESULTS SUCCEEDED PARTIAL_SUCCEEDED FAILED EMPTY_SELECTION # 用户主动不抠不是故障 CANCELLED在本文迁移表中WAITING_USER_SELECTION表示控制面已暂停后续抠图节点恢复条件是收到干预、取消或已声明的超时事件。若使用“推测执行 审核后补偿”执行器可以继续生成不可见的候选产物但在审核通过前不对外提交副作用。WAITING_BOX_BATCH_REVISION是第二轮等人用户补的手工框没过命名校验要把问题框打回去而不是把整单判失败。这俩等待态看起来像一回事前端展示完全不同——一个是「请确认检测框」一个是「这几个框我没认出来请重画」。当产品需要区分「用户主动不选」与「系统失败」时可以设置独立的EMPTY_SELECTION若下游只关心是否有产物也可用终态原因码表达。前者查询直观代价是状态枚举与迁移测试更多。是否把EMPTY_SELECTION视为终态、是否计费、是否计为业务成功、以及下游是否接受空产物都应在产品语义里单独定义它不是天然的成功或失败。PROCESSING_APPROVED_SUBJECTS和FINALIZING_RESULTS也故意分开前者表示已确认主体进入模型执行阶段后者表示模型结果已经齐备正在做汇总、产物收尾、终态写入或对外投影。把两者拆开后前端能区分“还在跑模型”与“模型跑完、正在收尾”排障时也更容易判断卡在执行还是卡在汇总。对外 HTTP / SSE 就用这一套名字。架构讨论里有人把处理中统称PROCESSING、把排队叫QUEUED那是聚合态别让前端按讨论稿去switch会漏掉二次修订和空选择。用显式迁移表约束状态边界本文对非法迁移直接抛异常而不是静默修改status。在启用强制人审的工作流中检测结束要进入等待态等待态仅由提交、取消或预先声明的超时策略推进如果产品允许高置信度自动放行则应把该分支显式写进迁移表并记录命中的策略版本。allowed.put(CREATED,EnumSet.of(DETECTING,CANCELLED));allowed.put(DETECTING,EnumSet.of(WAITING_USER_SELECTION,PROCESSING_APPROVED_SUBJECTS,FAILED,CANCELLED));allowed.put(WAITING_USER_SELECTION,EnumSet.of(VALIDATING_MANUAL_BOXES,FINALIZING_RESULTS,FAILED,EMPTY_SELECTION,CANCELLED));allowed.put(VALIDATING_MANUAL_BOXES,EnumSet.of(WAITING_BOX_BATCH_REVISION,PROCESSING_APPROVED_SUBJECTS,FINALIZING_RESULTS,FAILED,CANCELLED));allowed.put(WAITING_BOX_BATCH_REVISION,EnumSet.of(VALIDATING_MANUAL_BOXES,FINALIZING_RESULTS,FAILED,EMPTY_SELECTION,CANCELLED));终态的出边是空集。迟到的执行器报告不能把CANCELLED改回处理中。current target直接 return是给幂等用的同一份报告被队列重放状态已经在目标态不要当成非法迁移。这个细节不写重试一次检测报告就能把「等人」炸成异常。几条边值得单独说检测结束进等待该业务最终选择所有候选都经一次人工确认因为样本中出现过高分误检。若模型经过概率校准且误放行成本可控也可按置信度分流。等待态提交里有新增手工框本文要求先补齐标签与target_policy再进入分割。替代方案是允许匿名框直接分割或把命名与分割并行执行代价是后续质检缺少语义约束冲突时还要废弃已生成产物。用户提交空列表走人审空选择不投递执行器。已取消额外短路哪怕目标态在允许集合里也不迁。取消检查写在领域对象里避免已经CANCELLED的任务被检测回调救活privatevoidensureNotCancelled(){if(this.statusCANCELLED){thrownewIllegalStateException(job already cancelled);}}Redis 里的 pause 才是断点不是注释进程重启后要能从等待态继续靠的不是重放整张工作流图而是几把持久化状态键job:{job_id}:meta # 当前状态、版本、停在哪个节点 job:{job_id}:pause # 为什么停、token、给前端看什么 job:{job_id}:box_list # 审核对象检测框 用户补的框 job:{job_id}:approved_box_list # 真正获准进分割的集合 job:{job_id}:idempotency # 同一 intervention_id 只生效一次pause 的形状大概是{pause_token:pause_xxx,status:WAITING,stage:WAITING_USER_SELECTION,base_version:3,snapshot_id:snap_xxx,created_at:2026-05-21T10:00:00Z}在本文 token 乐观锁协议中pause_token识别「是不是同一次暂停」提交缺少或使用过期 token 时返回 409。其他系统也可以用 ETag、工作流任务 ID、数据库行版本或审核任务租约表达同一类并发语义。base_version对齐meta.version用于发现旧快照提交。若产品采用 last-write-wins、字段级合并或 CRDT则可以接受并合并并发编辑但冲突结果要能审计。stage告诉前端现在等人的原因是选框还是改框。status至少有WAITING和CONSUMED提交成功立刻消费不等下一跳命令跑完。这里几个名字都是术语化的业务对象第一次读容易卡一下pause一次人工等待态的持久化记录包含 token、阶段和快照版本。box_list当前审核面板展示的完整候选框集合既包括模型框也可能包括用户补框。approved_box_list已经通过当前轮审核、允许进入后续执行节点的框集合。active_pause当前仍处于 WAITING 的那条人工等待记录若任务支持多审核人并行就不能只用单个active_pause。target_policy框后续处理策略例如进入分割、跳过或走特定校验分支。框数据必须持久化到独立存储不能依赖单次请求上下文或进程内存否则 API 重启后审核面板就会变空。meta.current_node_instance_id指出停在哪。等人时它通常指向刚刚完成的检测节点。提交成功后改成新生成的校验或处理节点 ID。排障时先看meta.status再看pause.status再看当前节点输入有没有写好。三者不一致才是真卡死例如 pause 已 CONSUMED 但 outbox 还是空的。这也是为什么状态写入与事件投递之间必须有一致性协议要么放在同一个原子边界如 Lua / 事务要么通过 outbox 重扫恢复保证最终一致不能只依赖“先写几个 key 再发一条消息”的顺序偶然成功。执行器不要实现「等人」节点节点类型里可以有WAIT_USER_SELECTION但它不是执行器模块。执行器只注册自己能跑的handlers{DETECT_SUBJECTS:handle_detect_subjects,VALIDATE_MANUAL_BOX_LIST:handle_validate_manual_box_list,PROCESS_APPROVED_BOX_LIST:handle_process_approved_box_list,SEGMENT_SUBJECT:handle_segment,QUALITY_GATE_SUBJECT:handle_quality_gate,REFINE_SUBJECT:handle_refine,}ifnode_typenotinhandlers:raiseNodeExecutionError(codeUNSUPPORTED_NODE_TYPE,messagefunsupported workflow node type:{node_type},retryableFalse,)未知类型不可重试。控制面如果把暂停节点误投进队列应该立刻失败而不是让执行器干等。这是契约的负向测试等人只发生在控制面。检测报告到达后控制面决定写box_list创建 pause把任务迁到等待态通过查询和 SSE 把active_pause推给前端。用户提交走 HTTP不走 command / report。对外就两个口POST /api/v1/jobs/{jobId}/interventions GET /api/v1/jobs/{jobId}/events # text/event-streamSSE 带Last-Event-ID。审核面板刷新、浏览器休眠、反向代理掐掉空闲连接前端带着上次事件 ID 重连不应丢「已经进入 WAITING」这条事实。轮询GET /jobs/{id}也能干活但面板要跟手SSE 更省。在本文单活动审核协议中active_pause.statusWAITING是展示面板的条件提交体约定带回以下字段{intervention_id:iv_1,pause_token:pause_1,base_version:1,subjects:[]}intervention_id由前端生成用于幂等。pause_token取自当前active_pausebase_version对齐审核快照。本文的subjects采用完整框列表便于服务端一次校验最终集合替代方案是提交 add/update/delete diff消息更小、协作编辑更自然但要定义补丁顺序、缺失基线和重复应用语义。无论采用哪一种都应明确低分框是用户删除、策略过滤还是数据丢失。多人/多端审核场景还要把请求体 hash、操作者身份和权限上下文一起纳入幂等与审计判断避免“同一 intervention_id、不同意图”被错误当成重放。提交审核先校验三元组再原子消费 pause单 JVM 的synchronized(jobId)只覆盖当前进程。本文用 Redis Lua 原子完成校验和状态写入数据库条件更新、事务行锁、工作流引擎 signal 去重也能提供相应的一致性边界。按本文 HTTP 契约缺intervention_id/pause_token/base_version返回 400不进入原子状态更新。若接口采用 ETag 或服务端生成幂等键必填字段会相应变化。同一intervention_id再来一次比 payload hash相同返回上次响应幂等成功不同返回409 IDEMPOTENCY_CONFLICT。多端/多用户场景还应把提交者身份和权限上下文纳入比较避免相同 ID 被不同审核员复用。pause 不是 WAITING 返回PAUSE_NOT_ACTIVEtoken 对不上返回PAUSE_TOKEN_MISMATCHbase_version ! job.version返回VERSION_CONFLICT。这些 409 都会附带最新阶段信息。单人审核通常是“409 强制刷新”多人协作则需要 patch/merge、审核租约或 quorum 规则不能只靠 409 解决全部冲突。Lua 里的核心判断就这几行ifredis.call(HEXISTS,idempotency_key,intervention_id)1thenreturn{IDEMPOTENT,redis.call(HGET,idempotency_key,intervention_id)}endiftostring(current_meta[version])~base_versionthenreturn{VERSION_CONFLICT,base_version conflict}endiftostring(current_pause[status])~WAITINGthenreturn{PAUSE_NOT_ACTIVE,pause not active}endiftostring(current_pause[pause_token])~pause_tokenthenreturn{PAUSE_TOKEN_MISMATCH,pause_token mismatch}end通过之后一次性 SET meta、box_list、pause、approved_box_list必要时往 outbox 和事件流里追加最后 HSET 幂等字段。Java 侧把返回码映射成 HTTP。不要在 Lua 成功之后再开一次「如果投递失败就把 pause 改回 WAITING」——用户刷新会以为还能再点一次实际可能已经半提交。正确做法是进入可恢复的失败态用同一个intervention_id重放后续步骤。本文保留 pause 历史以排查冲突并约定一个任务同一时刻只有一个 active pause进入新审核阶段时生成新 token。这种模型适合串行审核。多角色并行审核可以维护多个带reviewer、quorum、scope的 active review按全票、任一通过或多数票聚合此时不能再用单个active_pause表达全部状态。同步成功只到「持久化干预 消费 pause 写事件」不等下一跳执行器跑完。前端收到 200应该立刻把面板收起来改听 SSE 看校验或分割进度。提交之后走哪条边由 diff 决定控制面读当前box_list和用户subjects做规范化有box_id就保留没有则尝试把candidate_id写成box_id。然后算 diff哪些是原检测框、哪些是新增手工框、哪些被删了。空列表是一条独立路径不投递执行器if(submittedBoxList.isEmpty()){nextMeta.statusEMPTY_SELECTION;nextMeta.empty_selectiontrue;// 事件EMPTY_SELECTION_SUBMITTEDreturn;}在本文实现里EMPTY_SELECTION表示“用户显式选择不继续处理”因此直接结束当前业务分支是否计费、是否视为成功、是否允许后续 reopen应由产品契约单独定义。非空时看有没有待校验的手工框booleanneedValidation!diff.itemsToValidate().isEmpty();NodeTypenextneedValidation?VALIDATE_MANUAL_BOX_LIST:PROCESS_APPROVED_BOX_LIST;然后生成新的node_instance_id把输入快照写到 Redisoutbox 里塞一条「执行这个节点」。执行器始终消费「跑某个节点」不知道也不应实现「等人」。断点恢复的关键是重启后 dispatcher 继续扫 outbox而不是把整张图从检测再跑一遍。节点输入里同时带box_list、items_to_validate、reusable_valid_items、deleted_box_ids。第一轮校验有低分框时控制面不会把整单失败而是再开一次 pausestageWAITING_BOX_BATCH_REVISION。第二轮仍不通过的框记拒绝原因已经过线的框继续进分割。不要让整单卡死在二次命名上。决策可以按轮次写round 1 且有低分或非法框 → NEED_BATCH_REVISION再等人 round 2 且批准列表为空 → ALL_REJECTED round 2 且有淘汰有通过 → PARTIAL_APPROVED带着过线框继续 其余 → ALL_PASSED本文把round存在 pause 上默认1二次修订复用同一提交协议但stage和 token 都更新旧 token 处于CONSUMED。若协议允许在原审核任务内追加 revision则可以保留 token、递增 revision并以(pause_token, revision)做并发校验。超时治理等待、默认动作还是转人工队列产品早期有过一套很诱人的描述人工干预可配置超时超时未提交就用当前自动框继续检测空结果超时则带着空列表结束。听起来省人工。真实情况是用户还在放大看图60 秒到了后端替他点了提交手和包装盒一起进了分割。客服拿到的是「系统自己抠错了」。由于该业务的误提交代价高于等待成本本文实现创建 pause 时不写超时字段pause.put(pause_token,pause_UUID.randomUUID());pause.put(status,WAITING);pause.put(stage,stage);pause.put(base_version,job.version1);pause.put(created_at,now());// 不写 timeout_at / timeout_seconds / auto_submit_on_timeoutjob.set(active_pause,pause);前端看到的下一步动作来自pending_actions不是猜状态。通常就两件SUBMIT_BOX_LIST提交完整列表DRAW_MANUAL_BOX在图上补框测试把「pause 上没有超时字段」锁死。扫描器方法体第一句就是return;后面整段超时自动提交被包进注释。注释写明不要挂Scheduled。即便有人把注释解开选框等待态也会被跳过。这是超时治理的三层刹车创建 pause 不写timeout_at扫描器默认空操作即使误开扫描器等人态也不自动提交运维上如果看到任务长时间停在WAITING_USER_SELECTION那是产品行为不是卡死。告警应看pause.created_at的年龄和 SSE 是否还有订阅者而不是写一个 cron 去替用户点「下一步」。构造函数里仍可以保留manual-intervention-timeout-seconds给低风险任务开放有限自动继续。当前策略只接受前端干预接口续跑其他系统可以由审核队列、管理员操作、工作流 signal 或经授权的超时事件推进。带timeout_at的旧 pause 也不该被扫描器消费。迟到的时钟不能代替用户点击。并列看三种常见策略无限等待 告警适合误决策损失高、人工响应可接受的审核收益是不会替用户做决定代价是积压与存储占用需要撤销、提醒和运营清理。超时采用默认结果适合低风险、可回滚且默认值经过业务授权的任务收益是吞吐稳定代价是可能违背用户尚未完成的判断失败边界是默认动作造成不可逆外部影响。超时转人工队列或取消适合有 SLA 的审核中心收益是责任明确代价是要维护队列容量、转派和补偿机制。队列耗尽时仍要定义最终处置。状态存储也不只有 Redis关系数据库便于事务查询和审计工作流引擎提供原生挂起/唤醒Redis 则适合低延迟状态访问。选择取决于恢复时限、审计要求、数据规模与团队运维能力无论采用哪种存储pause、版本和幂等记录都应具有一致的持久化边界。若 Redis 是单点、未开持久化或受淘汰策略影响就不应把它当成高可靠断点真相源高可靠场景至少要配合数据库、事件日志、outbox 或工作流引擎兜底。迟到报告和取消等人的时候照样会发生等待期间执行器可能还在发检测节点的重试报告或者用户点了取消。规则要写死取消任务cancel_requestedtruestatusCANCELLED追加事件。 在“终态不可逆”的本文状态机中后续报告记为 ignored不再改任务终态。替代语义包括把迟到成功保存为孤立产物、触发补偿删除或创建新的任务修订版若允许终态重开则需要新的状态版本和对外事件不能静默覆盖调用方已观察到的结果。 人工提交在任务已取消时返回 409 JOB_CANCELLED。终态出边为空加上取消短路两层挡住「报告把已取消任务救活」。SSE 事件里会带阶段、状态、框、产物引用、pause。前端用这些事件刷新而不是自己轮询猜。查询接口从 Redis 读API 重启后等待态仍在。这才叫断点人离开十分钟进程翻过一轮打开同一job_id仍然停在同一pause_token上。前端最小协议别让页面去理解工作流图页面不需要知道节点类型。它要盯的只有三类信息当前任务状态、候选主体、当前还需要用户执行的动作。推荐顺序POST /jobs拿到job_idGET /{jobId}初始化面板EventSource(/jobs/{jobId}/events)带上Last-Event-IDactive_pause.status WAITING时展示审核用户确认后POST /{jobId}/interventions把编辑后的完整列表放进subjects终态后再GET /{jobId}/results提交时已有框保留后端box_id人工新增框可用临时 ID后端可能改写成box_...。candidate_id可兼容提交控制面会转成box_id。冲突处理不要弹「请刷新页面」就完事。409 响应带最新快照token 不匹配别人或上一轮已经推进pause 不活跃这次暂停已经消费version 冲突你拿的是旧job.version正确动作是用响应里的新active_pause重建面板需要的话生成新的intervention_id。我踩过的几个坑全自动阈值曾把手当成商品。分数高于 0.7 就跳过人审在这组电商图片上出现了误放行。当前实现选择检测结束统一进入人审是这个高风险抠图场景下的保守策略阈值只用于排序和高亮。若其他场景有可靠的校准数据与可接受的误放行率也可以按置信度分流、让部分主体自动放行或把低风险主体与高风险主体拆成不同策略分支。单机 synchronized 当分布式锁。两个 API 实例同时收到提交pause 被消费两次outbox 里出现两条下一跳命令。Lua 是被这次事故逼出来的。提交成功后投递失败把 pause 改回 WAITING。用户再点一次校验节点跑两遍手工框被命名成两个不同的 label。消费 pause 是不可回滚的失败要走可恢复态 幂等重放。两个等待态共用一个前端文案。第一轮是「请确认」第二轮是「这几个框没过请重画」。混用之后用户不知道该改什么只会把整单取消。超时扫描器挂在 API 进程的Scheduled上。扩成 4 个实例就跑 4 份。即便要扫也应单独进程而且等人态默认跳过。框只活在 SSE 的某一帧里。浏览器一刷新候选框没了。本文把box_list持久化到 Redis使查询接口能重建面板也可以使用关系数据库或工作流引擎状态只要 SSE 不是唯一数据源。怎么验证这套是通的用一张有两只鞋加一只手的图做冒烟别一上来打收费分割。创建任务马上查状态应该是检测中检测报告落地后Redis 里能看到 pausestatusWAITINGtimeout_at不存在SSE 能收到进入等待的事件查询接口能带回完整box_list把 API 进程杀掉再拉起同一个job_id仍停在同一个pause_token提交完整列表只勾两只鞋pause 变成 CONSUMED状态离开等待再用同一个intervention_id打一次返回上次响应不会再投一跳换一个intervention_id但带旧 token应 409响应里是新快照另开一单提交空列表终态是EMPTY_SELECTION不是FAILED等人时点取消再伪造一份检测成功报告状态仍是CANCELLED把扫描器手动跑一遍带timeout_at的旧 pause 也不能被消费。双开两个标签页用旧base_version提交时本文乐观锁协议应返回版本冲突采用自动合并协议时则验证合并结果与审计记录。写在最后长时工作流里的人审模型只是执行器里的一个函数。真正难的是等人是状态不是线程阻塞也不是 HTTP 长连接审核对象要进入持久化存储并能在进程重启后恢复审核决议要有明确的写入协议本文采用单入口幂等提交多审核人场景则需要仲裁规则在本文高风险场景中超时用于告警不替用户执行默认提交把这四块做稳二次修订、部分成功、取消和迟到报告才有地方挂。多主体怎么并行抠、一个主体失败整单算什么我下一篇单独写。如果只准备做一个最小可用版本建议按这个顺序砍需求先 Redis pause 查询接口轮询再加 SSE最后才加手工框二次命名。反过来做一上来就超时自动提交 内存里等人重启和误提交会把你折磨很久。