OpenMontage 的 `scoring.py` 里还有第二套评分，README 一个字没提

2026-08-09

看 OpenMontage 这种把「智能」写在 Markdown 和 YAML 里的项目，最省事的读法是顺着 README 走一遍。README 的 Production Governance 一节列的条目不少，provider 怎么选、预算怎么控、渲染完怎么自审，都有。问题是，README 写到的东西不等于文件里全部的东西。

lib/scoring.py 就是个例子。README 讲了这个文件里的一套评分，而文件里有两套。

先说有文档的那一套

README 的说法是：每一次工具选择（视频生成、图像生成、TTS、音乐）都会跑一个 7 维评分引擎，维度和权重是 task fit (30%)、output quality (20%)、control features (15%)、reliability (15%)、cost efficiency (10%)、latency (5%)、continuity (5%)；胜出的 provider 及其分数，会连同所有考虑过的备选项一起记进决策链路。

这套说法是可以核对的。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

同一个文件第 57-63 行还有一份 (名称, 值, 权重) 的三元组列表，权重与上面完全一致。七项相加等于 1.00，和 README 的百分比逐项吻合。关于这套权重本身怎么读——为什么 task fit 一项就占到 30%、为什么成本效率只有 10%——我们另有一篇专门讲，这里不重复。

本篇要说的是紧接着它的那一段。

第二套：同一个文件，第 95-101 行

再往下翻，lib/scoring.py 里还有一段结构相同、维度完全不同的加权求和。我们实读抽出来的部分是这样：

+ self.quality_fit * 0.20
+ self.capability_confidence * 0.15
+ self.fallback_integrity * 0.10
+ self.budget_fit * 0.10
...
+ self.consistency_fit * 0.05

能确认的字段名有五个：quality_fit、capability_confidence、fallback_integrity、budget_fit、consistency_fit。中间还有我们没有抽取到的项——注意这五项的权重相加只有 0.60，离 1.00 还差 0.40，所以这段求和里一定还有别的维度，只是我们这次没有把它们全部抄下来。

把两套摆在一起，能直接看出的差异只有一条：维度名基本不重合。 第一套是 task_fit / output_quality / control / reliability / cost_efficiency / latency / continuity，第二套里出现的是 capability_confidence（能力置信度）、fallback_integrity（回退完整性）、budget_fit（预算契合度）这类第一套完全没有的名字。权重的分配方式也不一样，第一套最高一档是 0.30，第二套我们抽到的最高一档是 0.20。

而 README 里对这第二套评分一个字都没有提。

接下来我不打算说的话

写到这里，最容易顺手写下去的一段是「所以它大概是用在某某阶段的」。我不写，原因很实在：我们没有读那部分调用代码。

fallback_integrity 这个名字确实很容易让人联想到别的东西——比如 lib/delivery_promise.py 里那个 approved_fallback 字段，它只有 "animatic"、"still_led" 和 None 三种取值，是「降级必须被显式批准」的实现方式。名字上看起来有呼应，但名字像不代表调用关系存在。这两处是不是一回事、第二套评分在哪个阶段被触发、它和 provider 选择那一套是替代关系还是并列关系，我们都没有依据回答，就不答。

同样地，我也不去推断 README 为什么没写它。是刻意省略、是先写代码后写文档、还是别的什么，我们无从判断，也不打算用这件事去评价这个项目。能核实的是「代码里有、README 里没有」这个状态，说完就停。

这不是谨慎表演，是这类文章唯一站得住的写法。一篇讲源码的文章，把「读到的」和「猜到的」混在一起，读者就没办法用它了。

同一个文件里其它可引用的硬数字

lib/scoring.py 里还有一些散落的数值，第 276-278 行附近有两个成本分档阈值：

if estimated_cost < 0.05:
if estimated_cost < 0.20:

以及若干条件加分项，比如 output_quality + 0.05、control + 0.10、task_fit + 0.15 / + 0.05、output_quality + 0.10。

这些数字本身是确定的，但触发条件那部分代码我们没读，所以只能告诉你「文件里有这些分档和微调值」，不能告诉你「什么情况下会加这 0.15 分」。如果你要在自己项目里参考它的打分设计，这两行阈值和这几个加分幅度是可以直接看的锚点，但请自己翻源码确认它们各自挂在什么条件下。

