先看记录，再做判断
生产运行时不能只看最终回答。你通常还需要 requests、sessions、approvals、health 和 event history，才能判断下一步应该怎么处理。
const unsubscribe = subscribe(runtime, (event) => {
console.log(event);
});
const requests = await listRequests(runtime);
const sessions = await listSessions(runtime);
const approvals = await listApprovals(runtime);
const health = await getHealth(runtime);常见处理顺序
- 任务运行时先订阅事件。
- 任务暂停或结束后查看持久化的 requests、sessions 和 approvals。
- 通过 runtime API 处理审批，不直接操作 checkpoint。
- 结合 artifacts、events 和 health 判断是继续、恢复、重试还是升级处理。
审批如何处理
遇到人机协同中断时，你会看到批准、拒绝和备注这些产品层动作，而不是一堆 backend 恢复细节。
await resolveApproval(runtime, {
sessionId,
requestId,
approvalId,
decision: "approved",
message: "ok"
});做出批准、拒绝或补充说明等清晰决策。
通过托管的 resume 逻辑继续运行，而不是把 checkpoint 操作暴露给你。
恢复如何工作
进程重启后的恢复、审批后的继续执行，以及内部 resume 逻辑都由运行时托管。对使用者来说，更重要的是运行能不能继续，而不是内部用了哪一套补救动作。
恢复规则
你会看到 requests、approvals 和 outcomes，而不需要直接处理 checkpoint internals。
持久化与证据包
只有证据能保留下来，运维和排障才可靠。requests、sessions、approvals、events 和 artifacts 应该在任务结束后、进程重启后、甚至事故复盘时仍然可检查。
Requests、sessions、approvals、events、queue state 和 health projection。
文件、导出的证据包，以及与某次运行绑定的稳定产物。
排队与并发
上游框架可以定义执行层并发语义，但应用运行时层的调度、隔离、维护和审批流仍然由 `agent-harness` 负责。
这里会处理的事情
- Request queue 的准入和回压。
- 并发工作之间的隔离与可见状态。
- 保证恢复和持久化健康的维护策略。
- 与其他运行并存的审批暂停机制。
日常最需要看什么
日常运行时，最重要的是清楚状态、能回看历史、也能把一次 request 连到日志、trace、审批决策和失败处理路径上。
因此，产品通常会直接暴露 runtime health、审批队列、request tail 和 trace-export metadata，而不是把这些动作留给零散脚本。
CLI 也不该只停在原始 JSON。你最好能一眼看出失败 checks、待处理审批、stuck requests、当前 delegated agent 和最近活动时间。
最小事故处理流程
- 先找到受影响的 request 和 session。
- 查看 event stream 与当前 approval state。
- 如果跨多个系统，连 artifacts 和导出的运行时证据一起检查。
- 判断下一步是审批、重试、恢复还是修代码。
- 如果问题具有系统性，就把策略、文档和测试一起补上，而不是只救这一次运行。
agent-harness runtime overview --workspace .
agent-harness runtime health --workspace .
agent-harness runtime approvals watch --workspace . --status pending --once
agent-harness runtime requests tail --workspace . --once
agent-harness runtime export request --workspace . --session session-123 --request request-456 --artifact-contents --health