From Probabilistic Agents to Verifiable Execution: A Durable Control-Tower Architecture for LLM Agent Systems

摘要

大型语言模型智能体能够通过工具调用执行长链任务，但模型输出具有概率性、会话上下文具有瞬时性，且外部副作用、重试、并发与生产部署状态往往缺少统一的可验证语义。本文提出一种面向 LLM Agent 系统的持久化控制塔架构，将自然语言请求、语义目标、执行尝试、运行时证据与最终落地状态显式分离。核心机制包括：关系优先的 Intake 分类、先持久化后语义处理的 Durable Receipt、Q/RUN 双层身份模型、幂等键与可重放写入、终态单调性，以及由数据库触发器强制的 Evidence-gated Finality。本文基于 LMN516 生产系统给出观察性实证。于 2026-09-15 09:50 CST 的数据库快照中，共包含 1,533 个 canonical Q、994 个 canonical RUN 与 2,217 个 Intake receipt；精确幂等键重复数为 0，Q→RUN 与 RUN→Q 孤儿关系均为 0，终态 RUN 缺失 terminal_at 为 0。最近 7 日内有 27 条 receipt 经多次尝试后最终收敛，说明恢复路径在真实流量中被实际触发。同时，系统仍保留 66 条未收敛 receipt，以及 211 条历史 DONE 不满足当前 E4/E5 与 landing 证据标准，揭示了语义上下文恢复和历史真值迁移的剩余债务。本文不将上述生产观察解释为因果提升，而是进一步定义一套故障注入基准，以重复消息、数据库超时、Worker 崩溃、重复回调、跨机器接管与 Production 失败为干预变量，测量重复物化率、孤儿关系率、假终态率、恢复成功率与平均收敛时间。该工作表明，LLM Agent 的可靠性问题不仅是模型能力问题，也可以被重新表述为身份、状态、事务、证据与终态约束问题。

关键词： LLM Agent；持久化工作流；智能体编排；幂等；状态机；故障恢复；可验证执行

Abstract

LLM agents can execute long-horizon tasks through tool use, yet their probabilistic outputs, session-bounded context, retries, concurrency, and external side effects make operational correctness difficult to verify. This paper presents a durable control-tower architecture that separates natural-language requests, semantic intent, execution attempts, runtime evidence, and final landing state. The design combines relation-first intake, receipt-before-semantics persistence, a dual Q/RUN identity model, idempotent replay, monotonic terminal states, and database-enforced evidence-gated finality. A production snapshot of LMN516 captured on 15 September 2026 contains 1,533 canonical Q objects, 994 canonical RUN objects, and 2,217 intake receipts. Exact idempotency-key duplication is zero, bidirectional Q–RUN orphan counts are zero, and no terminal RUN lacks terminal_at. Twenty-seven receipts in the preceding seven days eventually settled after retries, demonstrating recovery paths under real traffic. However, 66 receipts remain unsettled and 211 historical DONE records do not satisfy the current E4/E5 landing standard, exposing remaining context-reconciliation and historical-truth debt. We therefore treat the production analysis as observational evidence rather than causal proof, and define a fault-injection benchmark for duplicate delivery, database timeouts, worker crashes, duplicate callbacks, cross-node takeover, and failed production landing. The main claim is that a substantial subset of agent reliability can be engineered as explicit invariants over identity, state, transactions, evidence, and finality rather than delegated to model behavior alone.

Keywords: LLM agents; durable workflows; orchestration; idempotency; state machines; fault recovery; verifiable execution

1. 引言

近年来，LLM Agent 从“生成文本”扩展到“执行任务”：模型可规划步骤、调用 API、修改代码、操作浏览器，并在多轮交互中处理真实环境。ReAct 将推理与行动交错组织 [1]；AutoGen 以多智能体会话编程支持复杂协作 [2]；AgentBench、WebArena 与 SWE-agent 则分别从交互式任务、真实网页环境和软件工程界面研究智能体的执行能力 [3–5]。这些工作共同说明：智能体性能越来越依赖运行时环境、工具接口和长链决策，而不仅是单次语言建模能力。

然而，当智能体进入持续运行的生产系统后，一个更基础的问题出现了：系统如何知道“用户真正提出了什么问题”“这次执行是否是同一次尝试”“失败重试是否会制造重复副作用”“Worker 声称完成是否等于目标环境真的完成”“会话中断后系统还能否恢复原始意图”。如果这些问题仅依赖模型上下文或自然语言自述，系统就难以获得稳定的身份、可审计状态和可证伪的完成条件。

