研究报告 · 约 36,461 字 · 预计推送 4 部分

Agent 任务可靠性工程：幂等、断点续跑、补偿、超时与人工接管（横纵综合报告） 未开始

目录

题记与说明

撰写日期：2026-11-03
本文由同日两份章节稿综合而成：纵轴稿《Agent 任务可靠性工程——幂等、断点续跑、补偿、超时与人工接管的发展历程》（历时轴，1950s–2026）与横轴稿《竞品/同类/替代方案横向对比》（共时轴，2026-11-03 时间截面）。综合稿消除了两稿之间的重复与口径不一致（统一贯穿案例、统一 Temporal 补偿/幂等的评级口径，见正文标注），关键事实保留来源 URL，未能核实之处在文末集中声明。
最终稿说明：本稿为按独立审读意见修订后的最终稿（2026-11-03）。相对初稿的主要修订：①交叉洞察的证据边界收紧——推断超出文本处显式标注"本课题外推"，可靠性判断口径统一为"水平低、建设滞后"（非趋势降）；②"五支柱×五类玩家"改为如实的"4+1"表述；③Airflow HITL 表述与评级对齐；④能力总表补偿列补评级判据、Pydantic AI 行改"随所选引擎评级"；⑤历史日期论断补官方出处（AgentKit 公告页另注组件停用更新）；⑥NightBatch-50w 参数闭环（补 800 条低置信度来历、区分两个窗口口径）；⑦分期交叠加说明、交叉洞察 §2 去重；⑧新增"落地第一步"专节（幂等键/意图表/补偿登记最小骨架、夜批成本量级）并在首次引用处补 Zylos 来源定性。初稿保留于 drafts/ 目录，未作改动。
贯穿案例：夜间批处理系统。纵轴用它串起五个概念的演化史，横轴用它派生出具体负载 NightBatch-50w 与"夜批五问"作为统一探针。

TL;DR

Agent 任务可靠性工程是把 1970 年代批处理的五个概念——幂等键、检查点续跑、Saga 补偿、超时窗口、人工值班——搬进 LLM 工具循环：语义未变，载体三迁（数据库内核→框架→协议→agent 运行时）。2026 年截面上的实况是"4+1"：四个支柱各有其主，且集中在三类玩家——B 类持久化执行引擎拿走断点续跑与超时，A 类批处理编排平台拿走分区幂等与审计（Airflow 3.1 还补上了 HITL 审批），C 类 Agent 框架拿走检查点与中断审批；D 类托管平台的招牌是托管与按量计费而非支柱本身，E 类替代范式用成本、检测、人审换可靠性。第五个支柱——补偿——无人认领，是全生态最大空位。检查点≠副作用记录是共同盲区。落地分三档：纯生成用 Batch API；有副作用以持久化引擎为骨架、工具幂等化并登记补偿链；强合规加审批门与审计。夜间批处理是默认验证负载。落地第一步（幂等键格式、"发送意图表"与补偿登记表的最小骨架、夜批成本量级估算）见交叉洞察之后的专节。

纵轴：发展脉络——五个可靠性概念从银行机房到 Agent 运行时

0. 为什么用"夜间批处理"做贯穿案例

夜间批处理是这五个可靠性概念的天然试验场，也是它们最早、最集中的落地形态：

概念夜间批处理中的原型
幂等批量扣款任务重跑不得重复扣款——业界通行做法以"会计日期 + 任务编号"作幂等键，重跑前先查执行状态表（银行日终批处理对账系统实战（知乎））
断点续跑跑批按步骤/分片记录 checkpoint，失败后从最后提交点重跑（Spring Batch 的 chunk 模型，见阶段三）
补偿批量中失败的交易用冲正交易回滚，冲正本身也必须幂等；日终对账差错进入次日处理（7×24 核心系统设计（博客园））
超时跑批窗口硬约束：凌晨 0:00–6:00 必须结束，否则"日切"失败，第二天营业无法开始（银行核心系统 7x24 方案（fintx PDF）、ITPUB：24 小时机制实现）
人工接管跑批失败 → 监控告警 → 值班人员按 runbook 手工干预 → 差错工单，这是最古老的 human-in-the-loop

横轴稿将这一案例具体化为 NightBatch-50w（口径说明：上表的 0:00–6:00 是行业通行的跑批窗口原型，本案例为自身设定把窗口收窄为 02:00–06:00）：每晚 02:00 启动，读取当日 50 万条交易，逐条调用 LLM 生成摘要与风控标记写库，其中约 800 条低置信度摘要需人工复核（"夜批五问"之五与人工接管落地一节的数字出处），另对约 4,000 条高风险项自动发送告警邮件，06:00 前完成，全程无人值守。它同时具备长时间窗（4 小时）、无人值守（凌晨）、副作用密集（写库 + 发邮件）、失败代价滞后（清晨才发现）四个特征，因而最能暴露五支柱的缺口。Agent 时代的可靠性工程，本质上是把这五件事从"银行机房"搬进"LLM 的工具调用循环"。

阶段〇（1950s–1970s）：批处理与"操作员"——人工接管是最古老的一环

主要参与者：IBM（OS/360/JCL）、贝尔实验室、Paul Vixie。驱动因素：硬件与机时昂贵，业务允许隔夜出结果——可靠性靠操作员手册（runbook 雏形）、磁带备份与值班操作员。"人工接管"在此时不是兜底机制，而是执行机制本身：任务失败时，是人在机房里换磁带、重跑作业。

阶段一（1978–1991）：事务处理理论奠基——ACID、两阶段提交与 Saga

