AI Agent 该用哪个 LLM？2026 实测选型指南

2026 年，几乎每个团队都在做 Agent。然后几乎每个团队都踩了同一个坑——第一版全用最强模型，跑通了，账单也炸了。

我见过一个数据分析 Agent，单次任务平均 22 步工具调用，全链路 Claude Opus。功能很惊艳。直到月底，财务来问"这一个功能怎么花了四位数"。问题不在模型，在于没人意识到 Agent 的成本是按步数乘出来的。一次对话只调一次模型；一个 Agent 任务调二十多次。同样的单价，账单差一个数量级。

这篇不评"哪个模型 MMLU 最高"。Agent 选型是另一套逻辑——它考验的是稳定性、工具调用、和成本结构。下面按我们做了一年多 Agent 的实战经验，把它讲清楚。

先破一个误区：Agent ≠ 用最聪明的模型

"既然 Agent 这么重要，那肯定要上最强的 Opus。" 这句话听起来对，做起来烧钱。

Agent 的本质是一个循环：观察 → 思考 → 调用工具 → 再观察，反复多轮直到完成。这意味着两件事被放大了。第一，成本：每一步都是一次完整的模型调用，而且上下文里塞满了之前所有步骤的 observation，输入 token 越滚越大。第二，延迟：二十步串行，每步多等一秒，用户就多等二十秒。

所以 Agent 选型的第一原则不是"多聪明"，而是"这一步值不值得用贵模型"。决定下一步干什么——值得。把一段 JSON 里的字段抽出来填进工具参数——不值得。

Agent 对 LLM 的真实需求（和聊天完全不同）

聊天场景，你要的是一次回答得漂亮。Agent 场景，你要的是二十步都别出岔子。具体拆成这几条，按重要性排序：

• ① 工具调用（function calling）的稳定性：这是 Agent 的命门。模型得在该调工具时调、参数填对、不该调时别瞎调。一个聪明但经常乱填参数的模型，做 Agent 是灾难。
• ② 多步不跑偏：第 15 步还记得第 2 步的目标，不被中间的噪声带歪。指令遵循（instruction following）能力直接决定这一点。
• ③ 结构化输出可靠：要 JSON 就给合法 JSON，别动不动多个 markdown 代码块或一句"好的，这是你要的"。
• ④ 成本结构：单价 × 步数 × 累积上下文。便宜一点点，乘以步数就是一大笔。
• ⑤ 延迟：串行步骤里，快模型的体验优势是累加的。
• ⑥ 推理/规划：只在"大脑"决策那一两步真正需要——不是每一步。

三层分工：把对的模型放在对的位置

我们的实践是把 Agent 内部的模型调用分成三层，每层配不同的模型。下面的价格均为 ApiTopMix 当前实时价（每百万 token，输入/输出，完整价格见定价页）：

规划层（Agent 的"大脑"）—— 强模型，低频

负责任务分解、复杂决策、卡住时的重新规划。调用频率低，但每次都重要，值得上强模型。

执行层（工具调用主力）—— 稳而快

Agent 大部分步骤都在这一层：决定调哪个工具、填参数、解析返回。要的是 function calling 稳定 + 快 + 不太贵。

子任务层（简单活）—— 越便宜越好

分类、抽取、格式化、短摘要这类没难度的活，用最便宜的，能省一大笔。

一个真实的多模型路由：就这么几行

很多人担心多模型会让 Agent 代码变复杂。其实用一个 OpenAI 兼容的聚合网关，所有模型共用一个 Key、一套 SDK，路由只是按当前角色换 model 参数：

# 一个 ApiTopMix Key 同时调三层模型
from openai import OpenAI
client = OpenAI(api_key="sk-...", base_url="https://apitopmix.com/v1")

ROUTING = {
    "plan":    "claude-sonnet-4-6",   # 规划层：稳
    "act":     "claude-haiku-4-5-20251001",  # 执行层：快而便宜
    "subtask": "gemini-2.5-flash",    # 子任务层：最省
}

def agent_call(role, messages, tools=None):
    return client.chat.completions.create(
        model=ROUTING[role],
        messages=messages,
        tools=tools,
        tool_choice="auto" if tools else None,
    )

