从Claude到GLM：AI应用模型迁移实战与架构解耦指南

在实际的 AI 应用开发中，模型选型与集成是决定项目成败和长期维护成本的关键环节。当核心业务逻辑严重依赖某个大模型 API 时，一旦该服务出现访问问题、成本飙升或策略调整，整个应用就可能陷入停滞。我们最近就经历了一次这样的架构迁移：将项目中核心的智能体（Agent）循环逻辑，从最初构建在 Anthropic Claude API 之上，完整地迁移到了智谱 AI 的 GLM 系列模型。这个过程远不止是更换一个 API 端点那么简单，它涉及到底层 SDK 的替换、提示词（Prompt）工程的调整、错误处理机制的适配，以及对响应格式的重新约定。本文将详细拆解这次迁移的技术细节、遇到的挑战以及最终的解决方案，旨在为面临类似模型切换或希望构建更健壮 AI 应用的开发者提供一份可复现的实战指南。

本文适合正在或计划使用大模型 API 构建应用的后端工程师、算法工程师以及全栈开发者。你将了解到如何系统性地评估和切换模型供应商，如何处理不同模型在上下文长度、思维链（Chain-of-Thought）格式、函数调用（Function Calling）等方面的差异，并最终构建一个对底层模型变化不敏感、更易于维护的智能体系统。

1. 理解 Agent Loops 的架构与模型依赖

在深入迁移细节之前，必须明确“Agent Loops”在我们的上下文中的具体含义。它并非指某个特定的开源框架，而是指一种应用模式：一个自主的、能够根据目标执行一系列推理和工具调用（如搜索、计算、代码执行）的循环程序。其核心通常包含一个大型语言模型（LLM），负责理解任务、规划步骤、评估结果并决定下一步行动。

1.1 典型 Agent Loop 的工作流程

一个简化的 Agent Loop 通常遵循以下模式：

1. 任务接收与解析：接收用户或系统发出的自然语言指令。
2. LLM 推理与规划：LLM 根据当前上下文（历史对话、可用工具描述、任务目标）生成一个“思考”过程，并决定是直接回答，还是调用某个工具。
3. 工具执行：如果 LLM 决定调用工具，则解析其输出中的结构化指令（如函数名和参数），执行相应的代码（如查询数据库、调用第三方 API、运行计算）。
4. 观察结果与循环：将工具执行的结果作为新的观察反馈给 LLM。LLM 基于此观察，继续思考，决定是再次调用工具、整合信息给出最终答案，还是宣告任务失败。
5. 最终输出：当 LLM 认为已收集足够信息或达到终止条件时，输出最终结果。

在这个流程中，步骤 2 和 4 严重依赖 LLM 的 API。模型的性能、稳定性、成本以及其输出格式的可靠性，直接决定了整个 Agent 系统的表现。

1.2 为什么最初选择 Anthropic Claude？

在项目初期，Claude 模型因其在长上下文、复杂指令遵循和安全性方面的优秀表现，成为了我们的自然选择。我们的代码库深度集成了anthropicSDK，提示词模板、错误处理、响应解析都是围绕 Claude 的 API 响应格式设计的。例如，我们依赖 Claude 的\n\nHuman:和\n\nAssistant:格式来构造对话历史，并利用其稳定的 JSON 模式输出来解析工具调用。

1.3 迁移的驱动力：不仅仅是“连接失败”

网络搜索材料中频繁出现的 “unable to connect to anthropic services” 错误，是促使我们思考迁移的导火索之一，但这并非唯一原因。综合来看，驱动力包括：

• 服务可靠性：偶发的 API 服务中断或高延迟，会影响终端用户体验和系统 SLA。
• 成本与预算控制：随着使用量增长，模型调用成本成为重要考量。不同供应商的定价模型差异显著。
• 功能与生态：需要评估新模型是否支持必需的特性，如足够长的上下文、函数调用、稳定的系统提示词（System Prompt）支持。
• 合规与数据安全：对于特定行业或区域，数据处理的合规性要求可能指向特定的模型服务提供商。
• 供应商锁定风险：避免业务逻辑与单一供应商的 SDK 和 API 规范过度耦合，保持架构的灵活性。

基于以上考虑，我们将目光投向了智谱 AI 的 GLM 系列模型，它提供了具有竞争力的中文理解能力、稳定的 API 服务以及丰富的 SDK 支持。

2. 迁移前的准备工作与环境配置