驱动因素：银行联机系统（ATM、柜面）要求跨资源原子性，但长事务锁表拖垮并发 → Saga 用"补偿"换吞吐。与夜批的映射：银行日终批量（计提结息、总账汇总）正是"长事务"的极端形态——天然无法全程持锁，于是行业用对账 + 冲正在批处理层面模拟原子性，这是 Saga 思想在业务侧的并行演化。

阶段二（1990s–2007）：中间件工程化——死信队列、幂等方法与"活动"模型

驱动因素：互联网规模化后，跨数据库 2PC 代价过高，可靠性的实现位置从"数据库内核"上移到"应用与消息层"。与夜批的映射：日终对账文件传输丢失 → 用同一文件名/批号重传，接收端凭幂等键去重；对不上的流水进差错文件，次日人工或半自动冲正。

阶段三（2003–2016）：云与大数据——重试、超时、断点续跑被"框架化"

五个概念从"论文与手工"变成"框架默认值"的阶段。（分期说明：本阶段区间自初稿的"2007–2016"改为"2003–2016"，以与首条 GFS/MapReduce 论文的实际年份对齐；它与阶段二在 2003–2007 区间存在交叠——阶段二以 2007 年 Helland 一文收官，那是中间件时代幂等理论的顶点；本阶段以 2003/2004 年 GFS/MapReduce 开篇，那是"框架替你做可靠性"的起点。分期按主题演进衔接，不按严格年序切分。）

驱动因素：云故障常态化（"一切皆会失败"）、微服务拆分、夜间 ETL 规模化。可靠性工程的重心从"防失败"转向"失败后自动恢复"。

阶段四（2016–2022）：Durable Execution 成熟——概念被"平台化"（口径统一说明见内文）

口径统一说明：纵轴稿曾写 Temporal 把"补偿"平台化，横轴稿则将 Temporal 的补偿评为 △（用户代码、无专门原语），并引用实践者原话"Temporal/Restate 解决的是 durability（崩溃后续跑），而不是 compensation（撤销已完成步骤）"（Reddit 帖）。两说并不冲突，本综合稿统一为：Temporal 平台化的是补偿的"执行保证"与官方样本（Saga class、补偿 cookbook——失败时登记的补偿代码一定会被调用），而非"补偿语义"本身；补偿逻辑仍是用户代码，因此横轴评级维持 △。同理，Temporal 的幂等评级为 ○：确定性重放让工作流代码"逻辑上只执行一次"，但 activity 层是 at-least-once，写库、发信等外部副作用仍需业务幂等键（Temporal Activity 文档）。

驱动因素：微服务编排复杂度失控 + 慢业务（网约车行程本身就是持续数分钟到数小时的"事务"）。与夜批的映射：跑批逻辑一旦写成 durable workflow，宕机自动从事件历史重放恢复；值班工程师从"凌晨被电话叫起来手工重跑"变成"早上看控制台回放"。夜间批处理第一次可以"自己从昨夜的中断点上醒来"。

阶段五（2022–2024）：LLM Agent 诞生期的可靠性危机

驱动因素：模型能力（长上下文、工具调用）到位，但 pass@1 尚可、pass^8 崩塌；AutoGPT 式的失控循环让"能力展示"让位于"可重复的成功"。可靠性第一次成为 agent 的显式工程学科。

阶段六（2025–2026）：可靠性工程正式成为 Agent 工程学核心

驱动因素：任务时长从分钟级跃升到小时/天级（METR 时间视界翻倍曲线），"无人监督长时间自主工作"成为产品默认形态（夜间 agent 跑批）；而 pass^k、24%、11.4% 这些数字反复证明：能力问题在收敛，可靠性问题在放大——这里"放大"指可靠性水平本就低、且与能力提升的差距在拉大，而非"可靠性正在变差"的趋势判断。

收束：夜间批处理的三个时代与贯穿规律

  1. 机房时代（1960s–2000s）：银行日终跑批——幂等键（会计日期+任务号）、步骤 checkpoint、冲正、跑批窗口（超时）、值班操作员。可靠性 = 人 + 手册。
  2. 框架时代（2010s–2020s）：Spring Batch/Airflow/Temporal 的夜间 ETL——backfill 即续跑，durable workflow 即自愈，SLA miss 即超时告警，on-call 即接管。可靠性 = 框架默认值。
  3. Agent 时代（2025–2026）：Claude Code routines、后台编码 agent、夜间 Deep Research——同一套概念换了载体：事件历史/会话存档 = checkpoint（/rewind、LangGraph checkpointer、Temporal 重放）；审批门 = 人工接管（hooks allow/ask/block、input-required、Take Control Mode）；工具 idempotency_key = 批量扣款幂等键；预算与时间视界 = 跑批窗口；晨间 PR 审查 = 日终对账。

贯穿性规律：

横轴：横向对比——2026-11-03 时间截面的五支柱竞品图

评级口径（承自横轴稿）：表格评级（◎ / ○ / △ / ✗）是对官方文档所示能力的文档级判断，不是压测结论：◎ = 官方一等原语；○ = 有官方支撑、需自建薄层；△ = 社区模式/部分覆盖；✗ = 本次检索未见官方原语，基本靠开发者自理。产品迭代很快，引用前请按来源链接复核。

1. 对比框架：五支柱定义与"夜批五问"

支柱一句话定义反面（没有它会发生什么）
幂等同一操作执行多次，副作用只发生一次重试导致重复写库、重复发信、重复扣费
断点续跑进程崩溃/重启后，从失败点继续而非从头再来50 万条的批次在第 49 万条崩掉后全部重跑
补偿已完成的步骤在后续失败时被显式"反向撤销"（Saga）已发出的告警邮件无法作废、已写入的标记无法回滚
超时挂死/慢死的单步被检测、取消、重试或降级一条 LLM 请求卡 10 分钟，拖死整批
人工接管流程能停在"安全点"等人批准/改写，再用人的输入继续凌晨无人值守时，低置信度输出直接流到生产

