估算、预留、对账：$10 上限与 $0.50 阈值背后的四个配置键

2026-08-09

调 AI 生成类流水线，最怕的不是效果不好，是账单不好看。OpenMontage 的 README 在 Production Governance 一节里给了一句挺提气的收尾：No surprise bills. The agent tells you what it will cost before it spends.（不会有意外账单，agent 会在花钱之前告诉你要花多少。）

这句话是愿景。真正落在磁盘上、能被你 diff 出来的，是仓库根目录 config.yaml 里的五行 YAML。这篇就只干一件事：把这五行逐个拆开，说清每个键管什么、默认值是多少、README 讲了哪几个、又漏讲了哪两个。

README 的四步：Estimate / Reserve / Reconcile / 模式

先看文档口径。README 的 Budget Controls 把预算控制拆成四步加四类配置，原文要点是：

Estimate —— 执行前估算，先看看会花多少
Reserve —— 预留预算，在调用之前把这笔钱锁住
Reconcile —— 事后对账，把实际花销记下来
可配置模式 —— observe（只跟踪）、warn（记录超支）、cap（硬上限）
单次动作审批 —— 超过阈值就暂停等确认，默认 $0.50
总预算上限 —— 默认 $10，完全可配置

注意这三个动词的顺序：估算在前，预留在中，对账在后。这是一条「先说、再锁、后核」的链条，而不是「花完了看报表」。README 给这一节对应的实现文件是 tools/cost_tracker.py 与 schemas/artifacts/cost_log.schema.json——这两个文件的内部我们没有读过，这里只按名字指路，不描述它们怎么记账。

落到配置：`config.yaml` 的 `budget` 段

看这类项目，我的习惯是先翻配置文件，因为默认值是跑不掉的硬事实。config.yaml 里 budget 这一段实读如下：

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

五行，其中四个是可调的数值或枚举，第五个是一个布尔开关。逐个说。

mode: warn —— 这一行是最容易看错的地方。三个可选值是 observe、warn、cap，按 README 的解释，只有 cap 是硬上限，warn 是「记录超支」，observe 是「只跟踪」。默认给的是 warn。 也就是说，你看到下面那行 total_usd: 10.00 时，不要下意识把它读成「花到 10 块就自动停」——在默认模式下它不是。这三种模式各自具体怎么执行，请以仓库代码和官方文档为准，我们没有跑过这套系统。

total_usd: 10.00 —— 全局总预算，单位美元，README 自称的默认值 $10 与配置实读值逐项吻合。

reserve_pct: 0.10 —— 行内注释原文是 holdback for retries / cleanup，即预留 10% 给重试和收尾。这一项 README 的 Budget Controls 一节没有写。 它对应的正是四步里的 Reserve：预留不是把钱花掉，是先扣一块出来别让前面的阶段吃光，免得渲染失败要重试时已经没额度了。

single_action_approval_usd: 0.50 —— 单次动作的审批阈值，与 README 自称的 $0.50 吻合。这个键和 total_usd 是两个正交的口子：一个管总量，一个管单笔。总量还没到 10 块，不妨碍某一次调用因为超过五毛而停下来等你点头。

require_approval_for_new_paid_tool: true —— 这一项 README 也没写。 默认为真，语义是「新的付费工具需要审批」。它管的既不是总量也不是单笔金额，而是「有没有引入一个新的花钱渠道」这件事本身。

把这两项补上之后，budget 段的形状就清楚了：三道口子（总量 / 单笔 / 新渠道）加一道预留，外面套一个模式开关。

一处少见的「文档与代码对得上」

这批仓库我们核过不少 README 数字，对不上的地方不算少。但预算这一块是个例外：默认模式 warn、总额 $10.00、单次审批阈值 $0.50、三个模式名，README 与 config.yaml 逐项吻合。 同样吻合的还有七维评分权重（lib/scoring.py 第 38-44 行的 0.30/0.20/0.15/0.15/0.10/0.05/0.05，相加正好 1.00）和幻灯片风险的 6 维与 2.0/3.0/4.0 三档判定门槛。

对不上的主要是计数类描述——比如 README 架构图里 schemas/ 那行标 “15 JSON Schemas”，我们实读该目录数出 24 个 .json。这类差异本批另有专篇逐条列表，这里只陈述事实：两处写的不一样，以仓库当前状态为准，我不推断原因，也不拿它评价项目。

区分这两类差异是有用的：核心治理数值（权重、阈值、默认金额）是逐项对得上的，对不上的是数量描述。 你照着 README 配预算，配出来的东西和代码里的默认值是一回事。

