AI 视频平台 Agent 复刻闭环实测：上传三步协议、审批门应答与僵尸态逃生

一句话结论：把一条 88 秒的爆款视频喂给一个为 Agent 设计的 AI 视频平台，它能在规划模式下不耗积分交出六段式分镜反推表，并自主给出「选纯剧情镜头、快档模型、十秒 720p」的控成本复刻方案——这是超预期的一半；另一半是三个没写进文档的雷区：签名上传协议的时效约束、审批门应答的极简字段边界，以及一个一旦触发就只能弃项目重来的僵尸态。本文是一次全链路实测的完整复盘，也是一份给所有要对接 Agent 平台接口的人的状态机避坑图。

状态面板上有四个标志同时亮着：运行状态是 failed，生命周期标志 isTerminal 是 false，控制通道可用性 controlAvailable 是 false，审批确认 acceptance 是 unconfirmed。做过运维的人都知道这组组合有多别扭：看到 failed，你以为到了终态，可以收拾东西走人了；isTerminal 却说没结束，这个 run 还「活着」。想主动止血，把 run 停掉，控制通道告诉你不可用；想配合平台的审批流程把问题答掉，审批账本返回的是「确认状态未知」。应答和停止两条路都报同一个错误码，超过十分钟没有任何恢复迹象，而在同一个画布上开新的运行，又被「已有活跃运行」的锁拒绝。

这不是一次故障演练，这是 2026 年 10 月 6 日晚间一次真实复刻闭环的最后一公里。任务本身很朴素：把一条别人已经验证过的爆款视频上传到一个为 Agent 设计的 AI 视频平台，让平台侧的 Agent 把它拆成分镜，再复刻生成一条同结构的新视频。前面所有环节——认证、建项目、分片上传、派发 Agent、拿到分镜反推表、拿到复刻方案——全部跑通了，而且有几处超出预期。唯独在第二轮审批门的一次应答上，整条链路坠入了上面描述的僵尸态。

回看整条链路，值得写下来的不是「我跑通了」这三个字。跑通本身没有信息量，任何一个接口都能在多次试错后跑通。真正有信息量的是三类东西：一是平台协议里那些文档没写、但违反了就寸步难行的隐含约束；二是 Agent 交互接口与传统 REST 接口在「容错哲学」上的根本差异；三是那个僵尸态背后的状态机缺陷——它不是一家平台的孤立问题，同一周的开源 Agent 工具社区里，同类「半死状态」症状正在成簇出现。下文先讲链路是怎么通的，再讲雷具体埋在哪，最后把它放进行业坐标系里看这条赛道的走向。

从 doctor 到画布 UUID：闭环的六步骨架

先说接入形态。这个平台（LiblibAI 旗下的 LibTV）没有走「网页上传、表单填写」的传统产品路线，而是把整个平台能力打包成 52 个 MCP 工具暴露给调用方的 Agent。也就是说，你的本地智能体装上这份工具清单之后，就「会」用这个视频平台了——创建项目、申请上传凭据、派发平台 Agent、审批应答、检查产物，全部是工具调用。这个设计决定了后文所有坑的性质：它们全部出现在 Agent 与 Agent 的接口上，而不是人与界面的交互上。

链路的第一步是认证体检。平台提供了一个 doctor 工具，专门用来验证调用方凭证是否有效。这个设计比想象中重要：后面所有操作的失败模式里，「认证过期」和「参数非法」的报错在外观上非常相似，先用 doctor 把认证变量摘干净，后面排查时可以少走一半弯路。

第二步建项目。create_project 有一个必填参数 idempotencyKey，幂等键，合法字符集是字母、数字、点、下划线、冒号和连字符，长度 8 到 255 位。这个键的语义是：同键重复调用不会创建出重复项目。对自动化场景来说这不是可选项而是必需品——Agent 的重试逻辑天然会重复调用，没有幂等键的项目创建接口，会在每次网络抖动后留下一地孤儿项目。调用成功后返回的 projectId 就是后续一切的锚点：它是平台上「画布」的 UUID，上传、派发、审批、取产物，全部挂在这个 ID 下面。

第三步是整个链路里最有「协议味」的部分，上传三步走。第一步调 upload_ticket，向平台申请一个上传凭据，拿到一个带签名的对象存储 URL；第二步用 HTTP PUT 把视频数据推到这个签名 URL 上；第三步调 upload_complete，把路径和 upload_id 交还给平台，平台确认后返回 file_ref 和 CDN 地址，至此文件才算真正「属于」这个项目。三步里每一步都有自己的约束：签名 URL 的有效期大约只有一小时，超时未传完就得重新申请 ticket；好消息是重新申请时幂等机制会让相同 uploadId 的提交走重放，不会产生重复文件；分片上传还有硬性下限，每个分片不能小于 5MB。