五个支柱化作对 NightBatch-50w 的五问，作为逐项对比的统一探针：

  1. 幂等之问：02:40 一个 worker 宕机重启，已处理的 12 万条会不会重复写库、重复发邮件、重复计费？
  2. 续跑之问：03:17 上游 API 限流导致整批失败，修复后重跑，是从断点继续，还是重跑 50 万条（再烧一遍 token 钱）？
  3. 补偿之问：06:30 复盘发现 prompt 版本有缺陷，已发出的 4,000 封告警邮件是误报——平台能帮我们"撤销"吗？
  4. 超时之问：某条 LLM 调用挂死 10 分钟，谁在多长时间后发现它、杀掉它、重试还是降级？
  5. 接管之问：800 条低置信度摘要要人复核，人批准后流程继续；凌晨没人时流程必须停在安全点，而不是挂死或瞎跑。

2. 竞品分类学：五类"同类/替代方案"

类别产业传统代表核心主张
A 类·批处理编排平台数据工程/调度Apache Airflow 3.1、Prefect 3、Dagster夜批的"原生栖息地"：调度、重试、回填、审计已成熟，Agent 只是新任务类型
B 类·持久化执行引擎分布式系统Temporal、AWS Step Functions、Restate、DBOS、Inngest、Hatchet 等把"崩溃后续跑"做成运行时保证，而非应用层纪律
C 类·Agent 框架内置原语LLM 应用框架LangGraph、OpenAI Agents SDK、Mastra、Pydantic AI、CrewAI/AutoGen/MS Agent Framework在 agent 抽象内部提供 checkpoint、interrupt、审批等原语
D 类·云托管 Agent 平台云厂商一体化Amazon Bedrock AgentCore、LangGraph Platform/Smith、Temporal Cloud托管运行时 + 会话隔离 + 计费，可靠性外包给云
E 类·替代范式各种① Batch API 直跑 ② 观测/评估驱动（LangSmith/Langfuse/Braintrust） ③ 审批即服务（HumanLayer）与低代码 HITL（n8n） ④ 冗余/投票/LLM-as-judge ⑤ "重试+换模型"裸奔派不做执行层工程，用别的机制（成本、检测、人审、冗余）换可靠性

注意：A/B/C/D 存在大量交叠（Pydantic AI 可跑在 Temporal 上；LangGraph 有官方 Temporal 集成；Airflow 3.1 已于 2025-09-25 补上 HITL——见 §3 其人工接管列的 ◎ 评级与出处）。分类依据是方案的"主传统"，而非互斥边界。

3. 能力对比总表（五支柱 × 方案）

图例：◎ 一等原语 ｜ ○ 有支撑需自建薄层 ｜ △ 社区模式/部分覆盖 ｜ ✗ 未见官方原语 ｜ N/A 不在其职责范围。

补偿列单独判据（该列口径分歧最大，补充如下）：◎ = 平台内置补偿原语/自动补偿编排（本次检索无一方案达到，全生态没有一处 ◎）；○ = 官方文档给出成体系的补偿接线模式，需手工接线（如 Step Functions 官方 Catch 状态链、Prefect 事务回滚钩子）；△ = 仅官方样本/指南级材料、补偿本身仍是用户代码（Temporal 官方 Saga 样本、Restate Sagas 指南），或只能撤销框架内状态、外部副作用撤不回（LangGraph 的 rewind/time-travel——与"显式反向撤销副作用"的支柱定义尚有距离，故 △；其余 C 类框架连状态回滚的官方材料都没有，故评 ✗），或虽有官方持久化/事务原语可承载补偿、但无补偿专文，补偿逻辑需完全自建（部分覆盖）（DBOS 的事务性 Postgres 步骤日志、Inngest 的步骤记忆化）；✗ = 未见任何官方补偿材料。

