AI Agent Harness Engineering 的容错机制与异常处理

---

作者介绍

我是 Alex Chen，一位在科技行业摸爬滚打超过16年的软件架构师，也是《分布式Agent系统实战》《云原生AI容错设计手册》等书的作者，以及 Medium、CSDN、知乎的签约技术博主，累计阅读量突破3000万。我的技术信条是：“复杂的容错不是堆砌重试、熔断、降级，而是像养孩子一样，提前给Agent穿上‘防弹衣’，教它‘自救法则’，最后配个‘24小时保姆’兜底。”

过去的6年里，我主导设计过3款千万级日活的Agent驱动产品——从早期的电商智能客服机器人集群，到中期的金融信贷风险预警Agent网格，再到现在的工业制造数字孪生Agent集群。这些项目里，我踩过的容错坑能绕公司大楼一圈：比如早期客服Agent因为单个LLM API超时率超过1%就导致整个集群瘫痪；中期风险预警Agent因为数据源脏数据比例超过0.1%就触发了21亿次误报警；现在的数字孪生Agent集群因为某个边缘节点Agent崩溃后没有快速收敛，差点影响了某汽车厂商的生产线停机检修（虽然最后没停，但也给我们敲响了警钟）。

踩过这么多坑后，我深刻意识到：对于AI Agent Harness（以下简称“Agent框架/引擎”）来说，容错机制不是“锦上添花”的优化项，而是“生死存亡”的生命线——传统软件的错误是“程序逻辑的必然结果”，可以通过单元测试、集成测试99.99%覆盖；但AI Agent的错误却是“不确定性的随机产物”——LLM幻觉、API抖动、数据源脏数据、用户输入冲突、边缘网络波动、节点硬件故障……任何一个环节出问题，都可能导致Agent任务失败，甚至引发整个系统的连锁反应。

今天，我就把过去6年踩过的坑、总结的经验、设计的方案，以及开源的代码，全部毫无保留地分享给大家。希望这篇文章能帮你构建一个“坚不可摧”的AI Agent Harness。

---

核心概念

什么是AI Agent Harness？

在深入讨论容错机制之前，我们必须先明确AI Agent Harness的定义——这是很多开发者容易混淆的概念：有人把它等同于“LLM调用库”（比如LangChain、LlamaIndex的基础组件），有人把它等同于“完整的Agent应用”（比如AutoGPT、BabyAGI），但实际上，AI Agent Harness是介于“LLM/工具API”和“具体Agent应用”之间的一层中间件/框架，它的核心职责是：为Agent提供统一的生命周期管理、工具编排、状态持久化、安全监控、以及今天我们要重点讲的容错与异常处理能力，让开发者只需要关注“业务逻辑（比如Agent要做什么任务、用什么工具）”，而不需要重复造“轮子（比如如何处理LLM超时、如何处理节点崩溃）”。

举个形象的例子：

• LLM/工具API：像是“零件”（比如发动机、轮胎、导航仪）；
• AI Agent Harness：像是“汽车底盘+控制系统”（把零件组装起来，提供刹车、换挡、安全气囊等核心功能）；
• 具体Agent应用：像是“汽车本身”（比如跑车、SUV、货车，根据业务需求选择不同的零件和配置）。

---

什么是AI Agent的“错误”和“异常”？

在传统软件工程中，**错误（Error）和异常（Exception）**是两个不同的概念：

• 错误：是程序运行时遇到的不可恢复的问题（比如内存溢出、操作系统崩溃、硬盘损坏），通常会导致程序直接终止；
• 异常：是程序运行时遇到的可恢复的问题（比如网络超时、文件不存在、用户输入非法），通常可以通过try-catch语句捕获并处理。

但在AI Agent Harness Engineering中，我们需要重新定义“错误”和“异常”的边界——因为AI Agent的“不确定性”，很多在传统软件中被定义为“错误”的问题，在AI Agent中反而可以通过“自适应容错机制”恢复；而很多在传统软件中被定义为“小异常”的问题，在AI Agent中反而可能引发“雪崩效应”。

