企业AI的下一个战场：不是选模型，而是搭框架

编者按：当模型能力逐渐成为可采购的通用商品，企业之间的差距将不再由模型清单拉开，而由围绕模型构建的工程体系决定。这一点，正在成为企业AI从试点走向规模化生产的分水岭。

过去几年，围绕人工智能的讨论几乎被同一条叙事主导：更大的模型、更强的推理能力、更长的上下文窗口、更高的基准分数。每一次能力跃迁都会引发一轮「换模型」的讨论，仿佛只要选对了那个榜单上最靠前的模型，企业的AI战略就能自动成立。

但MIT Technology Review刊发的这篇题为《Designing an AI serving harness built to last》的文章提出了一个不同的判断：企业AI的下一个竞争优势，与其说取决于你选择哪个模型，不如说取决于你在模型周围构建了什么。这是一个重要的转向——它意味着竞争的焦点正从「模型能力」迁移到「系统能力」。

一、模型正在变成可替换的零件

理解这一转向，首先要明白模型市场正在发生什么。开源模型与闭源模型的能力差距持续收窄，同一梯队的模型在通用任务上的表现日益接近，价格战让推理成本快速下降，而模型迭代周期已经缩短到以月乃至以周计。今天的最优选择，很可能在半年后既不是最强、也不是最便宜的。

在这种环境下，把所有业务逻辑、提示词、评测流程和运维经验都硬编码到某一个模型的调用方式上，是一种高风险做法。一旦更换模型，这些沉淀就得推倒重来。反过来，如果企业能把「模型」抽象为一个可插拔的组件，用统一的接口去调度、评测、切换、回滚，那么模型能力的每一次进步都能被低摩擦地吸收，而不是每次都要重新做一遍集成工程。

这正是「服务承载框架」（serving harness）要解决的问题。它不是模型本身，而是模型运行其上的那一层工程结构。

二、什么是AI服务承载框架

所谓serving harness，可以理解为模型与业务之间的中间层。它负责的事情相当具体：把请求路由到合适的模型；管理上下文与提示模板；处理重试、超时、限流与降级；记录完整的调用链路以便审计与排障；对输出进行结构化校验与安全过滤；以及在多个模型之间做成本与质量的动态权衡。

这一层听起来并不起眼，却恰恰是「演示」与「生产」之间的差距所在。一个在实验室里跑通的智能体，到了真实业务环境中会遇到并发尖峰、长尾延迟、模型幻觉、上下文超限、供应商故障、合规审计等一系列问题。承载框架的价值，就是在这些问题发生时不至于让整个系统一起崩塌。

换句话说，模型决定了能力上限，而承载框架决定了可用性下限。对企业而言，下限往往比上限更重要——因为业务不能靠偶尔一次的惊艳表现来运转。

三、为什么「built to last」如此困难

文章标题中「built to last」这个限定词值得注意。设计一个能撑过数年的框架，比设计一个能跑通今天的框架难得多，原因有三。

其一，技术栈变化太快。今天的推理接口、工具调用协议、上下文管理方式，两三年后可能完全不同。框架若过度耦合于某一代技术细节，很快会变成技术债。

其二，需求会漂移。业务方最初只想要一个问答机器人，后来可能要求它接入内部系统、执行多步任务、承担有审计要求的决策辅助。框架必须具备足够的抽象能力来承接这种演进，而不是每来一个新需求就重写一遍。

其三，组织会变化。谁来维护这套框架？是平台团队、数据团队还是各业务线自建？如果框架设计没有清晰的责任边界和可观测性，它会在多人协作中逐渐腐化，最终无人敢动。

四、长期框架的四条设计原则

基于上述挑战，可以归纳出几条在实践中被反复验证的原则。

第一，把模型当作可替换依赖。统一抽象层，保留灰度切换与快速回滚能力，让「换模型」成为一个配置动作，而不是一次项目立项。

第二，把可观测性作为一等公民。从第一天起就记录请求、上下文、模型版本、token消耗、延迟与失败原因。没有这些数据，成本优化和质量评估都只能靠猜。

第三，把评测内嵌到流程中。框架应能对新模型、新提示、新版本自动跑回归评测，用数据回答「这次改动是变好还是变坏」，而不是靠个别案例的主观感受。

第四，把成本与质量放在同一张仪表盘上。不同任务对质量的要求并不相同，框架应支持按场景选择模型档位，把昂贵的推理能力用在高价值环节，把轻量模型用在高频简单环节。

当模型本身越来越像水电一样的基础资源，真正构成壁垒的，是企业围绕模型沉淀下来的工程资产：路由策略、评测集、提示资产、运维经验和组织流程。这些东西不会因为一次模型发布而过时，反而会随使用而增值。

五、对企业的现实含义

这一判断对企业有三点直接含义。首先，AI预算的分配需要重新审视：如果绝大部分投入都用于追逐最新模型，而承载框架仍停留在脚本拼接阶段，那么投入产出比会越来越差。其次，平台团队的价值被低估了——那些看起来「不产出业务功能」的抽象层、评测工具和监控体系，恰恰是长期竞争力的来源。最后，管理层需要把AI视为一项系统工程，而不是一次采购决策。

模型会继续进步，榜单会继续刷新，价格会继续下降。这些都值得关注，但它们更像是潮水，会同时抬高所有船只。真正让一家企业与另一家企业拉开差距的，是它在潮水之下打下的那层地基——一个设计良好、能够长期演进、经得起模型换代与业务扩张冲击的服务承载框架。

这也解释了一个看似矛盾的现象：在模型能力最强的时代，工程能力反而变得更重要了。

本文编译自MIT Technology Review