方案类幂等断点续跑补偿超时与重试人工接管
Temporal（含 Cloud）B○ 活动"至少一次"，业务幂等自建；工作流代码确定性重放◎ 事件史 + 确定性重放△ 补偿以用户代码表达（官方 Saga 样本），无专门原语◎ StartToClose / Heartbeat / ScheduleToClose 三层超时 + RetryPolicy◎ Signal / Update + 持久定时器，官方 HITL cookbook
AWS Step FunctionsB○ 靠任务设计（如 DynamoDB 条件写）◎ redrive 从失败点重启；Distributed Map 只重跑失败的子工作流○ Catch 显式接补偿状态链◎ Task 级 TimeoutSeconds + 默认重试 3 次指数退避 + JitterStrategy○ 回调令牌（wait-for-task-token）等外部事件，可接人工审批，无内置审批 UI
RestateB◎ 日志化 ctx.run 步骤 + 内置幂等键◎ journal 重放△ 官方 Sagas 指南最成体系（补偿链反序执行、两段式 reserve/confirm），但补偿本身是用户闭包○ 持久定时器 / awakeables 一等公民○ awakeable 等外部事件，可承载 HITL
DBOSB○ 步骤日志存 Postgres◎ 轻量库（非独立服务），状态全在 Postgres△ 无专门原语，需自建○△ 有 OpenAI Agents 集成；审批原语未见专门文档
Inngest（含 AgentKit）B◎ step.run 结果记忆化 = 天然幂等；并发/节流控制内置◎ 步骤记忆化 + 断点续跑△ 无 Saga 级文档，错误按步处理◎ 持久 sleep、waitForEvent 带超时、重试策略○ waitForEvent 等人
HatchetB△ 普通任务"至少一次"，幂等靠开发者（其文档自述）○ 持久事件日志✗○ 持久定时器/事件△
Apache Airflow 3.1A△ 靠 logical_date/分区键的开发者纪律△ 任务级重试；子集重跑靠 clear，无步骤级✗○ execution_timeout 每次尝试独立生效 + Deadline 提醒（注意"超时未必杀死底层查询"的坑）◎ 3.1（2025-09-25）新增 4 个 HITL deferrable operator + common-ai provider 的 HITL Review（审批 agent 输出）
Prefect 3A◎ 事务 + 幂等键（commit/rollback 语义）○ 任务缓存 + 重试○ 事务回滚钩子是补偿的雏形○✗
DagsterA◎ 分区（partition）= 幂等单位，回填天然安全○ RetryPolicy 声明式 + 资产重跑✗○✗
LangGraph（含 Platform）C✗ 工具副作用需自行包装◎ 每 superstep 检查点；生产建议 Postgres/Mongo checkpointer；time-travel△ 无补偿原语；可 rewind+fork，但外部副作用撤不回✗ 节点级超时需自行包装◎ interrupt() + Command(resume=...)；HITL 强依赖持久 checkpointer
OpenAI Agents SDKC✗○ sessions 持久化运行状态✗✗△ guardrails（tripwire）+ 工具调用人工审批，运行可暂停
MastraC✗○ workflow 状态存 LibSQL/Postgres，suspend/resume✗○◎ suspend()/resume() + 工具审批 HITL（已知限制：带 suspend 的工作流暂不能被 agent 调用）
Pydantic AIC随所选引擎评级（见对应行）随所选引擎评级（Temporal/Restate/DBOS 为 ◎，Prefect 为 ○）随所选引擎评级（见对应行）随所选引擎评级（模型请求与工具调用跑成 activity/step）随所选引擎评级（经引擎的 Signal/中断实现，见对应行）
CrewAI / AutoGen / MS Agent FrameworkC✗○ 各自 memory/flow 持久化（AutoGen 有 Magentic-One ledger）✗✗△ CrewAI human_input、AutoGen UserProxy，非持久审批
Amazon Bedrock AgentCoreD△ 托管运行时不负责编排幂等○ 会话隔离 microVM + 托管会话存储（2026-03 preview）✗○ 托管弹性 runtime（2026-09 新版）△ 未见专门审批原语文档
n8nE△ 节点级重试 ≠ 步骤记忆化；社区指出失败执行重试不会自动从失败步骤续跑△✗△ 节点超时；"卡死重试"先于 error 分支触发，难以被错误工作流捕获◎ 原生 Human-in-the-loop for tools：暂停等审批后继续
OpenAI / Anthropic Batch APIE○ custom_id 关联请求与结果，失败单条可控重提△ 服务托管逐条状态✗△ 24 小时窗口 SLA，非细粒度超时（Anthropic 明示批量 5 折）✗
HumanLayerEN/AN/AN/AN/A◎ 审批即服务：API 把审批路由到 Slack/邮件，人批后 agent 继续（2026-10 仍在活跃发版）
LangSmith / Langfuse / BraintrustE✗ 检测失败 ≠ 恢复失败✗✗✗✗（提供人工标注/评审队列，但不驱动执行）

4. 成本与生态要点（2026-11 检索值，部分为第三方汇总，以官网为准）

5. 五支柱逐项深读：谁强、谁缺、夜批怎么办

幂等——两派做法。运行时记账派（Inngest 步骤记忆化、Restate journal 步骤 + 内置幂等键、Temporal 确定性重放让业务代码"逻辑上只跑一次"、Prefect 事务幂等键）：平台替你记账"这一步做没做过"。开发者纪律派（Dagster 分区键、Airflow logical_date、LangGraph/OpenAI SDK 完全自建）。第三方调研的行业忠告值得整段引用："检查点只告诉运行时它在哪里，不告诉它副作用是否已发生"；每个有变异副作用的工具都应成为事务边界——"先记录意图、再执行、落持久化回执"，并引用 Stripe 幂等键、Lambda Powertools 幂等工具与 Outbox 模式（Zylos 调研。来源定性（最终稿补）：Zylos 是一家构建持久化 agent 系统的 AI 产品公司，该文是其官网 Research 栏目 2026-04-24 发布的技术综述，属厂商研究而非独立第三方调研——其生态梳理部分与本课题引用的官方文档可交叉印证，但结尾明确落回"这对 Zylos 式 agent 意味着什么"的产品视角，页面亦无作者署名与机构自我介绍；引用其判断时应知悉此利益相关。本课题引用该调研的关键判断处，均另附官方文档或一手帖子对照；§7 的五条盲点为其独有总结、无其他来源可交叉验证，应按"单一厂商调研"的置信度对待）。夜批落地：写库用 upsert、发邮件先写"发送意图表"再投递、对外计费调用统一带幂等键——无论选哪列方案，这三件事都逃不掉（这与纵轴阶段六"幂等键必须在重试循环之外生成"的 2026 社区共识同源；幂等键格式与意图表字段的最小骨架见文末"落地第一步"）。

断点续跑——三档实现。服务托管状态（Step Functions redrive + Distributed Map 跳过已成功子项，AWS 文档）＞ 引擎重放（Temporal 事件史、Restate journal、DBOS Postgres）＞ 图/框架检查点（LangGraph 每 superstep）。Zylos 调研特别警告：图检查点必须被工程化为"重放边界"——例如 LangGraph 中 interrupt 之前的代码可能在恢复时重跑，检查点不等于事务边界；这正是纵轴阶段五记录的"resume 时工具双重执行"问题的机制解释。夜批落地：绝不要把"整批"塞进一个 task/一个节点；按"单条交易 = 一个 activity/步骤/分区"建模，断点续跑与计费优化同时成立。

