FullAgenticStack WhatsApp优先:RFC-WF-0018

发布: (2026年2月26日 GMT+8 17:24)
11 分钟阅读
原文: Dev.to

Source: Dev.to

请提供您希望翻译的完整文本内容,我将按照要求将其翻译为简体中文,并保留原始的格式、Markdown 语法以及技术术语。谢谢!

摘要

本文档规定了针对 WhatsApp‑first 系统的 State Model & Command Lifecycle (SMCL)。SMCL 定义了一个规范的有限状态机 (FSM),用于命令执行和恢复,包含:

  • 允许的状态
  • 有效的转换
  • 终止条件
  • 证据发射要求

SMCL 确保所有组件(命令执行、安全门控、可观测性、恢复/补偿以及审计)使用一致的生命周期模型——防止阶段漂移并实现确定性的工具和认证。

Index Terms – finite‑state machine, lifecycle states, command execution, recovery states, evidence emission, idempotency, distributed systems.

与其他 RFC 的关系

RFC缩写范围
RFC‑WF‑0003CCP命令信封 & 确认语义
RFC‑WF‑0006EAS证据制品
RFC‑WF‑0008RCP恢复操作
RFC‑WF‑0010IDS可重放安全执行
RFC‑WF‑0017TVRS合规性测试映射 (TVRS/CATS)

实现通常在生命周期阶段和转换顺序上出现分歧,导致互操作性和审计受阻。SMCL 提供了一个单一的规范生命周期有限状态机(FSM),其作用是:

  1. 标准化状态命名
  2. 限制有效的转换
  3. 定义终止状态
  4. 为每一次转换指定所需的证据
  5. 在重复/重试的情况下形式化幂等的重新进入行为

注意: SMCL 定义内部工作流引擎;它仅定义可观察行为

常规的 RFC 规范关键词(MUST、MUST NOT、SHOULD、SHOULD NOT、MAY)同样适用。

术语

TermDefinition
Primary Command用户请求的原始命令。
Recovery Command重试、取消、重新处理或补偿原始命令的命令。
Lifecycle State有限状态机中的当前阶段。
Transition从一个状态到另一个状态的允许移动。
Terminal State在此之后不再发生进一步执行转换的状态(除受治理恢复之外)。

Primary‑Command 生命周期状态

状态描述
S0 – received原始输入已接收(预信封)。
S1 – canonicalized已创建并持久化信封;command_id首次出现。
S2 – confirmation_required请求确认(如果是变更操作)。
S3 – confirmed已满足人工确认门槛。
S4 – authz_pending授权评估待定。
S5 – authorized授权已批准。
S6 – rejected验证、授权拒绝、策略拒绝或歧义(终止)。
S7 – started执行已启动;可能开始副作用。
S8 – executed执行成功完成(终止)。
S9 – failed执行失败(终止(针对主要执行);可能随后恢复)。
S10 – canceled执行已取消/中止(终止)。
S11 – compensated补偿已完成(终止)。

注意事项

  • 只读命令可能跳过确认状态(S2/S3)。
  • 某些实现可能合并 authz_pending/authorized;若如此,它们必须仍然提供语义等价的证据和顺序。
  • received 是预信封阶段,不得改变状态。
  • canonicalizedcommand_id 首次出现的最早点。
  • confirmed 表示已满足人工确认门槛。
  • authorized 表示范围/提升门槛已满足。
  • started 表示执行已开始,可能产生副作用。
  • executed 表示效果已完成且一致。
  • failed 表示执行因错误结束;可能进行恢复。
  • compensated 表示补偿已实现定义的终止性纠正。

允许的状态转换

以下转换 必须 强制执行:

received               → canonicalized
canonicalized          → confirmation_required   (if mutating and not auto‑confirmed by policy)
confirmation_required → confirmed
canonicalized          → authz_pending          (read‑only or pre‑confirm validation path allowed)
confirmed              → authz_pending
authz_pending          → authorized
authz_pending          → rejected
authorized             → started
started                → executed
started                → failed
started                → canceled
failed                 → compensated            (only if compensation executed successfully)
executed               → compensated            (allowed only if business‑defined compensation exists and is governed)

无效的状态转换

如果尝试进行无效的转换(例如 executed → started),系统 必须

  1. 拒绝该转换。
  2. 发出指示 invalid_transition_attempt 的证据。
  3. 保持先前的终止状态。

附加约束:

  • 对于任何会改变状态的命令,除非已发生 confirmed(除非有明确的、策略声明的 “安全自动确认”,该确认 必须 可审计且极少使用),否则 started 不得 出现。
  • 对于任何会改变状态的命令,除非已发生 authorized,否则 started 不得 出现。

幂等性与重复处理

  • 如果同一逻辑命令被多次投递(相同的 idempotency_key):

    • 终止状态executed | rejected | canceled | compensated):系统 MUST 重放结果,且 MUST NOT 重新进入执行。
    • 已启动:重复请求 MUST 返回 in_progress 视图,且 MUST NOT 创建并行执行。
  • 主命令在达到 executedrejectedcanceledcompensated 之后 MUST NOT 重新进入 started