传统工作流与事务系统早已研究长事务、补偿、显式状态和流程模式。例如 Sagas 将长事务拆解为可独立提交并可补偿的步骤 [9]，Workflow Patterns 系统化描述了工作流控制结构 [6]。但 LLM Agent 引入了新的不确定性：语义关系需要从自然语言中判定，执行器本身可能是概率模型，多入口可能重复送达同一需求，且“文本回答成功”和“外部世界状态成功”并不等价。

本文研究一个工程问题：能否在不要求 LLM 本身变成确定性程序的前提下，用传统系统机制把智能体执行包裹在一组可验证约束中？我们的答案是一个持久化 Control Tower。其核心不是增加一个管理界面，而是在 Agent 与外部世界之间建立 durable identity、state transition、evidence reconciliation 与 finality gate。

2. 研究问题与贡献

本文围绕以下四个研究问题展开：

RQ1. 如何从连续自然语言对话中建立稳定的语义身份，而不把每条消息机械地当作新任务？

RQ2. 如何区分“用户问题”与“某一次执行尝试”，使重试、换 Worker、跨设备接管不会破坏任务连续性？

RQ3. 如何在至少一次投递、并发和部分失败条件下，降低重复物化、孤儿状态与静默丢失？

RQ4. 如何阻止“模型说完成”“代码已提交”或“测试通过”被错误地提升为生产完成？

针对这些问题，本文的工程贡献包括：

• Relation-first Intake：将原始 USER 语义单元分类为 IGNORE、LINKEXISTINGQ、EVIDENCEORACCEPTANCE、NEWQ 或 SPLITTONQ，再决定是否创建 canonical Q。

• Durable Receipt：在语义处理前先持久化接收事实，使后续分类或数据库操作失败时仍保留可重放的恢复边界。

• Q/RUN 双层身份：Q 表示用户长期语义目标，RUN 表示一次不可变的执行尝试；终态 RUN 不允许回退，新尝试必须产生新 RUN。

• Evidence-gated Finality：DONE 不是模型输出标签，而是受 E4/E5、landingat 与 landingnote 约束的数据库终态。

• 生产观察与反证同时报告：不仅报告 0 重复、0 orphan 等正向结果，也保留 66 条未收敛 receipt 和 211 条历史 finality debt，避免把架构主张等同于完美实现。

3. 相关工作

3.1 推理、行动与多智能体编排

ReAct [1] 证明将推理轨迹与环境动作交错可以提升交互式决策表现；AutoGen [2] 将多 Agent 的对话与工具调用组织为可编程模式。这一类工作主要回答“Agent 如何协作和行动”。本文关注其下一层系统问题：当行动被重试、转移、延迟或部分失败时，如何保持身份和最终状态的可验证性。

3.2 Agent 基准与真实环境

AgentBench [3]、WebArena [4] 和 SWE-agent [5] 分别强调长期推理、真实网页交互以及 Agent-computer interface 对执行表现的影响。它们提供任务成功率与环境设计证据，但生产可靠性还需要评估重复送达、状态恢复、外部副作用和终态真实性。2026 年的 ReliabilityBench 预印本开始通过超时、限流、部分响应和 schema drift 等故障注入评估 Agent 可靠性 [7]，与本文提出的 fault-injection protocol 在方法论上相近。

3.3 持久化工作流与恢复

Workflow Patterns [6] 与 Sagas [9] 奠定了工作流控制、长事务与补偿的经典基础。2026 年 AgentR 预印本提出 stateful、recovery-aware 的 LLM 工作流架构，强调持久中间状态、重试、孤儿任务检测与审计 [8]。本文的差异主要在于：自然语言关系优先的 Intake、Q/RUN 双层语义与执行身份、receipt-before-semantics 入口边界，以及对 Production/target runtime finality 的数据库级强制。本文不主张“首次提出持久化 Agent 工作流”，而是研究这些机制在一个长期、多入口、多 Worker 的实际系统中如何组合。

4. 系统模型与威胁模型

4.1 基本对象