补偿——全生态最弱的一环，也是本课题最大的差异化空间。最重要的行业判断来自实践者："Temporal/Restate 解决的是 durability（崩溃后续跑），而不是 compensation（撤销已完成的步骤）"（Reddit 帖：为 Spring AI 自建 Saga 补偿库），与本课题分类学一致。生态现状：Restate 文档最完整（业务逻辑放 try 块、抛 terminal error 触发补偿、补偿闭包按完成顺序累积失败时反序执行、两段式 API 先 reserve 再 confirm、一次性 API 先注册带幂等键的补偿再执行动作、补偿本身必须幂等——Restate Sagas 指南）；Step Functions 靠 Catch 显式接补偿状态链，可行但要手写全部接线（AWS 错误处理文档）；Temporal/DBOS/Inngest/各 C 类框架的补偿=用户代码；LangGraph 的 rewind/time-travel 只能回滚"图内状态"，撤不回已经发出的邮件。夜批落地：4,000 封误报邮件的"补偿"本质是业务动作（发更正邮件、作废链接、回滚标记）。平台能保证的是"补偿代码一定会被执行"，不会替你发明补偿——每个有副作用的步骤都应同时登记其补偿函数（补偿登记表的最小骨架见文末"落地第一步"）。

超时——B 类成熟度断层领先。Temporal：StartToClose/Heartbeat/ScheduleToClose 三层超时 + RetryPolicy，heartbeat 超时是"发现挂死"的最快手段（Temporal Activity 文档）；Step Functions：Task 级 TimeoutSeconds，默认重试 3 次、1 秒起步指数退避、可配 JitterStrategy（tecracer 解读），但有两个著名陷阱——工作流级超时不能像状态级那样被 Catch 捕获（Stack Overflow 讨论），状态超时后 Lambda 仍在运行、补偿可能与"还活着的副作用"竞态（repost.aws 讨论）——夜批里"杀掉的任务其实还在跑"会直接破坏幂等假设；Airflow：execution_timeout 每尝试独立 + Deadline 提醒，但"超时未必杀死底层查询"（Airflow issue #32512）；C 类普遍无节点级超时原语；n8n 的卡死重试先于错误分支触发，观测性差。夜批落地：单条 LLM 调用设 start-to-close 60–120 秒 + heartbeat 30 秒；整批设 schedule-to-close 兜底（如 4 小时）；供应商 P99 抖动时降级到备用模型而不是阻塞队列。Zylos 调研同时警告嵌套重试会放大成重试风暴：HTTP 客户端 × 框架 × 引擎 × 供应商每层都配重试反而更脆，需要全局重试预算与熔断——这是纵轴"超时从窗口约束变成预算管理"的横轴落地形态。

人工接管——从"聊天消息"到 durable event 的范式迁移（2025–2026 年变化最大的一环）。四条实现路径已分化：① 框架内中断（LangGraph interrupt()、Mastra suspend()/resume()、OpenAI SDK 审批）——与 agent 循环无缝，但持久性取决于外部 checkpointer/存储；② 引擎内事件（Temporal Signal/Update + 持久定时器、Inngest waitForEvent、Step Functions 回调令牌）——审批是持久事件，等一个月也不占进程；③ 编排器内审批（Airflow 3.1 HITL operator + HITL Review，带通知、超时、分支选择，天然接批处理审计，官方博客、HITL 教程、HITL Review provider）；④ 外置审批服务（HumanLayer、n8n 原生 HITL，跨框架复用，但注意 n8n 执行层短板：失败执行重试不会自动从失败步骤续跑——社区帖）。行业对"正确形态"已有初步共识：审批必须是 durable event，而不是聊天窗口里的一条消息——要记录谁、何时、批准的是哪个工件（含哈希/版本）、决定与过期时间（Zylos 调研，来源定性见本节幂等一段）。同时评论界提醒"审批疲劳"：人跟不上 agent 的审批请求频率（Cobus Greyling 评述），第三方开始把审批设计成"按可逆性/影响分级的风控控制面"（ColdAI 指南、Digital Thought Disruption）。夜批落地：800 条低置信度摘要 → 审批队列，每条带过期时间（如 4 小时）；过期未批自动降级为"不发送"而非挂死整批；审批记录（人、时间、工件哈希、决定）入审计表——用 Temporal Signal、Airflow 3.1 HITL 或 HumanLayer 皆可实现，关键是别用微信/Slack 消息本身当状态存储。

6. 夜批场景选型建议（按副作用烈度分三档）

场景夜批形态推荐组合理由
① 纯生成型：只写自己的库，无对外副作用50 万条摘要入库，可重写覆盖LangGraph/Pydantic AI + Postgres checkpointer；或最省钱的 Batch API（5 折、24h 窗、custom_id 断点重提）+ 客户端超时包装副作用幂等可靠"重写覆盖"兜底，框架级 checkpoint 已够；执行引擎是过度设计
② 副作用型：写库 + 发邮件/扣费/改 CRMNightBatch-50w 本体持久化执行引擎为骨架（Temporal 全能 / Restate 要补偿文档 / Inngest 要开箱幂等 / DBOS 要省一个服务），agent 框架只当"大脑"；工具全幂等化；补偿链显式登记（Restate Saga 模式或 Step Functions Catch）五问中续跑、超时、幂等由引擎兜底；补偿目前任何方案都帮不了你，必须自己写
③ 强合规/高风险：金融、医疗、对外承诺类动作夜批含不可逆动作A 类（Airflow 3.1 + 分区幂等 + Deadline + HITL operator 卡在危险动作前）或 Temporal + Signal 人工门 + 全量事件史审计要的是审计轨迹、权限、SLA 与"人签字"的正式性，A 类的传统强项

