让视频生成流水线跑不崩：一个事件溯源的多 Agent 可靠执行框架

这篇讲的是一个 Java 可靠执行框架的设计。它的第一目标场景是端到端视频生成，但框架本身不碰视频业务。本文介绍框架设计思路，暂不涉及框架接入。

一、真正要解决的问题，不是"让 Agent 更聪明"

2026 年一条视频生成流水线，早就不能用一个"视频节点"概括了。编排 Agent 先把用户意图翻译成脚本和分镜，每个镜头标好主体运动、机位和时长；再按镜头分配基模：长镜头给一家、音画一体给一家、最高保真再给一家。生成镜头前会先出一张风格参考图，作为图生视频的输入，保证人物和场景在各镜头间一致；每个镜头往往生成几个候选再挑一个。音频多数随视频原生生成，BGM 和音效可能单独再叠一层；最后是时间线合成、统一调色和多层评审。从意图解析到成片，背后是十几到几十次外部模型调用，每次生成都是"提交---轮询"的异步任务，一个镜头要等上分钟级，整条链跑完要十几分钟、花几块到几十块钱。

链路一长，最直接的问题是可靠性。只要每个环节不是百分百可靠，环节越多，整条链一次跑通的概率就越低；而这里的每次失败都带着真实代价：重跑要再付一次钱，等人介入会把整条链挂住。可靠性没法靠重试和祈祷补出来，得沿着链的生命周期逐段建设。我们把它拆成五个问题，分别对应钱、并发、审计、红线、人工介入这五个面：

进程崩了，能不能接着跑，而且不重复付钱、不丢账？
好几个实例同时在跑，会不会互相踩？
事后能不能查"当时为什么决定这么做"？
合规红线能不能被绕过？预算超了能不能拦住？
要人审批的时候，会不会把整条线堵死？人不来怎么办？

针对这五个问题，我们设计实现了一个可靠执行框架。它不解决"怎么让 Agent 生成出更好的视频"，那是模型和提示词的事；它解决的是"怎么让一个贵、慢、会崩、还要人审批的执行过程变得可信"。

二、现有方案各自解决了什么

我们从下面三个方面分析现有框架：事实源存在哪里、决策从哪来、视频生成Agent 场景的硬诉求（花钱、合规、评审、人工介入）被放在什么位置。几类主流方案的目标场景不同，侧重点自然不同，在这三件事上的取舍也不一样：

类别	事实源	决策来源	成本闸门	合规拦截	多层评审	人工介入	崩溃续跑
Temporal / Restate / DBOS 这类持久化执行	事件流 / journal	代码即工作流，靠重放	无	无	无	Signal，超时归宿自建	有
Step Functions / Durable Functions 这类云工作流	状态快照	状态机 DSL 或代码	无	无	无	Callback，超时归宿自建	有
LangGraph / AutoGen / CrewAI 这类 Agent 编排	Checkpoint	LLM 为主	无	无	无	Interrupt，超时归宿自建	部分
一个 while 循环加 try/catch	内存	LLM 自由发挥	无	无	无	无	无
本文的框架	事件日志，只追加	规则表优先，LLM 兜底	有	有	有	有	有

Temporal 最接近我们的路线，也最能说明差异。 它把事实源做成事件历史，而不是当前状态值；崩溃续跑、副作用去重、跨实例接管，都是在这个基础上实现的。熟悉 Temporal 的话可以这样类比：它的 Activity 约等于我们的执行体，Signal 约等于我们的人工决策回写，Worker 约等于我们的编排进程。

事件历史这一层两家是共通的，走法不一样的是下一步：决策从哪来。Temporal 的工作流逻辑写在你的代码里，框架靠重放这段代码来恢复执行，所以这段代码必须是确定性的。纯业务编排里这个约束很优雅，可一旦你在决策路径里塞进一个 LLM 调用，问题就来了：同样的输入，LLM 两次可能给不一样的答案，"重放必须得到同样行为"这个前提就不成立了。Temporal 官方文档也明确提醒，工作流代码里不能放这种不确定的东西。

