春节假期被DeepSeek刷屏了，不少同学出了多个维度的解析，也介绍了不同平台支持一键部署DeepSeek的教程。作为尝鲜和使用，这样使用无可厚非，对于Agent ToB商用来说，是否要第一时间追逐采用最新的模型，这又是另外一个话题。
先说观点，我认为是有必要紧跟热点技术，但不能一拥而上，Agent ToB商用的架构师在设计方案时需要考虑切换模型带来的风险、选择合适的业务进行试点、通过技术架构封装底层模型变化，并且采用对Agent进行评估和灰度发布的方式进行新模型替换上线。
1
切换模型的风险
1.1 底层模型服务不稳定
DeepSeek提供模型服务状态监测status.deepseek.com。春节期间以及最近经常遭受攻击等问题导致服务出现异常卡顿等现象。我们希望DeepSeek能扛住并持续提供稳定服务，不过对于Agent架构师来说需要考虑这样一个问题：企业级应用来说是否能接受其中一项核心服务中断？答案不言而喻！
1.2 已经采用其他模型
已经开发和运行中的企业应用肯定已经采用了其他模型，包括Qwen、文心一言，也可能使用了GPT、Claude等模型，现在DeepSeek在性能、安装部署等方面有很大优势，是否要替换已有的模型？不采用DeepSeek是否会错失先机？采用DeepSeek模型需要遵循什么样的节奏和步骤？每次有新的大模型出来都要第一时间追随？
1.3 Prompt等需要适配，是否容易集成到现有应用中
开发的企业应用也会根据底层模型优化Prompt，不同底层模型会对Prompt有所挑剔，那么直接更换底层模型是否会打乱已经调整到最佳状态的模型+Prompt组合？替换底层模型是否会造成上层应用重新适配？
1.4 对模型精调会有额外成本和精力消耗
在企业级应用时会根据基础模型进行精调/微调，对于采用DeepSeek来说也会存在相同的抉择，对新推出的DeepSeek多个版本模型进行精调？每一次新模型和新版本发布都进行精调？这个维度看起来也不合适。
2
选择什么样的业务适配新模型
刚才也说了结论，我们应该积极拥抱新技术，应该挑选一部分业务进行试点验证，再逐步推广。那么如何挑选业务进行试点呢？建议参考以下维度。
2.1 之前遇到瓶颈的业务
基于现有模型开发的产品还存在瓶颈，那么应该优先考虑通过新模型来尝试解决。也应该看新模型在一些指标上是否和当前业务瓶颈存在相关性。参照模型厂商或第三方机构提供的Benchmark等评估数据来匹配。
2.2 低风险场景优先
选择对业务影响较小的场景进行试点，如内部工具、非核心业务流程或用户感知度较低的功能。例如，在客服系统中，可以先在新模型的问答功能上进行测试，而不是直接用于核心的订单处理。
2.3 高价值场景验证
选择能够体现新模型优势的场景、具有代表性的业务拆分出实验版本进行验证，如需要高精度自然语言理解或生成的任务，验证其性能提升效果。例如，在内容生成业务中，可以先用于生成辅助性内容（如推荐语、标签），而不是直接生成核心文案。
3
通过LLM Gateway封装模型
底层模型会经常变化，除了DeepSeek还会采用其他模型，2025年也会有新的模型推出，如何适应这种变化？
可以通过LLM Gateway将模型进行封装。
3.1 先进行架构解耦
根据墨菲定律，担心的也都有概率发生，AI应用架构每一层都可能出现故障，而Agent架构师需要做的就是将架构进行解耦并保持每一层的高可用。
首先要先理清Agent应用技术栈，初步拆分为IaaS基础设施/算力、模型、中间处理层、Agent应用层。其实还可以有更详细的拆分，在这里仅为了突出模型层的位置。
在模型层我们可能会在多个平台采用多个模型，比如在阿里百炼使用Qwen和DeepSeek，也可能会在火山方舟使用豆包和DeepSeek，也可能会在Amazon Bedrock采用Cluade和DeepSeek。这类平台包括阿里百炼、火山方舟、百度千帆、腾讯Ti-One、Amazon Bedrock等，这些平台提供对模型的封装，需要切换平台只需更换模型ID。
以阿里百炼为例，通过平台API访问模型兼容OpenAI格式，如果需要切换模型只需要更改下面代码第10行中的model即可。
import osfrom openai import OpenAI
client = OpenAI( # 若没有配置环境变量，请用百炼API Key将下行替换为：api_key="sk-xxx", api_key=os.getenv("DASHSCOPE_API_KEY"), base_url="https://dashscope.aliyuncs.com/compatible-mode/v1",)completion = client.chat.completions.create( model="qwen-plus", # 此处以qwen-plus为例，可按需更换模型名称。模型列表：https://help.aliyun.com/zh/model-studio/getting-started/models messages=[ {'role': 'system', 'content': 'You are a helpful assistant.'}, {'role': 'user', 'content': '你是谁？'}], )
print(completion.model_dump_json())
3.2 LLM Gateway
在传统开发中有API Gateway的服务集成多个平台的API，统一提供对外访问接口、统一鉴权、统一日志和监控等处理，对于模型服务同样也能采用这个思路，Konghq、APIPark、LiteLLM等提供对于模型调用的封装管理。
在这些平台中配置多个模型api_key，并支持提供统一对外的访问接口。比如Agent应用中调用的/chat API可以是Qwen、DeepSeek等多个模型或者自定义API提供的服务，那么/chat这个API就实现了对后端模型的封装。
（图片来自APIPark官网）
LLM Gateway平台支持模型调用优先级，数字越小则调用优先级越高，用于自行设定AI服务调用后端模型的顺序，如果排序靠前的模型出现故障则按照调用优先级自动选择后续提供服务的模型。
https://docs.apipark.com/zh-Hans/docs/ai/ai_model_balance
下图是对APIPark自行安装部署，LLM Gateway平台还有Kong AI Gateway、LiteLLM、OneAPI等等。
4
LLM Gateway最佳实践
4.1 负载均衡
在前面已经介绍LLM Gateway可以在多个模型之间进行负载均衡，不同标签的流量可以分发到不同模型提供服务，并且还能支持模型级别的高可用。
4.2 根据Prompt选择模型
根据Prompt来优化模型，好马配好鞍，不同的模型也需要不同的Prompt。当用户询问问题不同时会拼接为不同的Prompt，这时可以通过LLM Gateway来选择最佳模型提供服务。
4.3 LLM APIKEY资源池
APIKEY 资源池能够集中管理和调配 APIKEY，可以查看和管理各个供应商的 APIKEY，包括其状态（如正常、超额、过期等）和调用优先级。并且支持调整 APIKEY 的优先级顺序，以适应不同的业务需求。当某个 APIKEY 出现超额或过期等问题时，系统自动按优先级启用其他 APIKEY ，确保AI服务的持续可用。支持同一个平台配置多个APIKEY，即便一个APIKEY出现问题也不影响切换到其他APIKEY继续提供服务。
还有一个好处，就是通过AI APIKEY 资源池对 AI 调用资源额度进行统一再分配。
4.4 通过AgentScope等框架二次开发
AgentScope是对LLM和Agent进行编排的开源框架，由阿里团队提供（https://github.com/modelscope/agentscope/），使用这个框架需要先配置模型（见下面model_configs部分），dialog_agent部分可以实现用户和多个Agent/模型进行对话。
如果从gpt-3.5-turbo模型切换为DeepSeek模型，也只需要更换模型名称即可（均需要提前配置好模型名称、api_key等参数）。但是一个模型提供的服务异常，我们还是需要手动通过代码检测并切换模型。
无论是使用AgentScope框架还是采用其他框架或者自行编写代码来调用模型/Agent，都存在这个问题。
# -*- coding: utf-8 -*-"""A simple example for conversation between user and assistant agent."""import agentscopefrom agentscope.agents import DialogAgentfrom agentscope.agents.user_agent import UserAgentfrom agentscope.pipelines.functional import sequentialpipeline
def main() -> None: """A basic conversation demo"""
agentscope.init( model_configs=[ { "model_type": "openai_chat", "config_name": "gpt-3.5-turbo", "model_name": "gpt-3.5-turbo", "api_key": "xxx", # Load from env if not provided "organization": "xxx", # Load from env if not provided "generate_args": { "temperature": 0.5, }, }, { "model_type": "post_api_chat", "config_name": "my_post_api", "api_url": "https://xxx", "headers": {}, }, ], project="Multi-Agent Conversation", save_api_invoke=True, )
# Init two agents dialog_agent = DialogAgent( name="Assistant", sys_prompt="You're a helpful assistant.", model_config_name="gpt-3.5-turbo", # replace by your model config name ) user_agent = UserAgent()
# start the conversation between user and assistant x = None while x is None or x.content != "exit": x = sequentialpipeline([dialog_agent, user_agent], x)
if __name__ == "__main__": main()
4.5 LLM Gateway封装Bedrock中的API
还有一个用法，LLM Gateway可以封装基础模型API，也可以封装模型平台的服务或者自定义API，这也是一个融合的封装方案。
5
Agent应用评估与灰度发布
5.1 通过评分方式进行应用评估
试点业务需要时可保持能够适配新模型，采用新模型是否达到足够的效果，可以通过自动评估或人工评估方式来量化应用效果。
选择的评估范围可以这样来选：
针对瓶颈业务进行评估，在采用新模型之前的应用通常遇到的难点，可以拿在在新项目中进行测试；
综合全量评估：采用新模型前后均进行Agent应用评估，可以参考AI自动评估、人工评估的方式。
参照Prompt评估方案我们可以提供一个Agent应用效果评估方法，比如通过人工方式进行评估，则需要先准备以下数据和人力：
评测数据集，类似于测试用例集，包括输入信息、参考答案；
评分标准，类似于评委的打分表，对于Agent的输出信息应该从哪些维度进行打分；
Agent应用输出信息；
评审专家，人工方式评估是需要人力来根据评测数据集、评分标准、Agent应用输出信息进行打分的，这个打分会有主观因素存在，但这也是当前比较合适的评估方式。
扩展下，除了使用人工评估，还可以把上面的评估打分方式交给大模型和Agent来处理，我们写好对应的Prompt即可，这也就是自动评估方式。
5.2 通过A/B测试方式进行评估
业务上线后可以针对线上环境对基于新模型的应用进行测试与评估。
A/B测试设计
将用户随机分为两组，一组使用旧模型（对照组），另一组使用新模型（实验组），对比两组的效果。例如，在推荐系统中，对比新旧模型的点击率、转化率等关键指标。
效果评估指标
定义明确的评估指标，如准确率、响应时间、用户满意度、业务转化率等。通过监控系统实时收集数据，分析新模型的表现。
迭代优化
根据A/B测试结果，优化新模型的参数、提示词（Prompt）或微调策略，逐步提升性能。
5.3 灰度发布上线
在以上业务验证后可以采用流量分层和灰度发布的方式进行部署，这与传统发布方式相同。
流量分层
将业务流量划分为多个层次，逐步增加新模型的流量占比。例如：
第一阶段：1%的流量切换到新模型。
第二阶段：10%的流量切换到新模型。
第三阶段：50%的流量切换到新模型。
最终阶段：全量切换。
如果是采用LLM Gateway方式，则按照流量分层方式将新模型纳入到LLM Gateway后端模型组中。
灰度发布
通过用户分层（如按地域、用户群体、设备类型）逐步放开新模型的使用范围。例如，可以先对新注册用户或特定地区的用户开放新模型功能。
6
Agent架构师
除了上面因素，选择模型还需要考虑价格、版本选型、本地部署还是云端部署等因素，在LLM Gateway中还有限流、鉴权、监控数据等统一处理。
Agent架构师负责Agent应用整体架构设计，也就需要在更多维度进行考虑和设计，比如合理部署模型与应用、通过模型微调/RAG/Prompt优化等方式进行性能优化、高可用/高可靠/可扩展设计、数据库/数据集/知识库进行管理、应用/数据/环境安全、应用/算法/使用方式合规、成本量化及优化、对模型/Agent/应用进行监控告警和运营分析。
（部分图片来自konghq.com、APIPark、火山引擎官网）
