常驻Agent如何识别失效模型并切换

一个常驻 Agent 半夜停了，服务商却一直在线：接口可访问，配置里的模型早已退役。客户端把永久错误当成临时故障，每轮重试十二次，最终撞上重启上限，整晚没有恢复。

作者改造后的方案很朴素：每两小时探测免费路由，把结果写进文件；Agent 按排名选择线路，付费线路放在末尾；重试之前先判断错误能不能恢复。值得读的不是「免费模型清单」，而是怎样让一份不断过期的配置，少拖垮一个持续运行的程序。

路由应该跟着探测结果走

作者没有继续维护一张固定的免费模型表。免费额度、限流和模型供应都会变，公告里的可用状态，接进系统时未必还成立。

他们用 cron 每两小时扫描一次所有持有密钥的免费路由。探测重点也不是服务商能否连通，而是具体路由能否调用工具。对于需要执行动作的 Agent，一个能生成文字、却拒绝工具 schema 的模型，仍然不满足需求。

探测脚本给响应的路由排序，将结果写入映射文件。此后每一轮，Agent 都从文件顶部挑选，而不是坚持使用某个写死的主模型。

决定流量去向的，是最近一次探测结果，而不是几个月前的选型。

作者把这部分描述为 curl 脚本加少量配套逻辑，不需要 LLM 参与路由决策。不过，具体如何验证工具调用、如何排名，原文没有提供实现。两小时一次也只是更新频率，不能保证下一轮请求必然成功。

免费线路排前面，付费线路负责兜底

链构建器读取映射文件，再生成故障切换顺序：排名最高的可用免费线路在前，其余免费线路依次跟上，付费线路放到最后。

下面这段配置表达了费用控制的关键位置：

chain:
  - free-route-1   # whatever ranked first two hours ago
  - free-route-2
  - free-route-3
  - paid-route     # last resort; logged every time it fires

要看的是最后一行：paid-route 只在前面的线路无法承接请求时启用，而且每次触发都记录日志。

作者把付费线路当作每天少数重要轮次的安全网。如果它整天都在工作，作者会回头检查免费路由的实际表现和排名逻辑。

这里有一个实用思路：兜底日志也是检验主路径的证据。付费线路频繁触发，说明系统对免费线路的判断可能失真。

但标题里的「接近零成本」没有账单支撑。原文没有给出请求量、免费线路成功率、付费触发比例，也没计算维护时间。能确定的是成本控制方式，不能据此推算一般团队能省多少钱。

重试之前，先判断还有没有成功的可能

最初那次故障，模型 ID 返回 404，而端点仍返回 200。服务商没有整体宕机，客户端却把所有非 200 响应都按临时问题处理，退避、重试，直到耗尽机会。

作者在故障切换钩子里加了一个小插件，先给错误分类。遇到「模型已退役」「免费优惠结束」「模型 ID 不存在」，就标记为 do-not-retry，首次失败后直接切到下一条线路。

永久错误需要换路，临时错误才值得继续等待。

作者重新探测后发现，退役的通常只是某个模型，而不是整个服务商。同一端点、同一套认证，换一个模型字符串就可能恢复。这也是为什么探测对象应该细到路由。

他们仍把每轮重试预算设为十二次，但明确承认：这是配置值，不是测量得出的最佳答案。次数太少，短暂繁忙就可能触发 restart-limit-exceeded；次数太多，一条坏线路又可能耗掉整轮机会。

配置更新则采用等待当前轮次结束的重载方式：发送 SIGUSR1，让正在执行的任务完成，再切换配置并继续运行。作者最想避免的是故障时重启，以及随之而来的状态重建。原文没有给出这套信号处理的代码，不能把 SIGUSR1 当成任意 Agent 框架都支持的开关。

我的判断

我认可这套方案把问题拆成了三件事：路由是否满足任务要求、错误是否值得重试、更新配置是否需要打断任务。这些判断比单纯增加重试次数更有价值。

但它仍是作者的运维经验，没有改造前后的可用率、恢复耗时或成本对照。免费路由排名是否考虑延迟、工具参数准确性和回答质量，也没有说清。能接受工具 schema，只能证明一道门槛，不能证明复杂任务能可靠完成。

和固定付费主模型相比，这套方案增加了探测、排序和配置维护工作，换取更低的推理支出。适合愿意自己维护线路、能接受质量波动的个人项目；团队是否采用，还得看故障成本和维护投入。

另外，作者披露了自己使用的服务链接属于推荐返佣链接。这个利益关系不影响错误分类的工程逻辑，但服务推荐本身不能当成独立验证。

能拿来做什么

• 给 Node Agent 的模型调用层增加错误分类，把明确的模型退役、ID 不存在等错误直接交给下一条线路，并为暂时性故障保留有限重试。
• 为依赖工具调用的 AI 编程助手建立路由探测，至少验证任务需要的工具 schema，并记录探测时间，避免把历史成功当成当前可用。
• 如果采用免费优先的调用链，就记录每次付费兜底及其触发原因，用实际请求结果检查探测排名是否可信。
• 更新常驻 Agent 的配置时，先确认框架支持什么重载机制；若自行实现，就让当前轮次完成后再切换，减少重启造成的状态重建。