在构建和迭代AI驱动的应用时我们常常会依赖特定的模型服务提供商。然而当服务稳定性、成本或访问性成为瓶颈时迁移到另一个平台就成了必须面对的工程挑战。最近我们团队就完成了一次从 Anthropic 的 Claude 模型到智谱 AI 的 GLM 系列模型的技术栈迁移核心目标是重构我们的 Agent Loops智能体工作流系统。整个过程涉及架构调整、代码重构、性能调优和问题排查本文将完整复盘这次迁移的实战经验涵盖背景动因、技术选型对比、详细迁移步骤、核心代码示例、遇到的“坑”及其解决方案以及最终的性能与成本评估。无论你正在评估 GLM还是计划进行类似的模型迁移这篇文章都能提供一份详尽的避坑指南和实操参考。1. 背景与核心概念为何要进行这次迁移在深入技术细节之前我们首先需要理解几个关键概念和这次迁移的根本原因。Agent Loops智能体循环是我们系统的核心架构模式。它指的是一种让大语言模型LLM能够执行多步骤、有状态任务的设计。一个典型的 Agent Loop 通常包含以下环节任务规划LLM 根据用户目标拆解出具体的执行步骤。工具调用LLM 选择并调用外部工具如搜索 API、代码执行器、数据库查询来获取信息或执行操作。观察与反思LLM 分析工具执行的结果判断任务是否完成或是否需要调整计划。循环迭代基于反思继续规划下一步或输出最终结果。我们最初基于Anthropic 的 Claude 模型特别是 Claude Opus构建了这套系统因其在复杂推理和指令遵循方面表现出色。然而在实际运营中我们遇到了几个无法回避的痛点最终促使了迁移服务稳定性与访问性问题正如网络热词中频繁出现的unable to connect to anthropic services、failed to connect to api.anthropic.com所反映的部分地区或网络环境下对 Anthropic API 的访问存在不稳定甚至完全不可用的情况。这对需要高可用的生产系统是致命伤。成本考量Claude Opus 等高端模型虽然能力强但 API 调用成本相对较高。对于需要高频次、多轮交互的 Agent Loops长期成本压力巨大。开发与调试效率某些开发工具链如claude code在配置时可能出现setting.json配置不生效、环境变量$anthropic未设置等问题增加了本地开发和调试的复杂度。国产化与数据合规需求部分业务场景对数据出境有严格限制使用国内的 GLM 服务可以更好地满足合规要求。基于以上原因我们开始评估替代方案。智谱 AI 的 GLM 系列模型特别是 GLM-4 及其后续版本如网络提及的 GLM 5.2进入了我们的视野。GLM 模型在中文理解、代码生成和通用推理任务上表现强劲且提供了极具竞争力的 API 价格和更稳定的国内访问体验。其glm-coding等套餐也针对开发者场景做了优化。2. 环境准备与版本说明在进行迁移前需要明确新旧环境的技术栈。我们的 Agent Loops 系统是一个基于 Python 的异步 Web 服务。迁移前环境 (Anthropic):Python: 3.9核心SDK:anthropic(官方Python库)异步框架: FastAPIAgent框架: 基于 LangChain 和自定义逻辑构建关键配置:ANTHROPIC_API_KEY环境变量模型名称如claude-3-opus-20240229迁移目标环境 (GLM):Python: 保持 3.9 不变核心SDK:zhipuai(智谱AI官方Python SDK)异步框架: FastAPI (保持不变)Agent框架: 继续使用 LangChain但需替换其中的 LLM 组件部分自定义逻辑需重写。关键配置:ZHIPUAI_API_KEY环境变量模型名称如glm-4、glm-4-plus或glm-3-turbo根据任务选择。版本注意模型迭代很快本文撰写时 GLM-4 是主力模型。网络热词中提到的glm 5.2、glm 5.3可能是内部版本号或特定套餐标识请以智谱AI官方文档和API实际提供的模型列表为准。在配置时务必使用官方认可的模型名称。3. 核心差异与迁移策略拆解从 Claude 迁移到 GLM并非简单的 API Key 替换两者在 API 设计、参数命名、响应格式上存在差异。我们的迁移策略是保持上层 Agent 业务逻辑基本不变彻底重写底层的 LLM 调用适配层。3.1 API 调用方式对比Anthropic (Claude) 调用示例import anthropic client anthropic.Anthropic(api_keyos.environ[“ANTHROPIC_API_KEY”]) response client.messages.create( model“claude-3-opus-20240229”, max_tokens1000, temperature0.7, system“你是一个有帮助的助手。”, messages[ {“role”: “user”, “content”: “你好请介绍一下你自己。”} ] ) print(response.content[0].text)特点使用client.messages.create方法messages参数是一个字典列表包含role和content。系统提示通过独立的system参数传递。GLM (智谱AI) 调用示例import zhipuai zhipuai.api_key os.environ[“ZHIPUAI_API_KEY”] response zhipuai.model_api.invoke( model“glm-4”, prompt[{“role”: “user”, “content”: “你好请介绍一下你自己。”}], temperature0.7, max_tokens1000, # 注意GLM 的系统提示通常放在 prompt 列表的开头 ) print(response[“data”][“choices”][0][“content”])特点使用zhipuai.model_api.invoke方法。最关键的区别在于消息列表的参数名是prompt且其内容格式与 Anthropic 类似但系统提示需要作为一条role为user(或system取决于模型支持) 的消息插入到prompt列表的起始位置。响应数据的结构路径也不同。3.2 流式输出 (Streaming) 对比Agent Loops 中为了提升用户体验我们大量使用了流式输出。Anthropic 流式调用stream client.messages.create( model..., max_tokens..., messages..., streamTrue # 关键参数 ) for event in stream: if event.type ‘content_block_delta’: print(event.delta.text, end“”, flushTrue)GLM 流式调用response zhipuai.model_api.sse_invoke( model“glm-4”, prompt..., temperature..., max_tokens..., # 流式调用使用 sse_invoke 方法 ) for event in response.events(): if event.event “add”: print(event.data, end“”, flushTrue)迁移点方法名从create(streamTrue)变为sse_invoke()事件循环的解析逻辑完全不同。3.3 上下文长度与 Token 计算Claude Opus上下文窗口通常为 200K tokens。GLM-4标准上下文窗口为 128K tokens。这对于大多数 Agent Loop 场景已经足够但如果你有超长上下文需求需要评估是否满足。Token 计算差异两者对中文的 Token 切分方式不同。GLM 基于自己的分词器。这直接影响了max_tokens参数的设置和成本计算。在迁移后需要根据实际输出长度重新调整max_tokens的预算。4. 完整迁移实战重构 LLM 适配层我们的目标是创建一个统一的LLMClient类它对外提供一致的接口如generate,stream内部则根据配置决定调用 Claude 还是 GLM。以下是核心代码示例。4.1 项目结构与依赖首先更新requirements.txt添加智谱 AI SDK并保留 Anthropic SDK 以备回滚或 A/B 测试。fastapi0.104.0 anthropic0.18.0 zhipuai2.0.0 # 使用最新稳定版 langchain0.1.0 pydantic2.0.04.2 配置管理使用 Pydantic Settings 管理配置方便切换。# config.py from pydantic_settings import BaseSettings from enum import Enum class LLMProvider(str, Enum): ANTHROPIC “anthropic” ZHIPU “zhipu” class Settings(BaseSettings): llm_provider: LLMProvider LLMProvider.ZHIPU # 默认切换到 GLM anthropic_api_key: str | None None zhipuai_api_key: str | None None anthropic_model: str “claude-3-sonnet-20240229” zhipuai_model: str “glm-4” # 默认使用 GLM-4 class Config: env_file “.env” settings Settings()在.env文件中配置密钥ZHIPUAI_API_KEYyour_glm_api_key_here # ANTHROPIC_API_KEYyour_claude_api_key_here # 注释掉或删除 LLM_PROVIDERzhipu4.3 实现统一的 LLM 客户端这是迁移的核心。我们创建一个UnifiedLLMClient类。# llm_client.py import os from typing import AsyncGenerator, List, Dict, Any import anthropic import zhipuai from config import settings, LLMProvider class UnifiedLLMClient: def __init__(self): self.provider settings.llm_provider if self.provider LLMProvider.ANTHROPIC: if not settings.anthropic_api_key: raise ValueError(“Anthropic API key is not configured.”) self.anthropic_client anthropic.Anthropic(api_keysettings.anthropic_api_key) elif self.provider LLMProvider.ZHIPU: if not settings.zhipuai_api_key: raise ValueError(“ZHIPU AI API key is not configured.”) zhipuai.api_key settings.zhipuai_api_key else: raise ValueError(f“Unsupported LLM provider: {self.provider}”) def _format_messages_for_provider(self, messages: List[Dict], system_prompt: str None) - Any: “”“将通用消息格式转换为特定提供商所需的格式。”“” if self.provider LLMProvider.ANTHROPIC: formatted [] if system_prompt: # Anthropic 使用独立的 system 参数 pass # system 参数在调用时单独传递 formatted messages # Anthropic 的 messages 格式与通用格式基本一致 return formatted, system_prompt elif self.provider LLMProvider.ZHIPU: formatted [] # GLM 需要将 system prompt 作为第一条 user 消息或特定角色 if system_prompt: formatted.append({“role”: “user”, “content”: system_prompt}) # 注意这里假设模型支持此方式。更严谨的做法是查阅最新GLM文档。 formatted.extend(messages) return formatted, None # GLM 没有独立的 system 参数 return messages, system_prompt async def generate(self, messages: List[Dict], system_prompt: str None, **kwargs) - str: “”“同步生成文本。”“” formatted_messages, system_for_api self._format_messages_for_provider(messages, system_prompt) if self.provider LLMProvider.ANTHROPIC: response self.anthropic_client.messages.create( modelsettings.anthropic_model, max_tokenskwargs.get(“max_tokens”, 1024), temperaturekwargs.get(“temperature”, 0.7), systemsystem_for_api, messagesformatted_messages, ) return response.content[0].text elif self.provider LLMProvider.ZHIPU: response zhipuai.model_api.invoke( modelsettings.zhipuai_model, promptformatted_messages, # 关键参数名不同 temperaturekwargs.get(“temperature”, 0.7), max_tokenskwargs.get(“max_tokens”, 1024), top_pkwargs.get(“top_p”, 0.7), ) # 解析 GLM 响应结构 if response[“code”] 200: return response[“data”][“choices”][0][“content”] else: raise Exception(f“GLM API Error: {response[‘msg’]}”) return “” async def stream_generate(self, messages: List[Dict], system_prompt: str None, **kwargs) - AsyncGenerator[str, None]: “”“流式生成文本。”“” formatted_messages, system_for_api self._format_messages_for_provider(messages, system_prompt) if self.provider LLMProvider.ANTHROPIC: stream self.anthropic_client.messages.create( modelsettings.anthropic_model, max_tokenskwargs.get(“max_tokens”, 1024), temperaturekwargs.get(“temperature”, 0.7), systemsystem_for_api, messagesformatted_messages, streamTrue, ) for event in stream: if event.type ‘content_block_delta’: yield event.delta.text elif self.provider LLMProvider.ZHIPU: response zhipuai.model_api.sse_invoke( # 使用不同的流式方法 modelsettings.zhipuai_model, promptformatted_messages, temperaturekwargs.get(“temperature”, 0.7), max_tokenskwargs.get(“max_tokens”, 1024), top_pkwargs.get(“top_p”, 0.7), incrementalTrue, ) for event in response.events(): if event.event “add”: yield event.data elif event.event “error”: raise Exception(f“GLM Stream Error: {event.data}”)4.4 集成到 LangChain Agent如果你使用 LangChain需要创建一个自定义的LLM包装器。# custom_langchain_llm.py from typing import Any, List, Optional, Dict from langchain.llms.base import LLM from langchain.callbacks.manager import CallbackManagerForLLMRun from llm_client import UnifiedLLMClient class UnifiedChatLLM(LLM): model_name: str “unified-llm” llm_client: Any # 注入我们的客户端 def _call(self, prompt: str, stop: Optional[List[str]] None, run_manager: Optional[CallbackManagerForLLMRun] None, **kwargs: Any) - str: # LangChain 的简单调用可能需要将 prompt 转换为 messages 格式 messages [{“role”: “user”, “content”: prompt}] return self.llm_client.generate(messages, **kwargs) property def _llm_type(self) - str: return “unified_llm” # 在应用初始化时 llm_client UnifiedLLMClient() custom_llm UnifiedChatLLM(llm_clientllm_client) # 然后用 custom_llm 替换掉原来 LangChain Agent 中使用的 Anthropic LLM4.5 运行与验证编写测试脚本验证迁移后的功能是否正常。# test_migration.py import asyncio from llm_client import UnifiedLLMClient async def main(): client UnifiedLLMClient() # 测试同步生成 print(“Testing sync generation...”) messages [{“role”: “user”, “content”: “用Python写一个快速排序函数。”}] response await client.generate(messages, temperature0.1) print(f“Response: {response[:200]}...”) # 打印前200字符 # 测试流式生成 print(“\nTesting stream generation...”) async for chunk in client.stream_generate(messages): print(chunk, end“”, flushTrue) print() if __name__ “__main__”: asyncio.run(main())运行此脚本如果能看到正确的代码生成和流式输出说明基础迁移成功。5. 迁移过程中的常见问题与排查思路迁移绝非一帆风顺我们遇到了不少问题以下是典型问题及解决方案。问题现象可能原因排查与解决思路unable to connect to anthropic services(迁移后仍出现)1. 环境变量未正确切换。2. 代码中仍有硬编码的 Anthropic 调用。3. 依赖库缓存了旧配置。1. 检查.env文件确保LLM_PROVIDERzhipu并注释掉ANTHROPIC_API_KEY。2. 全局搜索代码中的anthropic、claude关键字确保所有调用都通过新的UnifiedLLMClient。3. 重启应用服务清除 Python 的__pycache__。GLM API 返回code不为 2001. API Key 无效或未设置。2. 模型名称错误。3. 请求参数格式不符合 GLM 要求。4. 套餐额度不足如glm coding套餐的 token 限制。1. 检查ZHIPUAI_API_KEY环境变量。2. 核对settings.zhipuai_model值访问智谱AI平台查看可用模型列表。3.重点检查prompt参数格式必须是List[Dict]且每条消息包含role和content。系统提示的处理方式可能与 Claude 不同。4. 登录智谱AI控制台检查调用量和剩余额度。流式输出不工作或格式错误1. 使用了错误的流式方法invoke而非sse_invoke。2. 没有正确处理sse_invoke返回的事件流。1. 确认调用的是zhipuai.model_api.sse_invoke。2. 按照官方示例正确迭代response.events()并处理“add”和“error”事件。Agent 逻辑出错或循环异常1. GLM 与 Claude 对某些复杂指令的理解或输出格式有差异。2.max_tokens设置过小导致输出被截断破坏了 Agent 的 JSON 解析等后续步骤。1. 在测试阶段增加对 GLM 输出的日志和断言。可能需要微调system_prompt或few-shot示例以引导 GLM 输出符合预期的格式。2. 根据任务复杂度适当增加max_tokens。监控 GLM 返回的usage字段了解实际消耗。性能下降或响应变慢1. GLM 模型本身在不同任务上的性能特性与 Claude 不同。2. 网络延迟差异。3. 客户端实现有性能瓶颈如同步阻塞调用。1. 进行基准测试对比相同任务下的响应时间和结果质量。根据业务需求可能需要在 GLM 系列中选择不同型号如glm-3-turbo速度更快。2. 确保服务器部署在访问智谱AI API 延迟较低的区域。3. 确保UnifiedLLMClient中的方法是异步的并在 FastAPI 等异步框架中正确使用await。6. 最佳实践与工程建议基于这次迁移经验我们总结出以下最佳实践可供后续类似项目参考抽象与隔离永远不要将模型供应商的 SDK 调用直接写死在业务逻辑中。像我们这样设计一个统一的 LLM 客户端层是应对未来可能再次迁移如切换到 GPT、DeepSeek 等的最佳架构。这符合依赖倒置原则。配置驱动所有模型名称、API 端点、密钥等都应通过环境变量或配置中心管理。使用pydantic-settings等工具进行验证和类型提示能极大减少配置错误。全面测试迁移后必须进行全方位的测试单元测试针对新的LLMClient类模拟 API 响应。集成测试使用测试专用的 API Key对关键 Agent Loop 流程进行端到端测试。非功能测试对比迁移前后的平均响应时间、错误率、成本消耗。渐进式迁移与回滚方案对于核心生产系统可以采用渐进式策略初期通过配置开关让部分非关键流量走 GLM进行线上对比。准备好一键切换回 Claude 的机制直到 GLM 的稳定性和效果得到充分验证。监控与告警迁移后立即加强对新 GLM 接口的监控。监控指标应包括API 调用成功率、延迟P50, P95, P99。不同模型和任务的 Token 消耗与成本。Agent Loop 的成功完成率与平均步数。Prompt 工程微调不同模型对同一套 Prompt 的反应可能不同。迁移后需要观察 Agent 的表现可能需要对system_prompt和few-shot示例进行小幅优化以适配 GLM 的“性格”和输出风格确保其能正确调用工具和解析结果。依赖管理在requirements.txt或pyproject.toml中明确固定核心 SDK 的版本范围避免因自动升级导致 API 不兼容。例如zhipuai2.0.0, 3.0.0。7. 迁移效果评估与总结完成迁移并稳定运行一段时间后我们从以下几个维度进行了评估稳定性之前因网络问题导致的unable to connect错误基本消失服务可用性显著提升。成本在保证可比任务效果的前提下API 调用成本下降了约 40%-60%效益非常明显。性能在常规推理和代码生成任务上GLM-4 的响应速度与 Claude Sonnet 相当略慢于 Claude Opus但在可接受范围内。对于注重速度的场景可以降级使用glm-3-turbo。开发体验智谱AI提供了中文文档和国内社区支持遇到问题时排查效率更高。glm-coding等套餐为开发者提供了更灵活的额度选项。这次从 Anthropic 到 GLM 的 Agent Loops 迁移是一次典型的生产级 AI 应用架构演进。它不仅仅是更换一个 API 调用更涉及到 SDK 集成模式、消息格式转换、流式处理、配置管理和全面测试等一系列工程实践。核心收获是在 AI 应用开发中将模型供应商视为“可插拔”的组件并通过抽象层来隔离变化是构建健壮、可持续系统架构的关键。对于正在考虑类似迁移的团队建议按照“评估-抽象-实现-测试-灰度-监控”的流程稳步推进。先从非核心功能试点积累经验后再全面铺开。希望这份详细的实战笔记能帮助你顺利绕过我们踩过的坑高效完成你自己的技术栈迁移。 
长河君 · 2026/8/21 20:12:58 · 阅读 1.2k 从Claude到GLM：AI Agent工作流迁移实战与架构重构指南
在构建和迭代AI驱动的应用时我们常常会依赖特定的模型服务提供商。然而当服务稳定性、成本或访问性成为瓶颈时迁移到另一个平台就成了必须面对的工程挑战。最近我们团队就完成了一次从 Anthropic 的 Claude 模型到智谱 AI 的 GLM 系列模型的技术栈迁移核心目标是重构我们的 Agent Loops智能体工作流系统。整个过程涉及架构调整、代码重构、性能调优和问题排查本文将完整复盘这次迁移的实战经验涵盖背景动因、技术选型对比、详细迁移步骤、核心代码示例、遇到的“坑”及其解决方案以及最终的性能与成本评估。无论你正在评估 GLM还是计划进行类似的模型迁移这篇文章都能提供一份详尽的避坑指南和实操参考。1. 背景与核心概念为何要进行这次迁移在深入技术细节之前我们首先需要理解几个关键概念和这次迁移的根本原因。Agent Loops智能体循环是我们系统的核心架构模式。它指的是一种让大语言模型LLM能够执行多步骤、有状态任务的设计。一个典型的 Agent Loop 通常包含以下环节任务规划LLM 根据用户目标拆解出具体的执行步骤。工具调用LLM 选择并调用外部工具如搜索 API、代码执行器、数据库查询来获取信息或执行操作。观察与反思LLM 分析工具执行的结果判断任务是否完成或是否需要调整计划。循环迭代基于反思继续规划下一步或输出最终结果。我们最初基于Anthropic 的 Claude 模型特别是 Claude Opus构建了这套系统因其在复杂推理和指令遵循方面表现出色。然而在实际运营中我们遇到了几个无法回避的痛点最终促使了迁移服务稳定性与访问性问题正如网络热词中频繁出现的unable to connect to anthropic services、failed to connect to api.anthropic.com所反映的部分地区或网络环境下对 Anthropic API 的访问存在不稳定甚至完全不可用的情况。这对需要高可用的生产系统是致命伤。成本考量Claude Opus 等高端模型虽然能力强但 API 调用成本相对较高。对于需要高频次、多轮交互的 Agent Loops长期成本压力巨大。开发与调试效率某些开发工具链如claude code在配置时可能出现setting.json配置不生效、环境变量$anthropic未设置等问题增加了本地开发和调试的复杂度。国产化与数据合规需求部分业务场景对数据出境有严格限制使用国内的 GLM 服务可以更好地满足合规要求。基于以上原因我们开始评估替代方案。智谱 AI 的 GLM 系列模型特别是 GLM-4 及其后续版本如网络提及的 GLM 5.2进入了我们的视野。GLM 模型在中文理解、代码生成和通用推理任务上表现强劲且提供了极具竞争力的 API 价格和更稳定的国内访问体验。其glm-coding等套餐也针对开发者场景做了优化。2. 环境准备与版本说明在进行迁移前需要明确新旧环境的技术栈。我们的 Agent Loops 系统是一个基于 Python 的异步 Web 服务。迁移前环境 (Anthropic):Python: 3.9核心SDK:anthropic(官方Python库)异步框架: FastAPIAgent框架: 基于 LangChain 和自定义逻辑构建关键配置:ANTHROPIC_API_KEY环境变量模型名称如claude-3-opus-20240229迁移目标环境 (GLM):Python: 保持 3.9 不变核心SDK:zhipuai(智谱AI官方Python SDK)异步框架: FastAPI (保持不变)Agent框架: 继续使用 LangChain但需替换其中的 LLM 组件部分自定义逻辑需重写。关键配置:ZHIPUAI_API_KEY环境变量模型名称如glm-4、glm-4-plus或glm-3-turbo根据任务选择。版本注意模型迭代很快本文撰写时 GLM-4 是主力模型。网络热词中提到的glm 5.2、glm 5.3可能是内部版本号或特定套餐标识请以智谱AI官方文档和API实际提供的模型列表为准。在配置时务必使用官方认可的模型名称。3. 核心差异与迁移策略拆解从 Claude 迁移到 GLM并非简单的 API Key 替换两者在 API 设计、参数命名、响应格式上存在差异。我们的迁移策略是保持上层 Agent 业务逻辑基本不变彻底重写底层的 LLM 调用适配层。3.1 API 调用方式对比Anthropic (Claude) 调用示例import anthropic client anthropic.Anthropic(api_keyos.environ[“ANTHROPIC_API_KEY”]) response client.messages.create( model“claude-3-opus-20240229”, max_tokens1000, temperature0.7, system“你是一个有帮助的助手。”, messages[ {“role”: “user”, “content”: “你好请介绍一下你自己。”} ] ) print(response.content[0].text)特点使用client.messages.create方法messages参数是一个字典列表包含role和content。系统提示通过独立的system参数传递。GLM (智谱AI) 调用示例import zhipuai zhipuai.api_key os.environ[“ZHIPUAI_API_KEY”] response zhipuai.model_api.invoke( model“glm-4”, prompt[{“role”: “user”, “content”: “你好请介绍一下你自己。”}], temperature0.7, max_tokens1000, # 注意GLM 的系统提示通常放在 prompt 列表的开头 ) print(response[“data”][“choices”][0][“content”])特点使用zhipuai.model_api.invoke方法。最关键的区别在于消息列表的参数名是prompt且其内容格式与 Anthropic 类似但系统提示需要作为一条role为user(或system取决于模型支持) 的消息插入到prompt列表的起始位置。响应数据的结构路径也不同。3.2 流式输出 (Streaming) 对比Agent Loops 中为了提升用户体验我们大量使用了流式输出。Anthropic 流式调用stream client.messages.create( model..., max_tokens..., messages..., streamTrue # 关键参数 ) for event in stream: if event.type ‘content_block_delta’: print(event.delta.text, end“”, flushTrue)GLM 流式调用response zhipuai.model_api.sse_invoke( model“glm-4”, prompt..., temperature..., max_tokens..., # 流式调用使用 sse_invoke 方法 ) for event in response.events(): if event.event “add”: print(event.data, end“”, flushTrue)迁移点方法名从create(streamTrue)变为sse_invoke()事件循环的解析逻辑完全不同。3.3 上下文长度与 Token 计算Claude Opus上下文窗口通常为 200K tokens。GLM-4标准上下文窗口为 128K tokens。这对于大多数 Agent Loop 场景已经足够但如果你有超长上下文需求需要评估是否满足。Token 计算差异两者对中文的 Token 切分方式不同。GLM 基于自己的分词器。这直接影响了max_tokens参数的设置和成本计算。在迁移后需要根据实际输出长度重新调整max_tokens的预算。4. 完整迁移实战重构 LLM 适配层我们的目标是创建一个统一的LLMClient类它对外提供一致的接口如generate,stream内部则根据配置决定调用 Claude 还是 GLM。以下是核心代码示例。4.1 项目结构与依赖首先更新requirements.txt添加智谱 AI SDK并保留 Anthropic SDK 以备回滚或 A/B 测试。fastapi0.104.0 anthropic0.18.0 zhipuai2.0.0 # 使用最新稳定版 langchain0.1.0 pydantic2.0.04.2 配置管理使用 Pydantic Settings 管理配置方便切换。# config.py from pydantic_settings import BaseSettings from enum import Enum class LLMProvider(str, Enum): ANTHROPIC “anthropic” ZHIPU “zhipu” class Settings(BaseSettings): llm_provider: LLMProvider LLMProvider.ZHIPU # 默认切换到 GLM anthropic_api_key: str | None None zhipuai_api_key: str | None None anthropic_model: str “claude-3-sonnet-20240229” zhipuai_model: str “glm-4” # 默认使用 GLM-4 class Config: env_file “.env” settings Settings()在.env文件中配置密钥ZHIPUAI_API_KEYyour_glm_api_key_here # ANTHROPIC_API_KEYyour_claude_api_key_here # 注释掉或删除 LLM_PROVIDERzhipu4.3 实现统一的 LLM 客户端这是迁移的核心。我们创建一个UnifiedLLMClient类。# llm_client.py import os from typing import AsyncGenerator, List, Dict, Any import anthropic import zhipuai from config import settings, LLMProvider class UnifiedLLMClient: def __init__(self): self.provider settings.llm_provider if self.provider LLMProvider.ANTHROPIC: if not settings.anthropic_api_key: raise ValueError(“Anthropic API key is not configured.”) self.anthropic_client anthropic.Anthropic(api_keysettings.anthropic_api_key) elif self.provider LLMProvider.ZHIPU: if not settings.zhipuai_api_key: raise ValueError(“ZHIPU AI API key is not configured.”) zhipuai.api_key settings.zhipuai_api_key else: raise ValueError(f“Unsupported LLM provider: {self.provider}”) def _format_messages_for_provider(self, messages: List[Dict], system_prompt: str None) - Any: “”“将通用消息格式转换为特定提供商所需的格式。”“” if self.provider LLMProvider.ANTHROPIC: formatted [] if system_prompt: # Anthropic 使用独立的 system 参数 pass # system 参数在调用时单独传递 formatted messages # Anthropic 的 messages 格式与通用格式基本一致 return formatted, system_prompt elif self.provider LLMProvider.ZHIPU: formatted [] # GLM 需要将 system prompt 作为第一条 user 消息或特定角色 if system_prompt: formatted.append({“role”: “user”, “content”: system_prompt}) # 注意这里假设模型支持此方式。更严谨的做法是查阅最新GLM文档。 formatted.extend(messages) return formatted, None # GLM 没有独立的 system 参数 return messages, system_prompt async def generate(self, messages: List[Dict], system_prompt: str None, **kwargs) - str: “”“同步生成文本。”“” formatted_messages, system_for_api self._format_messages_for_provider(messages, system_prompt) if self.provider LLMProvider.ANTHROPIC: response self.anthropic_client.messages.create( modelsettings.anthropic_model, max_tokenskwargs.get(“max_tokens”, 1024), temperaturekwargs.get(“temperature”, 0.7), systemsystem_for_api, messagesformatted_messages, ) return response.content[0].text elif self.provider LLMProvider.ZHIPU: response zhipuai.model_api.invoke( modelsettings.zhipuai_model, promptformatted_messages, # 关键参数名不同 temperaturekwargs.get(“temperature”, 0.7), max_tokenskwargs.get(“max_tokens”, 1024), top_pkwargs.get(“top_p”, 0.7), ) # 解析 GLM 响应结构 if response[“code”] 200: return response[“data”][“choices”][0][“content”] else: raise Exception(f“GLM API Error: {response[‘msg’]}”) return “” async def stream_generate(self, messages: List[Dict], system_prompt: str None, **kwargs) - AsyncGenerator[str, None]: “”“流式生成文本。”“” formatted_messages, system_for_api self._format_messages_for_provider(messages, system_prompt) if self.provider LLMProvider.ANTHROPIC: stream self.anthropic_client.messages.create( modelsettings.anthropic_model, max_tokenskwargs.get(“max_tokens”, 1024), temperaturekwargs.get(“temperature”, 0.7), systemsystem_for_api, messagesformatted_messages, streamTrue, ) for event in stream: if event.type ‘content_block_delta’: yield event.delta.text elif self.provider LLMProvider.ZHIPU: response zhipuai.model_api.sse_invoke( # 使用不同的流式方法 modelsettings.zhipuai_model, promptformatted_messages, temperaturekwargs.get(“temperature”, 0.7), max_tokenskwargs.get(“max_tokens”, 1024), top_pkwargs.get(“top_p”, 0.7), incrementalTrue, ) for event in response.events(): if event.event “add”: yield event.data elif event.event “error”: raise Exception(f“GLM Stream Error: {event.data}”)4.4 集成到 LangChain Agent如果你使用 LangChain需要创建一个自定义的LLM包装器。# custom_langchain_llm.py from typing import Any, List, Optional, Dict from langchain.llms.base import LLM from langchain.callbacks.manager import CallbackManagerForLLMRun from llm_client import UnifiedLLMClient class UnifiedChatLLM(LLM): model_name: str “unified-llm” llm_client: Any # 注入我们的客户端 def _call(self, prompt: str, stop: Optional[List[str]] None, run_manager: Optional[CallbackManagerForLLMRun] None, **kwargs: Any) - str: # LangChain 的简单调用可能需要将 prompt 转换为 messages 格式 messages [{“role”: “user”, “content”: prompt}] return self.llm_client.generate(messages, **kwargs) property def _llm_type(self) - str: return “unified_llm” # 在应用初始化时 llm_client UnifiedLLMClient() custom_llm UnifiedChatLLM(llm_clientllm_client) # 然后用 custom_llm 替换掉原来 LangChain Agent 中使用的 Anthropic LLM4.5 运行与验证编写测试脚本验证迁移后的功能是否正常。# test_migration.py import asyncio from llm_client import UnifiedLLMClient async def main(): client UnifiedLLMClient() # 测试同步生成 print(“Testing sync generation...”) messages [{“role”: “user”, “content”: “用Python写一个快速排序函数。”}] response await client.generate(messages, temperature0.1) print(f“Response: {response[:200]}...”) # 打印前200字符 # 测试流式生成 print(“\nTesting stream generation...”) async for chunk in client.stream_generate(messages): print(chunk, end“”, flushTrue) print() if __name__ “__main__”: asyncio.run(main())运行此脚本如果能看到正确的代码生成和流式输出说明基础迁移成功。5. 迁移过程中的常见问题与排查思路迁移绝非一帆风顺我们遇到了不少问题以下是典型问题及解决方案。问题现象可能原因排查与解决思路unable to connect to anthropic services(迁移后仍出现)1. 环境变量未正确切换。2. 代码中仍有硬编码的 Anthropic 调用。3. 依赖库缓存了旧配置。1. 检查.env文件确保LLM_PROVIDERzhipu并注释掉ANTHROPIC_API_KEY。2. 全局搜索代码中的anthropic、claude关键字确保所有调用都通过新的UnifiedLLMClient。3. 重启应用服务清除 Python 的__pycache__。GLM API 返回code不为 2001. API Key 无效或未设置。2. 模型名称错误。3. 请求参数格式不符合 GLM 要求。4. 套餐额度不足如glm coding套餐的 token 限制。1. 检查ZHIPUAI_API_KEY环境变量。2. 核对settings.zhipuai_model值访问智谱AI平台查看可用模型列表。3.重点检查prompt参数格式必须是List[Dict]且每条消息包含role和content。系统提示的处理方式可能与 Claude 不同。4. 登录智谱AI控制台检查调用量和剩余额度。流式输出不工作或格式错误1. 使用了错误的流式方法invoke而非sse_invoke。2. 没有正确处理sse_invoke返回的事件流。1. 确认调用的是zhipuai.model_api.sse_invoke。2. 按照官方示例正确迭代response.events()并处理“add”和“error”事件。Agent 逻辑出错或循环异常1. GLM 与 Claude 对某些复杂指令的理解或输出格式有差异。2.max_tokens设置过小导致输出被截断破坏了 Agent 的 JSON 解析等后续步骤。1. 在测试阶段增加对 GLM 输出的日志和断言。可能需要微调system_prompt或few-shot示例以引导 GLM 输出符合预期的格式。2. 根据任务复杂度适当增加max_tokens。监控 GLM 返回的usage字段了解实际消耗。性能下降或响应变慢1. GLM 模型本身在不同任务上的性能特性与 Claude 不同。2. 网络延迟差异。3. 客户端实现有性能瓶颈如同步阻塞调用。1. 进行基准测试对比相同任务下的响应时间和结果质量。根据业务需求可能需要在 GLM 系列中选择不同型号如glm-3-turbo速度更快。2. 确保服务器部署在访问智谱AI API 延迟较低的区域。3. 确保UnifiedLLMClient中的方法是异步的并在 FastAPI 等异步框架中正确使用await。6. 最佳实践与工程建议基于这次迁移经验我们总结出以下最佳实践可供后续类似项目参考抽象与隔离永远不要将模型供应商的 SDK 调用直接写死在业务逻辑中。像我们这样设计一个统一的 LLM 客户端层是应对未来可能再次迁移如切换到 GPT、DeepSeek 等的最佳架构。这符合依赖倒置原则。配置驱动所有模型名称、API 端点、密钥等都应通过环境变量或配置中心管理。使用pydantic-settings等工具进行验证和类型提示能极大减少配置错误。全面测试迁移后必须进行全方位的测试单元测试针对新的LLMClient类模拟 API 响应。集成测试使用测试专用的 API Key对关键 Agent Loop 流程进行端到端测试。非功能测试对比迁移前后的平均响应时间、错误率、成本消耗。渐进式迁移与回滚方案对于核心生产系统可以采用渐进式策略初期通过配置开关让部分非关键流量走 GLM进行线上对比。准备好一键切换回 Claude 的机制直到 GLM 的稳定性和效果得到充分验证。监控与告警迁移后立即加强对新 GLM 接口的监控。监控指标应包括API 调用成功率、延迟P50, P95, P99。不同模型和任务的 Token 消耗与成本。Agent Loop 的成功完成率与平均步数。Prompt 工程微调不同模型对同一套 Prompt 的反应可能不同。迁移后需要观察 Agent 的表现可能需要对system_prompt和few-shot示例进行小幅优化以适配 GLM 的“性格”和输出风格确保其能正确调用工具和解析结果。依赖管理在requirements.txt或pyproject.toml中明确固定核心 SDK 的版本范围避免因自动升级导致 API 不兼容。例如zhipuai2.0.0, 3.0.0。7. 迁移效果评估与总结完成迁移并稳定运行一段时间后我们从以下几个维度进行了评估稳定性之前因网络问题导致的unable to connect错误基本消失服务可用性显著提升。成本在保证可比任务效果的前提下API 调用成本下降了约 40%-60%效益非常明显。性能在常规推理和代码生成任务上GLM-4 的响应速度与 Claude Sonnet 相当略慢于 Claude Opus但在可接受范围内。对于注重速度的场景可以降级使用glm-3-turbo。开发体验智谱AI提供了中文文档和国内社区支持遇到问题时排查效率更高。glm-coding等套餐为开发者提供了更灵活的额度选项。这次从 Anthropic 到 GLM 的 Agent Loops 迁移是一次典型的生产级 AI 应用架构演进。它不仅仅是更换一个 API 调用更涉及到 SDK 集成模式、消息格式转换、流式处理、配置管理和全面测试等一系列工程实践。核心收获是在 AI 应用开发中将模型供应商视为“可插拔”的组件并通过抽象层来隔离变化是构建健壮、可持续系统架构的关键。对于正在考虑类似迁移的团队建议按照“评估-抽象-实现-测试-灰度-监控”的流程稳步推进。先从非核心功能试点积累经验后再全面铺开。希望这份详细的实战笔记能帮助你顺利绕过我们踩过的坑高效完成你自己的技术栈迁移。