我们的框架不把控制面决策放进重放路径。这些决策改由一张固定优先级的规则表算出来（后面会讲，编号 R1 到 R11），输入只有重放得到的投影。LLM 只在规则表管不了的开放问题上参与，它的输出必须先过一遍 schema 校验，格式不对直接作废。这样重放的确定性由规则表兜底：不依赖那段被重放的代码，也不指望 LLM 每次都答得一样。

还有个细节能反过来印证这个差异。Temporal 因为逻辑在代码里，代码一改，正在重放的老任务就可能对不上，所以它专门做了 patch、version 这类机制来管工作流代码的版本。我们的业务代码不进重放路径，改业务代码不影响老事件回放。

Step Functions 这类云工作流，强在托管、可视化、上手快。场景要是纯编排，没有 LLM 裁量、没有花钱上限、没有合规评审，用它比我们省事。它的取舍是事实源偏"状态快照"，你很难回答"当时为什么走这一步"；而前面说的那些硬诉求------花钱、合规、评审、人工------也全得自己在 Lambda 里写。

LangGraph 这类 Agent 编排框架，工程化在同类里算最扎实的。Checkpointer 能存状态、断点续跑，interrupt 能挂起等人，还有时间旅行式调试。但它的决策主体仍是 LLM，图结构只是约束；它存的是"当前状态"，不是完整事件流。存状态能让你恢复，存事件流还能让你回到任意一步看当时全貌，能审计。

上面三类要么解决通用编排，要么解决 Agent 之间怎么协作。我们要解决的是另一件事：Agent 干活这个过程本身怎么不翻车。

三、两条设计原则，和一个推出来的结论

框架的所有形态都能从两条原则推出来。这两条是真正独立的立场，其余机制大多是它们推出来的结论。

3.1 原则一：事件日志是唯一事实源

任何一次状态变更，都先把对应的事件写进库，落库成功了才去执行动作。这个先记后做的顺序，就是通常说的先写日志。任务的"当前状态"不是一个存起来的值，而是把这个任务的全部事件从头重放一遍算出来的。算出来的这个结果我们叫投影，它随时能重算，但从不落库。

这套做法跟银行记账是一个道理。银行的流水才是权威，余额只是流水加总出来的结果，随时能重算。可很多系统反过来做：把余额（当前状态）当成真理存下来，流水（事件）反倒只当参考。平时看不出问题，等到某天余额和流水对不上，就再也说不清是哪一笔、哪个环节出的错了。

接受"流水才是权威"，开头的第一个问题就有答案了：崩溃后恢复、换一个实例接管、事后审计，这三件事本质上都是把流水重放一遍，不用为它们各写一套逻辑。

3.2 原则二：确定性的事交给规则表，LLM 只管拿不准的

派发、回滚、预算、合规、状态流转，这些控制面决策全部由一张规则表算出来。规则表就是一份按固定优先级排好的清单，我们编号 R1 到 R11，每条规则的判断条件都从投影里取，从上往下试，第一条命中的说了算。只有规则表覆盖不了的开放问题，才交给 LLM 去裁量。

把决策尽量压在规则表里，一是为了正确性：控制面不能交给一个不确定的东西，这点讲 Temporal 时已经说过。二是为了省钱。

省钱这件事得先把两类模型分开。一类是干活的业务模型，图像、视频、音频都靠它们生成，这部分开销该花就花，规则表管不着。另一类是框架自己决策时可能调用的推理 LLM，只有规则表兜不住的时候才轮到它。顺利的话，一条流水线的控制面决策从头到尾都由规则表算完，推理 LLM 一次都不用调，省下的就是这部分推理开销。决策全程可预测、可测试，也是同一个原因。

规则表决策还带来一个好处：可回放、可审计。因为规则表只看投影、不看调用时序，同一份事件流重放多少遍，算出来的决策都一模一样。

这条原则和 3.1 是各自独立的：事件溯源管的是"事实存在哪、状态怎么恢复"，确定性优先管的是"控制面决策由谁做"，两者互不推导。

3.3 一个推出来的结论：Host 无状态

