
华为前大模型负责人王云鹤最近创业的基元律动瞄准了这个方向。
而在国外,这个赛道的代表产品 OpenRouter,Stripe 报价 100 亿美元打算收购。两个月前,OpenRouter 刚以 13 亿美元的估值完成 B 轮融资。领投方是 Alphabet 旗下的 CapitalG,跟投方里有英伟达 NVentures。短短两个月,报价涨了近 8 倍。
差不多同一时间,Cursor 发布了 Cursor Router,用超过 60 万条真实编程请求训练出一个路由器,自动决定每个任务交给哪个模型。日本 AI 研发初创公司 Sakana AI 推出 Fugu 模型,直接把多 Agent 编排系统打包成一个模型来卖。
模型市场、编程应用产品和研究实验室,原本是三种不同的生意,但近一个多月来的动作,都指向了同一个方向:模型与用户之间的编排层。比起「谁拥有最强模型」,或许下一阶段更值得争夺的,是「谁来决定每个任务使用什么模型、工具和 Agent」。
模型编排并不是一个新词。它为什么在当下被集中关注?模型厂商、基础设施公司和应用公司,谁更有机会控制这一层?创业公司如果想进入,需要掌握的关键要素是什么?
⬆️关注 Founder Park,最及时最干货的创业分享
我们将通过「AI 产品市集」、内容报道、社群分发等方式,帮你触达早期用户、获得真实反馈,以及建立关键连接。
如果你正在做 AI 相关的事,欢迎和我们聊聊。
01
Stripe 的 100 亿美元报价,
买的是模型供需之间的连接层
按照《华尔街日报》的说法,谈判仍在进行,交易可能告吹,也可能引来其他买家。但报价本身已经足够说明问题,这 100 亿美元买的显然不只是某种模型路由算法。
OpenRouter 的商业模式并不复杂,收入主要来自充值环节的信用卡手续费 5.5% 和 BYOK(自带 API key)的管理费,并不依赖推理服务本身赚钱。但它所处的位置很特别。截至 2026 年 6 月,OpenRouter 接入了 400 多个模型、70 多家供应商,拥有 800 万用户。每周处理的 token 从一年前的约 5 万亿增长到 29.2 万亿。
站在这一层,OpenRouter 能看到单一模型厂商看不到的东西。比如哪个模型在哪类任务中被使用,开发者愿意为速度还是质量付钱,哪些模型正在被替换,以及价格、性能和场景如何共同改变流量流向。
从 OpenRouter 的流量数据中,可以看到一些有意思的变化。过去一年,中国模型的 token 份额从 4.5% 提升至 46%,今年 2 月一度冲高至 61%。其中,DeepSeek 独占 17.6% 的 token 份额,成为平台最大的单一模型供应商。

