OpenMontage 七维评分权重 30/20/15/15/10/5/5：文档与代码逐项吻合

2026-08-09

翻这类「文档写得很漂亮」的仓库，我的习惯动作是先挑一个 README 里带具体数字的说法，去代码里对一遍。多数时候这一步是用来泼冷水的：数字对不上，或者根本找不到对应实现。

OpenMontage 的七维评分是少见的另一种情况——README 写的权重，和 lib/scoring.py 里的实现逐项一致。这篇就把这一处对照做完，顺带说清「对得上」这三个字的边界在哪里。

README 的说法

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

这段话有两个可以被证伪的点：维度是不是这七个，权重是不是这几个数。

源码里的两处，都在 `lib/scoring.py`

第一处是加权求和，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 行还有一份 (名称, 值, 权重) 三元组列表，权重与上面完全相同：

("task_fit", self.task_fit, 0.30),
("output_quality", self.output_quality, 0.20),
("control", self.control, 0.15),
("reliability", self.reliability, 0.15),
("cost_efficiency", self.cost_efficiency, 0.10),
("latency", self.latency, 0.05),
("continuity", self.continuity, 0.05),

七个数相加正好是 1.00。README 里的 control features 对应源码字段名 control，cost efficiency 对应 cost_efficiency，其余名称一一对应。也就是说，README 那句 7 维评分不是一句愿景式的形容，它有确切的落点，而且落点有两处、彼此一致。

这里顺带记一个实用细节：权重在这一个文件里出现了两次。要是哪天你想改这套排序的取向，改一处是不够的——第 38-44 行管的是算分，第 57-63 行管的是那份带权重的输出，两边不同步，算出来的分和打印出来的理由就会各说各话。

这组权重本身在说什么

权重表最有信息量的地方，不是最大的那一项，而是各项之间的比值。三条可以从数字直接读出来：

task fit 一项就占 30%，等于 control (15%) + cost efficiency (10%) + latency (5%) + continuity (5%) 四项之和。换句话说，「这个 provider 是不是干这类活的」这一个判断，权重等于 control、cost efficiency、latency、continuity 这四项加起来。这四个维度具体各自考察什么，README 只给了名字，源码里也只有字段名，我们不替它展开。

task fit 加 output quality 合计 50%，正好一半。而 cost efficiency 只有 10%，latency 和 continuity 各 5%。这套评分把任务匹配度和输出质量放在成本与速度之前，而且不是稍微靠前，是拉开了三到六倍的差距。

control 与 reliability 同为 15%，两者平权。README 把这两项写作 control features 与 reliability，在这套账里它们的话语权完全相同，谁也不压谁一头。

这几条对使用者是有实际含义的。如果你的诉求是「尽量便宜」，那你要清楚地知道：在默认权重下，成本效率只有十分之一的话语权，一个更贵但任务匹配更好的 provider 完全可能赢下来。这不是 bug，是这套权重写下来时就选好的立场。至于该不该改、改成多少，仓库没有给通用建议，我们也不给——这取决于你在做什么片子。

还有一点值得单独说。README 明确写了，胜出的 provider 及其分数会连同所有考虑过的备选项一起记进决策链路。把这句话和公开的权重放在一起看，意义就不只是「留个日志」：权重是写死在源码里的七个字面量，各维度的分数又被记了下来，那么事后拿这七个权重把总分重算一遍，是一道纯算术题。一个选择能不能被复核，前提就是它的评分函数不是黑箱——这套设计至少把这个前提摆出来了。至于日志里究竟落了哪些字段，对应的 schema 内部我们没有读过，不展开。

README 另外补了两点，都与打分前后的环节有关。一是选择器会在打分前归一化松散的需求上下文：当 agent 手上只有 “Pixar-style animated short with character consistency” 这种描述时，选择器会把它展开成打分器能吃的意图与风格信号，而不是要求上游先交出一个成型的 task_context。二是选择器的输出会带出所选 provider 的 agent_skills，好让 agent 接着去读对应的 Layer 3 provider skill 再写 prompt。这两条我们只能按 README 的文字转述，对应的实现代码没有读。

同一个文件里，还有第二套评分

lib/scoring.py 第 95-101 行还有一段加权求和，权重与上面那套不同，实读片段是这样：

+ 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，中间还有我们没有抽取到的项。可以确定的是：这套评分与前面那套 provider 评分的维度完全不同，而 README 对它只字未提。

这里必须停住。它在什么时候被调用、和 provider 评分是并列关系还是上下游关系、fallback_integrity 这种名字对应的是哪一段治理逻辑——那部分调用代码我们没有读，所以一个字都不推断。能写的只有这一句：文件里存在第二套加权评分，README 没有覆盖它。

文件里另有两个成本分档阈值，出现在第 276-278 行附近：if estimated_cost < 0.05: 与 if estimated_cost < 0.20:，以及若干条件加分值，例如 task_fit + 0.15 / + 0.05、output_quality + 0.05 / + 0.10、control + 0.10。数值本身是确切的，但触发这些加分的条件我们同样没有读，所以这里只列数字，不解释「什么情况下会加这 0.15」。

「逐项吻合」的边界

七维权重对得上，不等于这个仓库的文档全都对得上。把核对结果分成两类，界线其实相当清楚。

对得上的是治理数值。 除了七维权重，还有两处：config.yaml 里预算段的默认值与 README 描述逐条一致——默认模式 warn、总额 total_usd: 10.00、单次动作审批阈值 single_action_approval_usd: 0.50，三个模式名 observe / warn / cap 也一致；lib/slideshow_risk.py 的模块 docstring 写明幻灯片风险是 6 个维度、每维 0-5 分，判定门槛 2.0 / 3.0 / 4.0，比 README 的描述还更具体。顺带一提，配置里有两项 README 没写：reserve_pct: 0.10（预留一成给重试和收尾）和 require_approval_for_new_paid_tool: true。这几处的详细拆解本批另有专篇，这里只是用来说明「哪一类数字对得上」。

对不上的是计数类描述。 README 的架构图里 schemas/ 那行标的是 15 个 JSON Schema，我们实读该目录数出 24 个 .json；TTS 的 provider 表格是 5 行，而架构图里 tools/audio/ 写的是 4 个 TTS provider；流水线 README 自称 12 条，pipeline_defs/ 下有 13 个 yaml（含一个 framework-smoke）、skills/pipelines/ 下有 12 个目录，而 README 的流水线表格只列了 11 行。这些差异是我们数出来的客观结果，两处写的不一样，以仓库当前状态为准。为什么不一致、哪个才是「对的」，我们不推断，也不拿它去评价这个项目——说完就停。

把这两类分开，比笼统地说「文档准不准」有用得多：真正会影响系统行为的那些数（权重、阈值、预算默认值）是和代码对齐的，对不上的是描述规模的计数。你在读这个仓库时，前一类可以直接信源码并且发现文档也没写错，后一类一律以你自己 ls 出来的结果为准。

落到动作上

如果你想自己验一遍，路径很短：打开 lib/scoring.py，看第 38-44 行的加权求和，再往下几行看 57-63 行的三元组，两处对照 README 的那串百分比。七个数，一分钟就能对完，对完你手里就有了一条确定的信息：这套权重在源码里有确切落点，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，请以仓库最新内容为准。许可条款请以官方 LICENSE 原文为准，本文不构成法律意见。安全相关做法请结合自身环境评估，本文不构成安全方案建议。