1. 从“模型竞赛”到“系统能力”的转向信号过去两年整个行业的目光几乎都被“模型参数又翻了多少倍”“榜单又刷新了哪个指标”这类话题占据。我自己也经历过那个阶段每次新模型发布第一件事就是拉下来跑几个 benchmark看看推理能力、代码能力、多模态理解到底强了多少。但到了今年我越来越明显地感觉到身边真正在做落地项目的团队讨论的重心已经悄悄变了。大家不再只问“你用的哪个模型”而是开始问“你的模型是怎么被调度和管理的”“多个模型之间怎么切换”“Agent 执行链路怎么保证稳定”。这个变化不是偶然的。当模型能力逐渐趋同、开源模型和闭源模型的差距在特定任务上不断缩小单纯靠“选一个最强模型”就能赢的时代基本结束了。真正决定一个 AI 系统能不能跑起来、跑得稳、跑得久的是模型之外的那一层——我把它叫做“控制面”。这个词借用了网络架构里的概念数据面负责真正搬运数据包控制面负责决定数据包往哪走、走哪条路、什么时候限速、什么时候熔断。放到 AI 系统里模型就是数据面而围绕模型做路由、编排、监控、降级、成本控制的那一整套机制就是控制面。这篇文章我想聊的就是这个转向为什么“控制面”正在成为 AI 行业新的竞争焦点它具体包含哪些东西以及如果你现在正在做 Agent 开发或者多模型接入应该怎么理解和搭建自己的控制面。适合已经上手过至少一个模型 API、正在做多模型或 Agent 项目的开发者也适合想搞清楚“为什么我的 demo 很惊艳但上线就崩”的团队负责人。2. 为什么单靠“模型强”已经不够用了2.1 模型能力趋同带来的选择困境先说一个我自己的观察。去年我做的一个文档问答项目当时选模型的标准很简单谁的准确率高就用谁。但今年再回头看同样的任务排名前十的模型里有六七个都能做到“够用”的水平差距可能只有几个百分点。这时候你如果还只盯着“最强模型”就会忽略一个更现实的问题最强模型往往最贵、最慢而且在某些细分场景下未必真的比小模型好。我实测过一个场景从合同里抽取关键条款。用某旗舰模型跑准确率 94%单次调用成本大约 0.12 元换成一个 7B 级别的开源模型做微调后部署准确率 91%单次成本不到 0.01 元。差了 3 个百分点成本差了十倍以上。对于每天要处理几万份合同的企业来说这 3 个百分点值不值得多花十倍的钱答案往往是否定的。这时候你需要的不是“选哪个模型”而是“怎么让不同的请求走不同的模型”——这就是控制面要解决的问题。2.2 多模型并存是常态而非例外再往深一层看现在一个稍微像样的 AI 应用背后往往不止一个模型。我见过的一个典型架构是这样的用户输入先经过一个轻量意图识别模型判断类型如果是简单问答就走小模型如果是复杂推理就走大模型如果涉及图像就走多模态模型如果涉及代码就走代码专用模型。这还没算上 embedding 模型、rerank 模型、审核模型。这么多模型如果每个都单独接一套 SDK、单独做鉴权、单独做重试、单独做监控代码会迅速变成一团乱麻。我踩过这个坑早期项目里每个模型调用都写一遍 try-catch 和重试逻辑后来加一个新模型就要复制粘贴一遍改一个超时参数要改五个地方。这种架构在 demo 阶段没问题一旦要上线、要扩容、要换模型维护成本会指数级上升。2.3 Agent 把问题放大了一个量级如果说多模型只是让事情变复杂那 Agent 就是把复杂度直接拉满。一个 Agent 执行一次任务可能涉及十几轮模型调用、若干次工具调用、多次状态判断。每一轮调用都可能失败、超时、返回格式不对。如果没有一个统一的控制层来管理这些调用你根本不知道失败发生在哪一步也不知道该重试还是该降级。我印象很深的一次排查一个 Agent 任务偶尔会卡住不返回。查了半天发现是某一步工具调用返回了空结果模型收到空结果后陷入了“再试一次”的循环而循环次数没有上限。这个问题在单次模型调用里根本不会出现但在 Agent 链路里就是致命的。解决它靠的不是换模型而是在控制面里加一个“最大循环次数”和“空结果熔断”的规则。3. 控制面到底包含哪些核心组件3.1 模型网关统一入口与路由中枢模型网关是整个控制面最基础的一层。你可以把它理解成 AI 系统里的“路由器”所有模型调用都先经过它由它决定这次请求发给哪个模型、用什么参数、走什么策略。我目前用的网关是自己搭的核心功能包括几块。第一是统一鉴权所有模型的 API Key 都收在网关里业务代码不直接接触密钥换模型时业务侧无感知。第二是路由策略支持按任务类型、按成本上限、按延迟要求来选模型。第三是格式转换不同模型的请求和响应格式不一样网关负责抹平差异业务侧只用一套接口。这里有个细节值得展开路由策略怎么写。我一开始用的是最简单的“if-else”根据任务类型硬编码。后来发现这样不够灵活改一次策略要重新部署。现在改成配置驱动路由规则写在配置文件里支持热更新。比如这样一条规则routes: - name: simple_qa match: intent: faq target: small-model fallback: medium-model max_cost_per_call: 0.01 - name: complex_reasoning match: intent: analysis target: large-model fallback: medium-model timeout_ms: 30000这样调整策略不用改代码改配置就行。实测下来运维效率提升非常明显。3.2 多模型编排让合适的模型做合适的事网关解决的是“单次调用走哪个模型”编排解决的是“一个任务里多个模型怎么配合”。这两件事经常被混为一谈但其实是两个层次的问题。我做过一个多模态的图纸识别项目流程是这样的先用一个视觉模型把图纸里的文字和表格提取出来再用一个语言模型理解这些内容并回答用户问题最后用一个审核模型检查回答里有没有敏感信息。三个模型三种能力串成一条流水线。如果没有编排层这条流水线要手写状态管理和错误处理有了编排层我只需要声明每一步用什么模型、输入输出怎么衔接、失败怎么处理。编排层我建议至少支持三种模式串行、并行、条件分支。串行适合有依赖关系的步骤并行适合可以同时做的子任务比如同时调用多个模型然后投票条件分支适合根据中间结果决定下一步走向。Agent 本质上就是这三种模式的组合只不过循环次数更多、状态更复杂。3.3 可观测性看不见的调用等于失控这一块是我踩坑最多的地方也是我觉得最容易被忽视的地方。早期做项目时模型调用出问题基本靠日志和猜。后来调用量上来了日志根本看不过来出了问题只能一个个试。现在我的做法是所有经过网关的调用都打上统一的 trace id记录请求内容、响应内容、耗时、token 数、成本、模型版本、是否命中缓存、是否走了 fallback。这些数据汇总到一个看板上可以按模型、按任务类型、按时间段来查。有一次线上突然变慢我看板上一眼就发现是某个模型的 P99 延迟从 2 秒涨到了 8 秒直接切到备用模型五分钟解决问题。如果没有这套可观测性可能要排查半天。提示可观测性不是上线后才补的东西最好在网关搭好的第一天就把埋点加上。后补的话历史数据缺失很多问题没法回溯。3.4 成本与配额控制别让账单吓到你成本控制这件事没被账单吓过的人不会重视。我有一个月因为一个 Agent 任务写错了循环条件导致某个模型被反复调用月底账单出来比平时多了好几倍。从那以后我就在网关里加了硬性的成本控制。具体做法是三层第一层是单次调用成本上限超过就拒绝第二层是单任务累计成本上限Agent 跑着跑着超预算就中断第三层是单日总额度到了就降级到便宜模型或者直接限流。这三层加起来基本能避免“一夜之间烧掉一个月预算”的惨剧。配额控制还涉及一个容易被忽略的点不同业务线的额度隔离。如果所有业务共用一个额度一个业务出问题会拖垮其他业务。我现在是按业务线分配额度互不影响。4. 搭建控制面的实操路径4.1 从最小可用网关开始如果你现在还没有任何控制面我的建议是不要一上来就搞大而全先从最小可用的网关开始。所谓最小可用就是能统一鉴权、能路由、能记录日志这三件事。我当初的第一版网关只有不到两百行代码用一个轻量 Web 框架写的核心逻辑就是接收请求、根据配置选模型、转发、记录。没有花哨的功能但已经解决了“密钥散落各处”和“换模型要改代码”这两个最痛的问题。后面所有功能都是在这个基础上长出来的。技术选型上我建议用你团队最熟悉的语言和框架不要为了“先进”去选不熟的技术。网关本身是个 IO 密集型服务性能瓶颈通常在网络和模型响应不在网关本身所以语言性能差异没那么重要可维护性才是关键。4.2 路由策略的渐进式演进路由策略不要一开始就设计得很复杂。我的演进路径是这样的第一阶段硬编码哪个任务用哪个模型写死在代码里第二阶段配置化规则抽到配置文件第三阶段动态化根据实时延迟和成本自动调整。大部分团队到第二阶段就够了。第三阶段需要收集足够的运行时数据还要防止策略震荡比如两个模型来回切换导致不稳定实现成本不低。我目前也只在少数几个对延迟特别敏感的场景用了动态路由。一个实用的中间方案是“带权重的静态路由”给主模型配 90% 流量备用模型配 10% 流量。这样既能保证主模型出问题时备用模型是热的不是冷启动又能持续收集备用模型的表现数据。4.3 Agent 链路的控制要点Agent 的控制面比普通多模型调用要复杂因为它是循环的、有状态的。我在 Agent 控制上总结了几个必须有的机制。第一个是最大步数限制。不管任务多复杂超过 N 步就强制终止并返回当前结果。这个 N 要根据任务类型设我一般设 15 到 20 步。第二个是单步超时每一步模型调用或工具调用都有独立超时避免某一步卡死拖垮整个任务。第三个是循环检测如果连续几步的输入输出高度相似判定为陷入循环强制中断。第四个是中间状态持久化Agent 跑到一半失败了能从最近的检查点恢复而不是从头再来。这几个机制听起来简单但每一个都是我在实际项目里被坑出来的。尤其是循环检测没有它的时候一个写错的提示词能让 Agent 无限循环直到烧完额度。4.4 灰度与回滚机制换模型是件高风险的事。我见过太多“新模型上线后效果反而变差”的案例。所以控制面里必须有灰度能力新模型先接 5% 流量观察一段时间的关键指标准确率、延迟、成本、错误率没问题再逐步放量。灰度期间要重点看什么我的经验是看三类指标业务指标任务完成率、用户满意度、技术指标延迟、错误率、成本指标单次成本、总成本。三类都达标才放量任何一类异常就回滚。回滚要能做到秒级所以模型版本和配置都要支持热切换。5. 常见问题与排查实录5.1 模型返回格式不稳定怎么办这是多模型场景下最常见的问题。不同模型对同一个提示词的输出格式可能完全不同有的返回 JSON有的返回带 markdown 代码块的 JSON有的干脆返回一段自然语言。如果你的下游代码强依赖某种格式换个模型就崩。我的解法是在网关层做输出规范化。定义一个统一的输出 schema网关收到模型响应后先尝试解析解析失败就调用一个轻量的“格式修复”模型或者用规则做兜底转换。这样下游代码只面对一种格式换模型无感知。当然格式修复本身也有失败率所以还要有“修复失败就返回原始内容并标记”的降级路径。5.2 某个模型突然变慢或不可用模型服务不是 100% 可靠的尤其是第三方 API。我遇到过某模型在高峰期延迟从 1 秒涨到 15 秒的情况也遇到过整个区域不可用的情况。应对这类问题控制面要有健康检查和自动熔断。具体做法是持续探测每个模型的健康状态可以用真实流量的成功率也可以用专门的探测请求连续失败或延迟超标就自动熔断把流量切到备用模型。熔断后要定期探测恢复情况恢复了再切回来。这套机制我实测下来能把模型故障对业务的影响从“分钟级”降到“秒级”。5.3 成本失控的几种典型场景成本失控我总结了几种典型场景。第一种是 Agent 循环前面说过。第二种是缓存失效本来该命中缓存的请求因为参数微小差异没命中全部打到模型。第三种是重试风暴一个请求失败后疯狂重试重试又失败又重试。第四种是提示词膨胀随着功能迭代提示词越来越长token 数悄悄涨了好几倍。对应的解法循环用步数限制缓存用规范化后的参数做 key重试用指数退避加最大次数提示词定期做精简审查。这四条我都在网关里做了强制约束不依赖开发者自觉。5.4 排查速查表现象可能原因排查方向处理方式任务卡住不返回Agent 循环或单步超时未设查看 trace 里最后一步加步数限制和超时成本突然飙升缓存失效或重试风暴看单位时间调用量检查缓存 key 和重试策略换模型后效果变差提示词未适配新模型对比新旧模型输出灰度放量不行就回滚延迟忽高忽低模型服务不稳定看 P99 延迟曲线启用熔断和 fallback输出格式解析失败模型返回格式变化看原始响应网关层做格式规范化6. 我对控制面时代的一点判断做了这么多项目我越来越觉得AI 系统的竞争力正在从“模型有多强”转移到“系统有多稳”。模型是买得到的但一套能管住多模型、管住 Agent、管住成本、管住故障的控制面是买不到的只能自己一点点搭出来。这个转向对开发者的要求也变了。以前会调 API 就能做 AI 应用现在要懂路由、懂熔断、懂可观测性、懂成本控制。这些能力听起来更像后端工程师的活但确实就是现在做 AI 落地必须补的课。我自己也是从“只会写提示词”一步步被逼着学这些的。如果你现在正在做多模型或者 Agent 项目我的建议是尽早把控制面这件事提上日程。不用一步到位但至少先把网关和可观测性搭起来。这两样东西越早做后面省的事越多。等到系统复杂到一定程度再补成本会高得多。
AI系统控制面：多模型路由与Agent编排的工程实践
1. 从“模型竞赛”到“系统能力”的转向信号过去两年整个行业的目光几乎都被“模型参数又翻了多少倍”“榜单又刷新了哪个指标”这类话题占据。我自己也经历过那个阶段每次新模型发布第一件事就是拉下来跑几个 benchmark看看推理能力、代码能力、多模态理解到底强了多少。但到了今年我越来越明显地感觉到身边真正在做落地项目的团队讨论的重心已经悄悄变了。大家不再只问“你用的哪个模型”而是开始问“你的模型是怎么被调度和管理的”“多个模型之间怎么切换”“Agent 执行链路怎么保证稳定”。这个变化不是偶然的。当模型能力逐渐趋同、开源模型和闭源模型的差距在特定任务上不断缩小单纯靠“选一个最强模型”就能赢的时代基本结束了。真正决定一个 AI 系统能不能跑起来、跑得稳、跑得久的是模型之外的那一层——我把它叫做“控制面”。这个词借用了网络架构里的概念数据面负责真正搬运数据包控制面负责决定数据包往哪走、走哪条路、什么时候限速、什么时候熔断。放到 AI 系统里模型就是数据面而围绕模型做路由、编排、监控、降级、成本控制的那一整套机制就是控制面。这篇文章我想聊的就是这个转向为什么“控制面”正在成为 AI 行业新的竞争焦点它具体包含哪些东西以及如果你现在正在做 Agent 开发或者多模型接入应该怎么理解和搭建自己的控制面。适合已经上手过至少一个模型 API、正在做多模型或 Agent 项目的开发者也适合想搞清楚“为什么我的 demo 很惊艳但上线就崩”的团队负责人。2. 为什么单靠“模型强”已经不够用了2.1 模型能力趋同带来的选择困境先说一个我自己的观察。去年我做的一个文档问答项目当时选模型的标准很简单谁的准确率高就用谁。但今年再回头看同样的任务排名前十的模型里有六七个都能做到“够用”的水平差距可能只有几个百分点。这时候你如果还只盯着“最强模型”就会忽略一个更现实的问题最强模型往往最贵、最慢而且在某些细分场景下未必真的比小模型好。我实测过一个场景从合同里抽取关键条款。用某旗舰模型跑准确率 94%单次调用成本大约 0.12 元换成一个 7B 级别的开源模型做微调后部署准确率 91%单次成本不到 0.01 元。差了 3 个百分点成本差了十倍以上。对于每天要处理几万份合同的企业来说这 3 个百分点值不值得多花十倍的钱答案往往是否定的。这时候你需要的不是“选哪个模型”而是“怎么让不同的请求走不同的模型”——这就是控制面要解决的问题。2.2 多模型并存是常态而非例外再往深一层看现在一个稍微像样的 AI 应用背后往往不止一个模型。我见过的一个典型架构是这样的用户输入先经过一个轻量意图识别模型判断类型如果是简单问答就走小模型如果是复杂推理就走大模型如果涉及图像就走多模态模型如果涉及代码就走代码专用模型。这还没算上 embedding 模型、rerank 模型、审核模型。这么多模型如果每个都单独接一套 SDK、单独做鉴权、单独做重试、单独做监控代码会迅速变成一团乱麻。我踩过这个坑早期项目里每个模型调用都写一遍 try-catch 和重试逻辑后来加一个新模型就要复制粘贴一遍改一个超时参数要改五个地方。这种架构在 demo 阶段没问题一旦要上线、要扩容、要换模型维护成本会指数级上升。2.3 Agent 把问题放大了一个量级如果说多模型只是让事情变复杂那 Agent 就是把复杂度直接拉满。一个 Agent 执行一次任务可能涉及十几轮模型调用、若干次工具调用、多次状态判断。每一轮调用都可能失败、超时、返回格式不对。如果没有一个统一的控制层来管理这些调用你根本不知道失败发生在哪一步也不知道该重试还是该降级。我印象很深的一次排查一个 Agent 任务偶尔会卡住不返回。查了半天发现是某一步工具调用返回了空结果模型收到空结果后陷入了“再试一次”的循环而循环次数没有上限。这个问题在单次模型调用里根本不会出现但在 Agent 链路里就是致命的。解决它靠的不是换模型而是在控制面里加一个“最大循环次数”和“空结果熔断”的规则。3. 控制面到底包含哪些核心组件3.1 模型网关统一入口与路由中枢模型网关是整个控制面最基础的一层。你可以把它理解成 AI 系统里的“路由器”所有模型调用都先经过它由它决定这次请求发给哪个模型、用什么参数、走什么策略。我目前用的网关是自己搭的核心功能包括几块。第一是统一鉴权所有模型的 API Key 都收在网关里业务代码不直接接触密钥换模型时业务侧无感知。第二是路由策略支持按任务类型、按成本上限、按延迟要求来选模型。第三是格式转换不同模型的请求和响应格式不一样网关负责抹平差异业务侧只用一套接口。这里有个细节值得展开路由策略怎么写。我一开始用的是最简单的“if-else”根据任务类型硬编码。后来发现这样不够灵活改一次策略要重新部署。现在改成配置驱动路由规则写在配置文件里支持热更新。比如这样一条规则routes: - name: simple_qa match: intent: faq target: small-model fallback: medium-model max_cost_per_call: 0.01 - name: complex_reasoning match: intent: analysis target: large-model fallback: medium-model timeout_ms: 30000这样调整策略不用改代码改配置就行。实测下来运维效率提升非常明显。3.2 多模型编排让合适的模型做合适的事网关解决的是“单次调用走哪个模型”编排解决的是“一个任务里多个模型怎么配合”。这两件事经常被混为一谈但其实是两个层次的问题。我做过一个多模态的图纸识别项目流程是这样的先用一个视觉模型把图纸里的文字和表格提取出来再用一个语言模型理解这些内容并回答用户问题最后用一个审核模型检查回答里有没有敏感信息。三个模型三种能力串成一条流水线。如果没有编排层这条流水线要手写状态管理和错误处理有了编排层我只需要声明每一步用什么模型、输入输出怎么衔接、失败怎么处理。编排层我建议至少支持三种模式串行、并行、条件分支。串行适合有依赖关系的步骤并行适合可以同时做的子任务比如同时调用多个模型然后投票条件分支适合根据中间结果决定下一步走向。Agent 本质上就是这三种模式的组合只不过循环次数更多、状态更复杂。3.3 可观测性看不见的调用等于失控这一块是我踩坑最多的地方也是我觉得最容易被忽视的地方。早期做项目时模型调用出问题基本靠日志和猜。后来调用量上来了日志根本看不过来出了问题只能一个个试。现在我的做法是所有经过网关的调用都打上统一的 trace id记录请求内容、响应内容、耗时、token 数、成本、模型版本、是否命中缓存、是否走了 fallback。这些数据汇总到一个看板上可以按模型、按任务类型、按时间段来查。有一次线上突然变慢我看板上一眼就发现是某个模型的 P99 延迟从 2 秒涨到了 8 秒直接切到备用模型五分钟解决问题。如果没有这套可观测性可能要排查半天。提示可观测性不是上线后才补的东西最好在网关搭好的第一天就把埋点加上。后补的话历史数据缺失很多问题没法回溯。3.4 成本与配额控制别让账单吓到你成本控制这件事没被账单吓过的人不会重视。我有一个月因为一个 Agent 任务写错了循环条件导致某个模型被反复调用月底账单出来比平时多了好几倍。从那以后我就在网关里加了硬性的成本控制。具体做法是三层第一层是单次调用成本上限超过就拒绝第二层是单任务累计成本上限Agent 跑着跑着超预算就中断第三层是单日总额度到了就降级到便宜模型或者直接限流。这三层加起来基本能避免“一夜之间烧掉一个月预算”的惨剧。配额控制还涉及一个容易被忽略的点不同业务线的额度隔离。如果所有业务共用一个额度一个业务出问题会拖垮其他业务。我现在是按业务线分配额度互不影响。4. 搭建控制面的实操路径4.1 从最小可用网关开始如果你现在还没有任何控制面我的建议是不要一上来就搞大而全先从最小可用的网关开始。所谓最小可用就是能统一鉴权、能路由、能记录日志这三件事。我当初的第一版网关只有不到两百行代码用一个轻量 Web 框架写的核心逻辑就是接收请求、根据配置选模型、转发、记录。没有花哨的功能但已经解决了“密钥散落各处”和“换模型要改代码”这两个最痛的问题。后面所有功能都是在这个基础上长出来的。技术选型上我建议用你团队最熟悉的语言和框架不要为了“先进”去选不熟的技术。网关本身是个 IO 密集型服务性能瓶颈通常在网络和模型响应不在网关本身所以语言性能差异没那么重要可维护性才是关键。4.2 路由策略的渐进式演进路由策略不要一开始就设计得很复杂。我的演进路径是这样的第一阶段硬编码哪个任务用哪个模型写死在代码里第二阶段配置化规则抽到配置文件第三阶段动态化根据实时延迟和成本自动调整。大部分团队到第二阶段就够了。第三阶段需要收集足够的运行时数据还要防止策略震荡比如两个模型来回切换导致不稳定实现成本不低。我目前也只在少数几个对延迟特别敏感的场景用了动态路由。一个实用的中间方案是“带权重的静态路由”给主模型配 90% 流量备用模型配 10% 流量。这样既能保证主模型出问题时备用模型是热的不是冷启动又能持续收集备用模型的表现数据。4.3 Agent 链路的控制要点Agent 的控制面比普通多模型调用要复杂因为它是循环的、有状态的。我在 Agent 控制上总结了几个必须有的机制。第一个是最大步数限制。不管任务多复杂超过 N 步就强制终止并返回当前结果。这个 N 要根据任务类型设我一般设 15 到 20 步。第二个是单步超时每一步模型调用或工具调用都有独立超时避免某一步卡死拖垮整个任务。第三个是循环检测如果连续几步的输入输出高度相似判定为陷入循环强制中断。第四个是中间状态持久化Agent 跑到一半失败了能从最近的检查点恢复而不是从头再来。这几个机制听起来简单但每一个都是我在实际项目里被坑出来的。尤其是循环检测没有它的时候一个写错的提示词能让 Agent 无限循环直到烧完额度。4.4 灰度与回滚机制换模型是件高风险的事。我见过太多“新模型上线后效果反而变差”的案例。所以控制面里必须有灰度能力新模型先接 5% 流量观察一段时间的关键指标准确率、延迟、成本、错误率没问题再逐步放量。灰度期间要重点看什么我的经验是看三类指标业务指标任务完成率、用户满意度、技术指标延迟、错误率、成本指标单次成本、总成本。三类都达标才放量任何一类异常就回滚。回滚要能做到秒级所以模型版本和配置都要支持热切换。5. 常见问题与排查实录5.1 模型返回格式不稳定怎么办这是多模型场景下最常见的问题。不同模型对同一个提示词的输出格式可能完全不同有的返回 JSON有的返回带 markdown 代码块的 JSON有的干脆返回一段自然语言。如果你的下游代码强依赖某种格式换个模型就崩。我的解法是在网关层做输出规范化。定义一个统一的输出 schema网关收到模型响应后先尝试解析解析失败就调用一个轻量的“格式修复”模型或者用规则做兜底转换。这样下游代码只面对一种格式换模型无感知。当然格式修复本身也有失败率所以还要有“修复失败就返回原始内容并标记”的降级路径。5.2 某个模型突然变慢或不可用模型服务不是 100% 可靠的尤其是第三方 API。我遇到过某模型在高峰期延迟从 1 秒涨到 15 秒的情况也遇到过整个区域不可用的情况。应对这类问题控制面要有健康检查和自动熔断。具体做法是持续探测每个模型的健康状态可以用真实流量的成功率也可以用专门的探测请求连续失败或延迟超标就自动熔断把流量切到备用模型。熔断后要定期探测恢复情况恢复了再切回来。这套机制我实测下来能把模型故障对业务的影响从“分钟级”降到“秒级”。5.3 成本失控的几种典型场景成本失控我总结了几种典型场景。第一种是 Agent 循环前面说过。第二种是缓存失效本来该命中缓存的请求因为参数微小差异没命中全部打到模型。第三种是重试风暴一个请求失败后疯狂重试重试又失败又重试。第四种是提示词膨胀随着功能迭代提示词越来越长token 数悄悄涨了好几倍。对应的解法循环用步数限制缓存用规范化后的参数做 key重试用指数退避加最大次数提示词定期做精简审查。这四条我都在网关里做了强制约束不依赖开发者自觉。5.4 排查速查表现象可能原因排查方向处理方式任务卡住不返回Agent 循环或单步超时未设查看 trace 里最后一步加步数限制和超时成本突然飙升缓存失效或重试风暴看单位时间调用量检查缓存 key 和重试策略换模型后效果变差提示词未适配新模型对比新旧模型输出灰度放量不行就回滚延迟忽高忽低模型服务不稳定看 P99 延迟曲线启用熔断和 fallback输出格式解析失败模型返回格式变化看原始响应网关层做格式规范化6. 我对控制面时代的一点判断做了这么多项目我越来越觉得AI 系统的竞争力正在从“模型有多强”转移到“系统有多稳”。模型是买得到的但一套能管住多模型、管住 Agent、管住成本、管住故障的控制面是买不到的只能自己一点点搭出来。这个转向对开发者的要求也变了。以前会调 API 就能做 AI 应用现在要懂路由、懂熔断、懂可观测性、懂成本控制。这些能力听起来更像后端工程师的活但确实就是现在做 AI 落地必须补的课。我自己也是从“只会写提示词”一步步被逼着学这些的。如果你现在正在做多模型或者 Agent 项目我的建议是尽早把控制面这件事提上日程。不用一步到位但至少先把网关和可观测性搭起来。这两样东西越早做后面省的事越多。等到系统复杂到一定程度再补成本会高得多。
