1. 项目概述：为什么你的AI代理需要一个“成本大脑”

在AI代理的开发中，我们常常陷入一个技术至上的怪圈：为了追求那一点点可能的质量提升，默认选择最强大、最昂贵的模型。这就像每次出门买菜都开一辆重型卡车——确实能装，但油费和停车费会让你怀疑人生。在原型验证阶段，这种“火力全开”的策略无可厚非，毕竟首要目标是验证想法的可行性。然而，一旦进入生产环境，面对每天成千上万次的调用，这种粗放的策略就会迅速转化为惊人的成本黑洞。

问题的核心在于，AI模型的世界正在以惊人的速度演进。新的模型如雨后春笋般涌现，各家云服务商的价格表也像股市一样频繁波动。今天性价比最高的模型，下个月可能就被新品取代。与此同时，不同的任务对模型能力的需求天差地别：一个简单的文本摘要任务，可能完全不需要GPT-4级别的复杂推理能力；而一个涉及多步骤代码生成和工具调用的复杂工作流，用轻量级模型来处理又可能力不从心，导致任务失败或结果质量低下。

因此，为你的AI代理引入“成本感知”（Cost-Aware）的模型选择能力，不再是“锦上添花”的优化，而是“雪中送炭”的必需。这本质上是为你的代理装备一个动态的、实时的“成本大脑”，让它能根据当前任务的具体需求（复杂度、所需功能）和最新的市场价格，智能地匹配合适的模型，在保证任务成功率和质量的前提下，将每一次调用的成本控制在最优区间。

2. 核心方案解析：WhichModel与MCP架构

要实现上述目标，我们面临几个现实的工程挑战：第一，需要一个持续更新、覆盖主流厂商的模型价格与能力数据库；第二，需要一套逻辑来评估任务需求并与模型能力进行匹配；第三，需要将这套决策系统无缝集成到现有的AI代理工作流中。手动维护这些信息无异于一场噩梦，这正是开源项目WhichModel及其采用的MCP（Model Context Protocol）架构所要解决的问题。

2.1 MCP：AI代理的“插件”标准

在深入WhichModel之前，有必要理解MCP。你可以把它想象成AI世界的“USB标准”。过去，每个AI应用（如Claude Desktop、Cursor IDE）如果想接入外部工具或数据源，都需要开发者为其编写特定的、紧耦合的集成代码，过程繁琐且难以复用。

MCP的出现定义了一套标准协议，允许任何服务器（称为MCP Server）以统一的方式向兼容MCP的客户端（称为MCP Client，通常是AI应用或代理框架）提供工具（Tools）和资源（Resources）。对于客户端来说，它只需要实现一次MCP协议，就能接入无数个由社区或第三方开发的MCP Server，从而获得读取文件、查询数据库、调用API等扩展能力。这极大地提升了AI代理的模块化程度和可扩展性。

2.2 WhichModel：你的实时模型成本顾问

WhichModel就是一个专门构建的MCP Server。它的核心职责非常聚焦：

  1. 聚合数据 ：持续爬取和整合来自OpenAI、Anthropic、Google、Meta、Cohere等主流提供商以及众多开源模型的定价信息（按输入/输出Token计费）、上下文长度、功能支持（如工具调用、JSON模式、视觉理解）等元数据。
  2. 提供决策工具 ：通过MCP协议，向连接的AI代理暴露几个关键的工具函数，例如 recommend_model （推荐模型）、 compare_models （对比模型）。
  3. 执行成本优化逻辑 ：在内部，它封装了根据任务类型、复杂度、预算约束来筛选和排序模型的算法逻辑。

采用WhichModel方案，意味着你将模型选型和成本优化的复杂性外包给了一个专精于此的服务。你的代理无需关心价格表何时更新、哪个模型新发布了什么功能，它只需要在需要调用LLM时，先“询问”一下WhichModel：“嘿，我有个这样的活儿，预算大概这么多，你看派谁去最划算？”

