「可重放」不是形容词：我把自家 Agent 运行时的 run 账本翻了个底朝天

「你们说的『可重放』，是能把那次运行原样再跑一遍吗？」

不是。至少不全是。

我去翻了自家仓库，想给这个词一个准确的答案，结果发现「replay」这个词在我们代码里 指的是四件不同的事 ------从「把证据拼回来给人看」到「同一个幂等键第二次来直接还上次的结果」， 中间隔着三张表和一个叫 in_doubt 的状态。

更要紧的是：这四件事没有一件是靠日志实现的。 它们靠的是同一份东西------ 先落库的那份账本。

下面我把这份账本的五张表、四种重放，以及它现在还对不上的七个地方，一处一处摊开。

先看结论

replay 这个词在我们仓库里指四件不同的事。先把它们摆开，后面逐个展开：

#	叫法	入口	会不会重新执行	代价
1	证据重放	GET /api/v1/observe/runs/{run_id}/replay	不会	一次数据库读
2	断线补帧	GET /api/v1/runs/{run_id}/stream?last_event_id=...	不会	一次数据库读加继续订阅
3	幂等回放	工具网关内部，同一个幂等键第二次到达	不会（直接还上次的结果）	一次数据库读
4	重新执行	POST /api/v1/workflows/{id}/runs/{run_id}/replay 等三条路径	会	真的再跑一遍，真的再花钱

四件事共用一个前提：先落库的那份账本是唯一权威。

不是日志。不是事件流。不是控制台里那个正在滚动的 SSE。是数据库里那几张表。 这句话听起来平淡，但它决定了上面四种重放里有三种可以做到「进程死了也不影响」。

一、为什么「可重放」这个词需要被拆开

演示的时候，这三句话看起来是同一件事：

• 「你看，这次运行的每一步都在这儿。」
• 「网断了？刷新一下，中间那几步会自己补回来。」
• 「这次结果不对？点重放，再跑一次。」

但它们在工程上完全不同。第一件是读 ，第二件是读加续订 ，第三件是写------ 第三件会真的再调一次模型、再发一次 HTTP 请求、再花一次钱。

把它们混在一个词里的代价是：用户以为「重放」是安全的，结果点下去发了两封邮件。

所以下面的顺序是按代价排的，从最便宜的开始。

二、账本长什么样：五张表，和一个反复出现的 8192

账本一共五张表，都定义在同一个文件里（server/app/kernel/runtime/db/models/runs.py，396 行）：

runs                    一次执行                    Run           :25
run_steps               执行里的一步                RunStep       :120
run_step_tool_calls     一次工具调用的执行控制记录                :180
run_artifacts           这次执行产出的文件          RunArtifact   :242
run_cost_entries        一次计费调用的用量与成本                  :284

另外还有三张跟长任务有关的（models/tasks.py，98 行）：tasks / task_checkpoints / task_events，第七节会用到。

先说结构里最值得注意的一件小事：8192 这个数字在这份账本里出现了三次， 但三次的语义不一样。

第一次和第二次在 run 和 step 上------输入摘要和输出摘要都是截断：

input_summary=input_summary[:8192] if input_summary else None,

第三次在工具调用的结果上------超过 8192 字节不截断，而是转存对象存储， 账本里留 artifact id、字节数和 sha256：

if len(encoded_result) > 8192:
    ...
    artifact = self.trace_writer.create_artifact(
        run_id=record.run_id,
        step_id=record.run_step_id,
        artifact_type="json",
        storage_key=storage_key,
        mime="application/json",
        size_bytes=len(encoded_result),
        sha256=hashlib.sha256(encoded_result).hexdigest(),
        meta={"kind": "tool_result", "tool_call_id": record.tool_call_id},
    )

这个区别很重要，而且是有意的：摘要是给人看的，丢一点没关系； 工具调用的结果是要拿来对账和回放的，一个字节都不能丢。

后面第十二节会讲到，这个区别也带来了一个现在还没处理好的后果。

三、第一种重放：把证据拼回来

最便宜的那种。一个 GET：

GET /api/v1/observe/runs/{run_id}/replay

它做的事一句话说得完：按 run id 把五类记录各查一遍，加上审批和反馈，拼成一个结构返回。 服务实现在 server/app/modules/observe/application/service.py:212，返回的是七个键：