反面清单（何时不要上重型引擎）：团队 < 5 人且无分布式系统经验时，Temporal 的确定性重放心智负担真实存在（Reddit 实践反馈）；纯 LLM 批处理且可覆盖重写时，Batch API 比任何引擎都便宜；已有成熟 Airflow 资产且动作可逆时，先升级到 Airflow 3.1 的 HITL 比引入新栈划算。

7. 全行业共同盲点（所有"竞品"都没解决的）

据 Zylos 2026-04 对该领域的系统性调研（来源定性见 §5 幂等一段：厂商研究而非独立第三方调研，以下五条为其独有总结，无其他来源可交叉验证），当前整个赛道（含 Temporal/Restate/Inngest/LangGraph 全部阵营）共同缺失的是（Zylos 调研）：

  1. 检查点 ≠ 副作用记录：无一家的 checkpoint 同时回答"副作用是否已发生"（幂等收据仍是应用层责任）；
  2. 全局重试预算：嵌套重试层会放大成重试风暴，缺少运行级熔断与预算控制；
  3. 版本漂移：模型、prompt、工具、沙箱任一变更都可能破坏确定性重放——重放 hazard 无平台级答案；
  4. 恢复测试：故意在"最坏时刻"杀掉运行时的恢复测试套件，几乎没有团队拥有；
  5. 观测数据脱敏：trace 里的上下文可能成为数据泄露向量，行业默认配置普遍未处理。

该调研总结的行业收敛方向是一个五层架构：run/step 日志 → 围绕非确定性的重放边界 → 幂等工具包装 → 持久化人工门 → 恢复测试套件。与五支柱对照，这是部分对应而非"一一对应"，显式映射如下（最终稿补）：

Zylos 五层架构与本课题五支柱的对应
run/step 日志支柱间共享的可观测底座，不单独对应某一支柱
围绕非确定性的重放边界断点续跑
幂等工具包装幂等
持久化人工门人工接管
恢复测试套件无直接对应（五支柱之外的新增维度）
——（五层中无对应层）超时与补偿：超时散落在各层的重试策略里，五层未单列；补偿完全缺席

即五层架构直接覆盖幂等、断点续跑、人工接管三个支柱，超时与补偿没有对应层——补偿的缺席再次印证它是全生态空位。横轴对比的结论是：五支柱里没有任何单一竞品能整体覆盖，它天然是一个"组合工程"课题。

交叉洞察：两轴结合说明了什么、对用户的判断与建议

1. "平台化序列"：每一代基础设施只吃下五支柱中的一部分

把纵轴的演化史与横轴的能力矩阵叠在一起，会看到一个此前两章各自都未能点透的结构：五个概念的"平台化"是有先后顺序的，而这个顺序正在 agent 时代重演。

这个序列对判断 2026 年的产品格局给出一条简明法则：某一环在上一代基础设施里最弱、而在新负载上最疼，它就是下一代产品的机会。补偿正是这个位置——纵轴里它 40 年停留在论文与冲正交易，横轴里它是唯一全生态空缺的支柱，且已有实践者自建库回应（Reddit SpringBoot 帖）。"可补偿的 agent 工具调用协议"是本课题识别出的、最值得压注的细分。

2. 纵轴的"失败模式换皮"与横轴的"共同盲点"互为印证

纵轴收束处已给出"失败模式换皮、对策是老三样"的规律（见纵轴收束第 3、4 条），此处不再重复引子，只保留两轴对照后的增量：把横轴共同盲点五条逐条对到银行跑批的老答案上，并显式标注哪些是纵轴文本内确有出处、哪些是本课题外推（最终稿按审读意见收紧了初稿"全部是 40 年前就有答案的问题"的说法）：

横轴共同盲点银行跑批老答案出处状态
检查点 ≠ 副作用记录执行状态表（幂等收据）纵轴有出处：夜批原型表幂等行（银行日终批处理对账系统实战（知乎））
无全局重试预算跑批窗口（0:00–6:00 日切硬约束）纵轴有出处：夜批原型表超时行（fintx PDF / ITPUB，链接见纵轴 §0）
版本漂移程序版本与数据快照绑定本课题外推，纵轴文本未考据该实践的历史出处
无恢复测试日切/灾备演练本课题外推，纵轴文本仅提及日切约束、未考据"演练"实践
观测脱敏缺失差错文件权限控制本课题外推，纵轴文本仅提及差错文件、未提及权限/脱敏管理

即五条盲点中，前两条是纵轴文本内有出处、40 年前就有答案的老问题；后三条是本课题基于行业惯例的外推映射，合理但未考据——部分是老问题（两条有出处、三条为本课题外推），而非初稿所称"全部是老问题"。在此边界内，两轴交叉得出的结论比单轴更硬：agent 可靠性危机"不是 bug，是架构问题"（AIwire 2026-07）这句话，在时间轴上成立（每一代都重演），在空间轴上也成立（每一家竞品都缺同样五块）。

3. 能力在收敛、可靠性在放大，且可靠性同时是成本问题

三条独立证据链在两轴交汇处闭环：纵轴的 METR 时间视界每 7 个月翻倍（能力上行）对 τ-bench pass^k、TheAgentCompany 24%、AI SRE 真实解决率 11.4% vs 宣称 70%（可靠性水平低、且与能力提升的差距在拉大——与纵轴阶段六"能力问题在收敛，可靠性问题在放大"同一口径，指水平低而非趋势下行）；横轴的 LangChain 2026 调查显示 89% 装了可观测性但仅 52% 跑离线评估——需要说明（最终稿按审读意见修正）：89%/52% 均为检测侧数字，只能证明检测建设的普及程度；恢复侧（补偿、恢复测试）没有任何可比数字，因此本课题的结论限定为"可靠性水平低且建设滞后"，而非"检测能力的普及远快于恢复能力的建设"这类量化对比（LangSmith/Langfuse 在横轴评级中五支柱皆 ✗，因为检测失败 ≠ 恢复失败）。同时，Gartner 2026-08 预测 2028 年 agentic workflow 推理成本增长 5 倍以上，横轴的节点计费对夜批高扇出敏感，纵/横轴共同的案例 NightBatch-50w 里"重跑 50 万条 = 真金白银的 token"（具体量级估算见文末"落地第一步"）——可靠性工程在本课题中从来不只是正确性问题，它就是成本治理：幂等省的是重复执行的 token，断点续跑省的是重烧整批的钱，审批过期降级省的是挂死整夜的算力。

