💡

文章摘要

2026 年 6 月,Anthropic Fable 5/Mythos 5 出口管制事件给全球企业上了一堂残酷的课:依赖单一 AI 模型供应商是危险的。但更深层的洞察是:模型能力本身不是护城河,编排层才是。本文深度分析为什么 OpenAI、Anthropic、Google 的竞争本质是编排层竞争,企业如何构建多模型路由策略,以及如何避免供应商锁定。6 月 19 日更新:补充 GLM-5.2 开源替代方案和最新市场数据。

一、Anthropic 事件的企业启示:可用性 > 能力

2026 年 6 月 12 日,Anthropic 被迫在全球范围内关闭 Fable 5 和 Mythos 5 模型。 数百万用户在一夜之间失去了对最强 AI 模型的访问。

对于企业来说,这是一个警钟:

  • 你依赖的模型可能随时不可用——不是因为技术故障,而是因为政治决策
  • 模型能力再强,如果无法访问,价值就是零
  • 供应商锁定不是理论风险,而是现实威胁

但更深层的洞察来自 AI Business 的分析:OpenAI、Anthropic、Google 之间的竞争,表面上是模型能力竞赛,实质是编排层竞争。

💡 关键洞察:模型能力不是护城河,编排逻辑才是。企业关注的不是「哪个模型最强」,而是「如何灵活切换模型而不影响业务」。

动量评分的真实含义

AI Business 给出的动量评分(Momentum Score)揭示了一个反直觉的事实:

公司 动量评分 纸面能力 实际市场地位
OpenAI 10/10 编排层最成熟
Anthropic 8/10 被管制削弱
Google 3/10 失去叙事主动权

Google 的悖论:纸面能力领先(Gemini 2.5 Pro 在多项基准上表现优异),但动量评分最低。为什么?因为 Google 在编排层竞争中落后——企业不知道如何灵活使用 Gemini,而 OpenAI 和 Anthropic 已经建立了成熟的编排生态。

核心结论:企业 AI 战略的关键不是选择「最强模型」,而是构建「最灵活的编排层」。

图表加载中…

💡 一句话理解

评估你的 AI 供应商策略:如果某个模型明天不可用,你的业务能继续运行吗?如果不能,你需要多模型路由

⚠️ 常见踩坑

不要被供应商叙事绑架。Google 的案例表明,纸面能力 ≠ 市场成功。编排层的成熟度才是关键。

二、编排层竞争:被忽视的战场

