在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调用都自动接入了监控体系，成功率、延迟等数据一目了然，系统的可观测性得到了质的飞跃。
这次重构让我明白，设计模式不是银弹，而是“复杂性管理工具”。当重复代码出现、变化成为常态时，恰当地引入一层抽象，能将混乱梳理为清晰的流水线。重构的终极目标，从来不是为了炫技，而是为了让下一次需求变更来得更快、更安全。