实测中的两个细节值得单独拎出来。一是分片切法：本地用 split 命令按 5242880 字节（5MB）把视频切开，逐片上传，每个分片返回 HTTP 200 即为成功。二是 macOS 的 curl 没有 –upload-binary 这个选项，传文件用 -T 参数一样能走通——这种小坑不记下来，下次还会在同一台机器上浪费十分钟。

第四步到第六步是 Agent 协作段。run_agent 把任务派发给平台侧的 Agent，message 里写清楚要求；get_agent_status 轮询运行状态；中途如果平台 Agent 有拿不准的事，会通过审批门挂起等你应答，answer_agent_questions 就是过这道门的钥匙（下一节专门讲它）；最后 task_status 和 inspect_media 两个工具负责验收产物，确认视频真的生成了、时长规格与预期一致。

轮询本身也有纪律。get_agent_status 的返回里除了 run 的状态，还带着当前会话标识，这个标识每次轮询都可能更新——正确做法是每轮都把最新返回完整存下来，应答审批时取最近一次的值，而不是开头那一次。验收环节同理：task_status 只能看到任务级状态，产物是否真的可用要靠 inspect_media 看媒体元数据——时长对不对、分辨率是不是承诺的档位，这两个数字与任务状态无关，得单独核。骨架就是这么六步：体检、建画布、传素材、派活、过审批、验产物。

骨架简单，但每一步的「隐含正确姿势」都不简单。这条链路跑通的总耗时里，真正花在「正常流程」上的时间不到一半，剩下全花在摸清那些隐含约束上。

88 秒视频拆成六段：规划模式里免费拿到的能力

链路跑通之后，先看平台 Agent 交出的第一份作业，这也是整次实测里最超预期的部分。

给它的输入是一条 88 秒的爆款视频，任务是反推结构。平台 Agent 的输出是一张六段式分镜反推表——它把 88 秒切成了六个叙事段，每一段给了八个维度的描述：时间轴、场景、人物动作、运镜方式、构图、光影、节奏，以及画面里实际说了什么的 transcript。这不是「总结大意」级别的理解，而是可以直接拿去当拍摄脚本的颗粒度：哪一秒到哪一秒是中景推轨，哪一段光影从暖调切冷调，节奏在哪个位置起、在哪个位置收，都列在表里。

对做内容的人来说，这张表本身就是一个独立的中间产物。爆款拆解是内容行业的刚需工序，过去要么靠人工逐帧拉片，要么靠口头经验，现在它成了 Agent 规划流程的一个副产品。更关键的是获取成本：平台的 run_agent 有一个 autoGenerate 参数，设为 false 时进入纯规划模式——Agent 只做分析和方案，不执行生成。实测确认这个模式不消耗积分。也就是说，「拆解爆款」这一步可以单独白嫖，只有你认可了方案、决定执行生成时，才开始花钱。

第二处超预期是复刻方案的成本意识。拿到分镜表后，让平台 Agent 给复刻方案，它的选择是：在六个段落里挑出唯一一段纯剧情镜头作为复刻对象——避开了依赖特效和口播的段落，因为那些段落的复刻要么失真要么成本失控；模型选了快档（Seedance 2.0 Fast），时长压到 10 秒，分辨率 720p。整套选择没有一处默认奔着最贵的配置去。一个平台侧的 Agent 在没有额外提示的情况下自主做减法，这在当前的 Agent 产品里并不常见——更多产品的默认行为是「给最好的」，然后把账单留给你。

把这两处超预期和后文的雷区放在一起看，会得到一个有意思的对照：平台在「能力」维度上超出预期，在「协议」维度上也超出预期——严格得超出预期。这其实是同一枚硬币的两面。Agent 接口的状态空间天然比传统接口大：传统接口一个请求一个响应，状态就在报文里；Agent 接口有挂起、有审批、有会话、有多轮，状态散落在多个字段里。状态空间越大，服务端就越需要严格的 schema 来收敛解析歧义，调用端犯错的代价也就越高。能力上限和协议严格度，是同步上涨的。

审批门应答：三个键的生存边界