编排层(Orchestration Layer 是什么?它是介于「业务逻辑」和「AI 模型」之间的中间层,负责:

  • 模型路由:根据任务类型、成本预算、延迟要求,选择最合适的模型
  • 负载均衡:在多个模型实例之间分配请求
  • 故障转移:当某个模型不可用时,自动切换到备选模型
  • 成本优化:在满足质量要求的前提下,最小化推理成本
  • 供应商抽象:屏蔽不同模型 API 的差异,提供统一接口

为什么编排层比模型更重要?

类比:想象你在经营一个物流公司。你可以选择最快的货车(模型),但如果你的调度系统(编排层)很糟糕,整体效率仍然很低。相反,即使你的车不是最快的,但调度系统优秀,你仍然可以比竞争对手更快、更便宜地交付。

现实案例

2026 年 5 月,某金融科技公司做了一个实验:

  • 方案 A:全部使用 GPT-5.5(当时最强模型),成本 $15/M tokens
  • 方案 B:使用编排层,根据任务类型路由到不同模型(70% 简单任务用 7B 模型,20% 中等任务用 70B 模型,10% 复杂任务用 GPT-5.5)

结果:

指标 方案 A(纯 GPT-5.5) 方案 B(编排层) 差距
成本 $15/M tokens $2.3/M tokens 降低 85%
延迟 300ms 120ms 降低 60%
质量得分 82/100 85/100 提升 3 分

为什么质量反而提升了? 因为编排层可以为每个任务选择「最合适的模型」,而不是「最强的模型」。简单任务用小模型足够,复杂任务才用大模型——这种精准匹配比「一刀切」效果更好。

编排层的核心组件

一个生产级的编排层通常包含:

  1. 请求分析器:理解任务类型、复杂度、成本敏感度
  2. 路由策略引擎:基于规则或机器学习的路由决策
  3. 模型注册表:管理所有可用模型的能力、成本、延迟、可用性
  4. 负载均衡器:在多个模型实例之间分配请求
  5. 故障转移机制:自动检测模型不可用并切换
  6. 成本追踪器:实时监控和优化推理成本
  7. 质量监控器:评估每个模型的输出质量,动态调整路由
图表加载中…

💡 一句话理解

编排层不是银弹——它增加了系统复杂度。如果你的 AI 使用场景简单(如只做文本分类),直接用单一模型可能更合适。

⚠️ 常见踩坑

编排层的故障转移机制必须经过充分测试。2026 年 3 月,某公司因故障转移配置错误,在 GPT-5.5 宕机时切换到了一个能力不足的备选模型,导致输出质量暴跌。

三、多模型路由策略:实战指南

模型路由不是「把所有模型都接入系统」那么简单。它需要精心设计的策略。

3.1 路由策略的三种模式

模式一:基于规则的路由(Rule-Based Routing)

最简单的方式:根据预定义规则路由。

优势:简单、可预测、易调试
劣势:无法适应模型性能变化、需要人工维护规则

模式二:基于性能的路由(Performance-Based Routing)

根据模型的实时性能指标动态路由。

优势:自动适应模型性能变化、优化成本效率
劣势:需要实时性能监控、可能产生意外行为

模式三:基于强化学习的路由(RL-Based Routing)

使用强化学习训练路由策略,最大化长期奖励(质量 + 成本 + 延迟的综合指标)。

优势:可以学习复杂的路由策略、长期优化
劣势:需要大量训练数据、调试困难

3.2 故障转移策略

故障转移是多模型路由的关键价值之一。

策略一:主动-被动(Active-Passive)

  • 主模型处理所有请求
  • 备选模型待命
  • 主模型不可用时切换到备选

策略二:主动-主动(Active-Active)

  • 多个模型同时处理请求
  • 选择质量最好的输出
  • 或者使用投票机制

策略三:分级降级(Graceful Degradation)

  • 优先使用最强模型
  • 如果不可用,降级到次强模型
  • 如果次强也不可用,降级到基础模型
图表加载中…
typescript
function routeRequest(task: Task): Model {
  if (task.type === 'classification' && task.complexity < 0.3) {
    return '7b-model';  // 简单分类任务
  } else if (task.type === 'reasoning' && task.complexity < 0.7) {
    return '70b-model';  // 中等推理任务
  } else {
    return 'gpt-5.5';    // 复杂任务
  }
}
typescript
async function routeByPerformance(task: Task): Promise<Model> {
  const models = await getAvailableModels();
  
  // 选择质量得分 / 成本 比值最高的模型
  const bestModel = models
    .filter(m => m.supports(task.type))
    .sort((a, b) => {
      const scoreA = a.qualityScore / a.costPerToken;
      const scoreB = b.qualityScore / b.costPerToken;
      return scoreB - scoreA;
    })[0];
  
  return bestModel.id;
}
python
class RoutingAgent:
    def __init__(self):
        self.policy = PolicyNetwork()
        self.optimizer = torch.optim.Adam(self.policy.parameters())
    
    def select_model(self, task_embedding):
        # 根据任务特征选择模型
        model_probs = self.policy(task_embedding)
        model_id = torch.argmax(model_probs)
        return model_id
    
    def update(self, task, model_id, quality, cost, latency):
        # 根据结果更新策略
        reward = quality - cost_weight * cost - latency_weight * latency
        self.policy.update(task, model_id, reward)
typescript
async function activePassiveRoute(task: Task): Promise<Response> {
  try {
    return await callModel('primary-model', task);
  } catch (error) {
    console.warn('Primary model failed, switching to backup');
    return await callModel('backup-model', task);
  }
}
typescript
async function activeActiveRoute(task: Task): Promise<Response> {
  const responses = await Promise.all([
    callModel('model-a', task),
    callModel('model-b', task),
    callModel('model-c', task),
  ]);
  
  // 选择质量得分最高的
  return responses.sort((a, b) => b.quality - a.quality)[0];
}
typescript
async function gracefulDegradation(task: Task): Promise<Response> {
  const models = ['gpt-5.5', 'claude-opus-4.8', 'gemini-2.5-pro', '7b-fallback'];
  
  for (const model of models) {
    try {
      const response = await callModel(model, task);
      if (response.quality >= task.minQuality) {
        return response;
      }
    } catch (error) {
      console.warn(\`Model \${model} failed, trying next\`);
    }
  }
  
  throw new Error('All models failed');
}

💡 一句话理解

从基于规则的路由开始,积累数据后再考虑基于性能或 RL 的路由。过度工程化是早期项目的常见错误。

⚠️ 常见踩坑

主动-主动策略的成本是主动-被动的 3 倍(因为要调用 3 个模型)。只在质量要求极高的场景使用。

四、避免供应商锁定:架构设计原则

供应商锁定不是商业问题,而是架构问题。如果你的代码深度耦合了某个模型的 API,切换成本会非常高。

4.1 抽象层设计

核心原则:业务逻辑不应该直接调用模型 API,而是通过抽象层。

4.2 模型无关的 Prompt 设计

不同模型的 Prompt 最佳实践可能不同,但核心逻辑应该保持一致。

策略:使用模板引擎,为每个模型定制 Prompt,但保持输入输出格式一致。

4.3 数据格式标准化

不同模型的输出格式可能不同,需要标准化。

4.4 多云部署

即使使用同一个模型,也应该在多个云服务商部署,避免单一云服务商故障。

示例架构

  • AWS Bedrock:运行 OpenAI 模型(通过 Azure 桥接)
  • Azure OpenAI:运行 OpenAI 模型(原生)
  • GCP Vertex AI:运行 Gemini 模型
  • 自建集群:运行开源模型(Llama、Mistral)

编排层可以根据云服务商的健康状况和成本动态路由。

图表加载中…
typescript
// ❌ 错误:直接耦合 OpenAI API
import OpenAI from 'openai';
const client = new OpenAI();

async function analyzeSentiment(text: string) {
  const response = await client.chat.completions.create({
    model: 'gpt-5.5',
    messages: [{ role: 'user', content: \`Analyze sentiment: \${text}\` }],
  });
  return response.choices[0].message.content;
}

// ✅ 正确:通过抽象层
interface AIProvider {
  chat(messages: Message[]): Promise<string>;
  supports(taskType: TaskType): boolean;
  getCost(): CostInfo;
}

class OpenAIProvider implements AIProvider {
  async chat(messages: Message[]): Promise<string> {
    // OpenAI 特定实现
  }
  supports(taskType: TaskType): boolean {
    return ['reasoning', 'coding', 'analysis'].includes(taskType);
  }
  getCost(): CostInfo {
    return { perToken: 0.000015 };
  }
}

class AnthropicProvider implements AIProvider {
  // Anthropic 特定实现
}

// 业务逻辑通过抽象层调用
async function analyzeSentiment(text: string, provider: AIProvider) {
  return await provider.chat([
    { role: 'user', content: \`Analyze sentiment: \${text}\` }
  ]);
}
typescript
class PromptTemplate {
  private templates: Record<string, string> = {
    'openai': 'Analyze the sentiment of the following text. Respond with JSON: {"sentiment": "positive|negative|neutral", "confidence": 0-1}\\n\\nText: {text}',
    'anthropic': 'You are a sentiment analysis expert. Analyze the text and respond in JSON format with "sentiment" and "confidence" fields.\\n\\nText: {text}',
    'local': 'Sentiment: {text}\\nOutput: ',
  };

  render(model: string, text: string): string {
    const template = this.templates[model] || this.templates['openai'];
    return template.replace('{text}', text);
  }
}
typescript
interface NormalizedResponse {
  content: string;
  model: string;
  latency: number;
  cost: number;
  quality?: number;
}

function normalizeResponse(provider: string, raw: any): NormalizedResponse {
  switch (provider) {
    case 'openai':
      return {
        content: raw.choices[0].message.content,
        model: raw.model,
        latency: raw.usage.latency_ms,
        cost: raw.usage.total_tokens * 0.000015,
      };
    case 'anthropic':
      return {
        content: raw.content[0].text,
        model: raw.model,
        latency: raw.usage.latency_ms,
        cost: raw.usage.input_tokens * 0.000003 + raw.usage.output_tokens * 0.000015,
      };
    default:
      throw new Error(\`Unknown provider: \${provider}\`);
  }
}

💡 一句话理解

抽象层的成本很低,但收益很高。即使你现在只用一个模型,也应该从第一天就设计抽象层——未来切换模型的成本会降低 10 倍。

⚠️ 常见踩坑

不要过度抽象。如果你的业务只需要一个模型,简单的封装就够了。抽象层的复杂度应该与你的需求匹配。

五、成本优化:编排层的核心价值

成本优化是编排层最直接的价值。让我们通过一个真实案例来看。

5.1 案例:电商客服系统

某电商平台的 AI 客服系统每天处理 100 万条对话。

初始方案:全部使用 GPT-5.5

  • 成本:$15/M tokens × 平均 2000 tokens/对话 × 100 万对话 = $30,000/天
  • 延迟:平均 300ms
  • 质量:客户满意度 85%

优化方案:引入编排层

任务分析:

  • 60% 简单查询(订单状态、退货政策)→ 用 7B 模型
  • 25% 中等复杂(商品推荐、投诉处理)→ 用 70B 模型
  • 15% 复杂场景(纠纷调解、法律问题)→ 用 GPT-5.5

结果

指标 优化前 优化后 改善
日成本 $30,000 $4,200 降低 86%
平均延迟 300ms 150ms 降低 50%
客户满意度 85% 87% 提升 2%

为什么满意度反而提升了? 因为简单任务用小模型响应更快(50ms vs 300ms),客户体验更好。

5.2 成本优化的三个层次

层次一:任务级路由

根据任务类型选择模型(如上面的案例)。

层次二:动态定价感知

根据模型的实时定价调整路由。

层次三:批量优化

将多个请求批量处理,降低单位成本。

5.3 成本监控与告警

实时监控成本,设置告警阈值。

图表加载中…
typescript
const routingRules = {
  'order_status': { model: '7b', cost: 0.000001 },
  'return_policy': { model: '7b', cost: 0.000001 },
  'product_recommendation': { model: '70b', cost: 0.000005 },
  'complaint_handling': { model: '70b', cost: 0.000005 },
  'dispute_resolution': { model: 'gpt-5.5', cost: 0.000015 },
  'legal_inquiry': { model: 'gpt-5.5', cost: 0.000015 },
};
typescript
async function routeByPricing(task: Task): Promise<Model> {
  const models = await getAvailableModels();
  const currentPrices = await getCurrentPricing(models);
  
  // 选择性价比最高的模型
  const bestValue = models
    .filter(m => m.supports(task.type))
    .sort((a, b) => {
      const valueA = a.qualityScore / currentPrices[a.id];
      const valueB = b.qualityScore / currentPrices[b.id];
      return valueB - valueA;
    })[0];
  
  return bestValue.id;
}
typescript
class BatchOptimizer {
  private queue: Task[] = [];
  private batchSize = 10;
  private flushInterval = 1000; // 1 秒

  async submit(task: Task): Promise<Response> {
    this.queue.push(task);
    
    if (this.queue.length >= this.batchSize) {
      await this.flush();
    }
    
    return task.promise;
  }

  private async flush() {
    const batch = this.queue.splice(0, this.batchSize);
    
    // 批量调用可能有折扣
    const responses = await callModelBatch('7b-model', batch);
    
    batch.forEach((task, i) => {
      task.resolve(responses[i]);
    });
  }
}
typescript
class CostMonitor {
  private dailyBudget = 1000; // $1000/天
  private hourlyBudget = 50;  // $50/小时
  private currentDailyCost = 0;
  private currentHourlyCost = 0;

  track(cost: number) {
    this.currentDailyCost += cost;
    this.currentHourlyCost += cost;
    
    if (this.currentDailyCost > this.dailyBudget * 0.8) {
      this.alert('Daily cost approaching 80%');
    }
    
    if (this.currentHourlyCost > this.hourlyBudget) {
      this.alert('Hourly budget exceeded, switching to cheaper models');
      this.enableCostSavingMode();
    }
  }

  private enableCostSavingMode() {
    // 强制路由到最便宜的模型
    setRoutingPreference('cheapest');
  }
}

💡 一句话理解

从任务级路由开始,这是成本节省的最大来源。动态定价和批量优化是锦上添花,但不是必须的。

⚠️ 常见踩坑

成本优化不能以质量为代价。设置质量下限(如客户满意度 ≥ 85%),成本优化必须在质量约束内进行。

六、实战建议:从零构建编排层

如果你现在要从零构建编排层,这是我的建议路径。

阶段一:基础抽象(1-2 周)

  1. 定义 AIProvider 接口
  2. 实现 2-3 个 Provider(OpenAI、Anthropic、本地模型)
  3. 实现简单的规则路由(按任务类型)
  4. 统一响应格式

阶段二:故障转移(1 周)

  1. 实现主动-被动故障转移
  2. 添加健康检查
  3. 实现自动重试

阶段三:成本优化(2-3 周)

  1. 添加成本追踪
  2. 实现基于性能的路由
  3. 添加成本告警

阶段四:高级功能(持续迭代)

  1. 基于 RL 的路由
  2. 批量优化
  3. 多云部署
  4. 质量监控与自动调优

关键原则

  • 从简单开始:不要一开始就构建复杂的 RL 路由
  • 渐进式演进:根据实际需求逐步添加功能
  • 监控驱动:先监控,再优化
  • 质量优先:成本优化不能牺牲质量
图表加载中…
typescript
// 最小可行编排层
interface AIProvider {
  chat(messages: Message[]): Promise<string>;
  supports(taskType: string): boolean;
}

class SimpleRouter {
  private providers: Map<string, AIProvider> = new Map();

  register(name: string, provider: AIProvider) {
    this.providers.set(name, provider);
  }

  async route(taskType: string, messages: Message[]): Promise<string> {
    for (const [name, provider] of this.providers) {
      if (provider.supports(taskType)) {
        return await provider.chat(messages);
      }
    }
    throw new Error('No provider supports this task type');
  }
}
typescript
class RouterWithFailover {
  async route(taskType: string, messages: Message[]): Promise<string> {
    const providers = this.getProvidersForTask(taskType);
    
    for (const provider of providers) {
      try {
        if (await this.isHealthy(provider)) {
          return await provider.chat(messages);
        }
      } catch (error) {
        console.warn(\`Provider \${provider.name} failed, trying next\`);
      }
    }
    
    throw new Error('All providers failed');
  }

  private async isHealthy(provider: AIProvider): Promise<boolean> {
    try {
      await provider.chat([{ role: 'user', content: 'ping' }]);
      return true;
    } catch {
      return false;
    }
  }
}

💡 一句话理解

阶段一和阶段二是必须的,阶段三和阶段四可以根据实际需求决定。不要过度工程化。

⚠️ 常见踩坑

编排层的复杂度应该与你的业务规模匹配。如果你的日请求量 < 10 万,简单的规则路由就够了。

七、结论:编排层是新的竞争力

2026 年的 AI 竞争格局已经清晰:模型能力不是护城河,编排层才是。

Anthropic 出口管制事件给所有企业上了一课:

  1. 模型可用性是政治变量——你不能控制政治决策,但你可以控制架构
  2. 供应商锁定是现实威胁——抽象层和多模型路由是对冲手段
  3. 成本优化是编排层的核心价值——通过精准匹配任务和模型,可以降低成本 80%+
  4. 质量可以提升——编排层不是「降级」,而是「精准匹配」

给企业的建议

  • 立即行动:评估你的 AI 供应商策略,识别单点故障
  • 投资抽象层:从今天开始设计模型无关的架构
  • 渐进式演进:从简单路由开始,逐步添加功能
  • 监控驱动:先监控成本和性能,再优化
  • 质量优先:成本优化必须在质量约束内进行

给开发者的建议

  • 学习编排层设计:这是 2026 年最重要的 AI 工程技能之一
  • 理解多模型策略:不要只熟悉一个模型的 API
  • 关注成本优化:企业最关心的不是模型能力,而是成本效率
  • 实践故障转移:这是生产系统的必备能力

最后的话AI 编排层不是技术细节,而是战略选择。它决定了你的企业在 AI 时代的灵活性和竞争力。不要等到 Anthropic 事件发生在你的供应商身上才开始行动——现在就构建你的编排层。

图表加载中…

💡 一句话理解

编排层不是一次性项目,而是持续演进的架构。从简单开始,根据实际需求逐步添加功能。

⚠️ 常见踩坑

不要等待完美方案。现在就开始构建你的编排层,即使它很简单——简单的编排层也比没有强 10 倍。

八、6 月 19 日更新:GLM-5.2 开源替代与编排层新变量

距离本文初稿发布仅一周,AI 编排层的竞争格局已经发生了显著变化。 智谱 GLM-5.2 的发布(MIT 开源)和 Anthropic 管制的持续,为编排层策略引入了新的变量。

8.1 GLM-5.2 对编排层的影响

智谱 GLM-5.2 的核心参数回顾:

  • 744B MoE 架构,激活 40B 参数
  • 100 万 Token 上下文
  • CodeV3 评测全球第三(仅次于 GPT-5.5 和 Opus 4.8)
  • MIT 协议开源(可商用、可修改、可闭源衍生)

对编排层的三个关键影响:

1. 开源模型首次成为编排层的「一等公民」

在此之前,编排层的多模型路由主要在不同闭源 API 之间切换(OpenAI ↔ Anthropic ↔ Google)。GLM-5.2 的 MIT 开源意味着:

  • 企业可以自托管 GLM-5.2,完全不受出口管制影响
  • 编排层可以将 GLM-5.2 作为成本最低的选项(自托管无 API 费用)
  • 闭源模型和开源模型混合路由成为新范式

2. 「模型主权」概念兴起

Anthropic 事件后,「模型主权」(Model Sovereignty)成为企业关注的新概念:

  • 定义:企业对 AI 模型拥有完全控制权,不受外部政策影响
  • 实现路径:自托管开源模型(GLM-5.2、DeepSeek-V4)
  • 编排层角色:在自托管模型和闭源 API 之间智能路由

3. 成本结构重塑

GLM-5.2 的定价预期(约为 Claude Opus 4.8 的 1/3 到 1/5)进一步改变了编排层的成本优化空间:

模型 输入价格 输出价格 编排层角色
GLM-5.2 (API) ~¥0.10/千Token ~¥0.15/千Token 中等任务首选
GLM-5.2 (自托管) 硬件成本 硬件成本 高频任务首选
Claude Opus 4.8 $5/MTok $25/MTok 复杂任务
GPT-5.5 未公开 未公开 最强能力任务
Gemini 3.5 Flash $1.50/MTok $9.00/MTok 性价比任务

8.2 更新后的编排层策略建议

新增策略:闭源 + 开源自托管混合路由

8.3 预测市场与未来走向

截至 6 月 19 日的新数据点:

  • 预测市场:58-67% 概率在 7 月前恢复 Fable 5/Mythos 5 访问
  • 智谱港股GLM-5.2 发布后单日收盘涨 32.91%,盘中最高涨幅达 47.6%,总市值突破 6496 亿港元
  • 开源模型趋势GLM-5.2、Kimi K2.7 Code 均进入代码能力 Tier A

对编排层的影响:

  1. 如果 Fable 5 恢复:编排层多一个选项,但开源模型的竞争力已经确立
  2. 如果管制持续:开源模型(GLM-5.2)成为编排层的必选项
  3. 无论哪种情况:多模型 + 开源自托管的混合编排将成为主流

8.4 行动清单(更新版)

新增行动项:

  • 评估 GLM-5.2 作为自托管选项的可行性
  • 在编排层中加入开源模型路由
  • 建立「模型主权」策略,减少对闭源 API 的依赖
  • 监控 GLM-5.2 API 定价(下周上线),更新成本模型

原有行动项仍然有效:

  • 评估 AI 供应商策略的风险暴露
  • 建立多模型架构和切换能力
  • 投资抽象层设计
  • 实施动态路由和降级策略
图表加载中…
typescript
// 更新后的路由策略示例
const routingStrategy = {
  // 简单任务:使用自托管 GLM-5.2(零 API 成本)
  simple: {
    model: 'glm-5-2-self-hosted',
    thinking: 'standard',
    cost: '$0 (self-hosted)',
    fallback: 'gemini-3.5-flash'
  },
  // 中等任务:使用 GLM-5.2 API(成本约为 Opus 的 1/5)
  medium: {
    model: 'glm-5-2-api',
    thinking: 'high',
    cost: '~$0.50/MTok',
    fallback: 'claude-opus-4.8'
  },
  // 复杂任务:使用闭源旗舰模型
  complex: {
    model: 'claude-opus-4.8',
    thinking: 'high',
    cost: '$5/$25 MTok',
    fallback: 'gpt-5.5'
  },
  // 超长上下文:使用 GLM-5.2(100 万 Token)
  longContext: {
    model: 'glm-5-2-api',
    maxTokens: 1_000_000,
    cost: '~$0.50/MTok',
    fallback: 'gemini-3.5-pro'
  }
};

💡 一句话理解

GLM-5.2 的 MIT 开源为编排层引入了新的维度:自托管。企业可以在自托管开源模型和闭源 API 之间智能路由,进一步降低成本和风险。

⚠️ 常见踩坑

GLM-5.2 虽然代码能力进入 Tier A,但与 GPT-5.5 和 Opus 4.8 仍有差距。编排层应根据任务复杂度选择合适的模型,不要盲目用开源替代闭源。