正在加载，请稍候
从共享运行时、单位算力到集成维护，用 2026 年 9 月的真实数据拆开企业 AI 应用跨平台落地的三张成本账单。
2026 年 9 月，一个代码托管平台公布了一组数字：一名开发者带着 AI 智能体，用约 14.5 周把 Copilot agent runtime 从 TypeScript 全量重写为 832,378 行生产级 Rust，拆成 128 个 PR 陆续合入主干。同一套运行时，今天同时驱动 VS Code、Visual Studio、Excel、Outlook、PowerPoint 和 Word。
这才是企业 AI 应用谈「跨平台」时该有的样子——不是把同一个功能在四个端各做一遍，而是把智能收进一个内核，让外壳变得很薄。下面把这件事拆成三张账单来算。
官方复盘里有一句关键判断：那些产品「没有哪一个想要、也不应该需要去实现生产级智能体 harness 所包含的一切」。
此前多数产品各自实现了一套智能体循环，之后陆续替换为统一的 SDK 入口。给出的理由是：一处修复就能修复所有产品。
这句话直接决定了投入产出的形状。多端适配模式下，成本随端数线性增长；共享内核模式下，第二端之后的边际成本接近集成工作量，而不是重复研发工作量。评审跨平台方案时，先看它的内核边界画在哪里，比看功能清单更有信息量。
如果入口里包含桌面端，云推理与本地执行怎么分工就是必须先定下来的边界。企业 AI 桌面应用的案例分析里拆过这套分工的具体划法，可以直接拿来当评审清单。
官方给出的对照是：这个项目「在智能体出现之前需要一整个开发团队花上一两年」。实际结果是主要靠一名开发者、几个月完成，团队其余成员同期还在继续扩展该运行时的能力覆盖。回归问题在过程中被快速发现并修复，性能提升了好几个数量级。
| 核算口径 | 多端各自实现 | 共享内核模式 |
|---|---|---|
| 投入人力 | 一整个开发团队 | 1 名开发者主导，团队并行扩能力 |
| 工期 | 1–2 年 | 约 14.5 周 |
| 交付方式 | 末期一次性切换 | 128 个增量 PR 持续合入发布 |
| 代码规模 | 各端分别累积 | 832,378 行生产级 Rust 统一维护 |
同类信号不止一条。有研究机构让模型在不到四周内优化了 30 多个开源生物分子模型，平均提速约 4 倍，输出完全一致时约 2 倍，并开源了全部代码（该实验的具体数据）。
注意这里的口径差别：不是新建一个模型，而是把已经存在的资产变快。对多数企业来说，存量系统的提速空间往往比新立项更大，因为不需要重新积累数据和做验证。
2026 年 9 月 18 日，千问团队发布 Qwen3.8-Omni-Flash，给出了一组不常见的定价变化：每小时音频输入的 API 价格下降超过 98%，每小时音视频输入的价格下降超过 93%；同时支持 1M token 上下文，29 项评测平均分较上一代提升超过 25%（官方发布说明）。
另一条线路是「把模型做小」。一家专注高频决策的团队发布的 Jev，不做对话也不做文本生成，只输出判断，官方口径是速度比通用大模型快 20~200 倍，成本 0.042 美元/百万 token，且输出 token 免费（产品信息）。
两条线合起来说明同一件事：企业侧的单位推理成本正在结构性下移，而下移的大头不是通用大模型降价，是任务被拆到更合适的模型上。预算表里如果只有一个模型条目，基本可以判定这张表还没算细。
| 任务类型 | 模型选择 | 2026 年 9 月的单价信号 |
|---|---|---|
| 高频分类、预筛、路由判断 | 专用判断模型 | 0.042 美元/百万 token，输出 token 免费 |
| 音视频理解与长会议 | 全模态模型 | 音频输入每小时价格降幅超 98% |
| 通用文本与代码生成 | 通用大模型 | 按上下文长度核算，长上下文仍是成本主项 |
模型降价与成本模型的关系，GPT-5.6 Luna 降价那次调整里讨论过一个判断：降价不等于账单下降。如果账单反而变高了，问题通常出在任务路由上，这份模型切换实验记录里有一个很直接的对照。
用户在哪，入口就该在哪。2026 年 9 月 17 日，ChatGPT 正式集成进 Word，发布方同时提到 Excel 与 PowerPoint 两个集成的用量近期大幅增长——文档三件套补齐后，AI 入口不再是一个需要单独打开的网页（集成上线记录）。
桌面侧也在跟进。同日发布的 Muse for Mac 让个人智能体在用户明确授权下直接在电脑上完成任务，包括整理下载文件夹、查找丢失文件、总结消息与笔记（发布说明）。
这两条动态指向同一个成本判断：自研多端客户端是最贵的做法。把智能体接到用户已经在用的工作界面里，集成成本远低于自研四套界面并长期维护。
编排层的成本同样在下降。Claude Code 重构了 Projects：用户设定目标后由模型拆解任务、并行调度多个线程、审查输出并汇总结果，线程本质上是各自独立分支的云端会话（重构说明）。
反面教训也值得写下来。见过不少团队第一版就自研跨端 agent loop，两端的状态同步和权限模型各写一遍，三个月后维护成本超过了研发成本。更省的做法是先把内核抽出来，外壳只负责入口与权限。
按这个口径，判断一个跨平台项目值不值得立项，只要回答三个问题：内核能覆盖几个端？第二端的边际成本是多少？单位推理成本在未来 12 个月会不会再降一个量级？
账层怎么分，如果项目规模不大，可以先借用小程序场景下的两层账模型当简化版模板，再按端数往上加层。
先内核。上面的对照表已经说明，内核的复用次数决定摊销分母，而界面每多一端就多一份长期维护。把预算优先压在内核与权限模型上，后续每接一个新入口都只是薄壳工作。
会，但这个风险是可以量化管理的。既然一处修复能修复所有产品，一处缺陷也会影响所有产品，所以内核层需要比外壳层更严的回归样本与灰度发布机制。增量合入、持续发布比末期一次性切换更能控制这种风险。
如果只有一个入口，没必要。跨平台内核的价值来自复用次数，端数不到三个时，抽象成本通常高于收益。更务实的路径是先把单端做到可交付，再在接第二个入口之前做一次内核抽取。
多数情况是任务没有被拆分。长上下文、全量文档塞进提示词、把所有判断都交给通用大模型，这几种做法会把单价降幅吃回去。把高频判断类任务路由到专用模型，是当前最直接的降本动作。
如果你的团队正在评估跨平台落地路径与预算口径，可以先翻一下我们做过的 工程案例，或者直接 联系我们 做一次架构与成本口径的对齐。