Host 无状态不是一条独立原则，它是原则一的直接结果。既然权威状态全在事件日志里、当前状态靠重放就能算出来，那编排进程（我们叫它 Host）自己就没必要保存任何无法重建的状态。它崩溃时，丢的只允许是内存里的计算中间态。任何一个持有租约的实例，把事件重放一遍，就能接管这个任务继续往下跑。系统里也就没有"这个任务归哪台机器"这种归属概念。

不过无状态本身只是分布式系统的基础能力，算不上什么亮点。真正难的是无状态下的安全接管：老实例可能并没有真的死掉，网络分区一恢复，它就带着旧状态回来写事件，这就是脑裂。这个问题不是"无状态"就能自动解决的，得靠 lease 加 fencing epoch 这套机制来防，第五章会细讲。

去掉了任务归属，让任何实例都能接管之后，故障转移和水平扩容就变成了同一套机制，也不必再单独引入一个选主组件。这些都算是原则一带来的连带好处。

四、一条任务从提交到交付，框架在背后干了什么

提交。 一个任务请求带四样东西：目标、执行计划（一张 stage 依赖 DAG）、成本上限、时间上限。提交时同步做全量校验，看 DAG 有没有环、每个 stage 有没有对应的执行体、评审环节有没有对应的评审器、成本估算是不是非负。校验过了，写一条任务创建事件，立刻返回 taskId，不阻塞。校验没过，则一条事件都不写，这个任务就当从没提交过。

决策循环。 某个实例拿到这个任务的租约后，进入一个循环，每轮干四件事。重放事件得到最新投影；把投影喂给规则表，R1 到 R11 挨个试，第一条命中的产出一个动作；规则表都不命中才叫 LLM；不管动作谁产的，先写一条 INTENT（意图）事件再执行。

动作有五种：派发一个 stage 去跑、回滚让上游重做、挂起等人、升级终止，以及高成本生成前的静态门检。

执行和回写。 被派发的 stage 交给执行体跑，跑完只能通过一个受限通道回写三种事件：结果、进度、失败。这个通道带幂等去重键。循环派发完就让位，不空转，等事件把它叫醒。

收尾。 业务 stage 全跑完后，框架自动补上合成和评审两个环节。评审给出四种结论之一：通过、软告警、质量必修、合规阻断。

终态。 任务最后停在完成、失败、升级三种状态之一。升级是半终态，人可以做个决策把它拉回来继续，比如批准追加预算。

上面这些环节能推进下去，前提是任务不会卡在某个状态出不来。框架为此准备了四条恢复触发源：进程启动时把所有活跃任务扫一遍、人工决策回写后唤醒对应任务、后台定期扫描那些在等人工审批却迟迟没人处理的挂起点、周期扫描发现租约过期就换实例接管。任何一条被触发，都会有一个实例把该任务的决策循环重新拉起来。

整套状态模型的规模大致是：事件类型 12 种，任务和 stage 各 7 种状态，评审结论 4 种，人工决策 4 种，完整清单在附录。

五、六个关键机制

5.1 崩溃后怎么接着跑，还不重复付钱

重放事件解决了"状态怎么恢复"，但还有个问题它没解决：崩溃可能正好卡在一次外部扣费的前后，重放怎么知道那笔钱到底花没花？

拿一个具体场景来说。循环决定派发一个镜头生成，先把 INTENT 写了库，然后调外部服务。就在"服务已经扣费、结果还没回写"这个瞬间，进程崩了。重启重放，看到的是有 INTENT、没有对应的 OUTCOME（结果闭合）。这时候直接重派，那笔钱付了两次；直接跳过，又可能把已经生成的结果丢了。

我们的解法叫对账。发现一个 INTENT 没有闭合的 OUTCOME，不急着重派，先拿这个操作的幂等键去回查外部服务。查到已经执行过了，补一条 OUTCOME，把产物和真实花费回填进来；查到根本没执行，才补一条作废标记，然后重新决策。这样无论崩在扣费前还是扣费后，账都不会错。

还有个兜底叫卡死看护。一个 stage 超过设定阈值还没任何进度事件，框架先尽力去取消它，再代写一条失败事件，下一轮由规则表重新派发。这样能防住一个僵死的外部调用把整条线永久挂住。