return {
    "run": run,
    "steps": steps,
    "artifacts": artifacts,
    "costs": costs,
    "approvals": approvals,
    "feedback": feedback,
    "trace_spec": to_runtrace_spec(run, steps, artifacts, costs),
}

前六个是原始记录，第七个 trace_spec 是把它们压成一份可以直接喂给追踪系统的结构 （kernel/runtime/runs/exporter.py:88）。这份结构里除了时间线，还有两个汇总： usage_summary（token、嵌入数、重排数、毫秒数、存储字节数、请求数、向量数，七个维度累加） 和 charge_summary（按币种汇总的金额）。

注意这里没有任何「执行」。 这个接口不会碰模型、不碰工具、不产生费用。 它就是一次数据库读。所以它可以在运行结束之后的任何时刻调用， 调一万次和调一次的成本一样。

每一次查询都带着 tenant_id 和 workspace_id 做条件------ 换句话说，跨工作区拿别人的 run 账本这条路在 SQL 层就是不通的。

四、第二种重放：断线之后把漏掉的补上

第二便宜的那种，是给「页面开着、网断了」这个场景准备的：

GET /api/v1/runs/{run_id}/stream?last_event_id=st_xxxx

服务端的处理在 server/app/api/v1/workflow/streaming.py:401。关键的一段：

if last_event_id:
    step_query = select(RunStep).where(
        and_(
            RunStep.id == last_event_id,
            RunStep.run_id == run_id,
            ...
        )
    )
    last_step = db.exec(step_query).first()
    if last_step:
        last_step_time = last_step.created_at
        known_step_ids.add(last_step.id)

steps_query = select(RunStep).where(
    and_(
        RunStep.run_id == run_id,
        ...
        RunStep.created_at > last_step_time if last_step_time else True,
    )
).order_by(RunStep.created_at)

读到这儿我想强调的是它去哪儿取的 ：select(RunStep)------数据库， 不是内存里的环形缓冲区，不是消息队列的消费位点。

这个选择带来的性质是：你可以在运行结束一小时之后带着 last_event_id 来重连， 照样能把中间那几步取回来。 内存缓冲做不到这一点，进程重启就空了； 消息队列做得到，但你得先有一个消息队列。

SSE 的 id: 字段直接用的就是 step 的主键（streaming.py:432）， 所以浏览器的 EventSource 自动带上的 Last-Event-ID 正好就是账本上的行 id， 不需要额外维护一套游标。

另外一个细节值得一提：这个查询显式写了 populate_existing=True， 注释解释得很直白------执行侧是从它自己的 session 写的， 所以这个「跟读」的 session 必须绕过自己之前缓存的实例。 这是那种不写注释三个月后没人看得懂的地方。

五、第三种重放：同一个幂等键第二次来

这一种发生在更低的层次上------工具网关内部，用户看不见。

每一次工具调用在账本上都有一行 run_step_tool_calls。这张表上有三个唯一约束 （models/runs.py:182）：

UniqueConstraint("tenant_id", "workspace_id", "run_step_id", ...)
UniqueConstraint("tenant_id", "workspace_id", "run_id", "tool_call_id", ...)
UniqueConstraint("tenant_id", "workspace_id", "idempotency_key", ...)

第三个是关键。当同一个幂等键第二次进来，而账本上那一行已经是终态：

if existing.status in {"succeeded", "failed"}:
    payload = existing.result_json or {}
    ...
    return ToolExecutionClaim(
        record=existing,
        run_step=step,
        replayed=True,
        cached_response=ToolResponse(
            result=payload.get("result"),
            success=existing.status == "succeeded",
            error=existing.error_message,
            metadata={..., "idempotent_replay": True},
        ),
    )

直接把上次的结果还回去，不再出站。 返回的元数据里带一个 idempotent_replay: True，让上层知道这不是新执行的结果。

如果上次的结果大到进了对象存储，load_cached_response（tool_calls.py:636） 会去把 artifact 取回来，取之前还要把租户、工作区、run、step 四个维度全部核一遍， 对不上就抛 Tool result artifact scope mismatch。

这一层的意义是：上面第四种「真的再跑一遍」之所以敢做，是因为有这一层兜着。 重跑的时候，那些幂等键没变的工具调用不会被真的再执行一次。

六、账本上有一个状态叫「结果存疑」

这是我认为这份账本里最值得单独拿出来讲的设计。