设 U 为用户，M 为原始 USER 消息，Q 为 canonical semantic question，R 为 execution run，E 为证据集合，L 为目标运行环境的 landing 事实。控制塔将聊天消息从“上下文中的句子”提升为可追踪关系，但不要求每条消息都生成 Q。

定义 1 I(M) -> {IGNORE, LINK(Q), EVIDENCE(Q), NEW(Q), SPLIT(Q1...Qn)}

I 表示 relation-first Intake 分类器。

Q 的生命周期描述“用户要解决什么”；R 的生命周期描述“某一次真实执行尝试发生了什么”。同一个 Q 可以拥有多个 R，但一个已经进入终态的 R 不被重新启动。

4.2 目标不变量

I1 Receipt(M) is persisted before SemanticIntake(M)

入口故障不能使消息从系统视野中静默消失。

I2 for all (u,k): |Canonical(u,k)| <= 1

同一用户与同一幂等键至多物化一个 canonical identity。

I3 R -> Q and Q -> R must reference existing canonical objects

Q/R 双向关系不得出现孤儿引用。

I4 if state(R,t) in T, then state(R,t2)=state(R,t) for all t2>t

T={DONE, FAILED, CANCELLED, SUPERSEDED}，终态单调。

I5 DONE(R) => E(R) in {E4,E5} and L.at != null and L.note != empty

完成必须由目标运行环境证据支持，而非调用方自报。

4.3 威胁模型

表 1 威胁模型与主要防护机制

5. Control Tower 架构

USER turn ──▶ Durable receipt ──▶ Relation-first Intake ──▶ Q semantic identity
                                                      │
                                                      ├── IGNORE ──▶ receipt settles, no Q
                                                      └── LINK / EVIDENCE ──▶ reuse existing Q

Q semantic identity ──▶ RUN execution attempt ──▶ Worker / Runtime
                                                    │
                                                    ▼
                              Evidence + target-runtime landing
                              E4/E5 · landing_at · landing_note
                                                    │
                                                    ▼
                                             VERIFYING ──▶ DONE

Identity plane ≠ event plane · terminal RUNs are monotonic

图 1 从自然语言入口到 Evidence-gated Finality 的控制链

5.1 Relation-first Intake

传统任务系统通常在收到输入后立即创建任务；对聊天式 Agent 而言，这会把“继续”“等一下”“验证好了吗”等上下文依赖语句错误地碎片化为新任务。Control Tower 先判定新消息与现有语义对象的关系。只有独立、可追踪的语义单元才创建 NEW_Q；延续、修正或证据优先绑定已有 Q；纯 filler 则以 IGNORED receipt 收敛而不创建 Q。

这种设计使“是否创建身份”成为一个显式决策，而不是由入口数量、UI 事件数或模型回复轮次隐式决定。

5.2 Durable Receipt 与至少一次语义处理

入口首先将 message identity、发生时间、摘要、text hash、source reference 与 receipt 状态写入 controlintakereceipt，然后进入 canonical semantic intake。数据库迁移使用嵌套 PostgreSQL 子事务：语义写入失败时，内层 canonical 变更回滚，外层 receipt 仍可保留为 FAILEDRETRYABLE 或 PENDINGCONTEXT。该结构更接近“至少一次 + 幂等重放”，而不是不可现实地宣称所有外部副作用都具有 exactly-once 语义。

对于终态 receipt，再次收到相同 source/idempotency identity 时直接 replay 已有结果，从而避免重复 canonical side effects。

5.3 Q/RUN 双层身份

Q 表示稳定的语义目标，例如“修复桌面端站内信慢”；RUN 表示某一次执行，例如由 M4 Worker 执行的一次修复尝试。reserve_run 在事务中分配 RUN 编号，绑定 canonical Q，并同时写 durable relation event。若兼容的非终态 RUN 已存在，则可复用；若终态 RUN 已结束，新的执行尝试必须得到新的 RUN。

这种分层使系统可以表达“同一问题有多次尝试”，同时不把一次失败重试误记为一个新用户问题。

5.4 Identity Plane 与 Event Plane 分离

Control Tower 将 canonical identity 与观察事件区分：Q/RUN 是身份与生命周期真值；assistant activity、heartbeat、UI activity 等是 projection/evidence。观察到 Worker 活跃不能自动创建 RUN，也不能证明工作已完成。该边界降低了“有日志 = 有状态”“有心跳 = 已执行”的类别错误。

