01 触发事件

近日，网易有道发布企业级大模型聚合平台 ThinkFlow。按 36kr 的表述，这个平台通过标准 API 接口，让企业一次接入即可调用 DeepSeek、Kimi、Qwen、MiniMax 等 20 余款主流大模型，并提供智能路由、负载均衡、毫秒级故障切换、熔断降级，以及把调用成本精确到单次请求的全链路 Token 消费可视化看板。

这里最值得注意的，不是“20 余款模型”这几个字。

真正重要的是，它把 Token 的生产、分发、计费和效率优化，明确当成了一个企业级标准化问题。

这意味着，国内模型调用层开始从“接入更多模型”走向“管理更多 Token 流”。

我没在内部跑过 ThinkFlow，也不知道它的 routing policy 到底是静态规则、阈值触发，还是更复杂的实时评估。但仅从公开描述看，它已经不只是 API gateway，而是在往 AI 控制面走。

36kr 提到：ThinkFlow 允许企业一次接入即可调用 DeepSeek、Kimi、Qwen、MiniMax 等 20 余款主流大模型，业务端切换模型无需重写代码，并将调用成本精确到单次请求。

这句很短，但里面其实塞了三件事：标准接口、低切换成本、可计量成本。

02 这事的真正含义

这才是 ThinkFlow 在说的事：模型能力正在商品化，而 Token 调度能力正在产品化。

过去一年，很多“模型聚合平台”的叙事都停留在 access 层：帮你接更多模型，做统一鉴权，补一个 billing。问题是，这种层的 moat 很薄。谁都能封装一个 OpenAI-compatible API，谁都能做 provider adapter。真正难的是，企业为什么要把生产流量长期压在你这里。

答案不是“模型多”，而是“你能不能帮它把 Token 变成一个可运营对象”。

有三个结构变化在这里叠加。

第一，供给碎片化已经是常态，不是过渡态。

36kr 点名的 DeepSeek、Kimi、Qwen、MiniMax，本身就代表了能力、价格、延迟、上下文长度、稳定性的差异化供给。企业不会长期只押一个 provider。不是因为多云信仰，而是因为 AI inference 的单位经济学和可用性波动太大。今天某个模型便宜，明天可能价格调整；今天某家稳定，明天可能限流；今天某个任务 Sonnet-like model 胜出，明天可能被更便宜的 open-ish 供给替代。

第二，真正会被定价的不是“接了几个模型”，而是“切换模型的 operational friction”。

业务端切换模型无需重写代码，这句话看似基础，实际上在卖 switching cost 的反面：降低用户对上游模型的锁定，同时提高用户对中间层控制面的依赖。也就是说，ThinkFlow 如果成立，它吃到的不是模型 moat，而是 workflow moat。

第三，单次请求级别的 Token 可视化，比很多人以为的更关键。

AI 预算过去常被当成“云成本附属项”，但当企业开始把不同模型用于不同链路：检索、总结、分类、代码生成、客服、Agent orchestration，成本就不再只是总账问题，而是 unit economics 问题。你必须知道，哪一个 prompt 模板在烧钱，哪个 tenant 在异常放量，哪个功能的 gross margin 被长上下文吞掉，哪个模型 fallback 正在悄悄把 SLA 换成更高成本。

问题不在于企业缺不缺一个 dashboard，而在于没有这个 dashboard，它根本无法建立 AI 产品的财务纪律。

我可能高估了国内企业对“单请求级成本归因”的成熟度；很多团队也许还停留在先上线、后对账。但只要调用规模上来，这层能力会从 nice-to-have 变成 procurement 要求。

03 历史类比 / 结构对照

更像的历史参照，不是某个大模型发布，而是 2014 年前后的 AWS 使用治理工具兴起。

早期云计算的卖点是弹性和易用性。后来的真实问题却变成：资源太容易创建，结果成本失控、权限失控、架构失控。于是 CloudHealth、Datadog、Snowflake 周边一整套控制、观测、治理层长出来。不是因为算力不重要，而是因为当底层资源标准化之后，企业的瓶颈会转移到“怎么管”。

今天的 Token，正在重复这个过程。

最早大家关心的是“能不能调到 GPT-4 级能力”；后来变成“能不能多路接入 Claude、Gemini、DeepSeek、Qwen”；再往后，竞争焦点一定是“谁能把模型调用做成一个有预算边界、有 SLA、有 routing 策略、有 audit trail 的系统”。

这和 2007 年 iPhone 的类比也有一点像，但不在终端，而在控制权迁移。iPhone 重新定义了应用分发入口；AI gateway/控制面要重定义的，是模型供给入口。谁控制入口，谁就有机会控制默认路由、fallback 逻辑、缓存策略、账单视图，最终控制开发者的默认选择集。

