网关路由拿走控制权，为什么代价是让AI变傻三倍！
这个行业正在犯一个代价极其昂贵的集体错误：把模型路由塞进网关！
摘要：AI Agent执行复杂任务时，单次任务可调用上百次模型。业内普遍将模型路由放在网关层统一管控，但生产环境实测数据表明，网关路由导致成本飙升237%、延迟激增65%，而任务完成质量并未提升。Factory Router在Harness层路由两个月，节省58%总成本，91%会话节省过半。问题核心：网关只看到单次请求，而Harness拥有会话缓存、任务状态、工具执行结果等关键上下文。模型切换的缓存代价被忽视时，廉价模型反而更贵。
网关只是个传话的，凭什么替大脑做决定！
模型路由放在哪里，表面看是个技术架构问题，实际上是对“谁拥有决策信息”的根本误判。
网关是什么？它就是一道门。应用发来一个请求，网关看一眼：哦，允许调哪些模型，好，转发给云厂商，完事。连接一关，什么记忆都没留下。网关看到的，永远只是一个孤零零的请求：一段提示词进去，一串token回来。它不知道这个请求之前发生了什么，也不知道之后要干什么。它只是一个没有短期记忆的传话筒。
Harness是什么？它是Agent的大脑皮层，是整个Agent循环的中枢神经系统。它组装提示词，运行模型调用的工具，创建子Agent会话，检查任务完成状态，记录会话历史和缓存状态。一个任务跑起来，可能是几百次模型调用、持续几个小时的连续计算。Harness从头到尾都在场，它知道当前这个请求是第几步、之前失败了几次、缓存里有什么、工具执行结果是什么、任务还剩多少工作量。
网关看到的是一次“聊天补全”请求，Harness看到的是一个正在演化中的复杂计算任务。把路由决策权交给网关，就等于让一个只看过一帧画面的观众给整部电影做剪辑决策。这荒谬吗？但这就是今天绝大多数企业的做法！
数据摔门：58%成本蒸发，91%会话节省过半，网关能做到吗？
数字不说谎。
Factory Router在生产环境跑了两个多月，结果是什么？路由决策放在Harness层之后，总成本砍掉58%。中位数会话节省76%，超过九成会话至少节省一半。
这些节省是在零质量损失的前提下实现的。路由会话与始终使用最强模型的会话，在八个生产指标上打了个平手：任务完成率、命令失败率、测试失败率、重复编辑次数、交付产物质量、用户接受率、用户重开率。一个不落，全部打平。
延迟也在降。始终用最强模型的会话，单次模型调用中位数等待81秒；路由之后，中位数降到49秒。因为轻量模型响应更快，它们在能处理的任务上大幅缩短了等待时间。
网关路由能做到吗？做不到。网关连“这个请求被路由到轻量模型后，后续任务是否还能正常完成”都不知道，它拿什么来保证质量不跌？它只有一个空荡荡的请求，没有任务上下文，没有历史轨迹，更没有“之前选的模型表现如何”的反馈信号。网关路由是闭着眼睛做决策。Harness路由是睁开眼睛看着任务进程做决策。
模型A和模型B不是同一物种：切换有隐藏税！
切换模型不是换条便宜的管道。它是一次代价高昂的协议切换！
不同模型家族的接口不兼容。假设下一个请求要编辑文件。模型A用的是查找-替换编辑器，指令是这么写的；模型B用的是基于diff的编辑器，指令是那么写的。Harness必须提前知道选哪个模型，然后才能组装对应的系统指令、工具定义和推理参数。到网关那层，请求已经按照特定模型的接口封装好了。网关如果强行换一个模型，Harness就得拆掉重来。
更狠的是推理缓存。每次模型调用，都会把整个会话记录重新送进去。Provider会把这段前缀缓存起来，下次同一模型再调，直接复用缓存，费用只有新鲜输入的一成左右。同一个会话记录，换到另一个模型，对不起，缓存作废，必须按新鲜输入收费，价格直接翻五到十倍。
网关根本就不知道缓存这回事。网关路由如果无视缓存状态瞎切换，会发生什么？实测数据触目惊心：完全无视缓存的网关路由策略，成本会在第6到20轮之间超过始终用最强模型的基线，到第61到150轮时飙到基线的2.12倍，第151到200轮冲到2.37倍！Harness层缓存感知的路由，同期成本只有基线的0.19到0.28倍。
这就是隐藏的切换税。便宜模型标价低，但切过去要重新暖缓存，可能比留在当前模型贵好几倍。网关看不见这笔账，Harness看得见。
一个任务跑166轮全用轻量模型，凭什么说它不需要“聪明”！
来看三组真实会话数据，每一组都是一个完整的认知反转。
第一组：实现一个带HTTP端点的目录加载器。跑了166轮，路由全程只用轻量模型，节省81%，任务完美收工。166轮，全用最便宜的模型，没出任何岔子。这说明什么？说明大量看似复杂的工作，本质上是体力活加简单模式匹配，根本不需要把最聪明的大模型搬出来。
第二组：构建按阶段展示产物的查看器。100轮，轻量模型和最强模型混着用，节省42%。部分环节需要更强的推理能力，部分环节轻量模型足够。路由捕捉到了这个节奏。
第三组：配置Prisma对接Supabase迁移。67轮，路由让最强模型从头跑到尾，节省0%。路由判断这个任务从头到尾没有安全的降级机会，0%节省就是正确答案！
这个零节省案例才是最精彩的。网关路由敢不敢在67轮里全部选最贵的模型？在成本压力下它可能不敢。但它不知道什么时候该省、什么时候不该省。Harness知道。因为Harness能看到任务有没有卡住、测试有没有通过、代码有没有反复改同一个地方。这些信号决定了一个模型切换到底值不值得。
缓存价格差十倍，网关装看不见，Harness不得不算这笔账！
每次模型调用，整个会话历史几乎全部重发。Provider按输入token收费，缓存命中时只收一成左右。这十倍的价差，网关根本看不见，但Harness躲不开。
缓存是有时效的。会话在两次调用之间闲置太久，缓存过期。Harness把长历史压缩成摘要后，下次调用带的是更短的前缀，但这个新前缀在缓存热起来之前，还是要按新鲜输入收费。同一个模型切换操作，在第5轮做很便宜，在第90轮做就贵得离谱。网关连当前调用是第几轮都不知道，怎么算这笔账？
生产环境里，推理花费高度集中在长会话上。长会话里，中位数单次调用输入量是前五轮调用输入量的7.6倍。缓存感知路由把成本增长压到4.4倍，缓存盲路由让成本飙到没法看。网关完全看不见自己正在引爆一个成本炸弹。
父任务生儿子，Harness给儿子分活再选妈，网关连儿子是谁都不知道！
Agent在工作中会创建子Agent。一个会话进行到一半，当前模型提出建议：让子Agent去探索某个目录，或者在一个隔离环境里尝试修复。Harness写一份精简的任务说明书，给这个子Agent单独选一个模型，启动它。子Agent启动时不继承父任务的缓存，但它也不需要继承整个会话历史，它只拿到那份精简说明书。
这意味着什么？父任务可以继续留在原来的模型上，保住已经热好的缓存；子任务用另一个模型去干苦力活，干完把结果交回来。父与子各走各的模型路线，各算各的缓存账。网关根本不知道子Agent的存在。它看到的只是一堆来自不同会话的、散落的请求。
更复杂的场景是Factory Mission。一个规划会话把用户指令拆解成有序计划，每个子任务都写清楚目的、前置条件和完成标准。Harness为每个子任务单独选模型。中位数Mission跨越423次调用、十个子会话、大约十二小时，路由节省总成本37.8%。网关连“这十个会话属于同一个Mission”都不知道，怎么给每个子任务选模型？
还有Review机制。Harness把一个评审任务定义为独立的作业。实现者用一个模型，评审者用另一个不同家族的模型。两者的能力互补，评审者能发现实现者遗漏的问题。网关看到的是一堆独立的请求，Harness看到的是一个实现-评审的闭环。
任务失败信号传不回网关，Harness靠它学聪明！
一个模型调用成功，只是token回来了。任务到底成没成，要看命令跑没跑通、测试过没过、文件改对没改对、用户最终接受了还是推倒重来。这些信号，网关一个都拿不到。网关只知道“200 OK，token已返回”。
Harness全部看得到。因为它运行工具、执行命令、跑测试、检查产物。Harness知道这次修改是不是又失败了，知道同一个地方改了几次还没好，知道测试从红色变绿色还是从绿色变红色。
重复失败会触发立即的模型切换。一个模型在某类修复上反复翻车，Harness当场就能换人。网关做不到，因为它收不到失败信号。任务最终完成后，一个长会话把几十次模型选择绑定到一个结果上，确实很难归因。但Harness-created的作业把因果链缩短了：一个Worker通过或未通过自己的完成条件，一个Review对某一块具体工作打出分数。每个结果只绑定少数几次模型选择，归因变得可行。
每一次路由选择，连同当时的状态和最终结果，都存成一条记录。这些记录不是用来事后写报告的，是用来训练下一个版本的路由策略的。今天运行的Factory Router，就是在用昨天的生产数据在优化。数据闭环在Harness层存在，网关层不存在。
基准测试把话说死：网关能用同样成本达到96%质量吗？
公开基准测试上，路由方案对始终用最强模型的基线，跑出了什么成绩？
Terminal-Bench 2上，路由达到最强模型通过率的99%。Legacy-Bench上，达到96%。关键是，每成功完成一个任务的成本比基线低大约20%。这两个基准都比典型的生产工作流更难。
96%和99%不是100%。但这是一个工程取舍：放弃1%到4%的极端情况成功率，换来20%的成本降低和65%的延迟缩短。网关路由根本做不到这个取舍，因为它既不知道什么时候放弃，也不知道放弃多少会翻车。
还有一个细节。路由会话与始终用最强模型的会话在八个生产指标上平手。基准测试上路由略低一线。这个差异来自什么地方？来自基准任务的分布与生产任务的分布不同。路由策略是用生产数据训练的，在基准上表现稍弱，恰好说明策略是真实的，没有作弊。如果一个路由方案在所有分布上都吊打基线，那才该怀疑它是不是过拟合了测试集。
生产数据是真实的。两个月，真实客户，真实任务，真实的钱。网关路由方案里，有任何一个在生产环境跑出过58%总成本节省、91%会话节省过半、同时八项质量指标不下滑的成绩吗？没有。根本不可能有。因为网关天生瞎。
任务跑完最后一轮，Harness收到一个编辑请求的响应，执行了修改，准备构造下一个请求。它查了一下缓存状态，发现当前模型在这个会话上的前缀已经累积了超过十五万token，缓存命中率接近95%。如果下一轮换到另一个标价便宜30%的模型，缓存要重新暖，需要额外支付相当于当前轮次七倍的费用。Harness决定不移。那个便宜模型的价格单上写着“更便宜”，但Harness知道那不是真的。
原文期刊 / 2026年1月7日 / Why model routing must be in the harness / Factory AI 工程团队