一次成功的迁移始于周密的准备。盲目替换 API 调用只会引入无数难以调试的 Bug。

2.1 技术栈评估与依赖更新

首先，我们梳理了现有技术栈。我们的后端主要使用 Python，原核心依赖是anthropic库。要迁移到 GLM，我们需要其对应的官方 SDKzhipuai。

原依赖 (requirements.txt或pyproject.toml)：

anthropic>=0.25.0 # 其他依赖...

新依赖：我们需要添加zhipuai，并考虑是否暂时保留anthropic作为回滚方案。

anthropic>=0.25.0 # 暂时保留，用于回滚和对比测试 zhipuai>=2.0.0 # 其他依赖...

注意：在实际生产迁移中，建议先在新分支或新环境中进行，避免直接影响线上服务。

2.2 环境变量与配置管理

模型 API 密钥、基础 URL 等配置必须从代码中抽离，通过环境变量或配置中心管理。这是我们之前就遵循的最佳实践，它使得切换模型供应商变得非常容易。

原配置结构（示例）：

# config.py import os class Config: ANTHROPIC_API_KEY = os.getenv("ANTHROPIC_API_KEY") ANTHROPIC_MODEL = os.getenv("ANTHROPIC_MODEL", "claude-3-opus-20240229") ANTHROPIC_BASE_URL = os.getenv("ANTHROPIC_BASE_URL", "https://api.anthropic.com") # ... 其他配置

迁移后的配置结构：我们新增 GLM 的配置项，并为模型选择设计一个开关。

# config.py import os class Config: # 原有 Anthropic 配置（暂留） ANTHROPIC_API_KEY = os.getenv("ANTHROPIC_API_KEY") ANTHROPIC_MODEL = os.getenv("ANTHROPIC_MODEL", "claude-3-opus-20240229") # 新增 GLM 配置 ZHIPUAI_API_KEY = os.getenv("ZHIPUAI_API_KEY") GLM_MODEL = os.getenv("GLM_MODEL", "glm-4") # 或 glm-3-turbo, glm-4v 等 # 模型供应商选择开关 LLM_PROVIDER = os.getenv("LLM_PROVIDER", "glm") # 可选 'anthropic' 或 'glm' @property def active_llm_config(self): if self.LLM_PROVIDER == 'anthropic': return { 'provider': 'anthropic', 'api_key': self.ANTHROPIC_API_KEY, 'model': self.ANTHROPIC_MODEL } else: return { 'provider': 'glm', 'api_key': self.ZHIPUAI_API_KEY, 'model': self.GLM_MODEL }

通过一个配置开关，我们可以实现运行时无缝切换，便于进行 A/B 测试或快速回滚。

2.3 建立测试与评估基准

在开始修改代码前，我们收集了一批具有代表性的测试用例（Test Cases），涵盖：

• 简单问答：基础的理解能力。
• 复杂推理：多步骤的数学或逻辑问题。
• 工具调用场景：需要模型输出结构化 JSON 来调用函数的用例。
• 长上下文摘要：处理长文本并提取关键信息。
• 边界案例：模糊、有歧义或对抗性的提示词。

这些用例在原有 Claude 系统上的输入和期望输出被记录下来，作为迁移后验证效果的核心基准。

3. 核心迁移：重构 LLM 客户端与提示词工程

这是迁移中最核心、最繁琐的部分。目标是将所有与 Anthropic SDK 直接交互的代码，重构为面向一个抽象接口的代码，然后为该接口提供 GLM 的实现。

3.1 设计统一的 LLM 客户端接口

我们首先定义了一个简单的客户端接口（Abstract Base Class），规定所有模型供应商必须实现的方法。

# llm_client.py from abc import ABC, abstractmethod from typing import Dict, Any, Optional, List class BaseLLMClient(ABC): """LLM 客户端抽象基类""" @abstractmethod def chat_completion( self, messages: List[Dict[str, str]], tools: Optional[List[Dict]] = None, tool_choice: Optional[str] = None, temperature: float = 0.7, max_tokens: int = 2000, **kwargs ) -> Dict[str, Any]: """ 统一的聊天补全接口。 Args: messages: 消息列表，格式通常为 [{"role": "user", "content": "..."}, ...] tools: 可选，可供模型调用的工具描述列表。 tool_choice: 可选，控制模型是否必须使用工具。如 “auto”, “none”, 或指定工具名。 temperature: 生成温度。 max_tokens: 生成的最大 token 数。 **kwargs: 其他供应商特定参数。 Returns: 包含模型响应、token 使用量等信息的字典。 必须包含 `content` (str) 和 `tool_calls` (list) 字段。 """ pass @abstractmethod def count_tokens(self, text: str) -> int: """计算文本的 token 数量（近似）。""" pass