这里的 aggregation theory 很直接：当上游模型供给越来越多、越来越替代性强，中间层如果能同时聚合需求、降低切换成本、提供跨供给优化，就可能获得比单一上游更强的议价位置。

当然，这个位置并不天然稳固。因为 hyperscaler、头部模型厂、甚至开源网关都可以往下做。我的判断是，真正的分界线不在“是否聚合”，而在“是否深入业务流量和组织流程”。只做流量转发，迟早被压价；做进预算、权限、审计、租户隔离、缓存、策略编排，才有机会留下来。

04 对 AI builder 意味着什么

如果我在做 AI 产品，或者在带一个已经有稳定 Token 消耗的团队，这周就会检查四件事。

第一，别再把多模型接入当成 feature，把它当成财务系统的一部分。

你需要的不是“支持 20 个模型”的官网文案，而是按任务拆分的 routing policy。哪些请求必须走高质量模型，哪些可以走便宜模型，哪些在 latency 超阈值时允许 fallback，哪些 tenant 有独立预算池。这些都应该是配置问题，不该是硬编码问题。

第二，开始要求单请求级别的成本归因。

至少把 model、input tokens、output tokens、latency、error rate、tenant、feature、prompt version 这些维度落日志。没有这些数据，所谓 prompt optimization 往往是错觉。很多团队讨论 prompt engineering 非常热闹，但连哪条链路最贵都说不清。

第三，评估你是不是应该把“模型层可替换性”前置设计。

36kr 提到 ThinkFlow 的价值之一是业务端切换模型无需重写代码。这其实是在提醒 builder：你的应用架构不该直接耦合某个 provider 的特殊接口。可以利用 provider-specific feature，但要把抽象层留在自己手里。否则今天省的开发时间，会在明天的迁移、议价和风控里加倍吐出来。

第四，重新看待 AI gateway 的采购逻辑。

过去很多团队会把这类平台当渠道，核心判断是“便不便宜”。我觉得这个标准太浅。更该问的是：有没有 prompt caching、batch API 编排、预算告警、跨模型路由、tenant 级配额、审计日志、失败回放、可观测性接口，以及和 MCP/Agent runtime 的兼容潜力。价格差异是表层，控制面能力才决定你未来能不能扩。

如果我是独立创业者，我甚至会反过来利用这类平台做套利：尽量延后对单一模型 provider 的深度绑定，把产品迭代周期和上游模型迭代周期解耦。这样你卖的是 outcome，不是某家模型的 resale。

我没看到 ThinkFlow 在 prompt caching、semantic routing、quality eval、policy engine 这些更深层能力上的公开细节，所以还不能把它判成完整的 AI control plane。但至少方向是对的：把 Token 当成企业资产来管，而不是当成 API 调用顺手记账。

05 反方观点 / 风险

最强的反方观点是：这类平台可能只是一个会被迅速同质化的网关壳。

原因有四个。

第一，标准 API 接入和模型切换，本质上进入门槛不高。OpenAI-compatible 已经成了事实标准，企业自建一层 adapter 并不难。若没有显著的性能优化、缓存命中、失败率控制或采购折扣，中间层很容易被视为“多一跳”。

第二，头部云厂商和模型厂自己就能做这件事。阿里云、火山引擎、腾讯云，甚至更上游的模型实验室，都有能力把多模型调用、监控、计费、路由打包进自己的平台。如果企业本来就在这些 cloud 上，额外再采购一层外部控制面，决策阻力不会小。

第三，企业未必真的需要“20 余款模型”。很多实际业务最后只稳定在 2 到 4 个主力模型上：一个高质量、一个低成本、一个 embedding、一个备用。模型选择看起来复杂，但真正复杂的是工作流本身。如果中间层不能深入 workflow orchestration，只停留在 provider routing，它的价值会被高估。

第四，可视化不等于优化。把成本精确到单次请求当然重要，但可视化只是开始。真正难的是，你能不能基于这些数据自动做推荐、做约束、做闭环执行。否则 dashboard 最终会变成“知道问题存在，但团队没有动作”。

所以，我可能错在把 ThinkFlow 读得太超前了。它也许只是网易有道面对企业采购需求做出的标准化封装，而不是一个足以重塑国内 AI access layer 格局的拐点产品。

但即便如此，这条产品路径仍然值得重视。因为它暴露的不是网易有道的野心大小，而是整个市场需求的迁移：企业不再只问“有没有模型可用”，而是在问“我的 Token 流，谁来管”。

而一旦问题变成这个，战场就从模型能力转到了控制面能力。这个迁移，通常比单次模型发布更值得盯。