注意 ：WhichModel作为远程MCP Server运行，其数据更新频率（例如每4小时）是其价值的关键。这确保了推荐所依据的价格信息具有很高的时效性，避免了因使用过时价格数据而导致的决策失误。

3. 环境准备与集成配置

将WhichModel集成到你的AI代理中，过程出乎意料的简单。这得益于MCP标准的设计，使得添加一个新的能力源就像在配置文件中添加几行代码一样。

3.1 识别你的MCP客户端类型

首先，你需要确定你的AI代理运行在哪种MCP客户端环境中。目前主要分为两类：

  1. HTTP客户端 ：这是最常见的情况。许多现代的AI代理框架（如使用 @modelcontextprotocol/sdk 构建的代理）支持通过HTTP URL直接连接远程MCP Server。配置方式是在客户端的配置文件中指定服务器的URL。
  2. Stdio客户端 ：一些桌面应用，如Claude Desktop或Cursor IDE，它们通过标准输入输出（stdio）与本地命令行工具交互来连接MCP Server。这需要你在本地安装一个轻量的“桥接”包，该包会启动并与远程服务通信。

3.2 具体配置步骤

以下是根据不同客户端的详细配置指南。假设你正在使用一个基于TypeScript的AI代理项目。

对于HTTP客户端（大多数自定义代理框架）：

找到你的代理项目的MCP客户端配置文件（通常命名为 mcp.config.json 、 agent.config.ts 或类似文件）。在其中添加WhichModel服务器的配置。

{
  "mcpServers": {
    "whichmodel": {
      "url": "https://whichmodel.dev/mcp"
    }
    // ... 你可以在这里配置其他MCP服务器
  }
}

关键点解析 ：

  • ”whichmodel” ：这是你给这个服务器实例起的任意名称，方便在代码中引用。
  • ”url” ：指向WhichModel官方提供的公共MCP服务端点。无需API密钥，这是一个开源的公共服务。
  • 无需安装 ：你的代理直接通过互联网与该URL通信，获取模型推荐。这意味着你不需要在本地运行任何WhichModel相关的代码或服务。

对于Stdio客户端（如Claude Desktop）：

Claude Desktop等应用通过本地命令调用MCP Server。你需要使用WhichModel提供的npm包作为桥梁。

首先，确保你的系统已安装Node.js（>=18版本）。然后，修改Claude Desktop的MCP配置文件（具体路径因操作系统而异，通常在用户目录下的 claude_desktop_config.json ）。

{
  "mcpServers": {
    "whichmodel": {
      "command": "npx",
      "args": ["-y", "whichmodel-mcp"]
    }
  }
}

关键点解析 ：

  • ”command”: “npx” ：指示客户端使用 npx 命令。 npx 是Node.js自带的工具，用于临时下载并执行npm包，无需全局安装。
  • ”args”: [“-y”, “whichmodel-mcp”] ： -y 参数表示对任何提示都回答“是”， whichmodel-mcp 是要执行的npm包名。当Claude Desktop启动时，它会运行 npx -y whichmodel-mcp ，这个包会自动连接至远程的WhichModel服务，并在本地建立一个stdio通道。

配置完成后，重启你的MCP客户端（或AI代理应用）。如果配置正确，客户端在初始化时就会连接到WhichModel，并将其提供的工具（如 recommend_model ）加载到你的代理可用的工具列表中。你可以通过查看客户端的日志或工具列表来验证连接是否成功。

4. 核心使用模式与实战代码

集成成功后，你的AI代理就获得了调用WhichModel工具的能力。下面我们深入三种核心使用模式，并结合TypeScript代码示例，展示如何在实际的代理逻辑中运用。

4.1 模式一：基于任务类型的智能路由

这是最常用、最直观的模式。你的代理在执行任何需要调用LLM的子任务前，先根据该任务的特征，向WhichModel咨询最佳模型。

假设我们正在构建一个多功能AI助手，它需要处理代码生成、文本总结和数据分析等不同任务。