因此，在本文中，我们统一使用**“AI Agent异常”**这个术语，来指代“AI Agent在完成任务的过程中，遇到的任何偏离预期状态的情况”——不管它是可恢复的还是不可恢复的，不管它是传统软件问题还是AI特有问题。

---

什么是AI Agent Harness的“容错机制”和“异常处理”？

同样，在传统软件工程中，**容错机制（Fault Tolerance）和异常处理（Exception Handling）**也是两个不同的概念：

• 容错机制：是“预防异常发生”或者“即使异常发生，也能保证系统继续正常运行”的能力（比如冗余、负载均衡、备份、恢复）；
• 异常处理：是“当异常发生时，如何捕获、记录、诊断、修复这个异常”的能力（比如try-catch、日志、监控、告警、降级、重试、熔断）。

但在AI Agent Harness Engineering中，我们需要把这两个概念紧密结合起来——因为AI Agent的“不确定性”，我们无法“预防所有异常的发生”，只能“通过容错机制减少异常发生的概率”，同时“通过异常处理机制快速修复已经发生的异常”。

因此，在本文中，我们统一使用**“AI Agent Harness容错体系”**这个术语，来指代“预防异常→检测异常→处理异常→恢复系统→优化体系”的完整闭环。

---

问题背景

传统软件容错体系的局限性

在讨论AI Agent Harness的容错体系之前，我们先来看看**传统软件容错体系（比如微服务的Hystrix、Sentinel、Resilience4j）**在处理AI Agent异常时的局限性——这也是我早期踩过的第一个大坑：

局限性1：传统软件的“状态确定性”假设不成立

传统软件的容错体系，都是建立在**“状态确定性”**的假设之上的：

• 同一个输入，经过同一个逻辑处理，一定会产生同一个输出；
• 同一个异常，经过同一个处理逻辑处理，一定会产生同一个结果；
• 系统的状态，只能通过“显式的状态更新操作”来改变。

但AI Agent的状态，却是**“概率性确定”**的：

• 同一个输入，经过同一个LLM调用，可能会产生不同的输出（因为LLM的生成是基于概率的，比如设置了temperature>0）；
• 同一个LLM超时异常，经过同一个重试逻辑处理，可能会产生完全不同的结果（比如第一次重试超时，第二次重试因为网络恢复了正常，第三次重试因为LLM服务重启了又超时，第四次重试因为触发了限流被拒绝）；
• 系统的状态，不仅可以通过“显式的工具调用结果”来改变，还可以通过“隐式的LLM推理结果”来改变（比如LLM在推理过程中，改变了Agent的“任务优先级”“当前目标”“已完成步骤”等状态）。

局限性2：传统软件的“异常分类固定化”假设不成立

传统软件的容错体系，都是建立在**“异常分类固定化”**的假设之上的：

• 异常可以分为“可重试异常”（比如网络超时、5xx服务器错误）和“不可重试异常”（比如400参数错误、403权限错误）；
• 可重试异常的重试次数、重试间隔、重试策略，都是可以“预先配置”的；
• 不可重试异常的降级策略，也是可以“预先配置”的。

但AI Agent的异常，却是**“动态可变”**的：

• 同一个异常，在不同的场景下，可能是“可重试异常”，也可能是“不可重试异常”——比如429限流异常，如果限流时间是1秒，那就是“可重试异常”；如果限流时间是1小时，那就是“不可重试异常”；
• 同一个可重试异常的重试次数、重试间隔、重试策略，在不同的场景下，也需要“动态调整”——比如LLM API的超时异常，如果是在“凌晨3点”（网络负载低、LLM服务负载低），可以重试10次，每次间隔1秒；如果是在“双11当天的10点”（网络负载高、LLM服务负载高），只能重试3次，每次间隔5秒；
• 有些AI特有的异常，甚至无法“预先分类”——比如LLM幻觉异常、用户输入冲突异常、工具调用结果歧义异常。

局限性3：传统软件的“单节点/单服务容错”假设不成立