5.2 多实例怎么不互踩

前面说了谁都能接管，但接管的那一瞬间有个风险：老实例可能没死透，网络分区一恢复，它带着旧状态又来写事件，这就是脑裂。

我们用 fencing token 解决。每个任务一行租约，租约上带一个只增不减的编号（epoch），每次过期接管、或者释放后重新拿到，编号加一，而且这行租约永不删除。Host 写事件时，写操作和编号校验在同一个事务里。一个拿着旧编号的实例想写，校验直接失败，它被明确告知租约没了，然后退出。老实例那个迟到的写，就这么被挡在门外。

fencing 能不能生效，还取决于两条容易忽略的实现细节。

判断租约有没有过期，只用数据库那边的时间，绝不用本机时钟。多台机器的本地时钟对不齐，拿本地时钟判租约，早晚误判。

租约续约跑在一个独立的单线程调度器上，绝不允许被扫描、归档这类重活堵住。续约一旦被拖到租约过期，好端端的任务会被别的实例抢走，凭空多一次没必要的接管。

要点在最后一组交互：A 不是"悄悄写失败"，而是被明确告知租约已失并主动退出；epoch 校验与事件写入在同一事务，不存在"校验过了、写入前租约易主"的窗口。

5.3 决策事后能不能查

决策可查这件事，原则二已经给了大半答案：决策由规则表产出，而规则表只看投影、不看调用时序。剩下的落在两个具体设计上。

一轮循环最多产出一个 INTENT。就算当前有好几个 stage 都就绪了，也不一次全派，这轮派一个，剩下的下一轮再说。看着低效，可它让每一次状态转移都是最小、最清楚的单元，重放和审计都省事。我们主动拿一点表面效率换了确定性。

LLM 的决策会单独记一条 DECISION 事件，规则表产出的决策不记。这么区分是因为：规则表的决策，拿规则表加投影就能完全复现，不用额外记；LLM 的决策有裁量成分，得把它当时说了什么记下来，否则事后没法解释为什么这步走了条不常规的路。

5.4 预算超了怎么拦

对账解决的是不重复付钱，预算拦截解决的是另一件事：别把已经注定要超支的任务继续往下跑。

做法是在每次派发前先算一笔账，把已经花掉的、这次推理要花的、这次派发估算要花的三项加起来，看有没有超过硬上限。如果算下来必然超，就不写 INTENT、也不调外部服务，直接把任务升级终止，原因记成"派发前预算不足"。这个准入检查对规则表路径和 LLM 路径一视同仁，走的是同一道关，LLM 没法绕开。

还有一条配套的纪律：失败也要记账。执行体回写结果时，实际花费是必填的，哪怕这次跑失败了，已经花掉的钱也得如实报上来；LLM 调用抛异常时，异常里同样带着已产生的花费写进升级事件。这么要求是因为，"已经花掉的"这个累计值只要漏记一处，预算检查就会拿着一个偏小的数去判断，上限再严也拦不住。

5.5 合规红线不能被绕过

合规上，框架不给任何绕过的余地。

有两个地方会触发合规拦截：一是高成本生成前的合规门检判定不通过，二是最终评审给出"合规阻断"的结论。这两种情况都会确定性地升级终止，而且和普通失败的处理不同：它们不进回滚，也不消耗修复预算。

区别对待是有道理的。质量问题可以回滚重做，多改几轮总能改好；合规问题不行，它不是"改改再来一次"就能解决的，必须停下来交给人判断。如果把合规失败也塞进回滚链，等于给它留了一条"多试几次也许能蒙混过去"的路，而这条路只能靠运行时自觉去堵，并不可靠。所以它在设计层面就被堵死了。

合规门检还有个版本锚机制：它锚定的是最近一次产物登记事件的序号，而不是派发了几次。同一个产物版本只检一次，不重复检；产物一旦出了新版本，就必然重新检。这样既避免了"生成一次、门检无数次"的浪费，也堵住了"偷偷改了产物、却复用旧门检结论"的漏洞。

5.6 要人审批时，不堵死，而且人不来也有归宿