5.5 终态单调性

应用层的 reportControlRunStatus 对终态集合 {DONE, FAILED, CANCELLED, SUPERSEDED} 强制单调性。一旦 RUN 进入终态，不允许再次回到 RUNNING、VERIFYING 或 QUEUED。需要再次执行时创建新的 RUN，从而保存前一次尝试的审计语义。

5.6 Evidence-gated Finality

最关键的设计是将“完成”从自然语言声明提升为数据库约束。当前 PostgreSQL trigger 对新的 DONE 转换执行 finality gate：evidencelevel 必须为 E4 或 E5，同时 landingat 非空且 landingnote 非空，否则直接抛出 RUNDONEREQUIRESVERIFIEDPRODUCTIONLANDING。

因此以下事件均不充分：模型输出“完成”、单元测试通过、Git commit、合并 main、build 成功。它们最多构成中间证据。对网站类任务，只有真实 Production landing；对非网站目标，则要求对应 target runtime landing。该约束把“文本世界的成功”与“外部世界的成功”明确分离。

5.7 Self-heal 与 Reconciliation

未收敛 receipt 不被静默删除。FAILEDRETRYABLE 可在受限次数与退避间隔下重试；PENDINGCONTEXT 需要恢复关系上下文，并在无法确定目标 Q 时 fail closed。系统同时保留定时 reconciliation 作为安全网。但正如生产数据所示，安全网并不意味着所有积压已经被清零，未收敛状态本身必须作为一等健康指标暴露。

6. 实现

本文系统实现于 LMN516 生产代码库，应用层主要使用 TypeScript/Next.js 与 Prisma，持久层为 PostgreSQL（Supabase）。本文用于代码审计的 main 分支快照为 commit 51a8dce28f26acbc529f33938bfcbf945b9805b3（2026-09-15 01:34:16 UTC）。

表 2 代表性实现表面

值得强调的是，合同测试主要验证“不变量被代码表达”，而生产数据库查询验证“不变量在当前数据中是否出现违反”。两者不能互相替代。静态合同通过并不证明历史数据完全符合新规则；生产数据没有异常也不证明未来所有故障都已覆盖。

7. 研究方法

7.1 观察性生产快照

本文第一阶段采用只读生产数据库审计，不修改业务数据。快照时间为 2026-09-15 01:50:11 UTC（09:50:11 CST）。统计对象为 controlquestion、controlrun 与 controlintakereceipt，并检查以下指标：canonical 总量、精确 idempotency-key 重复、Q/RUN 孤儿关系、终态时间完整性、未收敛 receipt、重试后收敛以及 DONE 的当前 finality 合规性。

观察性数据用于回答“系统是否在真实流量下表现出设计预期的结构特征”，不用于证明 Control Tower 相比无 Control Tower 的因果增益。由于缺少严格的前后 A/B 或随机对照，本文不报告诸如“可靠性提升 X%”的结论。

7.2 评价指标

M1 Duplicate Materialization Rate = duplicate canonical identities / delivered identities

M2 Orphan Relation Rate = orphan Q-RUN references / all Q-RUN references

M3 Unsettled Intake Ratio = unsettled receipts / all receipts

M4 Recovery Yield = retry-settled receipts / receipts requiring retry

M5 False Finality Rate = invalid new DONE transitions / all new DONE transitions

其中 M5 必须限定在 finality guard 实际生效后的新 DONE 转换。把 guard 之前的历史 DONE 与新规则混合会产生错误因果解释，因此本文将其单独报告为 historical/legacy truth debt。

7.3 故障注入基准设计

为获得因果证据，本文定义第二阶段 Fault Injection Benchmark。每类故障在固定任务集合上重复执行，并与关闭对应控制机制的基线实现比较。建议每个条件至少运行 30 次，报告均值、95% 置信区间与失败类型分布。

表 3 Fault Injection Benchmark 协议

8. 生产结果

8.1 总体规模与完整性

表 4 2026-09-15 09:50 CST 生产完整性快照

在该快照中，三个 canonical 层级的精确 idempotency-key duplicate group 均为 0，Q/RUN 双向 orphan 均为 0。这些结果与 I2、I3 的设计方向一致。需要注意，0 违反是当前数据集的观察结果，不等价于数学证明，也不能覆盖语义上“不同 key 但同一意图”的重复。