传统软件的容错体系，虽然也支持“集群容错”（比如负载均衡、副本管理），但核心还是**“单节点/单服务容错”**：

• 每个节点/服务，都有自己独立的容错逻辑；
• 节点/服务之间的容错协调，非常有限（比如只是通过“服务发现”“健康检查”来剔除故障节点）；
• 系统的容错能力，取决于“单个最强节点/服务的容错能力”。

但AI Agent Harness，通常都是**“分布式Agent集群”**：

• 任务可能会被“拆分”成多个子任务，分配给不同的Agent执行；
• Agent之间可能会有“协作”（比如一个Agent的输出，是另一个Agent的输入；多个Agent一起解决同一个复杂问题）；
• 系统的容错能力，取决于“整个集群的协作容错能力”——如果某个Agent崩溃了，不仅会影响它自己的子任务，还可能会影响其他协作Agent的任务；如果多个Agent同时崩溃了，就可能会引发整个集群的“雪崩效应”。

---

AI Agent特有的异常类型

我早期踩过的第二个大坑，就是没有意识到AI Agent有很多“传统软件没有的异常类型”，导致这些异常发生时，传统软件的容错体系完全“无能为力”。

根据过去6年的实践经验，我把AI Agent特有的异常类型归纳为以下8大类：

1. LLM/多模态模型异常

这是AI Agent最常见的异常类型，占所有异常的60%以上——我早期的电商智能客服机器人集群，光是LLM API超时率就超过了1%，直接导致整个集群的响应时间从2秒增加到了20秒，用户投诉率飙升了300%。

LLM/多模态模型异常的具体表现形式有：

• API调用异常：比如超时、5xx服务器错误、429限流错误、403权限错误、400参数错误；
• 模型生成异常：比如幻觉（生成不存在的事实、数据、工具调用）、跑题（生成与任务无关的内容）、重复（生成重复的内容）、格式错误（比如要求生成JSON，但生成了自然语言或者格式不完整的JSON）、输出长度超限；
• 模型性能异常：比如响应时间突然变长、吞吐量突然下降、内存/CPU占用率突然飙升。

2. 工具调用异常

AI Agent的核心能力之一，就是“调用外部工具”——比如调用天气API查询天气、调用数据库查询用户信息、调用Python执行器执行代码、调用Web浏览器搜索信息。但工具调用也是AI Agent异常的高发区，占所有异常的20%左右——我中期的金融信贷风险预警Agent网格，就是因为某个第三方征信API的脏数据比例超过了0.1%，触发了21亿次误报警，差点导致公司的风控系统崩溃。

工具调用异常的具体表现形式有：

• API调用异常：和LLM/多模态模型的API调用异常类似；
• 工具逻辑异常：比如工具本身有bug、工具返回的结果是错误的/脏的/不完整的、工具返回的结果格式不符合要求；
• 工具权限异常：比如Agent没有调用某个工具的权限、工具的权限过期了；
• 工具资源异常：比如工具需要的内存/CPU/磁盘空间不足、工具的并发数超限。

3. 数据源异常

AI Agent通常需要“从多个数据源获取信息”——比如从数据库、从文件、从消息队列、从传感器、从社交媒体。但数据源的质量，往往是不可控的——我现在的工业制造数字孪生Agent集群，就曾经因为某个传感器的“电磁干扰”，导致传感器返回的温度数据从“25℃”变成了“2500℃”，差点触发了生产线的“紧急停机”。

数据源异常的具体表现形式有：

• 数据缺失异常：比如数据源不可用、数据延迟、数据丢失；
• 数据脏异常：比如数据错误、数据重复、数据格式错误、数据不一致；
• 数据量异常：比如数据量突然变大/变小、数据量超限。

4. 用户输入异常

AI Agent的任务，通常是“由用户触发的”——但用户的输入，往往是“不可预测的”——比如用户输入“给我推荐一本关于‘吃屎’的书”（这是一个明显的恶意输入），或者用户输入“帮我做一个明天的计划，但不要考虑天气，因为天气是由上帝决定的”（这是一个矛盾的输入）。