每次认领一个工具调用会拿一个租约（默认 60 秒，工具网关按超时时间放大）。 租约过期意味着执行者可能已经死了。这时候要不要重试？

代码的回答是「看有没有真的把请求发出去」（tool_calls.py:309）：

lease_expired = (
    existing.lease_expires_at is not None
    and _aware_utc(existing.lease_expires_at) <= now
)
if lease_expired and existing.outbound_started_at is not None:
    existing.status = "in_doubt"
    ...
    raise ConflictError("Tool call outcome is in doubt")
if lease_expired and existing.outbound_started_at is None:
    existing.status = "claimed"
    existing.attempt_count += 1
    ...

两条分支，分界线是 outbound_started_at 这一个字段：

• 还没出站就死了 → 安全，重新认领，尝试次数加一。
• 已经出站了才死 → 标成 in_doubt，不重试 ，同时把对应的 step 置为 paused， 然后抛冲突错误。

第二条分支是这套设计里最诚实的地方。对面是一个真实世界的系统------ 一个下单接口、一封邮件、一次转账。请求发出去了但响应没回来， 我们不知道它成没成，所以我们不猜。账本上留一个「存疑」， 交给人去决定。

自动重试在这种情况下是错的，而且是那种要等到用户收到两封邮件才会被发现的错。

七、第四种重放：真的再跑一遍

这一种会花钱。仓库里有三条不同的路径，机制各不相同。

（1）工作流：重放与重试

POST /api/v1/workflows/{workflow_id}/runs/{run_id}/retry
POST /api/v1/workflows/{workflow_id}/runs/{run_id}/replay

两个接口的实现只差一个判断（modules/workflow/application/service.py:804 与 :821）： retry 要求原 run 是 failed 或 canceled，replay 不要求。 两者都是「取出原来的输入，再执行一次」，然后在响应里带上 source_run_id 和 control_action。

（2）Agent 任务：回放持久化的交互快照

这条路径有意思一些（server/app/wiring/task_drivers.py:82）。 它不是「拿输入再跑」，而是把上次那条 ResponseInteraction 快照取出来， 故意把属于上一次尝试的标识符全部摘掉，再排一条新的进去：

execution_json["assistant_message_id"] = generate_thread_message_id()
payload = dict(execution_json.get("payload") or {})
if payload:
    # Drop identifiers that belong to the attempt being replaced so the
    # replay creates its own response, run and task.
    payload.pop("task_id", None)
    payload.pop("run_id", None)

然后把旧任务置为 CANCELED，并在进度里写一个指向新交互的 retried_as_interaction_id。理由注释写得很清楚：留着 queued 会报告一件 这个任务永远不会做的工作。

如果找不到快照，它不会硬跑，而是显式失败并给出一个专门的错误码 SNAPSHOT_MISSING_ERROR_CODE------没有证据就不重放，这条我很喜欢。

（3）知识库摄取：写进账本的重试血缘

这条是三条里唯一把血缘写进 runs 表的（modules/knowledge/application/runtime_service.py:848）：

run = self.trace_writer.create_run(
    ...
    source_run_id=previous_run.id,
    attempt_no=max(previous_run.attempt_no + 1, task.retry_count + 1),
    request_id=f"knowledge-ingest:{task.id}:{task.retry_count + 1}",
)

runs 表上本来就有 source_run_id 和 attempt_no 两个字段，还有专门的索引 ix_runs_scope_source_created。这条路径用上了。

另外两条没有用上。 这是第十二节的第一条欠账。

八、这份账本凭什么可信

前面说「账本是唯一权威」，那就得说清楚它凭什么。三条：

第一，状态更新是条件 UPDATE，不是读改写。 writer.py:375 那段的 where 子句里带着 Run.status == old_status：

result = self.db.execute(
    update(Run)
    .where(
        Run.id == run_id,
        Run.tenant_id == self.ctx.tenant_id,
        Run.workspace_id == self.ctx.workspace_id,
        Run.status == old_status,
    )
    .values(**values)
    ...
)
if result.rowcount != 1:
    ...
    raise RuntimeTransitionError(f"Concurrent run transition rejected: {old_status} -> {target_status}")

两个执行者同时想改同一个 run 的状态，只有一个能成功，另一个会看到 rowcount != 1 然后被拒。不是「后写的赢」，是「有人插队就报错」。

