五个 agent 平台各有一个配置文件，都指向同一份契约

换一个编辑器，同一个项目的行为会不会变？大多数工具不用问这个问题——流程写在代码里，编辑器只是个壳。OpenMontage 得问，因为它把流程写在了文本里，而读这些文本的是你的 AI 编码助手。

于是仓库根目录出现了一组看起来有点冗余的文件。

五个平台，五份配置，一个共同的终点

README 的 agent 兼容性表是这样一张表：

平台	配置文件
Claude Code	CLAUDE.md
Cursor	CURSOR.md + .cursor/rules/
GitHub Copilot	COPILOT.md + .github/copilot-instructions.md
Codex	CODEX.md
Windsurf	.windsurfrules

关键不在这张表本身，而在 README 紧跟着的那句说明：所有平台文件都指向共享的 AGENT_GUIDE.md（操作指南与 agent 契约）和 PROJECT_CONTEXT.md（架构参考）。

也就是说，这五份文件解决的是「各家 agent 各认各的入口文件」这个现实问题，它们不是五套不同的规则。真正的规则只有一份，落在 AGENT_GUIDE.md 里，五个入口只是五条通往它的路。

顺带说一处可核查的差异：我们实读仓库顶层，除了上表里的 CLAUDE.md、CURSOR.md、COPILOT.md、CODEX.md 之外，还有一份 AGENTS.md，而 README 的兼容性表里没有列它。这里只陈述差异，不推断哪份是主入口，也不推断为什么表里没写。

为什么它非得这么设计

理解这个结构，得先回到 README 里那句题眼：

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

没有代码编排器，你的 AI 编码助手就是编排器。配套的职责划分原文是 Python provides tools and persistence.——Python 只提供工具和持久化，所有创意决策、编排逻辑、评审标准和质量标准都活在可读的指令文件里，也就是 YAML manifest 加 Markdown skill。AGENT_GUIDE.md 里说得更死：Python 代码里没有编排逻辑、创意决策、评审逻辑或 checkpoint 策略，这些决策由 agent 在指令引导下做出。

这句话推到底就是：编排器不在仓库里，编排器是你带来的那个 agent。 而你带来的 agent 是哪一个，仓库不能假设。既然行为不由代码固定，它就只能靠文本约束；既然要靠文本约束，就必须保证不同平台读到的是同一份文本。这两句连起来，就是「五份配置指向同一份契约」的全部理由。

这也解释了 Quick Start 的前置条件为什么有点特别。README 列的 4 项里，前三项是 Python 3.10+、FFmpeg、Node.js 18+，第四项直接就是「一个 AI 编码助手」，并点名 Claude Code、Cursor、Copilot、Windsurf 或 Codex。前三项是运行时依赖，第四项是编排器本身——这一项没有替代方案，因为项目里没有别的东西在做这件事。

那份共同的契约里，到底约束了什么

AGENT_GUIDE.md 是一份 714 行的文件，我们实读它的标题结构，共 46 个标题。最硬的一节叫 Rule Zero — All Production Goes Through a Pipeline，加粗原文是：Every video production request MUST go through the pipeline system. No exceptions.

它要求 agent 在任何视频制作请求上依次做五件事：把请求匹配到 pipeline_defs/ 里的某一条流水线（不清楚就问用户）、读 pipeline_defs/<pipeline>.yaml 这份 manifest、跑 preflight 通过 registry 发现可用工具并展示能力菜单、逐阶段执行且在该阶段做任何工作之前先读 skills/pipelines/<pipeline>/<stage>-director.md、调任何带 agent_skills 字段的工具之前先读 .agents/skills/ 里被引用的 skill。

配套的 Do NOT 也写得很具体：不许写临时 Python 脚本直接调工具、不许跳过流水线直奔 API 调用、不许没读阶段导演 skill 就开始生成素材、不许用工具时不查它的 Layer 3 skill、不许绕过 preflight / checkpoint / review。

契约最后一节 What Not To Do 里，有几条特别值得跨平台使用的人留意，因为它们约束的正是「换了工具之后你还能不能看懂发生了什么」：

• 不要隐藏降级路径，替换和被阻断的选项要明确记录
• 不要孤立地呈现单个不可用工具，永远展示完整能力图景，用 “X of Y providers configured for this capability.” 这种说法
• 不要在 preflight 时跳过 Provider Menu，用户必须看到他有什么以及他还能解锁什么
• 不要在没有事先告知用户的情况下更换 provider、模型或渲染路径，改动重大时还要拿到批准
• 不要硬编码 provider 名、API key 名或安装 URL，要从 registry 的 install_instructions 和 dependencies 字段读
• 不要使用已被删除的旧名称，如 tts_cloud、tts_engine、video_gen

最后两条值得单独看一眼：它们把「一切经由 registry」这个前提落到了具体禁令上——名称与安装方式一旦被写死在别处，registry 里的 install_instructions 和 dependencies 就不再是唯一来源。这两条为什么被写进契约，文档没有说明，我们也不推断。