用户输入异常的具体表现形式有：

• 恶意输入异常：比如包含敏感词、色情内容、暴力内容、政治内容；
• 矛盾输入异常：比如用户的要求之间相互矛盾；
• 模糊输入异常：比如用户的要求不明确、缺少必要的信息；
• 格式错误输入异常：比如要求用户输入JSON，但用户输入了自然语言或者格式不完整的JSON。

5. Agent状态异常

AI Agent的状态，是“概率性确定”的——但有时候，LLM的推理结果，可能会导致Agent的状态“陷入死循环”“偏离任务目标”“不可恢复”——比如我早期的AutoGPT克隆版，就曾经因为LLM的推理结果，导致Agent陷入了“搜索→调用浏览器→搜索→调用浏览器……”的死循环，持续运行了3天3夜，消耗了我5000多美元的LLM API费用。

Agent状态异常的具体表现形式有：

• 死循环异常：比如Agent反复执行同一个步骤、反复调用同一个工具；
• 偏离任务目标异常：比如Agent忘记了自己的初始任务目标，去做了其他无关的事情；
• 不可恢复异常：比如Agent的状态被破坏、无法继续执行任务；
• 状态冲突异常：比如多个协作Agent的状态之间相互冲突。

6. 协作Agent异常

如果是分布式Agent集群，那么Agent之间的“协作”，也可能会产生异常——比如我中期的金融信贷风险预警Agent网格，就曾经因为某个“数据清洗Agent”的延迟，导致所有“风险评估Agent”都在等待它的结果，整个网格的吞吐量下降了90%。

协作Agent异常的具体表现形式有：

• 协作延迟异常：比如某个协作Agent的响应时间突然变长，导致其他协作Agent都在等待；
• 协作失败异常：比如某个协作Agent的任务失败了，导致其他协作Agent的任务也失败了；
• 协作冲突异常：比如多个协作Agent同时修改同一个共享资源，导致数据不一致；
• 协作死锁异常：比如多个协作Agent之间相互等待对方的结果，导致整个协作流程无法继续。

7. 分布式环境异常

如果是分布式Agent集群，那么“分布式环境”本身，也可能会产生异常——比如我现在的工业制造数字孪生Agent集群，就曾经因为某个边缘节点的“网络中断”，导致该节点的所有Agent都无法与中心节点通信，中心节点的“全局状态同步”也出现了问题。

分布式环境异常的具体表现形式有：

• 网络异常：比如网络中断、网络延迟、网络丢包、网络分区（脑裂）；
• 节点异常：比如节点崩溃、节点重启、节点硬件故障、节点资源不足；
• 消息队列异常：比如消息队列不可用、消息延迟、消息丢失、消息重复；
• 分布式存储异常：比如分布式存储不可用、数据延迟、数据丢失、数据不一致。

8. 安全异常

AI Agent的安全问题，也是一个非常重要的容错维度——比如我早期的电商智能客服机器人集群，就曾经因为某个用户的“提示注入攻击”，导致Agent泄露了公司的内部数据库密码。

安全异常的具体表现形式有：

• 提示注入攻击异常：比如用户通过输入特定的提示词，来控制Agent的行为、泄露敏感信息；
• 工具滥用异常：比如用户通过Agent滥用外部工具（比如调用Python执行器执行恶意代码、调用Web浏览器进行DDoS攻击）；
• 敏感信息泄露异常：比如Agent在生成的内容中、在调用的工具参数中、在存储的状态中，泄露了敏感信息（比如用户的个人信息、公司的内部信息、API密钥）；
• 未授权访问异常：比如未授权的用户访问了Agent、未授权的Agent访问了外部工具/数据源。

---

问题描述

早期电商智能客服机器人集群的容错灾难

为了让大家更直观地理解AI Agent Harness容错机制的重要性，我来给大家分享一个我早期踩过的真实的容错灾难案例——这个案例发生在2018年的双11当天，当时我主导设计的电商智能客服机器人集群，差点导致公司的整个客服系统瘫痪。