import { Client } from ‘your-mcp-client-sdk’; // 替换为实际使用的MCP SDK

async function getRecommendedModelForTask(taskDescription: string, taskType: string, complexity: ‘low’ | ‘medium’ | ‘high’) {
  // 初始化MCP客户端（假设已配置好WhichModel）
  const client = new Client();
  await client.connect();

  // 估算任务的Token消耗（这是一个需要你根据任务内容实现的函数）
  const estimatedTokens = await estimateTokenUsage(taskDescription);

  try {
    // 调用WhichModel提供的 recommend_model 工具
    const recommendation = await client.callTool({
      name: ‘recommend_model’,
      arguments: {
        task_type: taskType, // 例如: “code_generation”, “summarization”, “data_extraction”
        complexity: complexity,
        estimated_input_tokens: estimatedTokens.input,
        estimated_output_tokens: estimatedTokens.output,
        requirements: {
          tool_calling: taskType === ‘code_generation’, // 代码生成可能需要调用工具
          json_output: taskType === ‘data_extraction’, // 数据提取需要结构化输出
        }
      }
    });

    // recommendation 结果示例:
    // {
    //   “recommended_model”: “openai/gpt-4o-mini”,
    //   “budget_alternative”: “google/gemini-2.0-flash”,
    //   “cost_estimate_usd”: 0.0035,
    //   “reasoning”: “GPT-4o-mini balances cost and capability for medium-complexity coding, with strong tool-calling support.”
    // }

    console.log(`推荐模型: ${recommendation.recommended_model}`);
    console.log(`成本估算: $${recommendation.cost_estimate_usd}`);
    console.log(`理由: ${recommendation.reasoning}`);

    return recommendation.recommended_model; // 返回模型标识符，供后续LLM调用使用

  } catch (error) {
    console.error(‘调用WhichModel失败:’, error);
    // 降级策略：返回一个可靠的默认模型，如GPT-4o-mini
    return ‘openai/gpt-4o-mini’;
  }
}

// 在代理逻辑中使用
async function handleUserRequest(userInput: string) {
  // 1. 意图识别（这里简化处理）
  let taskType = ‘general’;
  if (userInput.includes(‘写一段代码’)) taskType = ‘code_generation’;
  if (userInput.includes(‘总结一下’)) taskType = ‘summarization’;

  // 2. 获取成本最优模型
  const optimalModel = await getRecommendedModelForTask(userInput, taskType, ‘medium’);

  // 3. 使用推荐的模型执行实际LLM调用
  const finalResult = await callLLM(optimalModel, userInput);
  return finalResult;
}

实操心得 ： estimateTokenUsage 函数的准确性会直接影响推荐效果。一个简单的实现是使用类似 tiktoken （针对OpenAI模型）或 @anthropic-ai/tokenizer 的库进行近似估算。对于混合任务， complexity 参数需要你根据经验定义，例如，将“修改变量名”定义为 low ，将“实现一个完整的REST API”定义为 high 。

4.2 模式二：基于单次调用预算的硬约束

在某些场景下，你对单次交互的成本有严格的上限要求。例如，在一个面向海量用户的免费产品中，每次AI交互的成本必须控制在极低的水平。

async function getModelWithinBudget(taskType: string, budgetPerCallUSD: number) {
  const client = new Client();
  await client.connect();

  try {
    const result = await client.callTool({
      name: ‘recommend_model’,
      arguments: {
        task_type: taskType,
        complexity: ‘low’, // 在预算严格受限时，通常假设任务复杂度可接受较低模型处理
        budget_per_call: budgetPerCallUSD,
        // 可以不提供token估算，让WhichModel在预算内寻找能处理典型任务的模型
      }
    });

    if (result.recommended_model) {
      console.log(`预算内最佳模型: ${result.recommended_model}， 估算成本: $${result.cost_estimate_usd}`);
      return result.recommended_model;
    } else {
      throw new Error(`未找到符合预算 ${budgetPerCallUSD} USD 的模型`);
    }
  } catch (error) {
    console.error(‘预算查询失败:’, error);
    // 如果预算太低没有模型，可以考虑返回null，由上游逻辑决定是否拒绝任务或使用非LLM方案
    return null;
  }
}