46 个标题里还有一个标题本身就把规则写在了脸上：Present Both Composition Runtimes (HARD RULE)——两种合成运行时必须都呈现，这是一条硬规则。需要说明的是，除了上面明确照抄的 Rule Zero、What OpenMontage Is 和 What Not To Do 三节，这份契约其余章节的正文我们没有读过，这里只按标题说明它覆盖了哪些方面，不展开细则。

一处跑不掉的锚点：跨平台一致的不止契约

契约是文本，文本靠 agent 自觉。但仓库里还有一处一致性是文件层面的：根目录的 config.yaml。它是一份文件，不随你在哪个编辑器里打开这个项目而变。里面几个值得记住的默认值：

budget:
  mode: warn                     # observe | warn | cap
  total_usd: 10.00
  reserve_pct: 0.10              # holdback for retries / cleanup
  single_action_approval_usd: 0.50
  require_approval_for_new_paid_tool: true

checkpoint:
  policy: guided                 # guided | manual_all | auto_noncreative

预算默认走 warn 模式而不是 cap，总额 total_usd: 10.00，留 10% 给重试和收尾，单次动作超过 $0.50 要审批，新的付费工具默认需要审批。checkpoint 策略默认 guided，另两个可选值是 manual_all 和 auto_noncreative。把这几行看清楚是有意义的：默认是 warn 不是 cap，别一看到 total_usd: 10.00 就当成一道硬性支出上限；这几行怎么执行请以仓库代码和官方文档为准，配好它也不等于不会超支。

config.yaml 里另有一段 llm，默认 provider: anthropic，注释里列了 7 个可选值 anthropic | openai | gemini | openrouter | ollama | mistral | minimax，model: null、temperature: 0.7、max_tokens: 4096。这一段与「你在哪个编辑器里跑 agent」是不是同一件事，我们读到的文件里没有给出说明，不推断，只如实摆出这几行。

这里有一处可核实的前后差异要一并说清楚：config.yaml 的注释里已经列了 ollama，而 README 明写通过 Ollama 和 LM Studio 支持本地 LLM 是 “Coming soon”。两处口径不一致，以仓库当前状态为准。README 把它写成计划，那它现在就是计划——如果你的选型前提是「必须完全脱离云端 LLM」，不要按已实现的功能去规划。

这个设计保证不了什么

必须把话说到底：契约文本是写给模型看的约束，是指令，不是工程保障。

Rule Zero 里写了「在该阶段做任何工作之前先读阶段导演 skill」，这句话的性质是一条要求，不是「装好之后模型一定会先读」的结果。同理，What Not To Do 里那十条也不是十道拦截器，它们是十条被写下来的期望。能不能真的落地，取决于你用的是哪个 agent、它当时的上下文里还剩多少空间、以及你有没有让它跳过步骤。

再补一句边界：不同平台读入口文件的机制有没有差别、哪一个更容易忠实执行这份契约，我们没有依据，本文不比。我们没有安装或运行过这套系统，也没有在任何一个平台上驱动过它，上面所有内容都是文件层面的口径。

顺带提一句 README 给 agent 的最短上手路径，第 1 步就是「先读契约」：先看 AGENT_GUIDE.md，再看 PROJECT_CONTEXT.md；第 2 步是「不要即兴发挥制作流程」；第 3 步是用 registry 的两条命令去查真实的能力边界（这两条命令我们另有一篇专门讲）；第 4 步是把每个视频请求都当成一个流水线选择问题。四步里有两步是「先读文本」，这本身就说明这套系统的重心在哪。

落到你的判断上

如果你在评估要不要上手，这一节的结论其实很简单：

先确认你手上有一个 AI 编码助手。 README 的前置条件第 4 项点名的是 Claude Code、Cursor、Copilot、Windsurf 或 Codex，兼容性那一节的措辞则更宽一些——「任何能读文件、能跑代码的 AI 编码助手」。两处口径宽窄不同，以仓库当前状态为准。但无论按哪一处读，这一项都没有替代方案：项目里没有代码编排器可以替你走完流程。

其次接受「同一份契约、不同的执行者」这个前提。 你换平台，规则不变，但执行规则的是另一个模型。想要可比的结果，值得自己在项目里留一条记录，比对不同平台下的决策日志——这是通用工程做法，不是该项目官方文档里的内容。

最后，别把契约当保险。 它约束的是「agent 应该怎么做」。相比之下，config.yaml 里 single_action_approval_usd: 0.50、require_approval_for_new_paid_tool: true 这几行是写在配置文件里的、可以逐行核对的开关；但预算 mode 默认是 warn 而不是 cap，这几个值具体怎么被执行，请以仓库代码和官方文档为准。把它们看清楚，比记住契约里那十条禁令更容易落到实处——不过这也不等于配好就不会超支。

另外，这个仓库以 AGPL-3.0 发布，与常见的 MIT、Apache-2.0 不是一类；我们没有读过 LICENSE 正文，这里只指路。

---

本文依据 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 原文为准，本文不构成法律意见。 安全相关做法请结合自身环境评估，本文不构成安全方案建议。