3.2 实现 Anthropic 客户端（适配器模式）

我们保留原有的 Anthropic 调用逻辑，但将其包装成上述接口的实现。这步主要是为了统一调用方式。

# llm_client.py import anthropic from .base import BaseLLMClient class AnthropicClient(BaseLLMClient): def __init__(self, api_key: str, model: str, base_url: Optional[str] = None): self.client = anthropic.Anthropic(api_key=api_key, base_url=base_url) self.model = model def chat_completion(self, messages, tools=None, tool_choice=None, temperature=0.7, max_tokens=2000, **kwargs): # 注意：Anthropic 的消息格式与 OpenAI 不完全相同，需要转换。 # 例如，它使用 “user” 和 “assistant” 角色，但历史消息构造方式不同。 # 这里是一个简化示例，实际转换可能更复杂。 system_prompt = None converted_messages = [] for msg in messages: if msg['role'] == 'system': system_prompt = msg['content'] else: # 将通用的 “user”/“assistant” 角色转换为 Anthropic 格式 # 这里需要根据你原有的提示词构造逻辑进行适配 pass # 调用 Anthropic API (示例，非完整代码) response = self.client.messages.create( model=self.model, max_tokens=max_tokens, temperature=temperature, system=system_prompt, messages=converted_messages, # 需要是 Anthropic 格式的消息列表 tools=tools, # Anthropic 也支持 tools 参数 tool_choice=tool_choice, **kwargs ) # 将 Anthropic 响应格式转换为统一格式 unified_response = { 'content': response.content[0].text if response.content else '', 'tool_calls': self._parse_tool_calls(response), # 解析工具调用 'raw_response': response, # 保留原始响应以备调试 } return unified_response def count_tokens(self, text: str) -> int: return self.client.count_tokens(text) def _parse_tool_calls(self, response): # 解析 Anthropic 响应中的 tool_use 块 tool_calls = [] for content_block in response.content: if content_block.type == 'tool_use': tool_calls.append({ 'id': content_block.id, 'type': 'function', 'function': { 'name': content_block.name, 'arguments': content_block.input # 通常是 JSON 字符串 } }) return tool_calls

3.3 实现 GLM 客户端

这是迁移的关键。我们需要熟悉zhipuaiSDK 的用法，并处理其与 Anthropic 在 API 签名、参数命名、响应格式上的差异。

# llm_client.py import zhipuai from .base import BaseLLMClient import json class GLMClient(BaseLLMClient): def __init__(self, api_key: str, model: str): # 初始化智谱 AI 客户端 self.client = zhipuai.ZhipuAI(api_key=api_key) self.model = model def chat_completion(self, messages, tools=None, tool_choice=None, temperature=0.7, max_tokens=2000, **kwargs): """ 调用 GLM 聊天接口。 注意：GLM 的 tools 参数格式与 Anthropic/OpenAI 略有不同，需要适配。 """ # 准备请求参数 request_data = { "model": self.model, "messages": messages, # GLM 使用标准的 OpenAI 格式消息列表 "temperature": temperature, "max_tokens": max_tokens, **kwargs } # 处理工具调用（如果 GLM 模型支持） if tools: # 将工具列表转换为 GLM 所需的格式 # 这里需要参考 zhipuai SDK 最新文档，格式可能变化 # 假设格式为 {"type": "function", "function": {...}} glm_tools = [] for tool in tools: if isinstance(tool, dict) and 'function' in tool: glm_tools.append(tool) else: # 尝试转换格式 glm_tools.append({ "type": "function", "function": tool }) request_data["tools"] = glm_tools if tool_choice: # 映射 tool_choice 参数 request_data["tool_choice"] = tool_choice try: response = self.client.chat.completions.create(**request_data) except Exception as e: # 处理 GLM 特定的异常，如认证失败、额度不足等 raise LLMClientError(f"GLM API call failed: {e}") # 解析响应，转换为统一格式 choice = response.choices[0] message = choice.message unified_response = { 'content': message.content or '', 'tool_calls': [], 'raw_response': response, } # 解析 GLM 响应中的工具调用 if hasattr(message, 'tool_calls') and message.tool_calls: for tc in message.tool_calls: if tc.type == 'function': try: # 确保 arguments 是字典 args = json.loads(tc.function.arguments) if isinstance(tc.function.arguments, str) else tc.function.arguments except json.JSONDecodeError: args = {} unified_response['tool_calls'].append({ 'id': tc.id, 'type': 'function', 'function': { 'name': tc.function.name, 'arguments': args } }) return unified_response def count_tokens(self, text: str) -> int: # GLM SDK 可能没有直接提供 count_tokens 方法。 # 可以使用近似估算，或者调用其 tokenizer 接口（如果提供）。 # 这里使用一个简单的基于字符的近似估算（不准确，仅示例） return len(text) // 3 # 非常粗略的近似