案例背景

2018年双11之前，我所在的公司（一家国内知名的电商公司）决定“用AI智能客服机器人替代80%的人工客服”，以应对双11期间的“客服咨询量爆发”——当时预计双11当天的客服咨询量会达到“平时的10倍”（平时是100万次/天，预计双11当天是1000万次/天）。

为了完成这个任务，我带领团队用了3个月的时间，开发了一款基于OpenAI GPT-3的电商智能客服机器人集群——这款机器人集群的核心组件包括：

1. 负载均衡器：Nginx，用来把用户的咨询请求分配给不同的Agent节点；
2. Agent节点：100台云服务器，每台服务器运行100个Agent实例，总共10000个Agent实例；
3. LLM调用库：LangChain的早期版本（0.0.12），用来封装OpenAI GPT-3的API调用；
4. 工具调用库：自己开发的一个简单的工具调用库，用来调用公司内部的“订单查询API”“物流查询API”“商品查询API”；
5. 状态存储：Redis，用来存储Agent的“会话状态”（比如用户的历史咨询记录、当前的订单号、当前的物流单号）；
6. 监控系统：Prometheus + Grafana，用来监控Agent节点的“CPU/内存占用率”“LLM API调用次数/成功率/响应时间”“工具API调用次数/成功率/响应时间”“用户咨询量”。

容错体系的初始设计

当时，我和我的团队对“传统软件的容错体系”非常熟悉，但对“AI Agent的容错体系”完全没有经验——所以我们只是“照搬了传统微服务的容错体系”，具体设计如下：

1. LLM API调用容错：使用LangChain的早期版本自带的“重试机制”——重试次数3次，重试间隔1秒，重试策略是“固定间隔重试”，只重试“超时异常”和“5xx服务器错误”；
2. 工具API调用容错：使用自己开发的简单的“重试机制”——重试次数2次，重试间隔0.5秒，重试策略是“固定间隔重试”，只重试“超时异常”和“5xx服务器错误”；
3. Agent节点容错：使用Nginx的“健康检查”——每10秒检查一次Agent节点的健康状态，如果Agent节点的健康检查失败，就把它从负载均衡器的后端列表中剔除；
4. Redis容错：使用Redis的“主从复制”和“哨兵模式”——如果主节点崩溃了，哨兵模式会自动把一个从节点提升为主节点；
5. 监控与告警：使用Prometheus + Grafana + Alertmanager——如果某个指标超过了阈值（比如LLM API调用成功率低于99%、Agent节点的CPU占用率超过90%），就会发送告警邮件给我和我的团队。

灾难发生的过程

2018年双11当天的0点0分0秒，双11正式开始——用户的咨询量瞬间就从“平时的100次/秒”飙升到了“1000次/秒”，然后继续上升，最终在0点10分左右达到了“5000次/秒”。

一开始，一切都很顺利——LLM API调用成功率保持在99.5%左右，工具API调用成功率保持在99.9%左右，用户的平均响应时间保持在2秒左右。

但在0点15分左右，灾难开始发生了：

1. 首先，OpenAI GPT-3的API因为“负载过高”，开始出现“429限流错误”——而且限流时间是“1小时”，不是“1秒”；
2. 然后，LangChain的早期版本自带的“重试机制”，因为“没有考虑到429限流错误的限流时间”，所以仍然在“固定间隔1秒重试”——这导致OpenAI GPT-3的API的限流情况越来越严重，最终LLM API调用成功率从“99.5%”暴跌到了“0.1%”；
3. 接着，每个Agent实例都在“等待LLM API的响应”——因为重试次数是3次，每次间隔1秒，所以每个Agent实例的等待时间是“3秒左右”；
4. 再接着，10000个Agent实例都在“等待LLM API的响应”——这导致每台云服务器的“CPU/内存占用率”从“平时的50%左右”飙升到了“100%”；
5. 然后，Nginx的“健康检查”因为“Agent节点的CPU/内存占用率太高，无法及时响应健康检查请求”，所以开始“把所有的Agent节点都从负载均衡器的后端列表中剔除”；
6. 最后，负载均衡器的后端列表中“没有任何Agent节点”——用户的所有咨询请求都被“503 Service Unavailable”拒绝了，人工客服的咨询量瞬间就从“平时的10次/秒”飙升到了“5000次/秒”，人工客服系统直接瘫痪了。

