Backlot 活体故事板：把审批闸做成一块本地看板

2026-08-09

让 agent 去做一件长流程的活，最难受的不是它做错，是你不知道它做到哪了。聊天窗口里滚过去的是一串「我正在生成第 3 个场景」，你既看不到它选了哪个 provider，也看不到这一步花了多少钱，等你反应过来，素材已经生成完了。

OpenMontage 对这件事给了一个不太常见的答案：不做进度条，也不让 agent 汇报，而是另开一块本地看板。

README 怎么定位这块看板

这一节在 README 里的标题是 “Watch It Happen — The Backlot Living Storyboard”，原文的对比句写得很干脆：聊天窗口告诉你 agent 说了什么，Backlot 展示制作实际在做什么。

它的描述是：一块本地看板，随流水线运行自我填充。阶段会亮起，脚本以剧本页的形式落下，场景卡在素材生成时闪动，每一个 provider 决策和每一笔花销都上墙。制作启动的时候，agent 会自动为你打开它，README 特意加了两句限定——无需配置、无需汇报。

「无需汇报」这四个字是这块看板在工程上最值得注意的地方。README 给的解释是：看板从流水线本来就会写的项目文件里推导出一切。也就是说，它被设计成读侧的派生视图，而不是让 agent 额外走一条上报链路。这个取向和 OpenMontage 整体是一致的：这个项目本来就把状态 checkpoint 成文件、把每次 provider 选择留成可审计的决策日志（README 说 provider 选择会在 7 个维度上打分），看板只是把这些已经落盘的东西摆出来。

需要说清楚的是，以上全部是 README 的说法，我们没有运行过这个系统，也没有读过 backlot/README.md 里的实现说明——README 把实现细节指到了那个文件，我们没有打开它，所以这里不谈它内部是怎么做的。

三条命令，照抄 README

README 给出的入口是三条：

python -m backlot open                  # the library — every project on disk
python -m backlot open <project-id>     # one production's live board
python scripts/backlot_simulate_run.py  # no production yet? watch a simulated one live

第一条打开的是 library，README 的注释写的是「磁盘上的每一个项目」；第二条要带 project id，看的是某一次制作的实时看板；第三条是给还没有任何制作记录的人准备的，README 的原话是「还没有 production？看一次模拟的跑」。

另外 README 提到，跑完之后可以按 ▶ REPLAY RUN，整个制作过程会按时间戳回放，可以从头到尾拖动。回放这件事之所以能成立，仍然是因为前面那条设计：状态是写进文件的，带时间戳，所以事后能重放一遍。

以上命令与说明照抄自 README，我们没有执行过其中任何一条，实际行为以你本地跑出来的为准。

真正的增量：故事板是一道会挡住流程的闸

如果 Backlot 只是个可视化面板，它其实不值得单开一篇。README 里那句被标出来的话才是重点：故事板是一道真正的审批闸。

原文描述的机制是这样：素材生成会在一张逐场景的样片接触表上暂停。这张表上有多个 take、对应的 prompt、每个素材的成本、以及质量分——让你在渲染之前批准视觉，而不是在来不及之后。README 还补了一句执行语义：创意闸会一直挂起直到你回答；看板显示在等什么、为什么等，你在聊天里回复。

把这几句拆开看，有三个可以核查的语义点，值得你在决定要不要用它之前先掂量：

一是闸是阻塞的，不是提示。「会一直挂起直到你回答」意味着人是流程的一部分，你不在电脑前，这条流水线就停在那儿。这对「挂机跑一晚上第二天收片」的期待是个直接的否定，但对「别烧完钱才告诉我」的诉求是个正面的设计。

二是闸落在渲染之前。素材生成完再看和渲染完再看，代价完全不同——前者你还能重来一个 take，后者已经把合成和编码的时间搭进去了。README 把这个位置说得很明确：before the render。

三是看和答分在两处。看板负责展示「在等什么、为什么等」，回复动作发生在聊天里。这意味着你没法只盯着一块看板把流程推完，agent 会话仍然是控制面。README 在 Quick Start 那节的说法与此一致：每一个创意决策都要经过你批准。

README 的 Production Governance 一节还把这道闸的执行方式写得更死：人类审批闸是强制的、不是建议的（原文 enforced, not suggested），proposal、script、scene plan、生成的素材和 publish 都会暂停等你签字；checkpoint 写入器会拒绝一个没有记录批准的「已完成」闸控阶段，每一个被取代的 checkpoint 都会被归档，所以审计链路（含闸的状态迁移）在修订之后仍然存活。原文特意点了一句：评审就是在 Backlot 看板上可视化进行的。这也是为什么这块看板不能只当成「进度可视化」来理解——按 README 的口径，它是那条审批链路的展示面。

同样要提醒的是，这些都是 README 对机制的描述，属于项目自述的行为契约。它写了闸会挂起，不等于你那次运行里 agent 一定会守住这个契约——能不能真的落地，取决于你用的 AI 编码助手和它当时的上下文。这一点在 OpenMontage 里是普遍情况：这个项目的编排逻辑大量写在给模型读的文本里。

「每一笔花销都上墙」，这个数字的性质要先说清楚

看板会把花销摆出来，这是个很实在的功能，但它容易带出一个误解：以为你能照着 README 里的数字预估自己要花多少钱。