4. 夜批为什么是两轴共同选中的试金石

纵轴用它串起 70 年历史（银行日终 → 大数据 ETL → 夜间 agent 跑批），横轴用它设计五问探针——两轴的选择并不偶然：夜间批处理同时具备长时间窗、无人值守、副作用密集、失败代价滞后四个特征，且经济学敏感。2026 年 Claude Code routines 的出现（2026-04）意味着夜间批处理从比喻变成了 agent 的默认运行形态：晨间 PR 审查就是日终对账，hooks 审批门就是值班操作员，/rewind 就是 checkpoint。用夜批验证可靠性方法，等于在最锋利的场景上测试。

5. 对用户的判断与建议

核心判断：

  1. 五支柱是五张不同的牌；2026 年的实况是"4+1"——四支柱有主且集中在 A/B/C 三类玩家，补偿无人认领。不存在"选一个框架就解决可靠性"的选项，它天然是组合工程。
  2. 补偿是全生态空位；若要在此方向投入，"可补偿的 agent 工具调用协议 + 恢复测试套件"（后者是五层中落地最少的恢复测试层；前者针对的是五层完全缺席的补偿维度，是空位本身而非其中一层）价值最大。
  3. 人工接管的共识形态已经明确：durable event + 过期时间 + 审计记录；新意空间在"按可逆性/影响分级的审批控制面"与审批疲劳治理。
  4. agent 可靠性危机是架构问题：外置评估层、supervisor、记忆治理、结构化审计（AIwire 2026-07 的处方与银行跑批老三样同构）。

分档落地建议（承接横轴 §6）：

无论哪一档，最后一条都相同：把"凌晨 3 点杀进程"写进恢复测试——这是横轴共同盲点里最便宜可补的一块，也是纵轴"日切演练"（本课题外推映射，见 §2 对照表）的直接继承。夜间批处理系统应作为所有方法的默认验证负载。

落地第一步：幂等键、意图表、补偿登记与成本量级（最终稿新增）

三档建议止步于"选型"，读者合上报告后的第一行代码写什么、夜批一晚到底烧多少钱——本节给出最小着落。以下 schema 与估算均为本课题建议的最小骨架/量级示例，非任何厂商官方样例或报价。

1. 幂等键：生成位置与最小格式

2. "发送意图表"最小骨架（PostgreSQL 方言）

CREATE TABLE send_intent (
  idempotency_key  TEXT PRIMARY KEY,   -- nightbatch:alert:2026-11-03-TX000123:v1
  batch_id         TEXT NOT NULL,      -- 批次号（logical_date / run id）
  txn_id           TEXT NOT NULL,      -- 交易号
  channel          TEXT NOT NULL,      -- EMAIL / SMS / WEBHOOK
  intent           JSONB NOT NULL,     -- 待发动作全量参数（收件人、模板 id、变量）
  payload_hash     TEXT NOT NULL,      -- 工件哈希：审批记录与审计用它对账
  status           TEXT NOT NULL DEFAULT 'PENDING',
                                    -- PENDING -> SENT / FAILED / CANCELLED
  attempt          INT  NOT NULL DEFAULT 0,
  approval_id      TEXT,               -- 关联人工审批（低置信度条目），可空
  created_at       TIMESTAMPTZ NOT NULL DEFAULT now(),
  sent_at          TIMESTAMPTZ,
  receipt          JSONB               -- 供应商回执（message id 等）= 副作用收据
);

投递协议三步：①投递前先 INSERT（主键冲突 = 已发送过，直接读回执返回）——这一步把"检查点不知道副作用发没发生"（§7 盲点一）变成数据库事实；②调供应商投递；③UPDATE status/receipt。崩溃恢复时扫 PENDING 且未超 attempt 限额的行继续，SENT 行天然跳过。

3. 补偿登记表最小骨架

CREATE TABLE compensation_registry (
  idempotency_key    TEXT PRIMARY KEY, -- 与被补偿的前向副作用同键
  action_type        TEXT NOT NULL,    -- SEND_ALERT_EMAIL / WRITE_RISK_FLAG / ...
  compensate_fn      TEXT NOT NULL,    -- 补偿动作标识（SEND_CORRECTION_EMAIL /
                                     -- VOID_LINK / UNSET_RISK_FLAG）
  compensate_payload JSONB NOT NULL,   -- 补偿所需上下文（更正文案、标记原值等）
  state              TEXT NOT NULL DEFAULT 'OPEN',
                                     -- OPEN -> COMPENSATED / UNCOMPENSATABLE
  reason             TEXT,             -- 触发补偿的原因（如 prompt 版本缺陷）
  created_at         TIMESTAMPTZ NOT NULL DEFAULT now(),
  compensated_at     TIMESTAMPTZ
);

使用规则（承 §5 补偿一节 Restate/Step Functions 的结论）：①每个有副作用的步骤在写"发送意图表"的同一事务里登记补偿行；②补偿函数本身必须幂等（同键重复执行无害）；③发给外部世界的动作多数只能"发更正"而不能真撤回——登记表的作用是把"哪些动作需要善后"从记忆变成记录。