单条流水线可以带更紧的预算

全局 $10 不是唯一的一层。pipeline_defs/documentary-montage.yaml 里 orchestration.budget_default_usd 的值是 1.00，比全局默认低一个数量级。这说明预算默认值是分层的：单条流水线可以自带比全局更紧的默认额度。

顺便说一句，同一份 manifest 里还写着 stability: beta。项目自己标了状态，我们如实抄过来。

为什么七维评分里成本只占 10%

预算这件事还有一个容易误解的地方：很多人以为「选便宜的 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 行还有一份 (名称, 值, 权重) 三元组列表，权重与上面完全一致。从这组数字能直接读出三件事：task fit 一项就占 30%，等于 latency、continuity、cost_efficiency、control 四项加起来的总和；cost efficiency 只占 10%，latency 和 continuity 各只占 5%；task fit 加 output quality 合计 50%，也就是说，这套评分把「任务匹配度」和「输出质量」放在成本和速度之前。

结论很直接：打分器不是省钱工具。 它默认愿意为了任务匹配和质量多付一点。真正把花销拦下来的，是审批阈值、总额上限，以及每一个创意闸上你自己那个批准动作。

lib/scoring.py 里还有两个成本分档阈值，源码是 if estimated_cost < 0.05: 和 if estimated_cost < 0.20:。这两个数值可以引用，但它们各自在什么条件下触发、分档之后做什么，那部分调用代码我们没有读，不做描述。

同一个文件里另有第二套加权评分（第 95-101 行），维度名与 provider 评分不同，其中恰好有一项叫 budget_fit，权重 0.10，另有 quality_fit 0.20、capability_confidence 0.15、fallback_integrity 0.10、consistency_fit 0.05。README 完全没有提到这套评分。 它用在哪一步、什么时候被触发、和第一套是什么关系，我们没有读那部分调用代码，一律不推断。

对账落在哪里

估算和预留讲完了，第三步 Reconcile 的落点也有可核查的锚。README 那张流程图里有一行原文是 Agent checkpoints state (JSON) -- resumable, with decision log and cost snapshot——checkpoint 是可恢复的，并且带决策日志和成本快照。config.yaml 的 checkpoint 段则给了它落盘的位置：policy: guided（另两个可选值是 manual_all 和 auto_noncreative），storage_dir: pipeline，相对项目根目录。

也就是说，成本记录不是跑完才生成的一份报表，它跟着 checkpoint 一路往下写。README 在 Decision Audit Trail 一节说，每一个重大选择——包括任何回退或降级——都会连同考虑过的备选项、置信度分数和理由一起记录，累积的决策日志跨所有阶段持久化。成本这条线和决策那条线是并排走的。

关于 README 里那些美元数字

README 里贴了 5 段演示视频，其中 4 段各标了一个总成本，也就是常被引用的 $1.33、$0.02、$0.69、$0.15 这几个数（第 5 段 “SIGNAL FROM TOMORROW” 没有标成本）。

这些是项目方在 README 中自行标注的金额，不是我们验证过的报价。 我们没有跑过 make setup，没有渲染过任何一条视频，没有调用过任何一个 provider API。所以这几个数字不能用来推算你自己做一条要花多少钱——你的时长、分辨率、重试次数、选到哪个 provider、当时的 API 定价，没有一项是这几个数字能覆盖的。它们能说明的只有一件事：项目方为它自己那几段演示片标了这个价。

所以，配完这五行意味着什么

意味着你有了一份声明式的、可以被 diff 的预算意图，仅此而已。

total_usd、single_action_approval_usd、reserve_pct 三个数值加 mode 一个枚举，是你写给系统看的口径；require_approval_for_new_paid_tool: true 是你留的第三道口子。它们能不能真的拦住支出，取决于执行侧是否按这套语义走，也取决于你在每个审批点是不是真的看了再点。把这几行配好不等于不会超支——这一点无论 README 写得多有底气，都不该由这篇文章替它下结论。

要自己核实上面每一个数字，办法很简单：打开仓库根目录的 config.yaml，翻到 budget 那一段，对着 README 的 Budget Controls 一节读一遍。五行 YAML，一分钟的事，比信任任何一篇二手文章都可靠。密钥不在 config.yaml 这一份文件里——README 把 API key 放在 .env（原文强调 every key is optional），贴配置到哪里之前先确认自己没把它们带出来，这一条是通用做法，不是该项目文档里的要求。

本文依据 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，请以仓库最新内容为准。安全相关做法请结合自身环境评估，本文不构成安全方案建议。