「你的编码助手就是编排器」：十一步流程图逐段读

2026-08-09

OpenMontage 的 README 里有一张竖着往下走的流程图，从「你说一句话」开始，到「最终成片」结束，中间十一格。这种图在开源项目首页太常见了，多数人扫一眼就翻过去，默认它是营销图示。

这张图不太一样：它的每一格几乎都能对回仓库里一个具体的文件或字段。把它当目录读，比读 README 正文效率高得多。

先把题眼句摆出来

流程图上面那句原文是整个项目的钥匙：

There is no code orchestrator. Your AI coding assistant IS the orchestrator.

没有代码编排器，你的 AI 编码助手就是编排器。配套的职责划分原文是 Python provides tools and persistence.，所有创意决策、编排逻辑、评审标准和质量标准都活在可读的指令文件里，也就是 YAML manifest 加 Markdown skill，你可以检查它们、改它们。AGENT_GUIDE.md 里说得更死：Python 代码里没有编排逻辑、创意决策、评审逻辑或 checkpoint 策略。

这句话决定了流程图该怎么读。图上的每一格不是「程序执行到了第几步」，而是「这一步由谁负责、依据哪份文本」。下面按格拆。

第 1 到 3 格：入口三格全是在读文本

第 1 格是你，图上举的例子是一句自然语言：Make an explainer video about how black holes form。入口就是聊天框，没有表单、没有参数面板。

第 2 格：agent 读流水线 manifest（YAML），图上标注的内容是阶段、工具、评审标准、成功闸（stages, tools, review criteria, success gates）。这一格对应 Rule Zero 的第二步，读的是 pipeline_defs/<pipeline>.yaml。往前一步的「确定流水线」在 Rule Zero 里是独立的第一条，写着不清楚就问用户，但流程图上没有单独画出来。

第 3 格：agent 读阶段导演 skill（Markdown），图上标注是 HOW to execute each stage，讲每个阶段怎么执行。文件位置是 skills/pipelines/<pipeline>/<stage>-director.md。skills/pipelines/ 实读有 12 个子目录，一条流水线一个：animation、avatar-spokesperson、character-animation、cinematic、clip-factory、documentary-montage、explainer、hybrid、localization-dub、podcast-repurpose、screen-demo、talking-head。图上第 1 格的例子说要做 explainer，落到目录里就是 explainer 那一个。

Rule Zero 对这一格的措辞是「在该阶段做任何工作之前先读」，Do NOT 里也单列了一条：不许在没读阶段导演 skill 之前就生成素材。这三格加起来没有产生任何素材，全部是读文件。

第 4 格：唯一真正动手的一格

第 4 格是 agent calls Python tools，图上标注是 scored provider selection ranks every tool across 7 dimensions，provider 选择会在 7 个维度上给每个工具打分。这 7 个维度各自是什么、权重怎么分，落在 lib/scoring.py 里，本批另有一篇专门拆那张权重表，这里只说它确实是一段可读的 Python，不是一句形容词。

这一格还有一条藏在 Rule Zero 里的前置动作：调任何带 agent_skills 字段的工具之前，先读 .agents/skills/ 里被引用的 skill。也就是说图上看着是「一格」，实际展开是「先读知识包、再调工具」。

工具本体在 tools/ 下。README 的架构图那行写的是 tools/ # 100+ Python tools，我们实读该目录，非 __init__.py 的 Python 文件是 130 个；README 架构图列了 video / audio / graphics / enhancement / analysis / avatar / subtitle 七个子目录，实读还有 capture/、character/、publishers/、_comfyui/、_kling/。同一张图里 schemas/ 那行标的是 “15 JSON Schemas”，和我们实读目录数出来的数量对不上，具体计数本批另有专篇。这几处只陈述差异，以仓库当前状态为准，不推断原因。

第 5 到 7 格：自审、存档、交回给你

第 5 格：agent self-reviews using reviewer skill，图上标注三件事，schema validation、playbook compliance、quality checks。对应的文件名在 skills/meta/ 里，那个分区实读 11 个 .md，其中就有 reviewer.md 和 checkpoint-protocol.md。这两份文件的正文我们没有读过，这里只按文件名说明它在链条上的位置。

第 6 格：agent checkpoints state (JSON)，图上标注是 resumable, with decision log and cost snapshot，可恢复、带决策日志和成本快照。这一格是全图少数能直接落到配置默认值的地方，config.yaml 里对应两行：

checkpoint:
  policy: guided                 # guided | manual_all | auto_noncreative
  storage_dir: pipeline          # relative to project root

默认策略是 guided，另两个可选值是 manual_all 和 auto_noncreative，状态写在项目根下的 pipeline 目录。三种策略各自具体怎么执行，请以仓库代码和官方文档为准。

第 7 格：agent presents for your approval，图上标注 you stay in control at every creative decision。README 说每个决策都会被记录，含考虑过的备选项、置信度分数和每次选择背后的理由。这一格在 AGENT_GUIDE.md 里被展开成一整节 Decision Communication Contract，实读的子标题包括 Announce Before Execution、Ask Before Major Changes、Re-log Changed Decisions (Binding)、Escalate Blockers Explicitly、No Unilateral Substitutions 等。这些是章节标题，正文我们没有逐节读过，但标题本身已经说明这一格想约束什么：动手前先说、大改先问、决策变了要重新记录、不许单方面替换。