// 使用示例：处理一个简单的用户查询，成本不能超过0.001美元
const budgetModel = await getModelWithinBudget(‘qa’, 0.001);
if (budgetModel) {
  await callLLM(budgetModel, userQuestion);
} else {
  await sendMessage(‘抱歉，当前无法处理您的请求。’);
}

注意事项 ：设置极低的预算（如 0.0001 美元）可能导致WhichModel无法推荐任何模型，因为即使最便宜的模型处理最小单位的Token也可能超过此预算。务必做好错误处理，并为用户提供友好的降级响应。

4.3 模式三：面向规模的成本预测与对比

当你计划将某个功能大规模上线前，或者需要在几个候选模型中进行架构选型时，批量成本对比至关重要。WhichModel的 compare_models 工具正是为此设计。

async function compareModelsForScaling() {
  const client = new Client();
  await client.connect();

  // 定义你要对比的模型列表和预期的业务量
  const comparison = await client.callTool({
    name: ‘compare_models’,
    arguments: {
      models: [
        “anthropic/claude-3-5-sonnet”,
        “openai/gpt-4o”,
        “google/gemini-2.0-pro”,
        “meta-llama/llama-3.1-8b-instruct” // 假设通过Together.ai等平台调用
      ],
      task_type: “customer_support_response”,
      volume: {
        calls_per_day: 50000, // 预计日调用量
        avg_input_tokens: 800, // 平均输入长度
        avg_output_tokens: 300  // 平均输出长度
      }
    }
  });

  // comparison 结果可能是一个数组，包含每个模型的详细成本分析
  console.log(‘规模化成本对比:’);
  comparison.forEach(model => {
    console.log(`\n模型: ${model.model_id}`);
    console.log(`  单次调用成本: $${model.cost_per_call}`);
    console.log(`  日均成本: $${model.cost_per_day}`);
    console.log(`  月均成本（30天）: $${model.cost_per_month}`);
    console.log(`  支持的功能: ${JSON.stringify(model.capabilities)}`);
  });

  // 你可以基于此数据做出决策，例如选择月成本最低且满足功能需求的模型
  const bestModel = comparison
    .filter(m => m.capabilities.tool_calling) // 假设需要工具调用
    .sort((a, b) => a.cost_per_month - b.cost_per_month)[0];

  console.log(`\n推荐用于规模化的模型: ${bestModel.model_id}`);
}

这个模式的价值在于，它将隐形的成本差异变得一目了然。正如原文提到的，日调用一万次时，单价细微的差别会放大成每月数千美元的运营成本差距。在项目初期进行这样的分析，能为技术选型提供强有力的数据支撑。

5. 高级策略与系统设计考量

将成本感知模型选择从简单的工具调用升级为代理系统的核心策略层，需要考虑更多工程化细节。

5.1 实现分层降级与故障转移机制

一个健壮的生产系统不能完全依赖WhichModel的实时响应。你需要设计一个分层模型选择策略：

  1. 主策略（成本最优） ：正常流程下，所有LLM调用请求都先经过WhichModel路由。
  2. 缓存策略 ：为了降低延迟并应对WhichModel服务暂时不可用的情况，可以在本地缓存高频任务（如“总结”、“翻译”）的模型推荐结果，并设置一个较短的TTL（例如5分钟）。
  3. 降级策略 ：如果WhichModel调用失败或超时，则降级到使用一个预定义的、按任务类型映射的静态模型列表。例如，代码生成默认用 gpt-4o-mini ，总结默认用 gemini-2.0-flash 。
  4. 兜底策略 ：如果所有指定模型都调用失败，则使用一个绝对可靠的“王牌”模型（如 gpt-4o ）来保证核心功能不中断，同时记录告警。