现在讲雷区里的第一个，也是把整个闭环从「顺利」打入「僵尸态」的那一个：审批门应答格式。

先说过门机制本身。平台 Agent 在运行中途如果有拿不准的决策——比如选哪个镜头复刻、用哪个模型档位——不会自作主张往下走，而是挂起一个待应答的问题。此时 get_agent_status 会返回一个 pending 状态的工具调用，带着它自己的 toolCallId。你需要在下一次 answer_agent_questions 调用里告诉平台你的决定，run 才会继续。这个设计思路是对的：关键决策留给人，是 Agent 平台在「自主」和「可控」之间画的那条线。

问题出在应答的格式宽容度上。正确的应答，feedback 参数里只放三个键：mode、node_keys、selected。就这三个，一个都不多。toolCallId 用 pending 状态里返回的那个，不能用自己上一次用过的；agentSession 参数必须用最新一次 get_agent_status 返回的会话标识——这是一个非常容易踩的时间差坑：轮询过多次之后，你手里有多个历史会话标识，用旧的那个，应答会挂到错误的会话上，平台侧看起来就是你答非所问。

第一次踩雷的现场是这样的：为了「提高应答成功率」，第一次应答把能想到的字段全塞了进去——selected、choice、answer、approved 四个键并存，意图是多给几条信息，总有一条能对上平台的校验。结果平台的反应不是「取其中正确的字段」，而是直接判死：run 当场进入 EXECUTION_FAILED。强 schema 校验的逻辑是，未知字段和冲突字段不是被忽略，而是被视为非法输入。「多塞几个键碰运气」这种在宽松接口上的有效策略，在这里是精确的自毁。

从这组对照里能提炼出的通用原则是：对 Agent 平台的交互接口，应答最小化优于应答完备化。你塞进去的每一个额外字段，都是给服务端校验器的一张罚单机会。传统 REST 时代大家积累了「字段给全一点防止信息不足」的习惯，这个习惯在强 schema 的 Agent 接口上需要整个反过来：只给平台明文要求的，其他一律不给。字段越少，爆炸半径越小。

僵尸态：四个标志同时成立时，没有任何按钮是对的

回到开头那个场景，现在可以完整复盘僵尸态的触发链了。

触发链的第一环是上一节的复合字段应答——run 被判 EXECUTION_FAILED 之后，理论上这是一次普通的执行失败，重新派发就好。但实测中它没有停在「失败」这个干净的状态上。第二轮审批门再次挂起时，状态读数变成了那个四标志矛盾组合：remoteRunStatus 是 failed，isTerminal 是 false，controlAvailable 是 false，acceptance 是 unconfirmed。逐个看，每个字段单独都合法；组合起来，它们互相否定。failed 暗示终态，isTerminal 否认终态；controlAvailable 说控制通道已关闭，acceptance 却还在等一个确认。四个字段像四个各自为政的子系统，没有一个仲裁者。

接下来的一切都是这个矛盾组合的必然延伸。answer_agent_questions 报「验收状态未知」——审批账本子系统认为这个 run 的确认状态未知，拒绝受理任何应答；stop 尝试主动止血，同样被拒——控制通道已经不可用。超过十分钟没有任何自愈。最后想绕开这个 run，在同一个画布上派发新任务，平台返回「画布已有活跃运行」——生命周期子系统还认为那个 failed 的 run 占着锁。进无可进，退无可退，绕无可绕。此时唯一的解法是：放弃这个项目，回到链路第二步，重新 create_project，重新走一遍上传三步，重新派发。好在幂等键和上传凭据的重放机制让重建的成本不高——这也是「弃项目」策略可行的物质基础。

值得强调的是，换成极简三键的应答也救不回这个 run。僵尸态一旦形成，问题就不在应答格式上了——格式是对的，受理通道本身已经断裂。这正是「僵尸」二字的准确含义：不是死了，是半死；半死的状态比死更麻烦，因为死会释放资源，半死会继续占锁。

从状态机设计的角度给这个缺陷归因：这四个字段本该满足一组不变式约束——failed 应当蕴含 isTerminal 为真；controlAvailable 为假时，不应再存在对 acceptance 的等待。不变式的存在意味着任一子系统写入状态前要过一致性校验，而这里的四个字段显然由不同子系统各自写入、各说各话。这不是「平台做得烂」那么简单，它是分布式状态机的经典通病：没有单一事实源时，状态一致性靠约定维持，而约定在异常路径上最先失效。异常路径恰恰是失败恢复代码运行的地方，于是「失败的失败处理」成了整个系统最脆的一环。

