S72：最小 Reviewer Queue：状态、租约、Override 与 Appeal

内容类型：预习教材（不代表已完成）
日期：2027-02-02
阶段：P2 · AI Systems Engineering 90
总路线：Day 162
周次节奏：W11 · 周二最小实现
状态：教材已备；学习未完成

一句话定义

Reviewer queue 是将人工复核从一个界面按钮变成可排队、可领取、可超时、可追溯、可升级和可申诉的状态机。

学习目标

1. 定义 queued、claimed、in_review、decided、escalated、expired、appealed 等最小状态与转移。
2. 理解 lease、idempotency、optimistic concurrency 与 immutable event history 对人工工作流的价值。
3. 为 override/appeal 保存当时 evidence snapshot，不让后续变更覆盖原决定上下文。

核心知识

一个 review item 至少包含 id, subjectRef, riskTier, priority, dueAt, evidenceRef, modelRelease, status, assignee, leaseUntil, version, createdAt。它不应复制全部敏感文本，可以引用受控 evidence store；但为防止决定后证据被静默改写，应保存 evidence version/hash 与关键字段快照。

Claim/lease 解决多个 reviewer 同时处理同一工单的问题。claim 只应在预期 version 仍一致时成功；lease 过期后可重新分配，但原 reviewer 的迟到提交必须被拒绝或进入冲突处理，不能覆盖新决定。

Idempotency 使重试不重复创建工单或执行两次决定。sourceEventId + reviewPolicyVersion 可作为候选幂等键。决定事件应 append-only，修正用新事件记录，而不是就地改掉旧 reason。

Override 记录 original recommendation/decision、new decision、reason code、free-text note、actor、evidence additions 和 timestamp。Appeal 记录 appellant、grounds、new evidence、independent reviewer、SLA、outcome 与 remedy。不应把 override 直接当作“AI 错”标签，因为人类也可能根据新信息或业务例外做决定。

机制与推导

状态转移可以用 guard 表达：

transition(item, from, to, actor, expectedVersion, evidence)

只有 item.status=from 且 item.version=expectedVersion 才接受，然后 version+1 并写 event。队列容量可追踪 arrival rate, completion rate, backlog size, oldest age, p95 time-to-decision, rework/appeal rate。平均处理时间下降可能来自快速 rubber-stamping，所以需与决定质量、override reason 与 appeal outcome 并列。

最小练习或观察

1. 选择写一个内存中 TypeScript/JSON 状态示例，或只画状态转移表。
2. 准备 3 个合成工单：正常、高风险、即将超时；不使用真实客户数据。
3. 模拟 claim，再用旧 version 重复 claim，写出应当拒绝的原因；未运行时只写预期。
4. 为一个工单追加 override，再创建 appeal，检查原始证据与决定历史是否仍存在。
5. 不实现完整前端、身份系统或消息中间件；小状态示例就是完成边界。

常见误区与边界

• 只存当前 status，没有事件历史、actor 和 evidence version。
• 用永久 lock 防重，reviewer 离开后工单永远卡住；需要 lease 与超时。
• 重试产生多个工单，或重复触发下游执行。
• override 直接改原记录，使后续无法重建当时决定。
• toy queue 不证明生产并发、持久化、安全或合规需求已满足。

系统 / 金融 / Web3 连接

AML 复核工单要保存案件与证据版本，否则数据后续更新会让原决定看起来毫无依据。Web3 交易审批需要过期时间：在 queue 中等待过久的 simulation、nonce、gas 与价格已不新鲜，不应在原快照上继续批准。

自检问题

1. claim 为什么同时需要 lease 和 version？
2. idempotency key 应包含哪些业务语义？
3. override 为什么不能直接当作模型错误标签？
4. 哪些指标可以暴露 queue 正在失效？

专业课程对齐

• Temporal Documentation：精读 workflows、activities、retries、timeouts、signals 与 durable execution，映射 claim/lease、人工等待和恢复语义。
• Google SRE Book：精读 monitoring distributed systems、handling overload 和 incident response，用于设计 backlog/age/capacity 信号。
• OpenTelemetry Documentation：选读 traces/logs、context propagation 与 semantic conventions，将 review item id、release id 与上下游事件关联。

深入学习提示

先按 Temporal 理解长时间工作流与重试，再用 SRE 审视容量，最后用 OTel 补可观测性。不要把框架 API 当作队列语义；先在纸上定义每个状态和转移的业务含义，再决定代码映射。

学后填写区

• queue / state 模型：
• claim、lease 与 version 规则：
• override / appeal 事件：
• 实际观察（未运行留空）：
• 仍未覆盖的生产问题：