从“复制粘贴”到“设计模式”：​一次AI系统LLM调用层的重构实践

在AI应用开发的初期，​为了追求快速上线，​我们常常会把各种逻辑一股脑地塞进业务代码里。​当业务模块还只有一个时，​这似乎是最高效的选择。​然而，​当第二个、第三个相似的模块出现时，​这种“短期最优解”很快就会演变成一颗随时可能引爆的“维护炸弹”。​最近，​我主导了公司AI聊天系统中LLM（大语言模型）调用层的重构，​深刻体会到设计模式并非教科书上的理论，​而是解决现实复杂性的实用工具。​

重构前，​我们的系统面临着典型的“复制粘贴”困境。​系统中有四个核心业务模块——AI伙伴群聊（ChatProcessor）、观点辩论场（DebateProcessor）、情绪树洞（TreeHoleService）和模型自动对话（ModelAutoChatService），​它们都需要调用大模型。​尽管业务场景各不相同，​但其底层的调用逻辑却高度相似：​构建HTTP请求、处理API Key、解析响应、处理流式数据。​这套逻辑被原封不动地复制了4份，​散落在各个业务类中，​累计约740行重复代码。​

这意味着，​每当需要新增一个模型供应商，​或是调整一次响应解析逻辑，​开发者都必须在4个文件中同步修改。​这不仅效率低下，​而且极易出错。​更糟糕的是，​当需要为所有LLM调用增加“调用次数统计”或“延迟监控”等横切关注点时，​因为没有统一的入口，​我们只能在4个类里各加一遍，​很容易遗漏。​问题的根源在于，​业务开发初期缺少前瞻性的架构设计，​将LLM调用逻辑与业务代码强耦合，​随着业务扩张，​其弊端暴露无遗。​

为了解决这一复杂性，​我引入了策略（Strategy）、工厂（Factory）和外观（Facade）三种设计模式，​构建了一个清晰的三层架构。​

首先是策略模式（Strategy），​它用于封装不同模型供应商的调用差异。​我们抽象出一个LLMStrategy接口，​定义了invoke（非流式）和invokeStream（流式）等标准方法。​然后，​为不同的供应商实现具体的策略类。​例如，​OpenAICompatStrategy覆盖了千问、DeepSeek等兼容OpenAI接口的模型；​而DoubaoStrategy则专门处理豆包早期非标准的/responses接口。​这样，​新增一个模型供应商，​只需增加一个新的策略类，​完全符合开闭原则，​对现有代码零侵入。​

其次是工厂模式（Factory），​它负责根据供应商名称，​自动路由到对应的策略。​业务层无需关心具体使用哪个策略类，​只需告诉工厂供应商的名字（如qwen或doubao），​工厂就会返回一个正确的LLMStrategy实例。​这实现了调用方与具体实现的解耦，​让业务代码更加干净。​

最关键的则是外观模式（Facade）。​我们创建了一个LLMInvoker类作为统一入口，​它收敛了所有“横切关注点”。​在LLMInvoker内部，​它首先通过工厂获取策略，​然后统一处理baseUrl解析、API Key选择、调用统计和日志记录等公共逻辑，​最后才委托给具体的策略去执行调用。​业务层从此只需调用llmInvoker.invoke()这一行简洁的代码，​即可完成所有复杂操作。​

重构的效果立竿见影。​业务层代码净减少了267行，​核心调用逻辑从4个分散的入口收敛为1个。​新增模型供应商的成本，​从修改4个文件降低为只增加1个策略类。​更重要的是，​所有LLM调用都自动接入了监控体系，​成功率、延迟等数据一目了然，​系统的可观测性得到了质的飞跃。​

这次重构让我明白，​设计模式不是银弹，​而是“复杂性管理工具”。​当重复代码出现、变化成为常态时，​恰当地引入一层抽象，​能将混乱梳理为清晰的流水线。​重构的终极目标，​从来不是为了炫技，​而是为了让下一次需求变更来得更快、更安全。