class ModelSelector {
  private cache = new Map<string, {model: string, expiry: number}>();

  async selectModel(task: Task): Promise<string> {
    const cacheKey = `${task.type}_${task.complexity}`;

    // 1. 检查缓存
    const cached = this.cache.get(cacheKey);
    if (cached && cached.expiry > Date.now()) {
      return cached.model;
    }

    // 2. 调用WhichModel（主策略）
    let recommendedModel: string;
    try {
      recommendedModel = await this.queryWhichModel(task);
      // 更新缓存，TTL设为5分钟
      this.cache.set(cacheKey, { model: recommendedModel, expiry: Date.now() + 300000 });
    } catch (error) {
      console.warn(‘WhichModel查询失败，使用降级策略’, error);
      // 3. 降级到静态配置
      recommendedModel = this.getFallbackModel(task.type);
    }

    return recommendedModel;
  }

  private getFallbackModel(taskType: string): string {
    const staticMap: Record<string, string> = {
      ‘code_generation’: ‘openai/gpt-4o-mini’,
      ‘summarization’: ‘google/gemini-2.0-flash’,
      ‘data_extraction’: ‘anthropic/claude-3-haiku’,
      ‘default’: ‘openai/gpt-4o’ // 4. 最终兜底
    };
    return staticMap[taskType] || staticMap[‘default’];
  }
}

5.2 与代理框架深度集成

如果你使用LangChain、LlamaIndex或自定义的Agent框架，可以将模型选择器抽象成一个独立的“Runtime”或“Router”。例如，在LangChain中，你可以创建一个自定义的 LLMRouter 类，它根据当前调用的上下文（来自WhichModel的建议）动态选择并实例化对应的ChatModel。

更进一步，你可以将成本预算作为Agent执行的一个全局约束。在每个Agent行动循环开始时，检查剩余预算，如果低于阈值，则强制切换到“极限节省”模式，甚至暂停某些高成本的功能。

5.3 监控、记录与持续优化

引入动态模型选择后，监控变得尤为重要。你需要记录：

  • 每次调用的元数据 ：使用的模型、任务类型、估算成本、实际Token消耗、任务成功率、响应延迟。
  • WhichModel的推荐记录 ：推荐了什么模型，理由是什么。
  • 成本与实际效果 ：对比使用不同模型完成同类任务的质量差异（可通过人工评估或自动化评分）。

这些数据可以帮助你：

  • 验证WhichModel的推荐质量 ：是否更便宜的模型真的达到了相同的效果？
  • 发现新的优化机会 ：也许对于某种特定任务，有一个WhichModel未覆盖的、性价比更高的开源模型。
  • 设置告警 ：如果某个任务的单次成本异常飙升，可能意味着任务复杂度判断逻辑有误，或者模型价格发生了剧烈变动。

6. 常见问题与故障排查

在实际集成和使用过程中，你可能会遇到以下典型问题。

6.1 连接与配置问题

问题现象 可能原因 排查步骤与解决方案
代理启动时报错，提示无法连接WhichModel。 1. 配置文件路径或格式错误。
2. 网络问题，无法访问 https://whichmodel.dev 。
3. 客户端不支持远程HTTP MCP Server。		 1. 检查配置文件JSON语法，确保 mcpServers 字段结构正确。
2. 在终端使用 curl https://whichmodel.dev/mcp 测试网络连通性。
3. 查阅你的MCP客户端文档，确认其支持远程HTTP连接。对于Stdio客户端，确保Node.js和npx可用。
WhichModel工具未出现在代理的可调用工具列表中。 1. 客户端未成功加载MCP Server。
2. 工具名称调用错误。		 1. 查看客户端启动日志，确认WhichModel服务器初始化成功。
2. 使用客户端提供的工具列表查询功能，确认 recommend_model 和 compare_models 工具是否存在。工具名称需完全匹配。
调用 recommend_model 返回超时或错误。 1. WhichModel服务端暂时过载或不可用。
2. 传入的参数格式不符合要求。		 1. 重试调用，并考虑实现上文提到的降级策略。
2. 仔细检查参数： task_type 是否在支持列表中（如 code_generation , summarization 等）， complexity 是否为 low / medium / high ，数字参数是否为有效数值。

