编者按当模型能力逐渐成为可采购的通用商品企业之间的差距将不再由模型清单拉开而由围绕模型构建的工程体系决定。这一点正在成为企业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本文首发于赢政天下 获取更多深度技术内容与资源欢迎访问官网。
编者按当模型能力逐渐成为可采购的通用商品企业之间的差距将不再由模型清单拉开而由围绕模型构建的工程体系决定。这一点正在成为企业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本文首发于赢政天下 获取更多深度技术内容与资源欢迎访问官网。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