3.4 重构提示词（Prompt）模板

不同模型对提示词的敏感度不同。Claude 和 GLM 虽然在遵循指令上都表现良好，但在某些细节上可能需要调整。

常见需要调整的提示词部分：

1. 系统提示词（System Prompt）：确保角色定义清晰。有时需要调整语气或格式强调。
2. 思维链（CoT）引导：如果原有提示词明确要求模型“一步一步思考”，这个指令对 GLM 同样有效，但输出的思考过程格式可能略有不同，需要调整后续的解析逻辑。
3. 工具描述：不同模型对工具描述 JSON Schema 的严格程度可能不同。确保工具的名称、描述、参数格式清晰无误。
4. 输出格式约束：如果要求模型输出特定格式（如 JSON、Markdown 表格），需要在提示词中明确说明。GLM 对格式指令的遵循能力需要测试。

示例：统一工具描述格式我们发现在 GLM 下，工具描述的parameters字段如果包含"additionalProperties": false这样的严格约束，有时会导致调用失败。我们将其调整为更宽松的定义，并加强了工具名称和参数描述的清晰度。

// 调整前（可能对 GLM 过于严格） { "name": "get_weather", "description": "获取指定城市的天气", "parameters": { "type": "object", "properties": { "city": {"type": "string", "description": "城市名称"} }, "required": ["city"], "additionalProperties": false // GLM 可能对此支持不佳 } } // 调整后（更通用） { "name": "get_weather", "description": "获取指定城市的天气信息。城市名需为中文或英文。", "parameters": { "type": "object", "properties": { "city": {"type": "string", "description": "城市名称，例如：北京、Shanghai"} }, "required": ["city"] // 移除了 additionalProperties } }

4. 处理迁移中的关键差异与挑战

直接替换 SDK 后，系统并不会立刻正常工作。我们遇到了几个需要重点解决的差异点。

4.1 上下文长度（Context Window）与 Token 计数

Claude 和 GLM 系列不同模型的上下文长度上限不同。例如，Claude-3 Opus 支持 200K tokens，而 GLM-4 的标准版本可能支持 128K。这直接影响能处理的历史对话长度和输入文档大小。

我们的做法：

1. 在配置中明确指定：为每个模型设置一个安全的max_context_tokens配置项，实际使用时，输入 token 数不能超过此限制减去预留的输出 token 数。
2. 实现动态摘要：对于长对话，当历史消息 token 数接近上限时，触发一个摘要过程，让模型自己总结之前的对话核心，用摘要替换掉部分旧消息，从而腾出空间。
3. 统一 Token 计数：如前所述，我们实现了一个统一的count_tokens方法。对于 GLM，由于 SDK 未直接提供，我们初期使用近似算法（如tiktoken的cl100k_base编码器进行估算，因为 GLM 也基于类似 GPT 的 tokenizer），后期可以接入 GLM 官方提供的 tokenizer 计算服务（如果开放）。

4.2 函数调用（Function Calling/Tool Use）的响应格式

这是 Agent Loop 的核心。模型必须能稳定地输出结构化的工具调用请求。

差异与适配：

• Anthropic：响应内容是一个包含type: “tool_use”的ContentBlock。
• GLM：响应格式更接近 OpenAI，在message.tool_calls中返回一个列表。

我们的统一接口GLMClient._parse_tool_calls已经处理了这个差异，将不同格式都转换成了内部统一的tool_calls列表格式。关键在于确保解析代码能兼容两种结构，并且能处理arguments字段是 JSON 字符串还是已解析字典的情况。

4.3 错误处理与重试机制

不同 API 的异常类型、错误码和速率限制策略不同。

我们构建了统一的错误处理层：