逃生策略由此清晰，三条：一个画布一个生命周期——把画布当成一次性的执行环境而不是可回收的常驻资源，run 结束（无论成败）就换新画布，状态机再脏也污染不到下一个项目；审批应答只发三键——从源头不给 EXECUTION_FAILED 的入口；审批一旦失败立即弃项目——不要在锁死的画布上反复重试，每次重试都在消耗下一次调用的熔断预算（下一节会讲到熔断机制的存在），恋战的成本不是零而是复利。

连撞四次之后的四十二秒静默

雷区二的规模小一些，但它揭示的机制值得单独立一节：MCP 层的熔断。

run_agent 有一个 skills 参数，按设计意图应该是用来给平台 Agent 指定技能模板的。实测中这个参数的格式始终没有破解：catalog selection 对象的三种 plausible 形态——嵌套结构、平铺结构、带 name 字段包装的结构——全部返回同一个错误码 SKILL_SELECTION_INVALID。看起来是「指定模板」这个功能通道的格式没有随工具暴露出来，或者文档与实现脱节。

真正有信息量的是失败四次之后发生的事：整个 MCP 工具集进入了熔断，大约 42 秒的惩罚窗口，期间调用任何一个该平台的工具都直接被拒。熔断恢复后也不能立刻高频调用，实测经验是熔断触发后至少间隔 45 秒以上再碰任何工具。也就是说，连续的参数试错不只是浪费调用次数，它会把你的整个接入通道按在地上 42 秒——如果你正处在审批门的时间窗口里，这 42 秒可能刚好错过应答时效。

对调用方的工程启示是：面对格式未文档化的参数，试错预算必须前置设定。本例的正确决策点是三次——三种主流形态都验完仍报同一个错，就该判定「此路不通」而不是继续发明第四种形态。第四次失败触发熔断，是预算超支的罚金。

而这个故事的结尾反而有意思：skills 参数放弃之后，选择是裸跑——run_agent 不带模板，把要求全部写进 message 自然语言里。结果平台 Agent 自己完成了等价的技能选择：它自己去翻了技能目录，自己挑了合适的处理方式，分镜表和复刻方案都是裸跑状态下产出的。结构化参数通道走不通，自然语言通道反而更鲁棒。这个对照放在当下这个时间点格外值得玩味：大家都在把能力往结构化接口里收（函数调用、schema 校验、强类型协议），但自然语言作为万能后备通道的价值没有消失——当结构化通道的格式知识与调用方脱节时，它是唯一不需要格式知识就能走通的路。

同一周的同款症状：半死状态是 Agent 系统的共有缺陷

如果僵尸态只是这一个平台的孤立问题，这篇文章的价值会减半。把它放进同一周的行业视野里看，会发现「半死状态」正在成为 Agent 系统的一个共有缺陷类别。

同窗口的开源 Agent 工具社区动态里，同类症状成簇出现。Gemini CLI 的 #22323（P1 级，13 条评论）：子代理达到轮次上限被截断、未做任何分析，仍上报状态为 success——状态说谎的直接样本，「看起来成功了但没有结果」。同项目的 #21409（P1 级）：主代理把任务委派给通用子代理后永久挂起，连建目录这种简单操作也会卡死，有用户等了一个小时，唯一规避方法是显式禁用子代理。Claude Code 的 #87692：无人值守的 headless 会话永久挂起，没有流式不活跃看门狗，遇到本可重试的临时性服务端错误也直接终止——挂起与误终止是同一枚硬币的两面。Claude Code 的 #99513：一份过期的「曾经连接过」缓存，把 16 个已断开连接器的完整工具定义持续注入每个新会话——状态已过期但仍在服役，静默污染上下文。OpenCode 社区则直接喊出了口号：「宁可报错，不要沉默」。

把这五个案例并排放在一起，共性浮出水面：它们都不是「功能缺陷」，而是「状态缺陷」——系统的某个状态字段所声称的，与系统实际所处的，不是同一件事。说谎的 success、不终止的挂起、不释放的失败、不退役的缓存，全部属于这一类。AI CLI 工具的社区日报把「静默失败成为众矢之的」列为当期趋势信号，把「子代理可靠性」（挂起、误报、结果可信度）列为多工具共性缺口，与这组观察完全吻合。