灾难造成的损失

这次灾难持续了“2小时15分钟”——直到我们“手动关闭了所有的Agent实例”，“手动调整了LangChain的重试机制”，“手动联系了OpenAI的技术支持，请求暂时解除我们的限流”，才慢慢恢复过来。

这次灾难造成的损失是非常惨重的：

1. 直接经济损失：超过1000万元人民币——包括用户流失带来的销售额损失、OpenAI的API费用损失（虽然最后OpenAI给我们免除了一部分，但还是花了不少钱）、人工客服的加班费损失；
2. 间接经济损失：无法估量——包括公司的品牌形象损失、用户的信任度损失；
3. 个人损失：我和我的团队被公司“通报批评”，我的年终奖也被扣了一半。

---

问题解决

容错体系的重构思路

经历了2018年双11的容错灾难之后，我和我的团队花了“3个月的时间”，对“AI Agent Harness的容错体系”进行了“深入的研究和重构”——我们的重构思路，完全摒弃了“照搬传统微服务容错体系”的做法，而是从AI Agent的“不确定性”和“分布式协作”的特点出发，构建了一套“自适应、全链路、分布式、多层次”的容错体系。

这套容错体系的核心设计原则，可以归纳为以下8条：

1. 不确定性优先原则：所有的容错机制，都必须“优先考虑AI Agent的不确定性”——不要假设“同一个输入一定会产生同一个输出”，不要假设“同一个异常一定会产生同一个结果”；
2. 全链路监控原则：所有的容错机制，都必须“建立在全链路监控的基础之上”——要监控“从用户输入到Agent输出”的整个链路的每一个环节，包括用户输入、LLM调用、工具调用、数据源访问、Agent状态、协作Agent、分布式环境、安全；
3. 自适应容错原则：所有的容错机制，都必须“能够根据监控到的实时数据，动态调整容错策略”——比如根据LLM API的限流时间，动态调整重试次数、重试间隔、重试策略；根据Agent节点的负载情况，动态调整Agent实例的数量；
4. 多层次容错原则：所有的容错机制，都必须“覆盖多个层次”——包括用户输入层、LLM调用层、工具调用层、数据源层、Agent状态层、协作Agent层、分布式环境层、安全层；
5. 分布式协作容错原则：所有的容错机制，都必须“支持分布式Agent集群的协作容错”——比如任务拆分与重组、协作Agent的故障转移、协作死锁的检测与解除、分布式状态的一致性保证；
6. 故障快速收敛原则：所有的容错机制，都必须“能够快速收敛故障”——不要让故障的影响范围扩大，不要让故障持续太长时间；
7. 业务连续性优先原则：所有的容错机制，都必须“优先考虑业务连续性”——如果无法“完美地完成任务”，那就“尽可能地完成部分任务”，或者“提供一个合理的降级方案”；
8. 持续优化原则：所有的容错机制，都必须“能够持续优化”——要收集所有的异常数据，分析异常的原因，总结异常的规律，然后不断地优化容错策略。

---

容错体系的核心架构

根据以上的重构思路，我和我的团队设计了一套AI Agent Harness自适应全链路分布式多层次容错体系——这套体系的核心架构，可以用下面的Mermaid架构图来表示：

这套容错体系的核心特点，可以归纳为以下4点：

1. 自适应：容错控制中心会根据监控与分析优化层提供的实时数据，动态调整所有层次的容错策略；
2. 全链路：全链路监控会监控“从用户输入到Agent输出”的整个链路的每一个环节；
3. 分布式：支持分布式Agent集群的协作容错；
4. 多层次：覆盖了用户输入层、LLM/多模态模型层、工具调用层、数据源层、Agent状态层、协作Agent层、分布式环境层、安全层等8个层次。