# error_handler.py import time from typing import Callable, Any class LLMClientError(Exception): """自定义 LLM 客户端异常基类""" pass class RateLimitError(LLMClientError): """速率限制异常""" pass class ContextLengthExceededError(LLMClientError): """上下文超长异常""" pass def retry_with_backoff( func: Callable, max_retries: int = 3, initial_delay: float = 1.0, backoff_factor: float = 2.0 ) -> Any: """ 带有指数退避的重试装饰器/函数。 专门处理 LLM API 调用中可能出现的瞬时错误。 """ def wrapper(*args, **kwargs): delay = initial_delay last_exception = None for attempt in range(max_retries + 1): # +1 包含第一次尝试 try: return func(*args, **kwargs) except RateLimitError as e: last_exception = e if attempt == max_retries: break time.sleep(delay) delay *= backoff_factor # 可以在这里加入抖动 (jitter) except ContextLengthExceededError as e: # 上下文超长无法通过重试解决，直接抛出 raise e except LLMClientError as e: # 其他客户端错误，如认证失败，通常重试无效 raise e except Exception as e: # 网络错误等，进行重试 last_exception = e if attempt == max_retries: break time.sleep(delay) delay *= backoff_factor raise last_exception return wrapper

然后，在BaseLLMClient.chat_completion的调用处，用@retry_with_backoff进行装饰。同时，在每个具体的客户端实现中，将 API 返回的特定错误（如 HTTP 429、HTTP 413）转换为自定义的RateLimitError或ContextLengthExceededError。

4.4 思维链（CoT）输出的稳定性

我们的 Agent 依赖模型输出“思考过程”来进行可解释的推理。我们发现，GLM 在零样本（zero-shot）的 CoT 提示下，有时思考过程的格式不如 Claude 稳定（例如，可能不总是以“思考：”开头）。

解决方案：

1. 少样本（Few-shot）提示：在系统提示词或首个用户消息中，提供一个清晰的思考过程示例。
2. 输出解析强化：编写更鲁棒的解析器，使用正则表达式或关键字匹配来提取思考内容，而不是依赖固定的行首标记。
3. 调整温度（Temperature）：适当降低temperature（如从 0.7 调到 0.3）可以使输出格式更稳定，但可能会牺牲一定的创造性。

5. 验证、测试与性能对比

完成代码迁移后，必须进行全面的验证。

5.1 功能测试

使用第 2.3 节准备的测试用例集，分别用原来的 Anthropic 客户端和新的 GLM 客户端运行，对比输出结果。我们主要关注：

• 任务完成度：是否能正确理解指令并完成任务？
• 工具调用准确性：在需要调用工具的案例中，是否能正确选择工具并生成格式正确的参数？
• 输出格式：最终答案的格式是否符合要求？

5.2 集成测试与回归测试

运行整个 Agent Loop 的集成测试，模拟真实用户对话流。确保在切换模型供应商后，原有的业务逻辑（如状态管理、工具执行、循环判断）依然正常工作。

5.3 性能与成本评估

我们设计了一个简单的基准测试脚本，针对同一批任务，从以下维度进行对比：

评估维度	Anthropic (Claude-3 Sonnet)	GLM (GLM-4)	说明
单次请求平均延迟	~2.5s	~1.8s	从发送请求到收到完整响应的平均时间。受网络和服务器负载影响。
Token 消耗（近似）	输入 1K / 输出 0.5K	输入 1K / 输出 0.5K	相同任务下，不同模型的 token 化方式不同，消耗有差异。
成本（每百万 Tokens）	$X	$Y	根据官方定价计算，Y 通常显著低于 X，是迁移的主要动力之一。
复杂推理任务成功率	95%	92%	在数学、逻辑等测试集上的通过率。
工具调用格式合规率	98%	96%	输出可被成功解析为工具调用的比例。

注意：上表中的数据仅为示例，实际数据需根据具体模型版本、任务类型和测试环境进行测量。GLM 在中文任务和成本上通常有优势，而 Claude 可能在复杂英文推理上更稳定。

5.4 A/B 测试与渐进式发布

在通过内部测试后，我们通过配置开关LLM_PROVIDER，将一小部分实际流量（例如 5%）导向新的 GLM 服务，同时进行监控。监控指标包括：

• API 调用成功率、错误率。
• 请求延迟 P50、P95、P99。
• 业务层面的成功率（如用户任务完成率）。
• 成本消耗对比。

经过一段时间的稳定运行和数据观察后，再逐步提高 GLM 的流量比例，直至完全切换。