8.2 Intake 收敛与恢复

2,217 条 receipt 中有 66 条处于 RECEIVED、PENDINGCONTEXT、FAILEDRETRYABLE 或 PARTIAL 等未收敛状态，对应未收敛比例约 2.98%；其余 2151 条已收敛，约 97.02%。最近 7 日内有 27 条 receipt 在 attempt_count>1 的情况下最终进入 APPLIED 或 IGNORED，表明 retry/reconciliation 路径并非仅存在于代码，而是在真实生产流量中被触发。

同时，最老未收敛 receipt 的 occurred_at 为 2026-09-09 00:00:00 UTC。这构成明确的反证：当前 self-heal 尚不能保证所有 pending context 或 retryable failure 在短时间内自动清零。因而，Control Tower 的价值应表述为“故障变得可见、可重试、可审计”，而不是“故障被消灭”。

8.3 RUN 状态分布

表 5 生产 RUN 状态分布

SUPERSEDED 与 STALE 的规模说明生产系统真实存在重试、替代与长期未收敛执行历史。对 Agent 系统而言，这些状态不应被压缩成简单的 success/failure 二分类，因为它们直接影响恢复策略、用户沟通与资源调度。

8.4 Finality：强约束与历史真值债务

当前共有 492 条 DONE RUN，其中 281 条同时满足 E4/E5、landingat 非空和 landingnote 非空，约占 57.11%；另有 211 条不满足当前 finality 标准，约占 42.89%。数据库中当前 finality trigger 已启用，因此这些不合规 DONE 不能被简单解释为“当前守卫失效”。此前审计显示其中绝大多数属于新守卫之前或历史迁移语义不完整的数据。

这一结果体现了系统演化中的一个重要原则：新增强约束可以阻止未来错误，但不会自动重写历史事实。若直接把 211/492 解释成当前 False Finality Rate，将混淆旧规则与新规则。本文因此把它定义为 legacy truth debt，并要求单独迁移、标注或降级其可信度。

9. 讨论

9.1 控制塔为什么在代码层面有用

本研究最直接的结论不是“多了一层管理系统”，而是 Agent 的概率行为被若干确定性边界包裹：消息接收事实先持久化；canonical identity 受唯一键约束；Q 与 RUN 分离；状态转换由事务与终态单调性限制；最终完成由目标运行环境证据决定。模型仍然可以犯错，但错误更难以无痕地改变系统真值。

9.2 为什么不是 exactly-once

本文刻意不使用“exactly-once Agent execution”作为主张。数据库内部可以通过唯一键、事务和 upsert 逼近精确一次物化，但 HTTP、GUI、邮件、微信、部署等外部副作用通常无法由单个数据库事务原子覆盖。更准确的工程语义是 at-least-once delivery + idempotent materialization + observable reconciliation；对不可幂等外部动作还需要业务级 dedupe key、补偿或人工确认。

9.3 语义幂等比键幂等更难

当前“0 duplicate key”只能证明精确 source identity 没有重复物化，不能证明两个不同 messageKey、不同入口或不同措辞表达的同一需求一定会归并到同一 Q。Relation-first Intake 试图解决语义重复，但它本身仍是模型/规则混合判断，未来需要人工标注集与 precision/recall 评估。

9.4 Finality 的意义

LLM 系统常把“生成了一个完成报告”误当成完成。Evidence-gated Finality 的价值在于将完成权从生成模型转移到可审计状态：模型可以提出“我认为完成了”，数据库只接受“目标环境已有足够证据”。这与软件交付中“代码完成、测试通过、main、build、Production”逐层增强证据的实践一致。

10. 局限性

• 单系统研究：生产数据来自一个持续演化的 LMN516 实例，工作负载与用户行为具有明显特定性。

• 缺少随机对照：目前无法从观察性数据推断 Control Tower 相对无控制塔架构的因果提升幅度。

• 历史策略污染：211 条 legacy/invalid DONE 混合了规则升级前后的数据，不能作为新 finality guard 的失败率。

• 语义分类未标注评测：LINKEXISTINGQ、NEWQ、PENDINGCONTEXT 等决策尚未基于独立人工 gold set 报告准确率。

• 外部副作用不可原子化：数据库事务无法自动覆盖所有 GUI、第三方 API、部署与消息发送副作用。

• Self-heal 尚未收口：66 条未收敛 receipt 表明可见性与自动恢复之间仍有差距。