与此同时,美国模型的 token 份额从 70% 下滑至 30%。不过,Anthropic 用 12% 的 token 份额,拿走了平台约 50% 的收入。这意味着,token 的份额和收入份额并不总是一致,「调用最多」和「最能赚钱」可能是两回事。
这张实时变化的模型需求地图,或许就是 Stripe 最看重的资产。过去一年,这家估值 1590 亿美元的支付公司一直在为「Agent 经济」铺路。
此前,Stripe 收购了用量计费平台 Metronome。Metronome 在做的事,是实时记录每一次 API 调用消耗的 token,完成计量、聚合和生成账单。OpenAI、Anthropic、Databricks 等行业最大的几家 token 卖家,都是它的客户。
如果再将 OpenRouter 纳入体系,Stripe 就能把模型选择、流量分发、用量计量和支付结算串联成一条完整链路。从开发者发起一次模型调用,到 token 被计量,再到最终完成收费,几乎都可以发生在 Stripe 的生态之内。这样一来,它覆盖的就不只是 AI 支付基础设施,也会进一步深入到 AI 服务交易的核心环节。
OpenRouter CEO Alex Atallah 在近期采访中并没有把自己定义为路由公司。他反复强调的核心价值是「unplanned inference capacity」,帮企业兜住没有预料到的推理需求。他的判断是,整个市场在持续低估自己的推理消耗量。当一家公司突然需要试计划外的模型,或某个模型的调用量远超预算,OpenRouter 负责确保这不会变成基础设施事故。如果 Stripe 已经通过 Metronome 掌握了 token 的计量和账单,再加上一层推理需求的弹性缓冲,它拿到的就不只是流量分发枢纽,而是 AI 推理消费的完整闭环。
所以,这 100 亿美元想买的,实则是模型访问、流量分发和交易结算三者交汇的关键入口。某种意义上,资本已经开始为连接模型供给与需求的中间层单独定价。
02
模型供给过剩后,
选择模型成了一笔经济账
模型编排并非新概念。路由、降级和故障切换本来就是工程系统的常规能力。变化在于,过去「选模型」并不困难,现在却成了一项经济问题。
最直接的变化,是模型供给从稀缺转向过剩。据 OpenRouter 的数据,仅 2026 年 7 月,平台就上线了 70 个新模型,大约每 10 小时一个。企业面对的选择早已不止 GPT、Claude 和 Gemini,闭源模型、开放权重模型、行业模型、小模型、推理模型、多模态模型不断增加。同一类任务下,不同模型之间经常存在明显的价格、速度、上下文长度和能力差异,没有一个指标能代表全部表现。
另一个事实是,最强的模型并不等同于每次调用的最佳模型。复杂的代码重构可能需要前沿模型,简单的分类、格式转换和信息提取交给便宜模型就够了。所有请求都调用最贵的模型,成本会快速失控。过度追求低价,任务失败、重试和人工修正又会制造隐藏成本。
Agent 又把这个问题放大了一层。在 Agent 产品里,一个用户请求可能被拆成搜索、规划、写代码、调用工具、验证结果和总结输出等多个步骤,每一步需要的能力都不同。编排的对象也从为一个 Prompt 选一个模型,变成为一条任务链分配模型、工具、算力和权限。
推理市场本身还在快速膨胀,这让编排的经济意义进一步放大。OpenRouter 上一组近期数据可以说明这个趋势:GPT-5.6 Luna 在平台上降价 10 倍之后,用量增长了 13 倍,而且增长是稳定的,不是短期脉冲。这次降价恰好发生在 DeepSeek 和 GLM 同时以低价抢量的时段,Luna 反而反超了 GLM 的 token 量,成为 OpenAI 很长时间以来第一次跻身平台前五的模型。降价没有只是重新分配存量,而是把整个池子撑大了。当推理总量以这种速度增长的时候,每一次模型选择所牵动的成本差异也在同比放大。
成本的经济账则将这件事推到台前。当调用规模上来之后,模型账单不再是研发预算里的小项,能够直接决定毛利。Router 的商业价值也必须用更接近业务的指标来衡量:单次成功任务的成本、单个有效代码提交的成本、人工接管率、首次完成率,以及用户是否还需要重做一遍。
当 AI 产品开始规模化,编排就不单是省几分钱的工程优化,更直接影响单位经济性。对大多数使用者来说,决定「哪一步该用多贵的能力」,已经成为成本控制的关键。
03
别把所有 Router 混为一谈,
模型编排至少有四层
「模型编排」这个概念,如今已经被装进了太多产品。要判断其中真正的机会,首先要分清它们到底在调度什么。
第一层是供应商路由。 同一个模型可能由多家推理供应商提供,系统会根据价格、吞吐量、延迟、可用性和数据政策等因素,在不同供应商之间分配请求。OpenRouter 的 Provider Routing 属于这一层,解决的问题是,同一个模型从哪买更划算、更稳定。
第二层是模型路由。系统根据任务难度和类型,在不同模型之间选择。比如把简单请求交给小模型,把复杂请求升级到前沿模型。Cursor Router、Microsoft Foundry Model Router、Amazon Bedrock Intelligent Prompt Routing 都在这一层。
第三层是 Agent 与工作流编排。这里需要决定的不只是用哪个模型,还要拆解任务、安排 Agent 分工、调用工具、决定执行顺序、处理失败重试。Sakana Fugu 更接近这一方向。
第四层是企业控制与治理。统一管理模型权限、预算、审计、日志、评测、安全策略、隐私和故障切换。这已经更像是 AI 时代的 Control Plane,路由只是其中一项能力。
四层之间会互相覆盖。只做模型路由的公司,很容易被做治理的平台顺手覆盖掉。从治理层切进来的公司,未必能在 Agent 编排上做出差异化。真正值得关注的是,谁能在关键一层掌握数据、工作流或客户关系,并把它延展成不易替换的控制权。
04
掌握结果数据的应用公司,
更有机会赢得编排层
争夺模型编排层的玩家,大致可以分成三类,各自的优势和短板都很鲜明。
第一类是模型厂商和云平台,它们希望把路由能力留在自己的生态里。AWS、Microsoft、Google 都已将路由作为企业 AI 产品的一部分。OpenAI 也将 Fast 与 Thinking 的选择内化进产品。云平台拥有企业客户、算力、统一账户体系和合规能力,可以把模型路由与采购、权限、SLA 和数据区域打包销售。对企业来说,这种方案的部署摩擦更小。
但它们也存在天然局限。云平台能看到 Prompt 和模型响应,却很难完整看到业务结果。一段 AI 生成的代码是否真正进入代码仓库,一份合同是否被律师采纳,一个客服回复是否最终解决了用户问题,这些决定模型价值的信号,大多留在具体应用之中。
第二类是独立 Router 和 AI Gateway,包括 OpenRouter、Martian、Not Diamond,以及一批开源网关项目。它们主打中立、多供应商接入、统一 API 和成本管理。客户选择它们,很大程度上是为了不被任何一家模型厂商锁死。
不过,这一层的功能门槛并不高,很容易被云厂商或开源方案复制。如果缺乏独有的决策数据、路由效果,或足够强的交易网络,独立平台最终很容易退化成一条可替换的数据管道。
第三类是应用公司,Cursor 是其中最典型的代表。它从「写代码」这个完整任务切入,能够拿到前两类玩家都拿不到的数据:完整的任务上下文、用户主动切换模型的行为、生成内容是否被接受、任务是否真正完成、结果是否进入生产系统、哪种错误造成了业务损失。Cursor 甚至专门提出了「keep rate」这个指标,用来衡量 AI 生成的代码在一段时间后还有多少留在代码库里。
除了结果数据,应用层还在积累另一种资产:用户记忆。Atallah 在采访中提到一个尚无定论的问题,记忆应该归谁管?模型、推理供应商、应用、路由器,每一层都会试图拥有它。放在应用层的记忆上下文最丰富且与模型无关,放在模型层的记忆个性化表现可能最好。但他的判断是,没有一层能独占所有有价值的记忆,因为应用积累的上下文是模型厂商根本拿不到的。跨模型、跨会话的用户记忆一旦沉淀在某一层,就会变成实质性的切换成本,效果跟结果数据类似。
这也是应用层最有机会掌握模型编排权的原因,它们能够看到任务最终是否成功。只有能持续观察任务结果,将结果反馈到模型选择和评测中的平台,才能建立真正与业务价值挂钩的编排能力。
05
不是所有模型编排生意,
都能跑出数据飞轮
理想状态下,应用公司在模型编排上能跑出一个高价值的数据飞轮。
更多用户和任务,带来更多真实任务类型、失败案例和反馈。这些反馈不断沉淀,形成更精细的任务分类和模型能力地图。Router 判断越来越准确,成功率提高、单任务成本下降。产品体验和单位经济性改善后,进一步吸引更多用户。
Cursor Router 已经体现出这种循环,用真实请求训练分类器,再通过在线 A/B 测试和满意度指标评估效果。
但容易被忽略的是,这个飞轮并不会自动转起来,它成立的条件其实相当苛刻。
首先,反馈必须接近真实结果。用户点赞、停留时间、重新生成等信号都存在较大噪声。一段代码被接受,可能只是因为修改成本太高,不是模型真的完成得更好。真正有价值的反馈通常更接近业务终点,例如代码通过测试、合同被律师采用、客服工单顺利关闭、研究结论得到验证。
不同模型之间还必须存在足够明显的能力差异。如果模型能力和价格逐渐趋同,路由能够创造的价值也会下降。任务需要有一定重复性,高度定制、极低频的任务,很难积累足够的数据来训练稳定可靠的路由策略。
企业数据隔离同样会削弱这种飞轮。一个 Router 在大型银行内部学到的策略,未必可以合法迁移到另一家客户。企业数据隔离、隐私政策和合规要求,都可能切断跨客户学习的路径。应用公司需要把通用能力、客户私有策略和数据边界拆开设计。
2024 年前后,市场上曾涌现一批「语义路由」公司,试图解决同一个问题。他们先让一个小模型读每条 Prompt、做语义分析,再决定把它交给哪个大模型。但几年过去,这条路线上的不少公司已经转型或收缩。
问题在于,语义路由试图仅凭单条 Prompt 做决策,而一条 Prompt 能提供的信号往往过于有限,噪声却很高。即使判断错了,也很少有明确反馈告诉系统哪里出了问题。同时,路由器额外增加的延迟和推理成本却是真实存在的。更关键的是,它通常看不到任务最终是否完成。离线 Benchmark 上的节省,不等于生产环境中真实的质量、重试和人工成本。
OpenRouter 的留存数据提供了另一个佐证。即使平台把模型切换成本做到了接近零,仍有相当一部分开发者在更优选项出现后拒绝切换。据 Atallah 在采访中的说法,原因大致有三:围绕旧模型已经做了大量提示词优化和安全边界设定,换模型意味着重做这些工作;现有模型的价格曲线随时间下降,而新模型定价通常更高再逐步回落,切换在经济上未必划算;开发者对输出建立了自己的「个人 eval」,新模型通不过这些私人测试就不会被采用。沉没的优化成本、价格曲线错位、私人评测标准,这些都是单条 Prompt 的语义分析读不到的信号。
这也解释了为什么许多看似聪明的「自动选模型」方案,并不会自然变成一门好生意。它们能否成立,最终取决于能不能拿到可靠的任务反馈,并把这些反馈转化为持续有效的路由决策。
06
Cursor 和 Fugu 的警示:
编排的隐形成本,很可能抵消收益
OpenRouter 之外,Cursor 和 Sakana AI 的 Fugu 也提供了两种具有代表性的模型编排样本。
7 月 22 日,Cursor 发布 Cursor Router。据官方博客介绍,这套路由器基于超过 60 万条真实编程请求进行训练,并在数百万次生产环境请求中做了在线 A/B 测试。系统会先判断每个请求的难度,再在前沿模型和价格更低的模型之间选择。
按照 Cursor 公布的数据,在线 A/B 测试中,路由后的输出质量接近前沿模型,成本降低约 60%。早期接入的三家大客户,合计数千名开发者,在两周内节省了 30% 到 50%。按「每次有效提交的成本」计算,Balance 模式为 4.63 美元,而全量调用 Opus 4.8 需要 7.34 美元。