6. 迁移后的最佳实践与经验总结

6.1 架构层面的收获

1. 抽象与依赖倒置：这次迁移充分证明了面向接口编程的价值。通过BaseLLMClient抽象，核心业务逻辑与具体的模型 SDK 解耦。未来若要接入百度文心、阿里通义等模型，只需新增一个客户端实现即可。
2. 配置驱动：所有模型相关的参数（API Key、Model Name、Base URL、超时时间、重试策略）都必须通过配置管理，绝不允许硬编码。
3. 统一的监控与日志：在所有客户端实现中，加入统一的请求/响应日志记录（注意脱敏）、耗时统计和错误上报。这为问题排查和性能分析提供了唯一的数据源。

6.2 针对 GLM 的调优建议

• 系统提示词要清晰简洁：GLM 对系统提示词响应良好，但过于冗长复杂的系统提示可能会占用过多上下文，影响主要任务。建议将核心指令前置。
• 温度（Temperature）设置：对于需要稳定输出格式的 Agent 任务，建议使用较低的temperature（如 0.1~0.3）。对于创意生成任务，可以适当调高。
• 利用“网络搜索”等原生工具：如果业务场景合适，可以考虑直接使用 GLM API 集成的网络搜索等功能，这比让模型输出工具调用再自己去执行，有时更简单高效。
• 关注官方更新：大模型 API 和 SDK 迭代很快，及时关注智谱 AI 官方文档的更新，获取新特性（如流式响应、视觉理解）和最佳实践。

6.3 常见问题排查清单

如果在迁移或使用 GLM 过程中遇到问题，可以按以下清单排查：

问题现象	可能原因	检查步骤	解决方案
认证失败	API Key 错误或过期；未设置环境变量。	1. 检查ZHIPUAI_API_KEY环境变量是否正确加载。 2. 在智谱AI官网控制台检查 API Key 状态和额度。	更新正确的 API Key；确保应用有访问环境变量的权限。
响应内容为空或无意义	提示词格式有误；模型参数（如 temperature）设置极端；请求被安全策略过滤。	1. 检查messages列表格式是否符合 GLM 要求。 2. 将temperature设为 0.7 等常规值测试。 3. 检查请求内容是否包含敏感或违规词汇。	修正提示词格式；调整模型参数；修改输入内容。
工具调用未被触发	工具描述格式不符合 GLM 要求；tool_choice参数设置错误；模型当前版本对工具调用支持不佳。	1. 使用最简单的工具描述进行测试。 2. 确认tool_choice参数设置为"auto"或指定工具名。 3. 查阅官方文档，确认所用模型是否支持工具调用。	简化工具描述 JSON Schema；明确设置tool_choice；升级到支持工具调用的模型版本。
arguments解析失败	模型返回的arguments不是合法 JSON 字符串。	在解析前打印tool_calls的原始内容，检查arguments字段。	在提示词中强化“输出必须是合法 JSON”的指令；在代码中增加 JSON 解析的容错逻辑（如尝试修复常见错误）。
请求超时或网络错误	网络不稳定；GLM 服务端临时故障；客户端超时设置过短。	1. 检查网络连通性。 2. 查看智谱AI服务状态公告。 3. 检查 SDK 客户端初始化时的timeout参数。	实现重试机制；适当增加超时时间；联系服务商。

6.4 下一步扩展方向

完成本次迁移后，我们的系统架构变得更加灵活。接下来的优化方向包括：

1. 模型路由与降级：实现一个智能路由层，可以根据请求类型（中文/英文、简单/复杂）、成本预算和当前各 API 的健康状态，动态选择最合适的模型供应商。
2. 响应缓存：对于频繁出现的、结果确定的查询（如知识库问答），引入缓存机制，直接返回缓存结果，大幅降低成本和延迟。
3. 性能持续监控：建立更细粒度的监控看板，持续追踪不同模型在不同任务类型上的性能、成本和效果，为后续优化和选型提供数据支撑。

迁移大模型供应商是一项系统工程，涉及从基础设施到应用逻辑的多个层面。通过本次从 Anthropic 到 GLM 的迁移，我们不仅获得了成本优势和服务冗余，更重要的是构建了一个更具弹性和可维护性的 AI 应用架构。核心经验是：尽早进行抽象、统一接口规范、并通过详尽的测试来保证迁移质量。希望这份实战记录能为你的 AI 应用开发之路提供有价值的参考。