第二，成功是不可逆的终态。 状态机定义在 kernel/runtime/status.py，那张转移表里：

ExecutionStatus.SUCCEEDED: frozenset(),
ExecutionStatus.FAILED: frozenset({ExecutionStatus.RETRYING}),
ExecutionStatus.CANCELED: frozenset({ExecutionStatus.RETRYING}),
ExecutionStatus.EXPIRED: frozenset({ExecutionStatus.RETRYING}),

SUCCEEDED 的可达集合是空的。账本上写下的成功改不回去 ， 连改成失败都不行。失败可以走向 retrying，成功哪儿都去不了。

第三，对外通知走事务性发件箱，不是即时广播。 每次创建 run、更新状态都会往 outbox 里写一条（writer.py:282 等五处）， 这条写入和业务数据在同一个数据库事务里。

而那个即时的事件总线是尽力而为 的，_emit_event 最后一行是：

except Exception:
    return

异常直接吞掉。这个设计是对的：通知失败不能让账本写不进去 。 但它也意味着一件事------核对一律以账本为准，不要以你在事件流里看到的为准。

九、账本是端口的属性，不是循环的属性

上一篇的结论是「治理是端口的属性，不是循环的属性」。 这一篇可以给它加一个平行的结论。

数一下有多少地方在往 TraceWriter 上写：

位置	提及 trace_writer 的次数
kernel/ports/llm/policy.py	57
kernel/ports/storage/policy.py	47
kernel/ports/vector/policy.py	44
kernel/ports/tools/policy.py	15
kernel/ports/plugins/policy.py	12

五个 kernel 端口的策略网关，全都在写同一份账本。

这个事实的含义是：你不需要在 agent 循环里插桩，也不需要在工作流引擎里插桩。 只要一次操作是通过端口出去的，它就会在账本上留下行。 agent 循环调 tool_port.invoke 会留，DAG 工作流的工具节点调同一个 tool_port.invoke 也会留，而且留在同一张表里、用同一个 schema。

反过来说也成立，而且这是这套设计的真实边界 ： 绕过端口直接发出去的调用，账本上不会有。 这不是 bug，是分层的必然结果------ 账本记的是「经过治理层的操作」，不是「这个进程做过的所有事」。

十、平台自己算的那个布尔值

前面讲的都是机制。但用户真正想问的是一个更简单的问题： 我这次运行，证据够不够？

GET /api/v1/runs/{run_id} 会返回一组治理证据，一共 13 项 （kernel/runtime/runs/service.py:530 起）：

actor_scope        subject_version     capability_binding   permission_scope
secret_boundary    egress_policy       audit_record         cost_attribution
trace_timeline     tool_call           knowledge_citation   child_workflow
replay_ready

最后那一项 replay_ready 就是那个布尔值。它的判据在 service.py:516：

replay_missing: list[str] = []
if not steps:
    replay_missing.append("steps")
if response_timeline_applicable and not response_events:
    replay_missing.append("response_events")
if cost_attribution_applicable and not cost_entries:
    replay_missing.append("costs")
if knowledge_citation_applicable and not citations:
    replay_missing.append("citations")
if tool_governance_applicable and not tool_calls:
    replay_missing.append("tool_calls")
if tool_governance_applicable and not audits:
    replay_missing.append("audits")

注意那几个 _applicable 前缀：它是按这次 run 实际做过什么来判定的 。 一次纯聊天的 run 没有工具调用，不会因为「缺 tool_calls」被判不合格； 但一次调过工具的 run，如果账本上没有对应的审计记录，就会被判 fail， 并且在 missing 里点名缺的是哪一类。

我觉得这比在文档里写「支持完整回放」有用得多。它是一个能被查询的字段， 不是一句形容词。 而且它会失败------如果它永远返回 pass，那它就没有意义。

十一、账本里留的是指纹，不是原文

一份要长期留存的账本，最怕的是它自己变成一个泄密面。

处理办法在 tool_calls.py:59 起。参数写进账本之前先过一遍脱敏， 键名匹配 16 个敏感词之一就替换成 [REDACTED]：

api_key       apikey          access_token   authorization
client_secret cookie          credential     password
private_key   refresh_token   secret         secret_access_key
session_token token           x_api_key

（键名比对前会先做规范化------驼峰拆词、非字母数字统一成下划线， 所以 apiKey、API-KEY、api_key 会被同样对待。）