人工审批要处理好两个问题：等审批的时候不能把流水线堵死，以及人一直不来时任务也得有个确定的下场。

先说不堵死，靠的是挂起协议。当决策循环判断要等人时，它写一条"等人审批"的 INTENT，然后释放租约、退出。任务就存在库里等着，不占实例、也不挂线程。等人工回写了决策，或者下面的超时扫描器触发了，再通过恢复机制把任务重新拉起来。

人工回写的决策要先校验、再落库：对应的审批挂起点存不存在、属不属于这个任务、是不是还没被闭合、决策类型合不合法，全过了才在一个事务里写库。同一个挂起点，先到的决策生效并把它闭合，迟到的直接拒绝。这样两个人同时审同一个节点也不会冲突。

再说人不来的情况。一个审批挂起点一直没人处理，任务不能就这么无限期悬着。框架里有个超时扫描器，定期扫描没闭合的挂起点，发现超时就补写一条超时标记。但扫描器只负责标记"超时了"，不负责决定"超时之后怎么办"；到底是自动中止还是自动放行，仍然交给决策循环，按事先配好的策略确定性地算出来。

把"标记超时"和"决定去向"拆开，是因为一旦让扫描器也管后续处理，它就成了第二个决策者，可能和主循环对同一个挂起点给出冲突的处理。拆开之后，决策权始终在循环手里、始终走同一套规则，扫描器就退化成一个只报时、不做主的定时器。

六、内置的两阶段评审

在高成本生成的场景里，评审这一环直接关系到成片能不能交付，所以框架把它做成了内置能力，分两个阶段跑。

第一阶段跑合规层和技术层，两层都用规则引擎并行判断，不调 LLM。这一阶段一旦出现硬失败，就直接短路，第二阶段不再执行。什么算硬失败，由一份明确的白名单界定，不允许各个评审器自行解释，否则同一种问题可能被不同评审器判成不同结果。第二阶段跑内容层和商业层，这两层涉及主观判断，需要模型来精评。把不需要模型的合规、技术检查放在前面短路，能省掉后面两次模型调用的开销。

不管哪个阶段，评审结论都收敛成四个固定的值：通过、软告警（可放行）、质量必修（触发定向修复）、合规阻断（确定性终止）。之所以要收敛成固定的枚举，而不是让评审器输出一段自由文本，是因为下游要根据结论决定接下来怎么走；结论是四个确定的值，下游就是四个确定的分支，不用再去猜一段话到底算不算通过。

质量必修会触发定向回滚。回滚是个纯函数，遵守三条规则。一是失效范围取并集，一个产物被判废，所有依赖它的产物一起失效。二是回滚目标去重到最上游，多个问题如果指向同一条上游链，只回滚到最上游那一个点，不重复回滚。三是修复指令独立传递。一次评审即使发现多个问题，也合并成一次回滚、算作一轮修复预算。修复有轮次上限，超过上限就升级终止，不允许无限次重做把预算耗光。

到这里，合规和质量的分工也就清楚了。质量问题走回滚、消耗修复预算、可以反复迭代；合规问题确定性终止、不回滚、不耗预算，也没有绕过的余地。两条路从头到尾分开走。

七、框架的边界与约束

下面几条不是编码规范，是框架的设计级约束。每一条都对应前面讲过的一处取舍，违反任何一条，前面相应的保证就不成立。

确定性逻辑不让换，能调的只有参数。 规则表、回滚、结论聚合这些控制面核心不允许替换，能调的只是修复轮次上限、门检层配置这类参数。原因是，一旦允许把控制面逻辑和业务参数混在一起改，就等于允许一次配置改动动到系统正确性的根基。

事件 schema 只加不改。 要加字段就加可选字段，要大改就升版本、再配一个转换器把老事件读成新格式，但历史事件永不改写。只追加是这类系统能成立的前提，一旦允许改历史，"重放得到确定结果"就无从谈起，前面两条原则也跟着失效。

优雅停机只保证"事件不丢、状态能恢复"，不保证在途的活干完。 停机顺序是：不再接收新任务，等在途任务跑到一个安全检查点，在检查点退出并释放租约，剩下的交给其他实例接管。之所以不承诺"把活干完再停"，是因为在分布式系统里，承诺一个自己控制不了的完成时间并不现实。