4. NightBatch-50w 的成本量级（示例估算，口径已注明）

估算假设：每条交易组装 prompt 约 1.5K 输入 tokens（交易上下文 + 模板）、输出摘要与标记约 0.5K tokens；单价取某中档旗舰模型公开牌价 $3/百万输入、$15/百万输出为锚（请按实际模型与 2026-11 牌价代入重算）。

项目计算量级
单跑一遍整批（输入）50 万 × 1.5K = 7.5 亿 tokens × $3/百万≈ $2,250
单跑一遍整批（输出）50 万 × 0.5K = 2.5 亿 tokens × $15/百万≈ $3,750
单夜全量上两行合计≈ $6,000/夜
Batch API（5 折）$6,000 × 50%≈ $3,000/夜
无断点续跑时整批重跑一次+$6,000事故使当夜成本翻倍
每月 5 次整批失败、全部从头重跑5 × $6,000≈ +$30,000/月
800 条低置信度人工复核800 × 2 分钟 ≈ 27 人时 × $50/时≈ $1,300/夜

读法：一次"从头重跑"的代价 ≈ 单夜全量 $6,000，约等于两晚 Batch API 的成本——断点续跑每挽救一次整批失败，省下的就是"单夜全量"那一格的数字；800 条人审约 $1,300/夜，说明"审批过期自动降级为不发送"的设计（§5 接管落地）在钱上也是成立的。若按 Gartner 2026-08 的 5 倍推理成本预测外推（未计模型降价对冲），2028 年同规模夜批的单夜成本将到 $30,000 量级——这正是纵轴"超时变成预算管理"、横轴"全局重试预算"在钱上的含义。

5. 第一周可以做完的事

  1. 为写标记、发邮件（及如有）计费调用三个副作用各自定出幂等键格式，落库为发送意图表 + 副作用收据；
  2. 为每个副作用登记补偿行（补偿函数哪怕先是"发更正邮件"的占位实现）；
  3. 单条 LLM 调用包 start-to-close 60–120 秒 + heartbeat 30 秒；HTTP 客户端重试次数与引擎重试预算对齐，防嵌套风暴（§5 超时落地）；
  4. 跑通"低置信度 → 审批队列（带过期时间，过期自动降级不发送）"最小闭环（Temporal Signal / Airflow 3.1 HITL / HumanLayer 任选其一）；
  5. 用"凌晨 3 点 kill -9"做一次恢复演练并记录实测恢复行为——这就是 §7 盲点四"恢复测试"的最小版。

参考来源（两章节稿合并去重，均为 2026-11-03 检索/阅读）

理论与经典论文

批处理、框架与协议

持久化执行引擎（横轴一手文档）

批处理编排平台

Agent 框架与平台

替代范式

Agent 时代评测与事件

未核实与局限声明（两章节稿声明合并，最终稿修订时更新）

*本稿为最终稿（按独立审读意见修订，2026-11-03）；评级、价格与 2026 年行业数字在正式引用前建议按上述链接二次复核。*

思考题（读完后想一想，参考答案可展开）

  1. 这份报告的核心论点是什么？如何理解 2026 年 agent 可靠性生态“4+1”的格局，以及为什么说补偿是全生态最大空位？
    参考答案

    核心论点：Agent 可靠性工程是把 1970 年代批处理的五个概念——幂等、续跑、补偿、超时、人工值班——搬进 LLM 工具循环，语义未变、载体三迁。2026 年实况是“4+1”：续跑与超时归 B 类持久化引擎，幂等与审计归 A 类编排平台，检查点与审批归 C 类 Agent 框架；第五支柱补偿无人认领，全生态评级无一 ◎，是最大空位。可靠性天然是组合工程，不存在“选一个框架就解决”的选项。

  2. 横向对比中，B 类持久化执行引擎（如 Temporal）、C 类 Agent 框架（如 LangGraph）与 E 类 Batch API 各有什么取舍？报告建议按什么思路选型？
    参考答案

    取舍：B 类 Temporal 续跑与超时最强，但副作用幂等仍需业务幂等键；C 类 LangGraph 有检查点与 interrupt() 审批，但超时、幂等需自建；E 类 Batch API 最便宜（5 折）。按副作用三档选型：纯生成用 Batch API；有副作用用持久化引擎做骨架、工具幂等化、登记补偿；强合规用 Airflow 3.1 HITL 或 Temporal Signal 人工门。

  3. 报告总结了哪些全行业共同盲点？在引用这些结论时，报告对自身声明了哪些证据边界与局限？
    参考答案

    全行业共同盲点（据 Zylos 调研，属厂商研究、单一来源）：检查点≠副作用记录；缺全局重试预算，嵌套重试会放大成重试风暴；模型/prompt/工具版本漂移可破坏确定性重放；几乎无团队有“最坏时刻杀进程”的恢复测试；观测数据未脱敏。证据边界：评级是文档级判断、非压测结论；89% 装可观测性、仅 52% 跑离线评估皆检测侧数字，结论限定为“可靠性水平低且建设滞后”；价格为第三方汇总未核实。

  4. 对个人/小团队开发者，报告给出的分档建议与“第一周可以做完的事”分别是什么？
    参考答案

    按副作用分三档：纯生成用 Batch API+超时+覆盖写库，别上 Temporal（过度设计）；有副作用以持久化引擎为骨架，三铁律：幂等键在重试循环外生成、用业务键（批次日期+交易号）非 UUID，每步登记补偿，单条调用 60–120 秒超时+30 秒心跳、配全局重试预算。第一周：建发送意图表与补偿登记表，审批队列带过期时间（过期自动降级不发送），用“凌晨 3 点 kill -9”做恢复演练。

← 资料库今日播报 →