一个细节尤其说明应用层视角的价值,Cursor 的 cache-aware 设计。切换模型会让已有的 Prompt 缓存失效,表面上换成更便宜的模型节省了调用费用,实际上却可能因为缓存重建增加额外成本。Cursor 把这笔成本也纳入了训练与评估,所以优化的不是单次调用价格,而是完成一次有效工作的总成本。
6 月下旬,Sakana AI 正式发布 Fugu,验证的是另一条更激进的路线。编排不再依赖人工规则,编排器本身也可以是一个被训练出来的模型。Sakana 用一个 7B 参数的 Conductor,根据任务难度弹性调配 1 到 3 个 agent,背后调用的是 Opus 4.8、GPT-5.5、Gemini 3.1 Pro 这些前沿模型。这样一套多 Agent 编排系统被包装成一个模型 API,用户发出一个请求,系统在后台动态选择模型、分配角色、组织协作和验证结果。
从评测表现来看,Fugu Ultra 在 SWE-Bench Pro 上达到 73.7%,高于其对比中的 Opus 4.8 单模型成绩。

但不要把编排带来的收益想得太轻松。独立评测者 Sean Kim 对 Fugu 做的 token 审计显示,大约 60% 的计费 token 都消耗在用户看不见的内部协调过程。一个简单问题,单模型 2 秒即可完成,Fugu 却用了 108 秒,耗时增加了 54 倍。在 38 个知识类任务的对比测试中,Fugu 的成本是直接调用 Opus 的 5 倍,结果却是 36 场打平、Opus 赢下 2 场,Fugu 一场未胜。
Sean Kim 的评价很尖锐:你放弃的是一个行为可预期、成本透明的具名模型,换来的却是一个行为难以理解、由系统替你决定花多少钱的黑箱协调器。
Fugu 验证的是,编排策略可以像模型能力一样,用强化学习和任务数据训练出来,但同时也引出了所有编排产品必须回答的经济学难题。编排本身会产生额外开销,这些开销很可能抵消编排带来的收益。更关键的是,两者往往来自同一套机制,很难只保留收益、消除成本。
多模型编排的价值,最终体现在完成一次真实任务的总成本更低,而非单纯节省模型调用成本。否则,它只是把用户看得见的模型费用,转移到了看不见的协调层。
07
To C 省去用户选择,
To B 让企业掌控决策
同一层模型编排技术,在消费端和企业端会长成两门不同的生意。
To C 的目标,是让模型选择尽量退出用户的注意力。大多数用户并不关心哪个模型代码能力更强、哪个价格更低、哪个更适合长上下文。他们只想把任务说清楚,然后拿到结果。因此,最自然的产品形态是 Auto,由产品自己选择模型、重试、切换和降级。用户最终只关心任务有没有完成,以及订阅价格是否合理。
但 Auto 最大的挑战是信任。一旦用户怀疑产品为了降低成本,偷偷切换到更便宜的模型,或者无法理解为什么同一个任务今天和昨天表现不同,路由器就会从体验优化器变成黑箱。成熟的消费级编排,需要尽可能减少用户决策,同时保留必要的透明度和控制权。
To B 恰好相反。企业不仅要结果,还要知道为什么选了这个模型、数据流向了哪里、一次任务花了多少钱、路由策略是否发生变化、出错时由谁负责、能否回放和审计、能否给不同部门设预算。因此,企业级编排最终更像云成本管理、API Gateway、身份权限和可观测性平台的结合体。
企业真正付费买的不是「最佳路由」,是可控性、可验证性和组织级治理能力。一个能省 40% 却说不清缘由的系统,往往过不了采购和合规。相反,一个节省幅度较小,但每次决策都可审计、可回放、可归因的系统,反而更容易签下来。
Atallah 在采访中提到一个反直觉的观察:他接触的企业客户对前沿闭源模型的紧张程度,其实高于对中国开源模型。原因不是安全威胁,而是数据政策的不透明。prompt 存在哪里,谁在看,能不能在自选基础设施上运行,这些问题对闭源模型更难回答。这种焦虑给独立编排层打开了一个意外的切入点。OpenRouter 已经提供了 PII 脱敏、prompt 注入检测等安全功能,企业打开开关就能在所有模型上统一执行数据治理策略。直接对接任何一家模型厂商做不到这件事,因为安全策略只覆盖那一家的模型。
做 To B 编排,产品能力的重心可能有一半以上不在路由算法上。这或许跟大多数技术出身团队的直觉相反。
08
模型编排还有创业机会,
真正的价值在工作流里
模型编排的牌桌已经挤入了很多玩家,但机会并未消失,只是不能再停留在「模型聚合」这一层。
第一类机会是垂直行业 Router。法律、金融、科研、医疗、客服、安全,每个领域都有自己的任务分类体系、评测基准、风险规则和合规要求。通用 Router 读不懂行业的任务标准,一份并购协议的条款审查和一封客服邮件的语气润色,在通用 Router 眼里可能是差不多的「文本生成任务」。行业 Router 的竞争力来自任务知识和结果数据,接入多少模型反而是次要的。
第二类是企业 AI Gateway。为企业提供统一的模型入口,管理多模型接入、多云和本地模型、权限、预算、日志、数据策略和故障切换。这个方向需求明确,但会直面云厂商、开源项目和传统 API 管理平台的竞争。
第三类是 Router 评测、可观测性相关情报。企业很难知道 Router 是否真的有效,独立评测平台可以帮客户回答:路由比固定模型省了多少钱,质量有没有下降,哪类任务最容易被错误路由,模型升级后策略是否失效。编排普及之后,这一环节可能成为整个体系的「监控层」。
第四类是 Agent 任务调度系统。当 Agent 开始处理长任务,模型选择只是其中一步。分工、工具权限、任务状态、并行与串行、失败重试、人工接管和预算上限,都需要被系统化管理。这个方向的产品形态更接近 Agent Runtime,甚至 Agent 的操作系统。
还有一个变化正在发生:应用公司从编排向模型开发延伸。Cognition 已经有了自己的模型,Cursor 也有。据 Atallah 在采访中的判断,做 Agent 的公司有明确动机训自己的模型,这个趋势才刚开始。如果应用公司掌握了结果数据,又开始用这些数据训练专属模型,编排层的竞争就不只是「谁来选模型」,还包括谁能用编排积累的数据去改进甚至替换外部模型。这条路走下去,编排层和模型层的边界会越来越模糊。
无论从哪一层进入,判断一个编排方向值不值得做,都可以追问几个问题:是否拥有真实任务数据?能否观察最终任务结果?路由收益能否用成功率、成本和稳定性量化?策略能否跟上模型迭代?产品是否已经嵌入客户核心工作流?数据飞轮在隐私与合规边界内是否真的转得起来?
接入更多模型,最多做出一个初始产品。真正的壁垒,是进入高价值任务场景,看见任务如何完成,再通过持续实验长出一套别人难以复制的模型选择与 Agent 调度系统。


DeepSeek V4 Flash 可以交付结果了,Agent 开始拼 Harness 了
MiniMax 怎么做 Agent:Model-Harness 协同只是第一步,还有 Inference-Harness 协同
Manus 重新独立:这七个月一直没停下,但通用 Agent 的牌桌已经挤满了玩家
3 天上了两个 SOTA 模型,视频 Agent 们接得过来吗?
内容中包含的图片若涉及版权问题,请及时与我们联系删除



评论
沙发等你来抢