• 本文报告的 2026 年 ReliabilityBench 与 AgentR 为预印本，应与已同行评审工作区分看待。

11. 下一阶段实验

下一阶段应优先执行表 3 的 Fault Injection Benchmark，并建立“有 Control Tower / 移除某一控制机制”的消融实验。推荐至少包含四个 ablation：A0 全机制；A1 去掉 durable receipt；A2 去掉 Q/RUN 分离；A3 去掉 idempotency unique guard；A4 去掉 finality trigger。对每个条件固定任务、模型与工具版本，注入相同故障序列，从而估计各机制对 Duplicate Materialization、Orphan Relation、False Finality 与 MTTR 的边际贡献。

若实验结果支持预期，论文即可从“系统设计 + 生产观察”升级为“系统设计 + 生产观察 + 因果故障实验”，更接近可投稿的系统论文。

12. 结论

本文提出并分析了一种面向 LLM Agent 的持久化 Control Tower 架构。核心思想是：不要求概率模型本身承担所有可靠性，而是把请求身份、执行身份、状态转换、重试、证据和最终落地分别提升为可持久化、可审计、可约束的系统对象。LMN516 的生产快照显示，当前 1,533 个 Q、994 个 RUN 和 2,217 个 receipt 中未发现精确幂等键重复或 Q/RUN orphan，且 retry recovery 在真实流量中发生；与此同时，66 条未收敛 receipt 和 211 条历史 finality debt 说明系统仍存在明确、可量化的剩余问题。

因此，本文的最重要观点不是“LLM Agent 可以被变成确定性程序”，而是“LLM Agent 的执行边界可以被工程化为确定性不变量”。当身份、事务、状态与证据从会话记忆中脱离并进入持久化控制层后，Agent 系统才具备长期运行所需要的恢复、审计和可验证终态基础。

参考文献

[1] Yao, S., Zhao, J., Yu, D., Du, N., Shafran, I., Narasimhan, K., and Cao, Y. ReAct: Synergizing Reasoning and Acting in Language Models. ICLR, 2023. arXiv:2210.03629.

[2] Wu, Q., Bansal, G., Zhang, J., et al. AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation. COLM, 2024. arXiv:2308.08155.

[3] Liu, X., Yu, H., Zhang, H., et al. AgentBench: Evaluating LLMs as Agents. ICLR, 2024. arXiv:2308.03688.

[4] Zhou, S., Xu, F. F., Zhu, H., et al. WebArena: A Realistic Web Environment for Building Autonomous Agents. ICLR, 2024. arXiv:2307.13854.

[5] Yang, J., Jimenez, C. E., Wettig, A., Lieret, K., Yao, S., Narasimhan, K., and Press, O. SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering. NeurIPS 2024. DOI: 10.52202/079017-1601.

[6] van der Aalst, W. M. P., ter Hofstede, A. H. M., Kiepuszewski, B., and Barros, A. P. Workflow Patterns. Distributed and Parallel Databases, 14(1):5–51, 2003. DOI: 10.1023/A:1022883727209.

[7] Gupta, A. ReliabilityBench: Evaluating LLM Agent Reliability Under Production-Like Stress Conditions. 2026. Preprint. arXiv:2601.06112.

[8] Samanta, R., Saha, B., Ghosh, S. K., and Buyya, R. AgentR: A Stateful and Recovery-Aware Software Architecture for LLM-based Auditable Workflows. 2026. Preprint. arXiv:2608.15264.

[9] Garcia-Molina, H., and Salem, K. Sagas. Proceedings of ACM SIGMOD 1987, pp. 249–259. DOI: 10.1145/38713.38742.

附录 A：生产审计口径

生产统计使用只读 SQL，对 canonical tables 做聚合与引用完整性检查。duplicate key 指同一 userid 与非空 idempotencykey 出现多于一个 canonical group；orphan 指数组引用中的 Q/RUN identity 在另一 canonical table 中不存在。未收敛 receipt 定义为 RECEIVED、PENDINGCONTEXT、FAILEDRETRYABLE 或 PARTIAL。Verified DONE 定义为 status=DONE 且 evidencelevel∈{E4,E5}、landingat 非空、landing_note 非空。

附录 B：可复现实验记录模板

表 B1 Fault Injection 实验最小记录集