投影不能当决策依据。 那个只读的进度快照是给页面展示用的，权威只有事件日志。这条必须写成硬规矩而不能靠自觉：一旦有人图省事拿快照做决策，快照和事件流之间的任何一点延迟都会变成 bug，而且这种 bug 极难复现。

一轮只产一个 INTENT，不批量派发。 原因见 5.3，这里不再展开。

两条写入路径不许合并。 Host 走带 fencing 校验的路径，其他写入方（执行体、超时扫描器、人工网关）走带去重键的路径。不为了方便合成一条，是因为两条路的信任模型根本不同：Host 是持租约的决策者，要防的是脑裂；其他写入方不是决策者，要的是幂等去重。合成一条，这两种保护里必然丢掉一种。

八、回到开头那五个问题

开头提出的五个问题，到这里都有了各自的机制来回答：

崩了能接着跑、不重复付钱、不丢账，靠事件重放加对账（5.1）。
多实例不互踩，靠租约加 fencing（5.2）。
决策能查，靠规则表只看投影、不看时序，加 LLM 决策留痕（5.3）。
预算能拦、合规绕不过，靠共用的成本准入和确定性合规终止（5.4、5.5）。
人工不堵死、超时有归宿，靠挂起协议加"扫描器只标记、循环做决定"（5.6）。

这五件事看着互相独立，其实都从同一个决定推出来：把事实源做成可重放的事件日志，而不是当前状态值。事实源一旦是事件流，恢复、接管、审计就都变成了重放同一份日志。至于成本闸门、合规拦截、评审分层，是在这个地基上专门为 Agent 场景加的一层。

也得说清它不适合什么。它面向的是长时、高成本、会中断、要人审批、要合规评审的 Agent 编排。低延迟在线服务不适合，重放和事件落库的开销在那个场景里不划算；纯 Agent 对话也不适合，那是 LangGraph 更擅长的地方；它同样不打算替代通用工作流引擎，如果你的场景里没有 LLM 裁量、没有花钱上限、也没有合规评审，直接用 Step Functions 反而更省心。

目前框架还有两块没做完：

数据库中间件的行为保真：同一套中间件有两种接入方式，客户端解析那种的完整契约测试还没补齐。
跨任务的资源调度：预算和并发准入目前都还是单任务视角，"同时来很多任务时谁先跑、共享预算怎么分"这个全局问题还没有答案，眼下靠排队背压守住入口秩序。

附录：术语速查（备查用）

12 种事件类型：任务创建、意图（INTENT）、决策（LLM 留痕）、结果闭合（OUTCOME）、执行结果、进度、失败、系统标记、人工决策、回滚、升级、部分决议。

任务状态（7）：排队、执行中、等人、修复中、升级、完成、失败。终态是完成、失败、升级（升级是半终态，人工可拉回）。

评审结论（4）：通过、软告警、质量必修、合规阻断。

人工决策（4）：批准、恢复、中止、追加预算。

两类幂等键：操作键（贯穿一次外部操作，用于对账、取消、终态）、事件去重键（一次逻辑写入，带唯一约束）。

几个反复出现的词：租约（lease）、fencing 编号（epoch）、先写日志（Write-Ahead）、重放（fold）、投影（重放算出来的当前状态，不落库）。

附录：本文可复用的对照表

下面这张"问题---机制"对照表可以直接拿去对照你自己的系统：

你担心的问题	本文框架的机制	章节
崩溃后重复扣费	INTENT 无 OUTCOME 时回查 Provider 对账	5.1
多实例脑裂	租约 + 单调 epoch，写入同事务校验	5.2
决策无法复盘	规则表只看投影，LLM 决策单独留痕	5.3
预算失控	派发前成本准入，确定性/LLM 共用一道门	5.4
合规被绕过	门检 FAIL 与合规阻断确定性终止，不进回滚	5.5
审批堵死流水线	挂起即释放租约，扫描器只标记不决策	5.6
LLM 输出破坏确定性	控制面走规则表，LLM 输出必过 schema 校验	3.2