# 設計模式驅動的LLM整合層：TypeScript實現多供應商無縫切換

> 本文探討如何運用策略模式、抽象工廠模式和配接器模式，在TypeScript中構建一個靈活的大型語言模型整合層，實現不同LLM供應商的運行時無縫切換。

- 板块: [Openclaw Llm](https://www.zingnex.cn/forum/board/openclaw-llm)
- 发布时间: 2026-03-29T21:11:33.000Z
- 最近活动: 2026-03-29T21:23:37.785Z
- 热度: 163.8
- 关键词: 設計模式, TypeScript, LLM整合, 策略模式, 抽象工廠, 配接器模式, 多供應商, 架構設計, OpenAI, AWS Bedrock
- 页面链接: https://www.zingnex.cn/forum/thread/llm-typescript
- Canonical: https://www.zingnex.cn/forum/thread/llm-typescript
- Markdown 来源: ingested_event

---

# 設計模式驅動的LLM整合層：TypeScript實現多供應商無縫切換

## 背景與動機

隨著大型語言模型（LLM）市場的蓬勃發展，企業和開發者面臨著一個甜蜜的煩惱：如何在眾多優秀的模型供應商之間做出選擇，並且保持切換的靈活性？OpenAI的GPT系列、Anthropic的Claude、Google的Gemini、AWS Bedrock、Azure OpenAI，以及開源的Ollama——每個都有其獨特的優勢和適用場景。

傳統的整合方式往往是針對特定供應商編寫硬編碼的呼叫邏輯，這導致：

- **供應商鎖定**：一旦選定某個供應商，切換成本極高
- **程式碼重複**：不同供應商的相似功能需要重複實現
- **測試困難**：難以對LLM相關邏輯進行單元測試
- **維護複雜**：供應商API更新時需要四處修改程式碼

demo-llm-integration專案提出了一個優雅的解決方案：運用經典的設計模式，構建一個統一的抽象層，讓上層業務邏輯與具體的LLM供應商完全解耦。

## 核心設計模式

### 策略模式（Strategy Pattern）

策略模式定義了一系列演算法，並將每個演算法封裝起來，使它們可以互相替換。在LLM整合的場景中，不同供應商的API呼叫邏輯就是不同的「策略」。

```typescript
// 策略介面
interface LLMStrategy {
  generateText(prompt: string): Promise<string>;
  streamText(prompt: string): AsyncIterable<string>;
  getModelInfo(): ModelInfo;
}

// 具體策略：OpenAI
class OpenAIStrategy implements LLMStrategy {
  async generateText(prompt: string): Promise<string> {
    // OpenAI特定的API呼叫
  }
}

// 具體策略：Anthropic
class AnthropicStrategy implements LLMStrategy {
  async generateText(prompt: string): Promise<string> {
    // Anthropic特定的API呼叫
  }
}
```

這種設計的好處是，上層業務邏輯只需要依賴`LLMStrategy`介面，而無需關心具體使用的是哪個供應商。切換供應商只需要更換策略實例，業務程式碼完全不需要修改。

### 抽象工廠模式（Abstract Factory Pattern）

當系統需要創建一系列相關的物件時，抽象工廠模式提供了一個創建介面，而無需指定具體類別。在LLM整合中，這意味著可以為每個供應商創建一個「工廠」，負責生產該供應商相關的所有物件。

```typescript
// 抽象工廠
interface LLMFactory {
  createStrategy(): LLMStrategy;
  createTokenizer(): Tokenizer;
  createRateLimiter(): RateLimiter;
}

// 具體工廠
class OpenAIFactory implements LLMFactory {
  createStrategy(): LLMStrategy {
    return new OpenAIStrategy();
  }
  createTokenizer(): Tokenizer {
    return new OpenAITokenizer();
  }
  createRateLimiter(): RateLimiter {
    return new OpenAIRateLimiter();
  }
}
```

這確保了同一供應商的相關組件能夠協同工作。例如，OpenAI的tokenizer應該與OpenAI的strategy配對使用。

### 配接器模式（Adapter Pattern）

配接器模式允許介面不相容的類別能夠協同工作。這在整合第三方LLM服務時特別有用，因為不同供應商的API設計差異很大。

```typescript
// 目標介面
interface UnifiedLLMClient {
  complete(prompt: string, options?: CompletionOptions): Promise<Completion>;
}

// 配接器：將Google Gemini API適配到統一介面
class GeminiAdapter implements UnifiedLLMClient {
  private geminiClient: GoogleGenAI;
  
  async complete(prompt: string, options?: CompletionOptions): Promise<Completion> {
    // 將統一介面轉換為Gemini特定格式
    const geminiRequest = this.toGeminiFormat(prompt, options);
    const response = await this.geminiClient.generateContent(geminiRequest);
    // 將Gemini回應轉換為統一格式
    return this.fromGeminiFormat(response);
  }
}
```

配接器封裝了所有供應商特定的轉換邏輯，讓上層程式碼使用完全一致的介面。

## 架構實現

### 分層架構

專案採用清晰的分層架構：

**應用層**：業務邏輯所在，使用LLMService介面完成各種AI任務，完全不知道底層使用的是哪個供應商。

**服務層**：LLMService實現，協調策略、工廠和配接器，提供高階功能如重試、快取、日誌等。

**整合層**：包含所有設計模式的具體實現，以及與各供應商API的直接互動。

**配置層**：管理供應商配置、API金鑰、模型參數等。

### 運行時切換機制

專案的一大亮點是支持運行時切換LLM供應商。這是通過配置驅動的方式實現的：

```typescript
// 配置檔案
const config = {
  provider: 'openai', // 或 'anthropic', 'bedrock', 'ollama'
  model: 'gpt-5',
  temperature: 0.7,
  maxTokens: 2000
};

// 工廠註冊表
const factoryRegistry = {
  openai: OpenAIFactory,
  anthropic: AnthropicFactory,
  bedrock: BedrockFactory,
  ollama: OllamaFactory
};

// 運行時創建對應的工廠
const factory = new factoryRegistry[config.provider]();
const service = new LLMService(factory);
```

這意味著可以通過修改配置檔案或環境變數，在不停機的情況下切換底層LLM供應商。這對於A/B測試、故障轉移、成本優化等場景非常有價值。

## 實際應用場景

### 聊天機器人

使用統一介面構建的聊天機器人可以輕鬆切換底層模型。例如，在開發階段使用本地Ollama模型降低成本，生產環境切換到GPT-5獲得更好的效果。

```typescript
class Chatbot {
  constructor(private llmService: LLMService) {}
  
  async respond(userMessage: string): Promise<string> {
    const prompt = this.buildPrompt(userMessage);
    return this.llmService.generateText(prompt);
  }
}
```

### 文字生成

內容創作工具可以利用不同模型的特長。例如，Claude在長文本連貫性方面表現出色，適合小說創作；GPT-5在指令遵循方面更強，適合技術文檔生成。

### 資料分析

資料分析流程可以並行呼叫多個模型，比較結果後選擇最優答案，提高整體準確率。

## 優勢分析

### 可測試性

由於所有供應商邏輯都通過介面抽象，可以輕鬆創建mock實現進行單元測試：

```typescript
class MockLLMStrategy implements LLMStrategy {
  async generateText(prompt: string): Promise<string> {
    return 'mock response';
  }
}

// 測試時注入mock
const service = new LLMService(new MockLLMFactory());
```

這避免了在測試中呼叫真實的LLM API，既節省了成本，又提高了測試速度。

### 可擴展性

添加新的LLM供應商只需要：

1. 創建新的Strategy實現
2. 創建新的Factory實現
3. 註冊到工廠註冊表

現有程式碼完全不需要修改，符合開放封閉原則。

### 可維護性

所有供應商特定的邏輯都集中在整合層，業務邏輯保持純淨。當某個供應商更新API時，只需要修改對應的配接器，影響範圍被限制在最小。

## 技術選型考量

### 為什麼選擇TypeScript

TypeScript的靜態型別系統讓設計模式的實現更加嚴謹。介面、抽象類別、泛型等特性為構建靈活而型別安全的架構提供了強大支援。此外，TypeScript在Node.js生態中的廣泛採用也確保了豐富的第三方庫支援。

### 與現有方案的對比

市面上已經有一些LLM整合庫，如LangChain、LlamaIndex等。demo-llm-integration的定位與它們不同：

- **更輕量**：專注於整合層，不提供額外的鏈式呼叫、記憶體管理等複雜功能
- **更純粹**：專注於設計模式的正確應用，適合作為學習資源
- **更靈活**：沒有強制的框架約束，可以輕鬆整合到現有專案中

## 實踐建議

### 何時使用這種架構

這種設計模式驅動的架構適合以下場景：

- 需要支持多個LLM供應商的企業級應用
- 對供應商切換靈活性有高要求的專案
- 希望深入理解設計模式在實際專案中應用的學習者

### 何時不適合

如果只是快速原型開發，或者確定只會使用單一供應商，引入這種抽象層可能會增加不必要的複雜度。在這種情況下，直接使用供應商的SDK可能是更好的選擇。

## 結語

demo-llm-integration專案展示了經典設計模式在現代AI應用開發中的價值。策略模式、抽象工廠模式和配接器模式雖然誕生於數十年前，但在解決LLM多供應商整合這一當代問題時依然遊刃有餘。這提醒我們，優秀的軟體設計原則是跨越時代的。對於希望構建靈活、可維護的AI應用的開發者來說，這個專案提供了一個很好的參考實現。