OpenMontage：README 的数字与仓库实况，一张十行核查表
看 OpenMontage 的 README，最容易顺手做的一件事，就是把里面的数字直接抄进自己的选型笔记：700+ 个 agent skill 与生产知识文件、100+ 个 Python 工具、15 个 JSON Schema、12 条生产流水线。这些数字排版得像规格表，读起来也像规格表。
但它们的性质是「项目方在 README 里写的描述」，和「你 clone 下来那份仓库里此刻真实存在多少个文件」是两件事。这两件事在这个仓库里有的对得上，有的对不上。
这篇只干一件事：把 README 里能被计数或被源码字面量验证的说法，逐条摆到我们实读的结果旁边，做成一张十行的核查表。
先说清楚这次核查做了什么、没做什么
我们的动作只有两种。一是数目录里的文件——按后缀数个数，不打开看内容，不判断某个文件算不算「一个功能」。二是把 README 的描述性数值与 lib/ 下对应源码里的字面量逐项比对，比如 README 说评分是七个维度、权重多少，就去 lib/scoring.py 里看那几行加权求和写的到底是什么。
没做的更多：我们没有安装过这个项目，没有跑过 make setup，没有渲染过任何一条视频，也没有调用过其中任何一个 provider API。所以凡是「跑起来会怎样」「实际能用几个」的问题，这篇一律不答。
还有一条纪律，写在前面，后文每一行都按它执行：只陈述差异，不推断原因。哪一处写的是 15、哪一处数出来是 24，这是可以核对的客观结果；至于作者为什么没同步、哪个数字「才是对的」、这说明什么——我们不知道，也不打算猜，更不会拿它去评价项目质量。看到差异的正确用法是「以仓库当前状态为准，自己数一遍」，不是「据此下判断」。
身份锚点也带一下：calesthio/OpenMontage，截至 2026-08-09，star 46362、fork 5758、open issues 218，主语言 Python，许可是 AGPL-3.0。star 数只说明被收藏过多少次，本文不用它推导任何结论；许可这一条以官方 LICENSE 原文为准，我们没有读过 LICENSE 正文。
十行核查表
| README 的说法 | 我们实读的结果 | 结论 |
|---|---|---|
schemas/ —— “15 JSON Schemas” | 24 个 .json | 不吻合 |
| ”700+ agent skill and production-knowledge files” | skills/ 156 + .agents/ 567 = 723 | 吻合 |
| ”12 production pipelines” | pipeline_defs/ 13 个 yaml（含 framework-smoke），去掉后 12；skills/pipelines/ 12 个目录 | 吻合，但 README 表格只列了 11 行 |
| ”100+ production tools” | tools/ 下非 __init__.py 的 .py 文件 130 个 | 无法直接判定 |
| 视频生成 “15 providers” | 表格 15 行 | 吻合 |
| 图像生成 “11 tools/providers” | 表格 11 行 | 吻合 |
| TTS “5 providers” | 表格 5 行，但架构图里写 tools/audio/ 是 “4 TTS providers” | README 内部不一致 |
| 七维评分权重 30/20/15/15/10/5/5 | lib/scoring.py 第 38-44 行逐项一致 | 完全吻合 |
| 预算默认 $10 / 阈值 $0.50 / 三种模式 | config.yaml 逐项一致 | 完全吻合 |
| 幻灯片风险 6 个维度 | lib/slideshow_risk.py 的 docstring：6 维，判定门槛 2.0 / 3.0 / 4.0 | 吻合且更具体 |
十行摆完，可以分成四类看。
第一类：计数类描述对不上
最直观的一行是 schemas/。README 的目录树里那一行写的是 “15 JSON Schemas (contract validation)“，我们打开这个目录数 .json 文件，数出 24 个。构成是 20 个 artifact schema，加上 1 个 checkpoint、1 个 pipeline manifest、1 个 style playbook、1 个 tool schema，合计 24。这些 schema 文件的内部字段我们一个都没读过，所以这里只能说「存在这样一个契约文件」，不能说它校验什么。两处数字不一致，以仓库当前状态为准。
同一张架构图里还有一处可以核对的差异。图里 tools/ 下挂了七个子目录：video、audio、graphics、enhancement、analysis、avatar、subtitle。我们实读 tools/，除这七个之外还有 capture/、character/、publishers/、_comfyui/、_kling/。README 的这张架构图是简化过的，不是目录的完整快照——把它当成导览图看没问题，当成 ls 的输出看就会漏。
第二类：README 内部两处说法不一
这一类比「文档和代码对不上」更容易被忽略，因为你翻的是同一份 README。
TTS 那一行是典型：正文的 provider 表格写的是 5 个，而上面那张目录树里 tools/audio/ 的注释写的是 “4 TTS providers”。我们数表格是 5 行。同一份文档里两个数，这篇只陈述这个事实；关于这条差异本批另有一篇专门讲，这里不展开。
流水线那一行也属于这一类，只是方向相反。README 自称 12 条，我们数 pipeline_defs/ 有 13 个 yaml，其中包含一个 framework-smoke，去掉它正好 12；skills/pipelines/ 下也是 12 个子目录——三处能对上。但 README 正文里那张流水线表格只列了 11 行——同一份文档里，正文说 12，表格摆出来 11 行。「12」这个数与我们数这两个目录的结果吻合，表格那 11 行则少了一条。想知道到底有哪几条，比看表格更可靠的办法是直接列 pipeline_defs/ 和 skills/pipelines/ 这两个目录。
还有一处不在表里、但同源的差异值得记一笔：config.yaml 的 llm.provider 注释里已经列出了 7 个可选值 anthropic | openai | gemini | openrouter | ollama | mistral | minimax，其中包含 ollama；而 README 明写通过 Ollama 和 LM Studio 支持本地 LLM 是 “Coming soon”。配置注释里出现某个名字，不等于那条路径现在可用——README 把它写成计划，那它就是计划。同类的还有前置要求里的 Node 版本口径，README 的 Quick Start 与合成运行时那边标的下限不是同一个数字，那条属于运行时那一组的核对，本批另有一篇专门讲。
第三类：根本判定不了的那一行
“100+ production tools” 这一行，我们给的结论是「无法直接判定」，这不是偷懒。
我们能数的是文件：tools/ 下非 __init__.py 的 .py 文件有 130 个。但一个 Python 文件不等于一个工具——可能一个文件里有多个工具类，也可能有的文件根本不是工具本身。tools/ 根下就摆着四个不在任何子目录里的文件：base_tool.py、cost_tracker.py、google_credentials.py、tool_registry.py。其中两个的定位 README 自己交代过：新增一个工具的做法是在 tools/ 相应子目录下建 Python 文件、继承 BaseTool 并实现工具契约，然后 registry 会自动发现它、不需要手动注册；tools/cost_tracker.py 则被 README 的预算控制一节点名为对应文件。另外一个我们没有读过实现，不做推测。所以正确的写法只能是「文件数为 130」，而不是「工具数为 130」，更不能反过来说「130 > 100，所以 README 说的对」。
这一行其实是整张表里最该学的一条方法：核查前先确认你数的东西和文档说的东西是不是同一个单位。单位对不上的比较，得出「吻合」和「不吻合」都没有意义。想知道当前环境里到底有多少工具真的可用，README 给的办法也不是数文件，而是去问 registry——它自己列了两条查询命令，那属于能力发现的话题，本批另有一篇专门讲。
第四类：完全对得上的三处，而且都是硬数值
这一类是这张表里最值得单独说的部分，因为它和前三类刚好构成一个区分。
七维评分权重。README 说每一次工具选择都会跑一个七维评分引擎，权重是 task fit 30%、output quality 20%、control features 15%、reliability 15%、cost efficiency 10%、latency 5%、continuity 5%。我们打开 lib/scoring.py，第 38-44 行的加权求和写的是：
self.task_fit * 0.30
+ self.output_quality * 0.20
+ self.control * 0.15
+ self.reliability * 0.15
+ self.cost_efficiency * 0.10
+ self.latency * 0.05
+ self.continuity * 0.05
逐项一致，七个权重相加等于 1.00。同一文件第 57-63 行还有一份 (名称, 值, 权重) 三元组列表，权重与上面完全相同。文档怎么说，代码就怎么算。
预算默认值。README 的 Budget Controls 一节说默认总预算 $10、单次动作审批阈值默认 $0.50、三种可配置模式是 observe / warn / cap。config.yaml 里写的是 mode: warn、total_usd: 10.00、single_action_approval_usd: 0.50，逐项吻合。顺带一提，配置里还有两项 README 没提到：reserve_pct: 0.10（预留 10% 给重试和收尾）和 require_approval_for_new_paid_tool: true（新的付费工具默认要审批）。这里必须加一句：这几个键的默认值和文档口径一致，不等于配好就不会超支，默认模式是 warn 而不是 cap。
幻灯片风险的六个维度。README 提到 6 维分析，lib/slideshow_risk.py 的模块 docstring 不但确认了 6 维，还给出了 README 没写的判定门槛：每个维度 0-5 分、分越低越好，平均分 < 2.0 判 strong、< 3.0 判 acceptable、< 4.0 判 revise、≥ 4.0 判 fail 且不应进入 compose 阶段。这一行的实读结果比 README 更具体。这个模块内部那六个 _score_* 私有函数的打分逻辑我们没有读过，所以它「怎么判定重复」这类问题，这篇不答；具体阈值怎么用，本批另有一篇专门讲。
这张表真正的用法
把四类合起来看，结论其实很清楚：对不上的集中在计数类描述（schema 数、TTS provider 数、流水线表格行数、架构图里的子目录），而涉及行为的核心治理数值——评分权重、预算默认值、幻灯片风险维度——文档与代码是逐项吻合的。
所以读这份 README 时可以分两种态度。凡是「有多少个 X」这种数量描述，别直接引用，打开对应目录自己数一遍，成本只有几秒；凡是「系统按什么规则行事」这种行为描述，在我们核查到的三处里，它和源码是对得上的，可以拿来理解设计意图——但仍然要落到具体文件去看，因为源码往往比 README 多给一层（slideshow_risk.py 那四档阈值就是 README 里没有的）。
最后重申那条纪律：以上全部是我们数出来的、比对出来的客观结果。差异说完就停，不推断原因，不评价这个项目的质量或可信度。你要做的也是同一件事——clone 下来，打开目录，自己数一遍。
本文依据 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 原文为准，本文不构成法律意见。
安全相关做法请结合自身环境评估，本文不构成安全方案建议。