对自建 Agent 系统的开发者，这组案例指向一条具体的设计纪律：状态不变式要显式声明并机器校验。failed 必须蕴含终态；控制通道关闭必须蕴含不再等待外部输入；任何「进行中」状态必须有超时和看门狗兜底。这些约束在单体系统里往往由代码结构隐式保证，一旦状态散落到多个子系统（本地 Agent、平台 Agent、审批服务、存储服务），隐式保证就失效了——没有人拥有全部状态，就没有人能保证全部状态一致。

对调用方，防御要落在机制而不是期望上：每次涉及长流程的调用都预设「可能进入不可恢复状态」的预案，超时阈值和弃置策略写进代码而不是等到事故现场再临场发挥。弃置的勇气来自低廉的重建成本——这也反过来要求你在设计链路时就把幂等键、凭据重放这些「让重建变便宜」的机制备好。

生态背景板：agentic 视频生产正在成为一条新赛道

最后把这个闭环放进更大的坐标系。为什么这件事此刻值得做？

因为「用 Agent 生产视频」正在从演示走向赛道。同一个观察窗口的 GitHub 趋势榜上，开源 agentic 视频生产系统 OpenMontage 单日净增 361 个 star，其项目描述是 12 条流水线、100 多个工具、700 多个技能文件；更早的 MoneyPrinterTurbo（一键生成高清短视频的成熟工作流应用）已经积累约 12.8 万 star。把视频生产拆成 Agent 可编排的流水线，已经是被验证过的需求方向。

更大的背景是生态位的变化。当天的趋势榜前三名全部是 Agent 技能层的项目：ponytail 单日 +1894（教 Agent「最好的代码是不写的代码」的哲学层技能）、impeccable +1170（给 Agent 补前端设计语言）、Agent-Reach +979（让 Agent 读遍社交平台）。趋势日报对此的判断是：「skills for agents」已成为新的开源流量入口，框架战争阶段性结束，生态位下移一层——大家不再争着造 Agent 框架，而是争着给既有的 Agent 供给垂直能力。

本文实测的这个闭环，恰好坐在这两条趋势的交汇点上：平台侧的 Agent（视频平台把能力包装成 52 个 MCP 工具）与调用侧的 Agent（本地智能体）通过 MCP 协作完成生产任务。这条协作链上的协议经验——幂等键怎么设计、签名凭据的时效怎么处理、审批门怎么应答、熔断怎么对待——会随着赛道的扩张被越来越多的人踩到。早一天把这些隐含约束摸清楚，就少一天把时间烧在「明明每一步都对，合起来就是不通」的排障里。

边界

把全文的结论收拢成三条可以直接执行的铁律：一个画布一个生命周期，画布是一次性执行环境，不是可回收的常驻资源；审批应答只发三个键，mode、node_keys、selected，多一个键都是给校验器递刀；审批失败立即弃项目重建，幂等键和凭据重放已经把重建成本压到很低，恋战的成本反而是复利的。

同时把本文的边界如实交代清楚。实测数据来自单一测试项目在 2026 年 10 月 6 日的单次闭环，样本量为一，所有数字（52 个工具、88 秒输入、六段八维度分镜、约 1 小时的签名时效、5MB 分片下限、四次试错、约 42 秒熔断、超过十分钟不自愈）均来自这一次运行的记录，没有做多次重复实验，不能排除单次偶然性。僵尸态的归因（四字段缺乏一致性约束）是调用侧基于状态读数的推测，未经平台官方确认，平台侧的真实实现可能另有细节。skills 参数格式「至今未破」的结论是绕过而不是破解——正确的格式也许存在于某个未公开的文档或接口定义里。平台行为可能随版本变化，本文记录的协议细节（尤其是签名时效、分片下限、熔断时长）在读者使用时可能已经不同，一切以平台当期官方文档为准。分镜反推表的质量评估基于单条视频，不同类型素材下的表现未验证。

生态侧的引用数据（Gemini CLI 与 Claude Code 的编号案例、OpenMontage 与 MoneyPrinterTurbo 的项目数据、趋势榜的单日 star 增量）来自 2026 年 10 月 5 日生成的公开社区日报与 GitHub 趋势快照，编号案例的状态是当时点状态，读者复核时可能已发生变化。这些引用未经独立二次核验，采纳时请以各项目官方仓库的当前状态为准。

一句话收尾：Agent 平台的能力上限正在快速上移，但接口的状态机质量没有同步——调用方唯一能做的，是把每一次实测换来的隐含约束沉淀成自己的接入协议文档，并且永远给自己留一条「弃掉重来」的路。