README 列了 5 段演示视频，其中四段标了项目方自己给出的总成本：“THE LAST BANANA” $1.33、“The Library at Alexandria” $0.02、“VOID — Neural Interface” $0.69、“Afternoon in Candyland” $0.15（另一段 “SIGNAL FROM TOMORROW” 未标成本）。示例 prompt 那节也标了两档区间：配了图像/视频 provider 的写 ~$0.15–$1.50，完整配置的写 ~$1–$3。

这些全部是项目方在 README 中自行标注的金额，我们没有调用过任何一个 provider API，没有验证过其中任何一个数字，也不建议你拿它推算自己做一条要花多少钱——你的时长、provider、重试次数、take 数量都不一样。按 README 的描述，看板上出现的是你这次运行里发生的花销，README 标注的是它那几段演示的花销，这是两回事。

比 README 的形容词更值得看的，是仓库里真有一份可核查的预算配置。config.yaml 的 budget 段实读是这样：

budget:
  mode: warn                     # observe | warn | cap
  total_usd: 10.00
  reserve_pct: 0.10
  single_action_approval_usd: 0.50
  require_approval_for_new_paid_tool: true

这几个值有几点可以直接读出来。默认模式是 warn（记录超支）而不是 cap（硬上限），三个模式名 observe / warn / cap 与 README 一致；总预算默认 10.00、单次动作审批阈值默认 0.50，也和 README 写的 $10 与 $0.50 对得上。另外两项 reserve_pct: 0.10（预留 10%）和 require_approval_for_new_paid_tool: true（新的付费工具默认要审批）是配置里有、README 没写的，我们只陈述这个差异，不推断原因。成本相关的对应文件是 tools/cost_tracker.py 与 schemas/artifacts/cost_log.schema.json——后者的内部字段我们没有读过，这里只是指路。

必须说清楚：这些是配置默认值，不是开销保证。默认 warn 意味着开箱状态下超支是被记录而不是被截断的；把它改成什么、阈值定多少，取决于你自己的账户和风险偏好，我们没有跑过这套预算逻辑，也不会给出「这样配就不会超支」的结论。

顺带一提，README 的 .env 段强调 every key is optional，每一个密钥都写成 optional 的可选项。你配了哪些 provider，直接决定了看板上会出现哪些决策和哪些花销。

我们能核查到哪一步

这一篇必须把边界划清楚，因为 Backlot 是这个仓库里最容易「看图说话」的部分。

README 里放了 Backlot 的截图，文件是 docs/images/backlot/board-live.png、storyboard.png、script-gate.png、library.png。我们只见过这几个文件名——界面长什么样、好不好用、信息密度合不合适、颜色顺不顺眼，本文一个字都不会写，因为我们没有运行过它，评价截图和评价软件是两回事。

同样，backlot/README.md 里的实现说明我们没有读，所以看板是怎么解析项目文件的、刷新频率是多少、用了什么技术栈，这些本文一概不谈。你要是想知道，直接去看那个文件比看任何二手转述都强。

我们能确认的只有一件事：README 把这三条命令、这道审批闸和这几张截图写在了 “Watch It Happen” 这一节里，核对日 2026-08-09。

想自己看一眼，先准备什么

README 的 Quick Start 列了 4 项前置条件：Python 3.10+、FFmpeg、Node.js 18+，以及一个 AI 编码助手（Claude Code、Cursor、Copilot、Windsurf 或 Codex 之一）。标准安装路径是 git clone 之后 cd OpenMontage 再 make setup。

Windows 上有一条 README 单独记下来的已知问题值得先记着：如果 npm install 报 ERR_INVALID_ARG_TYPE，改用 npx --yes npm install。这条出现在手动安装串里那一步。

最后是预期管理的部分。截至 2026-08-09，calesthio/OpenMontage 的 star 是 46362、fork 5758、open issues 218，许可是 AGPL-3.0——star 只说明被收藏过多少次，本文不拿它推导任何关于好不好用的结论；AGPL-3.0 和常见的宽松许可不是一类，你要拿它做什么，请以官方 LICENSE 原文为准。README 里通过 Ollama 和 LM Studio 支持本地 LLM 那一条写的是 “Coming soon”，那是计划不是现有能力，别按已经能用来规划。README 结尾作者还自述了一句：OpenMontage is built nights and weekends。

把这些如实计入预期，再去按那三条命令打开看板，你对它该有什么、不该有什么，心里会清楚很多。关于 OpenMontage 的流水线契约和零密钥能力表，我们另有专门的篇目在讲，这里不展开。

本文依据 OpenMontage 官方仓库（github.com/calesthio/OpenMontage）的 README、 AGENT_GUIDE.md、config.yaml、pipeline_defs/ 与 lib/ 下的治理模块整理，核对日 2026-08-09。本文内容为仓库源码与文档口径，我们没有安装或运行过该系统，也没有调用过其中任何一个 provider API，文中出现的成本数字均为项目方在 README 中自行标注的金额，非我们的实测结果。该项目以 AGPL-3.0 发布，部分流水线在 manifest 中自标 stability: beta，请以仓库最新内容为准。许可条款请以官方 LICENSE 原文为准，本文不构成法律意见。安全相关做法请结合自身环境评估，本文不构成安全方案建议。