本文要点
- Databricks首次集中披露四类成本控制杆及其方向性分项。
- Smart Router获得平均任务成本降低超过30%的内部结果表述。
- harness与缓存调优获得生成token及相关成本接近减半的内部结果。
阅读辅助
先看数字、证据和来源，再读正文。
Databricks没有宣称整体AI编程支出下降70%。
2026-06-13 · Databricks开源Omnigent，用元harness统一代理、策略与会话成本控制。
如果先看社区标题，读者很容易得到一个醒目的结论：Databricks把AI编程支出压低了70%。但对官方原文逐项做口径审计后，这个结论并不成立。8月7日的Databricks文章披露的是四类成本控制杆、一组非正式调查形成的方向性分项，以及两组范围不同的内部结果；官方没有给出“公司整体AI编程支出下降70%”的基线、观察期或总账数字。
可以确认的内部结果有两项。其一，Databricks称Unity AI Gateway的Smart Router能够持续将平均任务成本降低超过30%，同时质量“大致匹配”工作模型集合中最昂贵的模型。其二，相对简单的harness与缓存设置调优，使生成token数量及相关成本降低接近50%，开发者侧“未观察到质量下降”。两句都带有限定语，适用范围也不同。
更大的汇总图则列出约60%+、30%、10%、10%四个方向性分项。文章明确说，这些数字来自对开发团队的非正式调查，只用于表示方向。它没有说明四项使用同一分母，没有证明效果互不重叠，也没有要求读者相加。低价模型、动态路由、支出控制和上下文优化都会影响token结构与模型选择，直接相加会重复计算。
对平台团队，这篇复盘的可复制部分不是一个百分比，而是测量框架：把每次请求归到用户、团队、任务和模型，记录输入输出token、缓存、时延与质量信号，再分别配置模型菜单、路由、预算绊线和上下文压缩。对采购与管理者，节省数字必须和任务成功率、返工、交付时长一起看，否则“更便宜的一次调用”可能只是把成本推迟到人工修复。
先审数字：六种表述不是一张总账
Databricks汇总图把成本手段分成四栏。OCR与页面原图可读到：更低成本模型约60%+，智能路由约30%，支出控制约10%，上下文优化约10%。紧邻图表的正文直接限定：这些数字是directional，依据开发团队informal survey。它们更像用于排优先级的经验区间，不是同一家公司同一时期的财务归因报告。
| 数字或表述 | 原文证据状态 | 准确适用范围 | 不能写成 |
|---|---|---|---|
| 低成本模型约60%+ | 非正式调查的方向性分项 | 更快采用开源或更高性价比模型 | Databricks整体支出实测下降60%以上 |
| 智能路由约30% | 非正式调查的方向性分项 | 按请求、任务或委派模式选择模型 | 所有任务固定节省30% |
| 支出控制约10% | 非正式调查的方向性分项 | 可见性、告警、审批和预算绊线 | 硬性断供预算必然节省10% |
| 上下文优化约10% | 非正式调查的方向性分项 | 压缩、裁剪工具输出、减少冗余与缓存调优 | 与内部接近50%结果是同一口径 |
| Smart Router超过30% | Databricks内部结果suggest | 平均任务成本；质量大致匹配集合中最昂贵模型 | 全公司总支出稳定下降30%，质量完全相同 |
| token及相关成本接近50% | Databricks内部调优结果 | 生成token数及相关成本；开发者侧未观察到质量下降 | AI编程总支出减半，质量已被证明不变 |
| 整体支出下降70% | HN用户提交标题 | 只能描述社区如何概括链接 | Databricks官方结论 |
这里至少有三处不可相加。第一，换用低成本模型与动态路由都会改变最终调用哪一个模型，路由节省可能已经包含模型价差。第二，上下文优化既能减少生成token，也会改变缓存命中和单次请求价格，和“低成本模型”不是独立变量。第三，预算绊线通过提示、审批或降档影响用户行为，也可能间接触发前述三种手段。没有同一基线下的因子实验，就无法算出四项组合后的净效果。
70%误读还暴露了新闻标题与原文归因的差别。HN item链接到Databricks文章，但提交标题由社区用户填写。它不是官方页面标题，也不是文章元数据中的摘要。把链接目标与提交者措辞混为一谈，会让“对多家公司经验的非正式调查”被改写成“Databricks自身总账已实现的财务结果”。
路由节省成立到哪一步
Databricks正文把路由分为三类。请求级路由在客户端与模型之间判断单次推理应由哪个模型完成；任务级路由由meta-harness识别任务复杂度，再把端到端任务交给某个harness或模型；委派模式则让便宜模型在遇到难题时升级，或让昂贵模型把简单工作外包给便宜模型。三者的计费、缓存和失败恢复结构不同。
Smart Router的原话值得保留所有状态动词：内部结果“suggest”它“is able to consistently reduce”平均任务成本超过30%，质量“roughly matching”工作集合中最昂贵模型。中文只能写成“内部结果表明”“能够持续降低”“质量大致匹配”。它不能升级为外部验证，也不能把“大致匹配”翻成“完全一致”或“没有质量损失”。
比较基准也不是某个永久固定的旗舰模型。原文说的是working set中最昂贵模型，意味着结果依赖当时允许选择的模型池、任务分布与价格。若企业把路由器接到不同模型、不同供应商折扣或不同缓存政策上，平均任务成本会改变。文章没有公开任务数、代码库类型、路由错误率、人工返工或质量评分方法，因此这组数字适合支持“路由值得试验”，不足以支持财务预算承诺。
同行材料说明了为什么评测设计很关键。Cursor在7月公开Router时，明确把缓存未命中的成本纳入路由结果，并用在线A/B测试、用户满意信号和代码保留率评估质量；OpenRouter文档则强调会话黏性，用固定模型与供应商尽量保留prompt cache命中。这些是直接相关的方法背景，却不能替Databricks补齐缺失数据。不同公司自报结果使用不同流量、基线与质量代理，不能横向拼成一个行业平均值。
Ramp公开称其Router把自身LLM成本降低30%，Databricks也把Ramp列为交流对象和路由案例之一。这个数字仍只属于Ramp的公开实践，不是对Smart Router的独立复现。它能证明“企业正在把模型选择工程化”这一趋势，不能证明Databricks的超过30%在别处必然成立。
缓存结果的分母在生成token
第二个最容易被放大的数字是接近50%。Databricks的完整表述是：对harness与缓存设置做相对简单的调优后，生成token数量及相关成本降低接近50%，开发者侧没有观察到质量下降。文章随后说仍在继续探索，并认为还有进一步优化空间。这是一个仍在推进的工程结果，不是对所有成本项完成审计后的终局结论。
为什么harness会制造大量可削减开销？代理式编程并非一次提示换一次回答。系统提示、仓库上下文、工具描述、文件读取、命令结果、错误日志和历史消息会反复进入上下文；模型还可能进行多轮规划、验证与重试。Databricks列出的做法包括压缩活动上下文、减少harness闲聊式开销、审计高频工具输出、降低冗长度，以及把大任务拆成范围更小的工作单元。
prompt caching在长上下文里能降低重复前缀的读取成本，但缓存写入本身也收费，保留多久、何时失效、是否切换模型都会改变收益。Databricks因此没有写“开启缓存即可减半”，而是强调按本公司工作负载手工调整默认缓存设置，提高命中率。若会话频繁换模型、上下文前缀不稳定，或者缓存生命周期短于任务间隔，同样配置可能得不到接近的节省。
“no observed quality degradation”也应忠实保留为“未观察到质量下降”。它描述的是开发者侧观察状态，没有公开独立盲评、错误率、返工率和长期缺陷数据。没有观察到差异，可能因为调优确实去掉了冗余，也可能因为样本或指标不足以发现较小变化。把它写成“证明质量没有任何下降”，会把观察结论提高为统计证明。
预算控制不等于月底断供
文章对硬预算的态度比汇总图更细。Databricks称，与之交流的公司通常只把达到阈值后完全切断使用作为最后手段。原因一是，开发者突然失去AI工具会直接影响生产力；原因二是，高支出用户中可能包含真正取得巨大效率增益的人，机械限额反而压制高回报使用。
更常见的路径是渐进式摩擦。先让用户接近实时地看到跨工具支出，再在费用上升时提示使用便宜模型、要求确认、增加审批，必要时才降档或停止。这个设计把成本控制从“一刀切配额”变成行为反馈与风险分层。汇总图里的约10%应在这个机制下理解，而不是一个硬限额开关的确定收益。
Unity AI Gateway文档提供了相应控制面：统一路由模型和MCP服务，按用户、团队或项目标记并归因支出，设置阈值与硬上限，应用QPM或TPM限流，记录请求、token和时延，并审计请求与响应。8月4日的正式可用公告还明确写出Smart Routing当时处于Beta。因此，文章中的内部路由结果不等于所有客户已经获得同样成熟度或默认配置。
Omnigent则把策略上移到meta-harness层。其官方公告举例称，可以动态跟踪每个会话的LLM成本，并在每花费一定金额后暂停、请求继续确认。这个层级还掌握代理操作、沙箱和会话状态，适合实施“某类高风险动作需要审批”或“超过阈值后换用其他模型”的组合政策。Gateway与meta-harness分别覆盖流量控制面和客户端任务编排，二者不是同一个产品按钮。
Databricks这篇文章最有价值的部分，是把AI编程成本从“采购了多少席位”改写为一组可观测、可干预的运行变量。模型价格决定单价，路由决定哪类任务付哪档单价，harness决定一次任务产生多少调用与token，缓存决定重复上下文如何计费，预算策略则决定用户何时收到反馈或被要求审批。只有把这些变量拆开，企业才知道成本增长来自采用率，还是来自每项任务的浪费。
但这套框架也最容易被一个合成百分比毁掉。把60%+、30%、10%、10%相加，或把超过30%与接近50%叠加，会制造一种“已有标准方案可直接兑现”的错觉。官方材料没有提供这种结论。当前更可靠的做法，是为每个控制杆设独立实验：固定任务集和模型池测路由，固定质量门测harness与缓存，固定用户群测预算反馈，再用端到端任务成本和返工验证组合效果。
早报判断是，AI编程平台的竞争指标会从“支持多少模型”继续转向“每个成功任务花多少钱，并能否解释为什么”。路由器若只报告token账单、不报告失败与返工，就可能把质量成本藏到开发者工时里；预算若只压高消费、不识别高产出，也会误伤收益最大的团队。可复用的治理资产应当是同一条任务从模型选择、缓存、执行到交付的可审计记录，厂商自报比例只能作为试验线索。
这一判断仍有边界。Databricks的主要证据来自官方产品与内部经验，同行案例也多是各公司自己的产品材料。它们共同说明实践方向，尚未构成独立、统一口径的行业基准。直到样本、观察期、质量指标和失败成本公开，企业应把这些百分比当作试验优先级，而不是预算书中的保证值。
建立一份可复核的成本实验账
落地时，第一步不是启用最复杂的路由器，而是统一任务单位。可以把“完成一个缺陷修复并通过测试”“合并一个可接受的提交”或“完成一次代码审查”作为分母，而不是只看每次请求。记录请求成本仍然必要，但最终需要聚合到成功任务成本，才能避免便宜模型反复失败却在单次调用上显得更省。
第二步是为质量设置多层信号。自动测试、静态检查、代码保留率、人工修改量、回滚与线上缺陷分别覆盖不同阶段；没有任何一个指标能单独代表质量。Smart Router所称“大致匹配”只有在这些测量方法公开后，才便于判断它匹配的是即时满意度、任务完成率，还是长期维护质量。
第三步是把缓存作为实验变量，而不是固定背景。需要记录cache write、cache read、未命中原因、会话内模型切换与上下文前缀变化。然后比较不同保留时间和压缩策略下的总任务成本。只统计输出token，会漏掉输入、缓存写入、工具调用、重试与平台费用，也无法解释为什么某个团队没有复现接近50%。
第四步是区分提示、软门槛与硬上限。可见性仪表盘是否改变模型选择，审批是否减少低价值调用，强制降档是否提高返工，都应该分别观察。高消费用户还需与产出和任务复杂度配对，避免把负责大型迁移、事故处理或高价值自动化的人简单标成异常。
最后才是组合部署。先在影子流量或受控团队中并行计算路由决策，再逐步扩大自动执行范围；对高风险任务保留回退到高能力模型的路径，并记录每次升级原因。组合效果要用“同一时间、相近任务、同一质量门”的净成本比较，而不是把不同来源、不同阶段的方向性分项相加。
接下来最值得等的不是另一个更大的节省标题，而是Databricks能否公开Smart Router的任务样本、模型池、质量代理和失败分布，以及harness与缓存结果在不同仓库规模、会话长度和缓存期限下的分解。若这些数据出现，企业才能从“借鉴控制杆”进入“复现可比结果”；在此之前，最稳妥的结论仍是：官方披露了两组有限范围的内部结果，没有披露整体AI编程支出下降70%。