为什么你的 AI Agent 不应只依赖单一供应商
Source: Dev.to
请提供您希望翻译的完整文本内容，我将按照要求保留源链接并将正文翻译为简体中文。
设置
我使用 OpenClaw 作为我的持久化 AI 代理。它负责研究、内容起草、代码审查、计划检查以及一系列自动化任务。过去一个月里，我构建了一个相当复杂的系统：
- 14 个在不同间隔运行的 cron 任务
- 一个 brain‑as‑router 架构，中心模型将任务委派给专门的子代理
- 一个充满记忆文件的工作区，使代理在会话之间保持连续性
所有这些都指向同一个提供商。
我知道这存在风险。 “为提供商独立性而设计” 在我的待办事项上，但系统运行得太顺畅，以至于迁移一直被推迟到 next week。经典。
真相时刻
当供应商停止支持时，我只有三天的时间窗口来迁移。实际的切换只用了一个下午——不是因为我很快，而是因为架构本身已经正确。
OpenClaw 将模型与系统分离：
- 模型在
openclaw.json中配置。 - Cron 任务通过参数指定使用哪个模型。
- 子代理在生成时接受模型参数。
提示、记忆文件、工作流定义和工具配置都不关心运行它们的具体模型。
因此迁移主要是：
- 在 OpenClaw 的配置中更改模型名称。
- 更新 cron 负载。
- 重启网关。
完成。
恐慌并不是因为迁移本身，而是因为在需要时之前没有进行过测试。
实际会出现的问题
当你更换供应商时，显而易见的变化是模型本身。但还有一些细微之处可能会让你陷入困境。
| 问题 | 需要注意的事项 |
|---|---|
| 思考模式工作方式不同 | 某些供应商可能将“扩展思考”以可见的流形式呈现；而另一些则在内部处理推理。相同的提示可能产生不同的行为，因为模型基于不同的训练来解释指令。 |
| 工具调用约定各不相同 | 函数调用语法、错误处理和结果报告没有统一标准。在一个模型上运行完美的子代理，可能在另一个模型上卡住（例如，我在新供应商上的第一个子代理在连接中断后卡住了 21 分钟）。 |
| 速率限制和定价会改变你的成本模型 | 从无限订阅转为按 token 计费，迫使你重新考虑哪些任务真的需要高级模型，哪些可以使用更便宜的替代方案。 |
| 上下文窗口大小不同 | 从 20 万 token 增加到 100 万 token 听起来是纯粹的优势，但这会改变压缩触发的时机、模型看到的历史量以及你的内存管理方式。如果你的压缩策略是为较小窗口调优的，更多并不一定更好。 |
救我于危难的架构
将模型视为配置，而非代码
在 OpenClaw 中，默认模型只在 openclaw.json 中出现一次。其余所有地方都间接引用它。更改主模型后，下一次运行时所有会话、定时任务和子代理都会自动使用新模型。
// openclaw.json
{
"agents": {
"defaults": {
"model": "google/gemini-2.5-pro",
"thinking": "low"
}
}
}只需一行。更新提供商，重启网关，所有组件都会采用新的默认模型。如果你的模型硬编码在提示模板、散落于定时任务定义，或写进了部署脚本中，你就会遇到麻烦。
备用模型链
OpenClaw 允许你配置主模型以及一系列备用模型。如果主模型失效（速率限制、宕机、认证错误），系统会自动尝试下一个模型。
// openclaw.json
{
"agents": {
"defaults": {
"model": "google/gemini-2.5-pro",
"fallbackModels": [
"google/gemini-3.1-pro-preview",
"google/gemini-2.5-flash"
]
}
}
}主模型处理普通请求。如果触发速率限制或返回错误，OpenClaw 会自动使用链中的下一个模型。你甚至可以把之前的提供商放在备用列表的最后，作为最后的后备，只要你仍然有访问权限。
这不仅适用于迁移；还能提升日常可靠性。提供商 API 宕机、速率限制被触发——备用模型链让你的代理保持运行。
基于任务的路由
并非所有任务都需要最强的模型。我最终使用了三层模型：
| 层级 | 角色 |
|---|---|
| Brain | 稳定的中等模型，负责对话和路由决策 |
| Heavy‑lift | 高能力模型，用于编码任务和复杂分析 |
| Light‑weight | 低成本、快速模型，用于通知、格式化和简单生成 |
Brain 决定任务需要哪个层级，然后在相应的模型上生成子代理。在 OpenClaw 中，定时任务和子代理可以直接接受 model 参数：
// Cron job — 在低成本模型上运行
{
"label": "morning-news",
"schedule": "0 9 * * *",
"model": "google/gemini-2.5-flash",
"thinking": "off",
"task": "Deliver today's top 5 news items"
}// 子代理生成示例
{
"name": "code-reviewer",
"model": "google/gemini-3.1-pro-preview",
"task": "Review the pull request and suggest improvements"
}要点
- 将模型视为配置值，而不是硬编码常量。
- 构建回退链，以应对中断和速率限制。
- 按能力路由任务，只为所需的算力付费。
有了这三个设计决策，本来可能需要一周才能修复的提供商停机，变成了下午即可解决的修复。如果你正在构建持久化的 AI 代理，请从第一天起就在架构中加入提供商独立性。
Cron job — 在昂贵模型上运行
{
"label": "weekly-review",
"schedule": "0 18 * * 5",
"model": "google/gemini-2.5-pro",
"thinking": "medium",
"task": "Run the weekly strategic review"
}我会做的不同之处
如果可以回到过去，我会从第一天起做三件事。
-
在需要之前测试故障转移。
每月一次，临时将主模型切换到备用模型并运行系统数小时。你会在还有时间修复时发现细微的不兼容问题。 -
保留迁移检查清单。
不是计划——而是清单。这样在提供商宣布重大变更时，你可以在压力下执行。我的清单有 15 项。我真希望在时间紧迫之前就写好它。 -
跟踪你的 cron 任务实际需要的模型。
每季度审计一次。你几乎肯定会发现有任务在使用昂贵的模型运行，而实际上可以在更便宜的模型上运行。
真正的教训
提供商独立性并不是出于不信任。我喜欢我的旧提供商——模型很棒，开发者体验也很顺畅。但公司会改变定价、停止平台支持、转变战略，或者在 API 故障数小时的糟糕日子里出现问题。
你的提示、你的上下文文件、你的工作流定义、你的记忆系统——这些才是你的真正资产。模型是堆栈中最容易替换的部分。要把它当作可随时更换来构建。
这次迁移让我清晰地看到了自己的系统。说实话，现在的情况更好：多个模型，各自发挥所长，并且在任意单一模型宕机时自动切换。这不是妥协，而是升级。
如果你今天正在运行一个 AI 代理，并且在某一家提供商上运行得很顺利，那真是太棒了。现在去测试一下当它不顺利时会怎样。
这是一系列关于模型迁移和多模型架构的第 1 部分。接下来：如何设置基于任务的路由，让不同模型处理不同类型的工作。
你经历过提供商迁移吗？有什么让你感到意外的？我真的很想听听，尤其是如果你发现了我还没遇到的坑。