与之呼应的是 What Not To Do 里那几条：不要隐藏降级路径，替换和被阻断的选项要明确记录；不要孤立地呈现单个不可用工具，要永远展示完整能力图景，用 “X of Y providers configured for this capability.” 这种说法；不要在没告知用户的情况下更换 provider、模型或渲染路径。

config.yaml 的预算段也压在这一格上：单次动作超过 single_action_approval_usd: 0.50 要审批，require_approval_for_new_paid_tool: true 表示新的付费工具默认需要审批。注意默认的 mode 是 warn 而不是 cap——这三个模式的名字写在同一行注释里（observe | warn | cap），把这几行配好并不等于开销就自动被拦住了。三种模式在代码里各自怎么执行，请以仓库代码为准；就流程图这一格而言，摆在明面上的关口仍然是你的那次批准。

第 8 到 11 格：合成前后各一道闸

第 8 格是 pre-compose validation gate，图上标注三样东西：delivery promise、slideshow risk、renderer governance。前两样在 lib/ 目录里有同名模块 delivery_promise.py 和 slideshow_risk.py，它们内部的阈值和判定逻辑本批各有专篇细说，这里只指出一件事：这道闸不是形容词，是合成动作之前的一次程序化校验。

第 9 格是 render (Remotion or FFmpeg)，标注 composition engine matched to visual grammar。两条渲染路径在 skills/core/ 里都有对应文件，那个分区实读 6 个：color-grading.md、ffmpeg.md、hyperframes.md、remotion.md、subtitle-sync.md、whisperx.md。AGENT_GUIDE.md 里有一节标题直接叫 Present Both Composition Runtimes (HARD RULE)，从标题就能看出「两种合成运行时必须都呈现给用户」是一条硬规则，而不是随手选一个。渲染的输出参数默认值同样写在 config.yaml：1920x1080、30 fps、CRF 23、mp4 容器。

第 10 格是 post-render self-review，标注四项手段：ffprobe、frame extraction、audio analysis、promise verification。最后一项和第 8 格的 delivery promise 是同一件事的两头，一头在合成前立承诺，一头在成片后核验承诺。

第 11 格是 final video output，后面跟着一句限定：only if self-review passes。只有自审通过才出成片。

数一数代码出现在哪几格

把十一格重排一遍，会看到一条很明显的分界：真正有程序在跑的只有四格——第 4 格（调工具）、第 6 格（写 checkpoint）、第 8 格（合成前的校验闸）和第 9 格（渲染），其余七格全是 agent 读文本、做判断、跟你对话。

这四格里也不是同一种代码。第 4 格调的是 tools/ 下的 Python 工具，第 6 格按 README 的说法是把状态写成 JSON，第 8 格对应的 delivery_promise.py、slideshow_risk.py 都在 lib/ 里，这三格是 Python；第 9 格标的是 Remotion 或 FFmpeg，README 的架构图把 remotion-composer/ 注为 React/Remotion 合成引擎，那条路径本身不是 Python。前三格正是 README 那句 Python provides tools and persistence 的字面意思，也是 AGENT_GUIDE.md 里 Rule Zero 收尾金句的意思：The intelligence is in the skills, not in improvised code.

顺带一个可核查的对照。AGENT_GUIDE.md 的 What OpenMontage Is 一节给的核心循环是 5 步：选一条流水线、跑 preflight、从 registry 发现真实工具、向用户呈现概念与工具计划与制作计划与成本、带 checkpoint 逐阶段执行。preflight 在这 5 步里是独立一步，Rule Zero 的五条里也单列了一条「跑 preflight，通过 registry 发现可用工具，展示能力菜单」，而 README 首页那张十一格流程图上没有单独画出 preflight 这一格。两处写法不同，以仓库当前状态为准，说到这里为止。

读完这张图，你能拿它干什么

最实用的用法不是背下来，是拿它当核查表。这套系统的执行者是你自己那个编码助手，它有没有照章办事，你只能自己看：它有没有在动手前告诉你走的是哪条流水线、读的是哪个 manifest；它有没有在生成素材之前先读那份 <stage>-director.md；它换 provider 的时候有没有先说一声；成片出来时它有没有做那一轮 post-render 自审。

也要把边界说清楚。AGENT_GUIDE.md 是一份 714 行、46 个标题的契约文本，Rule Zero 那句 “Every video production request MUST go through the pipeline system. No exceptions.” 是写给模型看的指令，不是运行时强制。契约写了「必须先读 skill」，不等于模型一定会读；能不能落地，取决于你用的 agent 和它当时的上下文。这张流程图同理，它描述的是项目希望发生的顺序，不是保证会发生的顺序。

所以真正值得记住的，是那四格代码和七格文本的分界线。知道哪几格有代码兜底、哪几格只有文本约束，你就知道该在哪几处亲自盯着。

本文依据 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，请以仓库最新内容为准。