恢复命令规则

恢复命令遵循相同的 FSM,并遵守以下附加规则:

  1. 引用 target_command_id
  2. 发出证据,链接到目标。
  3. 遵守 根据风险类别(RCP/ACSM/PPGP)的授权/确认/提升要求。

补偿模型

  1. target_command 处于 failed executed(取决于业务语义)。
  2. 恢复命令执行补偿计划。
  3. target_command 仅在计划成功且证据确认收敛时进入 compensated
  • 补偿 必须 仅以追加方式进行,并且可审计。

Evidence Emission

对于每个生命周期转换,系统 MUST 发出至少包含以下内容的证据工件:

  • lifecycle.command_id
  • lifecycle.transition(例如 received→canonicalized
  • lifecycle.timestamp
  • lifecycle.evidence_type(例如 state_changeinvalid_transition_attempt
  • 任何 additional context 由依赖的 RFC(CCP、EAS、RCP、IDS)所需的额外上下文。

确切的模式定义在 RFC‑WF‑0006 (EAS) 中。

合规性

  • 最小合规性测试已映射到 RFC‑WF‑0017 (TVRS/CATS)
  • 实现 必须 通过所有 TVRS 测试向量,以覆盖每个状态、转换、终止条件和证据发射要求。

安全与隐私考虑

  • 所有证据工件 必须 进行签名并具备防篡改特性。
  • 敏感字段(例如,用户标识符) 必须 根据 RFC‑WF‑0003 (CCP) 中定义的隐私政策进行编辑或加密。

IANA 考虑事项

  • 不需要 IANA 操作。

References

  • [RFC‑WF‑0003] 命令信封与确认 (CCP)
  • [RFC‑WF‑0006] 证据工件 (EAS)
  • [RFC‑WF‑0008] 恢复操作 (RCP)
  • [RFC‑WF‑0010] 可重放安全执行 (IDS)
  • [RFC‑WF‑0017] 测试向量参考套件 (TVRS/CATS)

生命周期状态映射

状态对应的命令 / 事件
canonicalizedcommand.accepted
confirmation_requiredcommand.confirmation.requested
confirmedcommand.confirmation.satisfied
authorized / rejectedauthz.decided (allow / deny)
startedexecution.started
executed / failed / rejectedexecution.executed | execution.failed | execution.rejected
compensatedcompensation.compensated

追踪绑定: (conversation_id, message_ids)
安全决策: 包括授权、提升步骤以及在相关情况下的确认。

X. 可观测性要求(OoC 兼容性)

OoC 必须至少能够报告:

  • 当前生命周期状态。
  • 最近一次转换的时间戳。
  • 终止结果(如果状态为终止状态)。
  • 拒绝/失败的原因(策略/原因代码)。
  • 下一步允许的恢复选项(如果有)。

符合 SMCL‑标准的实现必须通过以下验证测试:

  1. 无效转换拒绝 – 尝试转移到非法状态时应被拒绝。
  2. 顺序不变性 – 例如,没有先前的 confirm + authorize 就不能执行 start
  3. 重复处理 – 重新发送命令不会重新进入执行。
  4. 证据发出 – 在每个强制转换时都会发出所需的工件。

这些测试应以 TVRS(测试向量与参考场景)场景的形式呈现。

相关规范

规范ID目的
Conversational Command Protocol (CCP)0003定义信封创建和确认;SMCL 修正顺序/阶段。
Evidence Artifact Schema (EAS)0006定义工件结构;SMCL 定义何时必须发出工件。
Recovery & Compensation Protocol (RCP)0008定义恢复操作;SMCL 定义其生命周期约束。
Idempotency & Delivery Semantics (IDS)0010定义可安全重放的执行;SMCL 定义重新进入规则。
Test Vectors & Reference Scenarios (TVRS)0017提供生命周期行为的符合性场景。

安全与一致性说明

  • 生命周期不一致(例如,“在授权前启动”)可能导致绕过。
  • 实现必须强制不变式记录无效尝试作为证据工件。
  • 终态保护对于防止重放滥用和“双重效果”攻击至关重要。

SMCL 为 “WhatsApp‑first” 执行语义提供确定性骨干:一个规范化生命周期状态、转换、证据发射点和幂等重新进入行为的标准有限状态机。这防止跨服务的生命周期漂移,并实现可靠的可观测性、恢复和认证工具。

参考文献

  1. RFC‑WF‑0003, Conversational Command Protocol (CCP).
  2. Evidence Artifact Schema (EAS).
  3. Recovery & Compensation Protocol (RCP).
  4. Idempotency & Delivery Semantics (IDS).
  5. Test Vectors & Reference Scenarios (TVRS).

关键词: 有限状态机, 生命周期不变式, 终态保护, 证据发射映射, 幂等重新进入规则, 恢复/补偿状态建模, 合规性测试.

0 浏览
Back to Blog

相关文章

阅读更多 »