有一个例外分支值得注意：如果这个键的值是一个带 secret_id 的字典， 不脱敏------因为那已经是一个引用，不是明文，把它抹掉反而让账本失去了 「这次用的是哪个密钥」这条关键信息。

然后是大小控制。超过 8192 字节的参数不入库，改成留三样东西：

return {
    "truncated": True,
    "size_bytes": summary["size_bytes"],
    "request_hash": summary["payload_hash"],
    "argument_names": sorted(str(key) for key in value),
}

注意 request_hash 算的是脱敏之前的原始参数 （canonical_request_hash 对原值做 sort_keys 的紧凑序列化再 sha256）。

这个安排的效果是：账本上没有原文，但幂等性判定照样成立 ------ 同一个幂等键第二次来，比对 request_hash 就知道是不是同一个请求； 不一致就抛 Tool call identity was reused with different input。

能对账，但泄不了密。 这是我认为这份账本里第二漂亮的设计 （第一是 in_doubt）。

十二、现在还对不上的七个地方

这一节讲的全是我们自己的问题。按影响从大到小排。

① 工作流的 replay/retry 不把血缘写进账本。

runs 表上有 source_run_id 和 attempt_no，还有为它建的索引。 但全仓库 19 个 create_run( 调用点里，只有 1 个传了 source_run_id （就是第七节那条知识库摄取的路径）。

工作流的 replay 走的是 execute_workflow 到 engine.execute， 而引擎里的建 run 调用是这样的（modules/workflow/runtime/engine.py:145）：

run = self.trace_writer.create_run(
    mode=plan.mode,
    subject_kind=plan.subject_kind,
    subject_id=plan.subject_id,
    subject_version_id=plan.subject_version_id,
    input_summary=input_summary,
    run_id=plan.run_id,
)

没有 source_run_id，没有 attempt_no。

后果 ：source_run_id 只出现在那次 HTTP 调用的响应体 里。 调用方要是没存下来，这条「B 是 A 的重放」的关系就没了------ 在账本上查不到，ix_runs_scope_source_created 这个索引也就白建了。

现在能怎么绕 ：调用方自己记响应体里的 source_run_id。 打算怎么修 ：在 replay/retry 这两条路径上把 source_run_id 与 attempt_no 透传到 create_run。我打算提一个 issue，写这篇的时候还没提，所以正文里不挂链接。

② 重新执行用的输入，是被截断过的那份。

第二节说过 input_summary 存进去的时候截到 8192 字节。 而工作流重放取输入的方式是（modules/workflow/application/service.py:151）：

def _load_run_inputs(self, run: Run) -> dict[str, Any] | None:
    if not run.input_summary:
        return None
    import json
    try:
        parsed = json.loads(run.input_summary)
        ...

从 input_summary 里 json.loads。

所以输入超过 8KB 的那次运行，重放的时候会解析失败（截断的 JSON 通常不合法）， 报 Replay requires inputs or a parseable run input_summary。

现在能怎么绕 ：调 replay 的时候显式传 inputs，不要让它去账本里捞 （这两个接口都支持传入参覆盖）。 打算怎么修：大输入走 artifact，像第二节里工具结果那样，账本里只留指针。 同样打算提 issue，写这篇时还没提。

③ generate_ulid() 生成的不是 ULID。

这条源码自己招了（kernel/commons/ids.py:9）：

def generate_ulid() -> str:
    """Generate a ULID-like sortable ID.

    For now, we use UUID4 with prefix. In production, consider using
    python-ulid or similar library for true ULID generation.
    """
    return f"id_{uuid.uuid4().hex}"

UUID4 是随机的，完全不可排序。函数名和 docstring 里的 sortable 都不成立。

影响有限但真实 ：所有按时间排序的地方都只能靠 created_at， 不能靠 id。第四节那个断线补帧就是这么写的------它没有用 id 比较， 用的是 created_at > last_step_time。可以说是被迫的正确写法。

④ 断线补帧用的是严格大于。

接上一条。created_at 由 Python 侧的 datetime.now(UTC) 生成， 而过滤条件是 RunStep.created_at > last_step_time。

理论上的后果：如果两个 step 拿到了完全相同的时间戳， 而客户端最后收到的是其中一个，那么另一个会被这个严格大于漏掉。

写这篇的时候我没有构造出这个场景 ------现代 Linux 上 datetime.now() 的分辨率到微秒，同一个 run 内两步撞上同一微秒需要很特殊的条件。 所以这条我列在这里是作为「设计上的脆弱点」，不是「已观测到的 bug」， 请不要把它当成后者传播。修法也简单：等 ③ 修好之后按 (created_at, id) 复合排序。

⑤ 账本里的 id 前缀有三种形态。

因为 generate_ulid() 返回的字符串本身带 id_ 前缀， 所以在它外面再套一层前缀的地方会变成双前缀：

表	生成方式	实际长相
run_step_tool_calls	f"rstc_{generate_ulid()}"	rstc_id_xxxx
tasks	f"task_{generate_ulid()}"	task_id_xxxx
run_cost_entries	default_factory=generate_ulid	id_xxxx

三种都能用，只是不好看，而且第三种完全看不出是什么表的行。 纯观感问题，不影响功能，但你在账本里翻记录的时候会注意到。

⑥ Run.status 的注释只列了 6 个状态，实际有 11 个。

模型上那行 docstring 写的是（models/runs.py:79）：

"""Status: queued, running, paused, succeeded, failed, canceled."""

而 ExecutionStatus 枚举里有 11 个：上面 6 个之外还有 preparing、 waiting_input、waiting_approval、retrying、expired。 step 那边还多一个 skipped。

后果：照着这行注释写客户端的人会漏掉 5 个状态。 文档漂移，改起来一行的事。

⑦ 控制台上那行 soit runs replay 是示意文案，仓库里没有这个 CLI。

run 详情页的适配器里有这么一段（web/app/console/adapters/run-detail.ts:227）：

ledger_code: {
  command: `soit runs replay ${run.id} --dry-run`,
  output: `replaying ${detail.steps.length} steps · verdict on record: ${run.status}`,
},

这是渲染在页面上的一个代码展示块，用来说明这一屏在讲什么。 但 soit 这个命令行工具在开源仓库里不存在 ------server/pyproject.toml 里没有 [project.scripts]，server/scripts/ 下也没有对应的入口。

真正能用的是第三节那个 HTTP 接口。仓库里确实有一个叫 replay 的脚本， 但它是给发件箱用的（server/scripts/replay_outbox_event.py，41 行， 把一条终态失败的领域事件放回待发队列），跟 run 重放不是一回事。

这条我犹豫过要不要写。 写了显得我们连自己控制台上的文案都没对齐； 不写的话，读者照着截图敲命令会一脸问号。最后决定写------ 演示文案和真实能力之间的差距，是读者最有权知道的那一类信息。

坦白局

• 本篇没有新的实跑 。全部结论来自静态阅读 soit/ 仓库 fb46f20 这个提交， 以及仓库里已有的测试。我没有起一套环境跑一次 run 再去调 replay 接口。 本文的每一条论断都标了文件和行号，欢迎直接去仓库核对。
• 第十二节的 ④ 是推论，不是观测。我没有构造出两个 step 撞同一时间戳的场景， 它列在那里是因为设计上不该依赖时间戳唯一，不是因为我们见过它出问题。
• 「重放」不保证同样的结果。第四种重放是真的再跑一遍------模型有温度、 工具对面是真实系统、外部数据会变。我们保证的是「同样的输入、同样的治理策略、 完整的证据」，不是「同样的输出」。仓库里没有录制回放式的工具打桩机制。
• 本文讲的是社区版 。上面每一处代码路径都在 github.com/soit-ai/soit 里， 可以直接读。
• 利益相关：我是 SOIT 的维护者。

一句话结论

「可重放」在我们这儿不是一个形容词，是一个由平台自己计算、可以被查询、 而且会返回 fail 的字段------它背后是五张数据库表、四条不同代价的重放路径， 和一个愿意承认「我们不知道对面做没做」的状态。

来试试，也来挑刺

仓库在 github.com/soit-ai/soit。如果你想验证这篇里的说法：

1. 跑起来之后随便发起一次对话，拿到 run_id；
2. GET /api/v1/runs/{run_id}，看那 13 项证据里 replay_ready 是 pass 还是 fail， fail 的话 missing 里写着缺什么；
3. GET /api/v1/observe/runs/{run_id}/replay，看那七个键里都有什么。

第十二节那七条如果你发现我说错了任何一条，欢迎直接开 issue 打脸------ 比起被夸「设计得好」，我更需要知道哪里对不上。