6.2 推荐结果相关问题

问题现象 可能原因 排查步骤与解决方案
WhichModel推荐的模型在我的环境中无法调用。 1. 推荐的模型需要特定的API密钥或平台（如Together.ai, Replicate）才能访问。
2. 你的代理代码中未实现对该模型供应商的调用支持。		 1. WhichModel推荐是基于模型能力和价格，不验证你的访问权限。你需要在获得推荐后，确保你有该模型的API访问权。
2. 在你的LLM调用封装层，需要根据模型ID（如 openai/gpt-4o 或 anthropic/claude-3-5-sonnet ）路由到正确的API客户端和端点。
推荐模型处理复杂任务时效果不佳。 1. complexity 参数被低估。
2. 对于该特定任务，价格与性能的权衡点需要调整。		 1. 优化你的任务复杂度评估逻辑。可以基于输入长度、指令的嵌套程度、所需步骤数等进行更精细的量化。
2. 对于质量敏感的核心任务，可以在调用WhichModel时，通过 requirements 参数明确要求 minimum_quality: “high” （如果WhichModel支持此参数），或直接在推荐后手动“升级”到更强大的模型。
成本估算与实际账单有较大出入。 1. Token估算不准确。
2. WhichModel的价格数据有延迟。
3. 提供商的实际计费方式有细微差别（如按请求次数计费）。		 1. 改进本地的Token估算器，或在实际调用后，记录提供商返回的实际使用Token数，用于校准。
2. 理解WhichModel的价格更新频率（如每4小时），对于价格敏感型业务，这是一个可接受的风险窗口。
3. 将WhichModel的成本估算视为“强相关参考”而非“精确预言”。它最适合用于模型间的横向对比和趋势判断。

6.3 性能与延迟考量

为每个LLM调用前都先咨询一次WhichModel，会引入额外的网络延迟（一次HTTP请求）。对于延迟极度敏感的应用（如实时对话），这可能不可接受。

优化建议 ：

  • 批量预取 ：在代理启动或定时任务中，为你预期的所有任务类型和复杂度组合，预先获取一批推荐结果并缓存。
  • 异步并行 ：在代理思考链的早期，就异步触发模型推荐查询。当需要执行LLM调用时，推荐结果可能已经就绪。
  • 本地化部署 ：WhichModel是开源的。对于超大规模或对延迟、数据隐私有严格要求的场景，可以考虑将WhichModel MCP Server部署在你的私有基础设施中，并与你的内部模型管理平台集成，实现零网络延迟的查询。

为你的AI代理注入成本感知能力，绝非一次性的配置，而是一个持续的优化过程。它始于一个简单的MCP配置，成长于与业务逻辑的深度结合，最终成熟于基于数据反馈的迭代循环。这带来的不仅仅是立竿见见的成本下降，更是一种工程思维的转变：从盲目追求“最强模型”，到精准追求“最合适模型”。在AI应用日益普及、成本成为核心竞争力的今天，这项能力很可能就是你的项目从“可行”走向“可持续”的关键一步。

Logo
MCP技术社区

欢迎加入 MCP 技术社区！与志同道合者携手前行，一同解锁 MCP 技术的无限可能！

更多推荐

cover

AI本地文件交互踩坑崩溃？MCP文件服务5步实战+3个致命报错一次性解决

avatar MCP技术社区
cover

22年老研发详解MCP：AI通用插拔协议，彻底告别胶水代码

avatar MCP技术社区
cover

[MAF的工具-02]McpClientTool:MCP工具化桥接器

avatar MCP技术社区