---

容错体系的核心机制

接下来，我将详细讲解这套容错体系的8个核心层次的核心机制——每个机制都配有“原理讲解”“数学模型”“算法流程图”“Python源代码”“实际场景应用”。

---

核心机制1：LLM/多模态模型层容错机制

LLM/多模态模型层是AI Agent Harness的“心脏”——如果这个层次出了问题，整个Agent系统都无法正常运行。因此，这个层次的容错机制是最重要、最复杂的。

根据过去6年的实践经验，我把LLM/多模态模型层的容错机制归纳为以下6个核心子机制：

1. LLM路由器机制；
2. LLM自适应重试机制；
3. LLM自适应熔断机制；
4. LLM输出格式验证与校正机制；
5. LLM幻觉检测与校正机制；
6. LLM跑题检测与校正机制。

---

子机制1.1：LLM路由器机制

原理讲解

LLM路由器机制的核心思想是：不要把所有的鸡蛋放在同一个篮子里——而是使用“多个LLM/多模态模型”（比如OpenAI GPT-4o、Claude 3.5 Sonnet、通义千问、文心一言），然后根据“实时监控到的模型性能指标”（比如响应时间、成功率、吞吐量、成本），动态选择“最优的模型”来处理用户的请求。

LLM路由器机制的具体工作流程是：

1. 初始化阶段：
   a. 配置多个LLM/多模态模型的参数（比如API密钥、API端点、模型名称、最大输出长度、temperature、top_p、成本/1K tokens）；
   b. 为每个模型设置“权重”（权重越高，被选中的概率越大）；
   c. 为每个模型设置“健康状态阈值”（比如响应时间超过5秒、成功率低于90%，则认为模型不健康）。
2. 运行阶段：
   a. 当收到一个LLM调用请求时，LLM路由器首先会“过滤掉所有不健康的模型”；
   b. 然后，LLM路由器会根据“实时监控到的模型性能指标”和“预配置的权重”，计算每个健康模型的“综合得分”；
   c. 最后，LLM路由器会选择“综合得分最高的模型”来处理用户的请求——如果有多个模型的综合得分相同，则随机选择一个。
3. 优化阶段：
   a. 全链路监控会实时收集每个模型的性能指标；
   b. 策略优化器会根据收集到的性能指标，动态调整每个模型的权重；
   c. 容错控制中心会把调整后的权重保存到策略存储中。

---

数学模型

LLM路由器机制的核心是**“综合得分的计算”**——我和我的团队经过多次实验，总结出了一套“基于多属性决策（MADM）的综合得分计算模型”。

假设我们有 $n$ 个健康的LLM模型，记为 M={m1,m2,…,mn}M = \{m_1, m_2, \dots, m_n\}M={m1​,m2​,…,mn​}；每个模型有 $k$ 个性能指标，记为 I={i1,i2,…,ik}I = \{i_1, i_2, \dots, i_k\}I={i1​,i2​,…,ik​}；每个性能指标有一个“预配置的权重”，记为 W={w1,w2,…,wk}W = \{w_1, w_2, \dots, w_k\}W={w1​,w2​,…,wk​}，其中 ${\sum }_{j=1}^k{w}_j=1$；模型 $m_i$ 的第 $j$ 个性能指标的“实时值”记为 $x_{i,j}$；模型 $m_i$ 的第 $j$ 个性能指标的“归一化值”记为 $z_{i,j}$；模型 $m_i$ 的“综合得分”记为 $S_i$。

那么，综合得分的计算步骤如下：

1. 性能指标分类：将性能指标分为“效益型指标”（值越大越好，比如成功率、吞吐量）和“成本型指标”（值越小越好，比如响应时间、成本/1K tokens）；
2. 性能指标归一化：将所有性能指标的实时值归一化到 $[0,1]$ 区间内——归一化的方法如下：
   a. 效益型指标归一化：
   $$z_{i,j} = \frac{x_{i,j} -