# Agent 主循环里，按当前步骤的角色取模型
plan   = agent_call("plan", planning_messages)        # 低频、强模型
result = agent_call("act",  step_messages, tools=TOOLS) # 高频、便宜稳

Node.js 端同理，把 baseURL 指到 https://apitopmix.com/v1，用同一个 Key 切 model 即可。接口细节见 开发文档。这套结构的好处是：你可以在不动业务逻辑的前提下，随时把某一层换成更便宜或更强的模型——只改字典里一行。

成本测算：一个 20 步任务，分层 vs 全 Opus

假设一个典型 Agent 任务：20 步，其中 2 步规划、12 步工具调用、6 步简单子任务。每步平均累积输入 8K token、输出 1K token。我们对比"全用 Opus"和"三层分工"：

单次省 $0.69 看着不多。乘以每天一万次任务呢？一天省近 $7,000。这就是为什么 Agent 的模型分工，不是优化项，是生存项。详细的降本方法论，可以参考我们这篇 把 API 成本砍半。

不同类型 Agent 的推荐起点

• 通用任务 / RPA 类 Agent：规划 Claude Sonnet，执行 Claude Haiku，子任务 Gemini Flash。稳字优先。
• 代码 Agent（写/改/跑）：执行层用 qwen3-coder-480b 或 Claude Sonnet，规划层 Claude Opus 或 Sonnet。
• 研究 / 深度推理 Agent：规划层上 thinking 模型（Claude thinking、Kimi K2 thinking），执行层 Sonnet。
• 预算极敏感 / 个人项目：规划 DeepSeek，执行 Haiku，子任务用免费的 gpt-oss，能把成本压到很低。

常见问题

1. 一开始就要做三层路由吗？还是先单模型跑通？

先用一个 Claude Sonnet 把 Agent 跑通，验证逻辑对。逻辑稳了，再做分层降本——这时你已经有真实日志，知道哪些步骤简单到可以降级。别在还没跑通时就过度工程。

2. 便宜模型在执行层会不会经常调错工具？

会有概率，所以要兜底。给执行层加一个"工具调用结果校验"，参数非法或返回异常就 fallback 到更强模型重试一次。这样既吃到便宜模型 90% 的省钱，又不让边界情况砸到用户。

3. 为什么不直接用某个平台的 auto 路由？

auto 路由按通用启发式选模型，但它不懂你的 Agent 里"这一步是规划还是子任务"。你自己按角色显式路由，控制力和可预测性都更强。关于平台层的对比，可以看 AI API 聚合平台选型指南。

4. thinking 模型放在执行层会怎样？

不建议。推理模型每次会产生大量思考 token，放在高频的工具调用层，延迟和成本都会爆。把它的"想得深"用在低频的规划层，性价比才出得来。

延伸阅读

• AI API 聚合平台选型指南 2026 — 平台层怎么选
• 把 ChatGPT API 成本砍半 — 成本治理方法论
• 从 OpenAI 迁移到 Claude 的完整指南
• ApiTopMix API 文档 · 全部模型实时定价
• Model Context Protocol — Agent 工具标准化参考

结语

Agent 选 LLM，不是选一个冠军，是给一支队伍排兵布阵。规划层要将才，执行层要稳兵，子任务交给杂役。把对的模型放在对的位置，你的 Agent 既跑得稳，又花得起。

从今天起，别再用一个模型跑完整条链路。先去看一眼你 Agent 的日志：哪一步其实根本不需要那么强的模型？那就是你的第一个降级点。

Expert Tip：给 Agent 的每一步打三个埋点——step_role（规划/执行/子任务）、model、tool_call_valid（工具参数是否合法）。跑一周后做透视，你会发现两件事：某一层用了过强的模型（降级点），以及某个便宜模型的 tool_call_valid 异常低（该层不能降）。这张表比任何模型排行榜都更适合指导你自己的 Agent——因为它量的是你真实任务，不是别人的基准。我们靠它把一个 Agent 的月成本砍掉过三分之二，且成功率没动。