【导语】
上篇回顾：AISN 框架与四层演进路径。运营商目前所处的困境就是AI 系统开发能力不足。如何平衡重资产投入与系统开发投入？本文是"从 OpenRouter 到运营商 AI 服务网络"系列推文之三（终章）。
Token 经营的本质：从资源计量到 AI 价值经营
Token 究竟是什么
Token 究竟是新的计费单位、AI 能力的计量单位，还是未来 AI 任务价值结算的中间单位。在 AISN 战略中，Token 被视为智能服务的统一计量单位，其意义远超技术层面的 Token 计算。Token 经营的提出，标志着运营商计量体系从传输量向智能处理量的根本性转变。若将 Token 简单类比为 AI 时代的流量，则运营商确实难以摆脱管道角色，因为这意味着仍然以传输逻辑理解智能服务。然而，Token 的本质并非网络数据传输量，而是模型处理、生成和计量过程中的基本资源单位。它可以作为 AI 模型调用的重要计量与结算基础，但不能直接等同于 AI 服务的商业价值。相同数量的 Token，在不同模型、不同任务和不同业务场景下可能产生完全不同的价值。因此，Token 更准确的定位是 AI 服务的资源计量单位和商业计价基础，而不是最终的价值单位。随着 AI 服务从模型调用向 Agent 和任务执行演进，Token 可能逐渐成为后台资源结算单位，而用户前台购买的则是 AI 能力、任务执行和最终结果。因此，Token 经营不是流量经营的延伸，而是智能经营的起点。
竞争不是谁的 Token 套餐便宜
如果只是九块九买一千万 Token，运营商很容易陷入 Token 价格竞争。随着模型效率提升、推理成本下降和模型供给增加，单位 Token 的市场价格可能持续下降。因此，如果运营商仅以 Token 数量和价格作为竞争核心，容易陷入同质化的价格竞争。更重要的竞争方向应是扩大 AI 任务需求，并提高单位 Token 所支撑的业务价值。真正应该竞争的是谁能创造更多 Token 需求，以及谁能让单位 Token 产生更高的业务价值。
Token 是不是终极经营单位
初级阶段可能表现为"用户—Token—计费"，但随着 AI 服务向 Agent 和任务执行演进，经营关系可能逐步转向"用户—Agent—任务—结果—价值"。在这一过程中，Token 并不会消失，而更可能退居后台，承担模型调用、算力消耗和服务结算的统一计量功能。用户真正购买的则可能从 Token 数量逐渐转向客服任务、代码开发、合同审核、数据分析等具体 AI 服务。因此，Token 更可能成为 AI 服务体系的后台统一计量与结算层，而不是长期面向用户的最终商品；真正的前台经营对象将随着 AI 服务成熟度提高，从 Token 逐步转向 AI 能力、AI 任务和业务结果。如果运营商长期以Token作为业务的计费单位，那恐怕还逃不脱”管道“的命运。
关键制约：AI 系统开发能力的短板与平衡策略
运营商的能力结构失衡
运营商现有的能力结构呈现明显的偏科特征。在强项方面，运营商拥有算力基础设施、网络基础设施、用户接入、云和企业级计费结算体系等重资产及基础运营能力；在相对薄弱的方面，则主要表现为 AI 业务系统开发、互联网产品设计、开发者生态运营、模型与 Provider 生态 BD、AI 应用孵化和快速产品迭代能力。OpenRouter 的强项在于 AI 系统开发、开发者生态运营、互联网产品迭代和模型生态组织能力；其相对弱项则在于不拥有运营商意义上的大规模自建算力基础设施、全国性通信网络以及移动、固网和政企渠道体系。
AI 系统开发能力的战略价值
AI 业务系统与生态能力不是锦上添花，而是将运营商重资产转化为业务价值的关键能力。没有统一 API、智能路由、计量计费、开发者平台和运行数据闭环，算力难以形成规模化调用；没有开发者生态和 AI 应用生态，用户接入资源难以转化为持续 AI 需求；没有任务编排和服务质量保障，模型、算力和网络资源也难以进一步形成面向任务结果的产品。因此，运营商真正需要补齐的不是单一的软件开发能力，而是将基础设施、AI 资源和用户需求连接起来的业务系统与生态运营能力。
核心矛盾：重资产投入与系统开发投入的资源平衡难题
运营商面临的核心问题并非重资产投入与系统开发投入之间简单的零和博弈，而是如何在资本投入、研发投入和业务收益尚未完全确定的情况下优化能力建设节奏。过度倾向重资产，可能导致算力供给增长快于 AI 需求增长；过度强调软件能力，又可能削弱运营商已有基础设施的差异化优势。因此，真正需要解决的是资本性基础设施建设与业务能力建设之间的动态平衡，以及两者如何形成协同效应。
基于上述分析，本文提出以下可能的能力建设路径。需要说明的是，这些路径属于战略推演和建议，而非对运营商实际组织和投资决策的事实判断。
四项平衡策略
平衡策略一：分阶段投入，推动重资产与系统能力协同演进
运营商不宜试图在短期内同时完成大规模基础设施建设和完整的 AI 系统能力建设，而应根据 AI 需求增长、模型成本变化、算力利用率和业务成熟度，分阶段推进两类能力建设。这里的"分阶段"并不意味着重资产投入逐步退出、软件能力取而代之，而是指随着业务成熟度提高，投入重点由单纯扩大资源规模逐步转向资源效率提升、系统能力增强以及二者的协同优化。
第一阶段为能力验证期（1-2 年） 。核心目标是验证 Token 经营和模型聚合模式。重资产投入重点是 AIDC、智算中心和算力网络建设。系统能力建设重点不追求全面铺开，而是优先建设统一 API 入口、模型接入、基础计量计费、Token 结算和运行监控等最小可行能力，打通"模型—算力—调用—计量—结算"的基本闭环。该阶段的核心目标不是形成完整的 AI 服务生态，而是验证 Token 经营和模型聚合模式，形成可持续的 AI 服务调用需求，并观察算力供给与实际需求之间的匹配关系。
第二阶段为协同发展期（2-4 年） 。核心目标是提升算力、网络与 AI 系统的协同效率。随着 AI 服务调用规模扩大，运营商应继续完善算力网络和异构算力资源，同时明显加强智能路由、开发者平台、模型与 Provider 生态、运行数据分析以及 AI 应用孵化等系统能力建设。在这一阶段，竞争重点逐步从"拥有多少算力"转向"如何更有效地组织和使用算力"，通过模型路由、算力调度和网络感知等机制提高资源利用率、服务稳定性和单位 Token 的业务价值，逐步形成"重资产基础设施 + AI 系统能力"的组合竞争力。
第三阶段为价值经营期（4 年以上） 。核心目标是从资源规模扩张转向资源效率和任务服务能力提升。当 AI 服务形成较大规模的稳定需求后，算力基础设施仍然是运营商的重要战略资产，但投入重点可以逐步从单纯规模扩张转向异构算力优化、资源利用率提升、节点布局优化和网络协同。同时，更多系统能力应向 AI 任务编排、Agent 协同、行业知识服务、服务质量保障和结果评价体系延伸，使运营商能够从提供模型和算力资源进一步转向提供 AI 能力、AI 任务乃至业务结果。
因此，三个阶段并不是简单的"重资产优先、软件优先、重资产退出"的线性过程，而是重资产能力持续存在、系统能力持续增强、二者协同程度不断提高的演进过程。其基本变化可以概括为：第一阶段解决"有没有 AI 服务能力"的问题；第二阶段解决"能不能高效组织 AI 资源"的问题；第三阶段解决"能不能围绕用户任务和业务结果创造更高价值"的问题。
上述阶段划分属于本文提出的战略分析框架，而非对运营商实际投资节奏的预测。实际推进速度取决于 AI 需求增长、模型推理成本下降速度、算力利用率、市场竞争格局、监管环境以及运营商自身资本和研发投入能力。
平衡策略二：借力外部生态，避免全部自建
建议运营商不要试图全部自建 AI 系统开发能力，而应该借力外部生态。与互联网公司合作，引入互联网公司的 AI 系统开发能力，运营商提供算力、网络、用户接入，互联网公司负责系统开发、开发者生态、应用运营，通过调用量、服务收入或项目收益等方式建立利益共享机制。与 OpenRouter 及类似 AI Gateway、模型路由平台开展合作，借鉴其模型聚合、智能路由、开发者服务和运营机制，结合运营商本地算力、网络及政企渠道，快速验证相关业务模式。更好的方式是投资或收购具有 AI 系统开发能力的创业公司，快速获得技术团队和产品能力，避免从零开始自建的高成本和时间成本。这种AI系统开发的核心能力运营商必须自己掌握。开源加自研结合，核心系统如智能路由、计量计费自研，非核心系统如 API 网关、监控系统采用开源方案，降低系统开发成本和时间。
平衡策略三：组织变革，建立互联网化的研发体系
运营商的传统研发体系不适合 AI 系统开发，需要进行组织变革。建议建立独立的 AI 产品研发部门/子公司，独立于传统网络与 IT 部门，采用互联网公司的研发模式，包括敏捷开发、快速迭代，独立的预算和考核机制。引入互联网人才，从互联网公司引进 AI 产品、系统开发、开发者运营人才，提供有竞争力的薪酬和激励机制，建立技术与业务的复合型团队。建立试错文化，允许快速试错、快速失败、快速迭代，不追求一次性完美，而是小步快跑，建立数据驱动的产品优化机制。需要指出的是，运营商作为央企在组织变革中面临的体制性障碍，如薪酬体系、考核机制、决策流程等与互联网公司的根本差异，本研究未充分讨论，这是局限之一。
平衡策略四：聚焦核心场景，避免全面开花
运营商不应该试图在所有 AI 场景上都自建系统开发能力，而应该聚焦核心场景。聚焦政企市场，政企客户是运营商的传统优势市场，政务、医疗、工业、金融等行业具有较强的数字化基础和专业 AI 需求，在满足合规、安全和 ROI 要求的情况下具有较明确的商业化空间，集中资源打造政企 AI 服务能力，避免与互联网公司在 C 端市场正面竞争。聚焦网络加算力协同场景，发挥运营商网络加算力的独特优势，开发网络感知型 AI 服务，如低时延推理、边缘 AI，避免与互联网公司在纯软件领域竞争。聚焦任务结果而非技术实现，从用户视角设计产品，聚焦任务结果，如合同审核、代码生成、数据分析等具体场景，避免陷入技术自嗨，开发用户不关心的功能。
研究局限与后续方向
研究局限
本研究在以下维度存在局限。第一，缺乏对转型财务可行性的量化分析。文章提出了分阶段投入策略，但没有估算各阶段的投入规模、预期回报和投资回收期。运营商高层决策需要财务数据支撑，这一缺失降低了建议的可操作性。第二，未充分讨论监管合规和组织变革的体制性障碍。运营商作为央企，在 AI 服务中面临数据安全、模型合规、内容审核等监管要求，这些既是约束也可能是差异化优势。同时，运营商在组织变革中面临的薪酬体系、考核机制、决策流程等体制性障碍，本研究着墨甚少。第三，对 Stripe 收购 OpenRouter 后竞争格局的变化评估不足。Stripe 收购 OpenRouter 后，OpenRouter 获得了全球最大的支付基础设施能力，其 Token 计量与结算能力将大幅增强，这可能对运营商的 Token 经营构成直接竞争，本研究未对此展开分析。第四，缺少对市场时间窗口的判断。文章提出了分阶段演进路径，但没有评估市场留给运营商的时间窗口有多长。如果互联网公司或 Stripe/OpenRouter 提前占据 AI 服务网络的生态位，运营商的转型窗口可能关闭。第五，本文对运营商用户接入优势向 AI 用户入口转化的机制讨论仍不充分。运营商拥有庞大的移动、固网和政企客户基础，但用户规模并不自动等同于 AI 服务使用规模，二者之间还存在产品入口、用户习惯、应用生态和服务体验等转化环节。第六，本文对网络资源在 AI 推理调度中的实际价值缺乏量化分析。不同 AI 任务对网络时延、带宽和节点位置的敏感程度存在显著差异，网络是否能够形成可持续的 AI 业务溢价，需要结合实际业务场景进一步验证。
后续研究方向
后续研究可在以下维度进一步深入。第一，补充财务可行性量化分析，估算各阶段投入规模、预期回报和投资回收期，为运营商高层决策提供数据支撑。第二，深入讨论监管合规与组织变革的体制性障碍，分析运营商作为央企在数据安全、模型合规、内容审核等方面的约束与差异化优势，以及薪酬体系、考核机制、决策流程等与互联网公司的根本差异。第三，评估 Stripe 收购 OpenRouter 后竞争格局的变化，分析 OpenRouter 获得支付基础设施能力后对运营商 Token 经营的潜在冲击。第四，判断市场时间窗口，评估互联网公司或 Stripe/OpenRouter 提前占据 AI 服务网络生态位的可能性，为运营商转型提供时间维度的参考。
【终章结语】
OpenRouter 获 Stripe 超 80 亿美元收购，验证了 AI 资源编排中间层的商业价值。对运营商而言，简单算力堆叠与粗放 Token 转售均非长久之计，真正难以复制的优势在于海量终端接入、全国性网络、梯次化智算布局、企业级计费体系与政企渠道资源的综合整合能力。
本文提出，运营商应从 Token 经营向 AI 能力、AI 任务与价值经营演进，通过分阶段投入、借力外部生态、组织变革与聚焦核心场景，形成重资产与系统开发的组合竞争力。关键制约并非软件开发人员数量不足，而是 AI 业务系统、产品运营和生态组织能力相对不足。
当前，运营商正站在 AI 转型的关键十字路口。若仅将 Token 经营视为终极目标，而忽视向 AI 能力、AI 任务与价值经营的演进，未能真正形成以 AI 服务为核心、以业务结果为导向的运营模式，则即便拥有海量算力、网络与用户接入资源，最终仍可能陷入"新管道化"困境——从"流量管道"演变为"Token 管道"，难以摆脱价值传递者而非价值创造者的角色定位。反之，若能将重资产优势与系统开发能力有机结合，从"卖资源"转向"卖服务"、从"卖 Token"转向"卖结果"，运营商有望在 AI 时代重塑自身生态位，真正成为 AI 服务网络的价值创造者与主导者。
最终，运营商的成功在于是否形成重资产与系统开发的组合竞争力。运营商能否从 Token 经营走向 AI 能力与任务经营，取决于能否将算力、网络、用户接入和软件生态组织成面向用户价值的 AI 服务体系。
这才是 AI 时代运营商真正的护城河。
数据来源说明 ：本文涉及 OpenRouter 的数据主要来源于 OpenRouter 官方文档与博客、公开行业报道；涉及三大运营商的数据主要来源于公司公开披露及行业媒体报道。部分战略概念，如 AISN、Token 经营、AI 能力经营、AI 任务与价值经营，为本文提出的战略构想。本研究在财务可行性量化分析、监管合规与组织变革体制性障碍、Stripe 收购 OpenRouter 后竞争格局变化、市场时间窗口判断等维度存在局限，后续研究需进一步补充完善。