另外提一句这些分数最终会去哪里。README 的决策审计链路一节写的是：每一个重大的创意与技术选择——provider 选择、风格选择、音乐曲目、音色选择、渲染器 family、任何回退或降级——都会连同考虑过的备选项、置信度分数和理由一起被记录，累积的决策日志跨所有阶段持久化，对应的契约文件是 schemas/artifacts/decision_log.schema.json。这个 schema 的内部字段我们一个都没有读过，所以只能告诉你「存在这样一份决策日志契约」，它具体记哪些键、哪些是必填，请自己打开那个文件看。

把这件事放回整个仓库的核查框架里

我们这次对 OpenMontage 做过一轮 README 说法与实读结果的比对，结果大致能分成三类，第二套评分属于其中第三类。

第一类是逐项吻合的。 核心治理数值基本都在这一类：7 维权重与 lib/scoring.py 完全一致；预算默认值也一致——config.yaml 里 budget.mode 默认 warn、total_usd: 10.00、single_action_approval_usd: 0.50，和 README 讲的三种模式、$10 总额、$0.50 单次审批阈值对得上；幻灯片风险评分在 lib/slideshow_risk.py 的 docstring 里写了 6 个维度、每个 0-5 分、判定门槛 2.0 / 3.0 / 4.0，比 README 的描述还更具体。

第二类是计数对不上的。 README 的架构图里 schemas/ 那行标的是 “15 JSON Schemas”，我们实读该目录数出 24 个 .json——20 个 artifact schema 加 checkpoint、pipeline manifest、style playbook、tool schema 各一。TTS provider 数也是一处：README 表格列了 5 行，而同一份 README 的架构图里 tools/audio/ 那行写的是 “4 TTS providers”，这两个数字都在 README 自己内部。流水线那一项要说得再准一点：README 自称 12 条，我们实读 pipeline_defs/ 是 13 个 yaml（含 framework-smoke，去掉它正好 12），skills/pipelines/ 下也是 12 个目录，自称与实读是对得上的；对不上的只是 README 正文那张流水线表格——它只列了 11 行。这些差异都是我们数出来的客观结果，两处写的不一样，以仓库当前状态为准；至于哪个”对”，我们不推断。

第三类就是本篇这种：代码里存在、README 里没有对应描述。 除了第二套评分，config.yaml 的 budget 段里还有两个 README 没提的键——reserve_pct: 0.10（留 10% 给重试和收尾）和 require_approval_for_new_paid_tool: true（新的付费工具默认要审批）。它们就在配置文件里摆着，只是文档没讲。

这三类的实际影响完全不同。第一类说明你可以放心按 README 的口径去理解那部分行为；第二类提醒你别拿 README 的数字去做容量规划，要自己数；第三类最需要注意——你按 README 建立的心智模型，可能缺了几块，而缺的那几块恰恰是靠读文档补不上的。

给读者的可核查动作

这篇的结论其实很短：读 OpenMontage 这类项目，README 是入口，不是全集。

具体到你自己动手核查，可以这么做：

打开 lib/scoring.py，直接翻到第 38-44 行和第 95-101 行，把两段加权求和并排看一遍——这是本文全部结论的来源，五分钟就能自己确认一遍。
看到任何一段加权求和，先把权重加起来。加到 1.00 说明你读全了；加不到，说明还有维度在你视野之外，比如本文这五项只加到 0.60。
涉及钱和质量闸的数值，一律回配置文件和源码看默认值，别停在 README 的描述上。

需要说明的是，本文所有内容都来自读仓库文件本身。我们没有安装或运行过这套系统，没有调用过任何一个 provider API，因此也无法告诉你这两套评分在真实运行时各自打出什么分。README 里出现的那些成本金额（例如 $1.33、$0.02、$0.69、$0.15 这类）都是项目方在 README 中自行标注的，不是我们验证过的报价，更不能拿来推算你自己做一条片子要花多少钱。README 里那些 High quality、Cost-effective 一类的形容词，也都是 README 的措辞，不是我们的评价，我们不据此给任何选型建议。

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