1. 大模型赛道的现状与这份清单的由来
2026年9月下旬，我花了两周时间把国内外主流大模型和应用重新梳理了一遍。起因很简单：团队里新来的几个同学问我“现在到底该用哪个模型做Agent”，我张口想说“看情况”，但发现自己脑子里那套认知还停留在半年前。这个行业变化太快，半年前的经验放到今天可能已经过时了。
所以这份清单不是那种“十大模型排行榜”式的营销内容，而是我自己在真实项目里踩过坑、做过对比之后，按模型维度和应用维度两条线整理出来的实战参考。模型维度关注的是底层能力——推理、代码、多模态、上下文长度、API成本；应用维度关注的是上层落地——Agent框架、开发工具、部署方案、微调路径。
如果你正在选型、正在做Agent开发、正在纠结要不要微调，或者只是想知道现在市面上到底有哪些能用的东西，这份梳理应该能帮你省下不少自己试错的时间。我会尽量把每个选择的理由讲清楚，而不是只丢一个结论。
2. 模型维度：国内外主流大模型的能力拆解
2.1 海外第一梯队：GPT、Claude、Gemini的三国杀
先说海外这三家，因为它们目前仍然是很多场景下的默认选项。
GPT系列在2026年的状态比较微妙。它的通用能力依然很强，尤其是在结构化输出和函数调用方面，生态成熟度是最高的。你在网上搜“gpt免费使用”“gpt注册”这类词，说明它的用户基数依然庞大。但实际项目里，我发现GPT在长上下文推理任务上，相比Claude已经不再有明显优势。它的强项在于工具调用的稳定性——如果你在做Agent，需要模型频繁调用外部API，GPT的函数调用格式遵循度是最让人省心的。另外“gpt时钟模块几个函数的”这种搜索词，说明很多人在用它做嵌入式或硬件相关的开发，这块它的代码生成能力确实靠谱。
Claude系列是我个人在代码和长文档场景下的首选。它的上下文窗口处理能力非常突出，丢进去几万字的文档让它做摘要或问答，输出质量衰减很小。网上大量关于“claude code安装”“vscode配置claude code”“ubuntu安装claude code”的搜索，说明它已经深度绑定了开发工作流。Claude Code这个工具本身就是一个很好的例子——它把模型能力直接嵌入到终端和编辑器里，你不需要复制粘贴代码，它自己就能读文件、改文件、跑命令。不过要注意，Windows上配置Claude Code时经常遇到“requires the virtual machine platform”这类报错，这是环境依赖问题，后面我会专门讲。
Gemini系列今年的存在感明显增强。它的多模态能力是三家里最激进的，图片、视频、音频的理解和生成都在快速迭代。热搜里“谷歌承认gemini越狱”这种词，侧面说明它的安全边界在被不断试探，但也说明它的能力上限确实高。Gemini的使用门槛相对低一些，“gemini登录”“gemini使用教程”这类搜索量很大。但有个坑要注意：“your account is not eligible for gemini code assist for individuals”这个报错很常见，主要是账号区域和资格限制导致的，不是技术问题。
| 模型 | 最强场景 | 上下文 | 工具调用 | 多模态 | 上手难度 |
|---|---|---|---|---|---|
| GPT | 结构化输出、函数调用 | 中 | 极强 | 强 | 低 |
| Claude | 代码、长文档 | 极长 | 强 | 中 | 中 |
| Gemini | 多模态、视频理解 | 长 | 中 | 极强 | 低 |
2.2 国内大模型：谁在真正落地
国内大模型这两年洗牌很厉害，能活下来并且持续迭代的，基本都有自己的明确场景。
DeepSeek在代码和数学推理上表现突出，而且API价格极具竞争力。很多做“大模型微调实战”的团队会选它作为基座，因为它的开源版本质量高，微调成本可控。
通义千问的优势在于生态整合，它和国内云服务的绑定很深，部署和调用都很方便。“大模型部署”这个搜索词背后，很多人最终选的就是它。
Kimi的长文本能力是国内第一梯队，处理几十万字的文档没问题，适合做知识库和文档分析。
智谱GLM在Agent方向投入很大，它的工具调用和规划能力在国内模型里是比较靠前的。
豆包的C端渗透率很高，但B端API的稳定性还在打磨中。
这里要提一个搜索词：“herdsman大模型官网下载”“hermes agent”。这类词说明有很多垂直领域的大模型在冒出来，它们不一定通用能力最强，但在特定行业里可能比通用模型更好用。选型的时候不要只盯着头部，有时候垂直模型能省你很多微调功夫。
2.3 模型选型的核心判断逻辑
我自己的选型逻辑是这样的，你可以参考：
第一，先看任务类型。如果是代码生成和重构，Claude和DeepSeek优先；如果是多模态理解，Gemini优先；如果是高频API调用且预算敏感，国内模型优先。
第二，再看上下文需求。如果你的文档超过5万字，Claude和Kimi是首选。GPT和Gemini在超长上下文下的表现会打折扣。
第三，最后看成本和合规。国内项目优先考虑国内模型，海外项目再考虑GPT和Claude。API成本要算总账，不只是token单价，还要算重试率和人工修正成本。
注意：不要迷信“最强模型”。我见过太多团队用最贵的模型做最简单的事，结果成本爆炸。选型的第一原则是“够用就好”，第二原则是“留好切换余地”。
3. 应用维度：Agent与开发工具的实战地图
3.1 Agent框架：从概念到能跑起来
“agent”“ai agent”“agent开发”“agent框架”“agent智能体”——这些词在热搜里反复出现，说明Agent是今年最热的方向。但热归热，真正能跑起来的Agent项目并不多。
目前主流的Agent框架分几类：
第一类是通用编排框架，比如LangChain、LlamaIndex。它们的优势是生态全、文档多，但抽象层太厚，调试起来很痛苦。我个人的经验是，简单任务用它们没问题，复杂任务最好自己写编排逻辑。
第二类是代码原生Agent，比如Claude Code、Codex。它们直接嵌入开发环境，能读文件、改代码、跑测试。这类工具的实际效率提升最明显，因为它们的交互路径最短。
第三类是垂直Agent，比如“pi agent”“pi agent官网”这类。它们针对特定场景做了优化，开箱即用，但灵活性差一些。
“agent execution terminated due to error”这个搜索词很真实——Agent跑着跑着就挂了，这是常态。原因通常是工具调用超时、上下文溢出、或者模型输出格式不符合预期。后面我会专门讲排查方法。
3.2 开发工具链：VSCode、Claude Code、Gemini Code Assist
开发工具这块，VSCode依然是绝对主场。
Claude Code的安装和配置是高频问题。“vscode配置claude code”“ubuntu安装claude code”“claude : 无法将‘claude’项识别为 cmdlet”这些搜索词，说明很多人在环境配置阶段就卡住了。Claude Code本质上是一个CLI工具，它需要Node.js环境，Windows上还需要WSL或虚拟机平台支持。配置成功后，你可以在终端里直接让它读项目、改代码、跑命令，体验很流畅。
Gemini Code Assist是另一个选择，但它的账号资格限制比较麻烦。“vscode安装gemini code assist 身份验证”“your account is not eligible for gemini code assist for individuals”这两个词经常一起出现。解决办法通常是检查账号区域设置，或者改用企业版。
Codex接入Gemini这个搜索词说明有人在尝试混合方案——用Codex的界面接Gemini的模型。这种玩法可行，但稳定性取决于接口兼容性，不建议在生产环境用。
3.3 部署与微调：从“能跑”到“跑得好”
“大模型部署”“大模型微调”“大模型微调实战”“大模型下载平台”“免费大模型api”——这些词覆盖了从入门到进阶的完整路径。
部署方面，如果你只是自己用，Ollama是最简单的选择，一条命令就能跑起来。如果要上生产，vLLM和TGI是更专业的选择，它们支持并发和批处理，吞吐量高很多。
微调方面，LoRA和QLoRA是目前最实用的方案。全量微调成本太高，除非你有非常特殊的需求。微调的数据质量比数量重要得多，1000条高质量样本往往比10000条噪声数据效果好。
免费API方面，国内几家大厂都有免费额度，适合做原型验证。但要注意速率限制和并发限制，别把demo当生产用。
“android app集成ai大模型gguf”这个搜索词很有意思，说明有人在移动端做本地推理。GGUF格式是llama.cpp生态的标准格式，适合在资源受限的设备上跑量化模型。但移动端推理的体验目前还比较有限，适合做离线场景的补充。
4. 实操过程：从零搭建一个可用的Agent工作流
4.1 环境准备与工具安装
我以Claude Code为例，讲一下完整的搭建过程。这套流程在Ubuntu和macOS上最顺畅，Windows需要额外配置。
第一步，安装Node.js。Claude Code依赖Node环境，建议用nvm管理版本：
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.0/install.sh | bash nvm install 20 nvm use 20第二步，安装Claude Code：
npm install -g @anthropic-ai/claude-code第三步，验证安装：
claude --version如果这一步报“无法将‘claude’项识别为 cmdlet”，说明PATH没配好。Windows上需要把npm的全局目录加到环境变量里。
第四步，配置API密钥。Claude Code需要你提供API key，配置方式是在项目目录下创建配置文件，或者通过环境变量传入。
提示：Windows用户如果遇到“requires the virtual machine platform”报错，需要在“启用或关闭Windows功能”里勾选“虚拟机平台”和“适用于Linux的Windows子系统”，然后重启。
4.2 Agent工作流的核心配置
Agent要跑起来，核心是三件事：工具定义、提示词设计、错误处理。
工具定义方面，你需要明确告诉模型有哪些工具可用，每个工具的输入输出格式是什么。以文件操作为例：
{ "name": "read_file", "description": "读取指定路径的文件内容", "parameters": { "type": "object", "properties": { "path": { "type": "string", "description": "文件路径" } }, "required": ["path"] } }提示词设计方面，Agent的system prompt要包含角色定义、任务目标、可用工具列表、输出格式要求。我习惯把输出格式约束得尽量严格，比如要求模型每次回复必须是JSON，包含thought、action、action_input三个字段。这样解析起来不容易出错。
错误处理方面，这是最容易被忽视的环节。Agent执行失败的原因通常有几类：工具调用超时、模型输出格式错误、上下文超长、API限流。每一类都需要不同的处理策略。超时可以重试，格式错误可以要求模型重新输出，上下文超长需要做摘要或截断，限流需要退避重试。
4.3 参数计算与性能调优
Agent的性能调优，核心是平衡延迟、成本和准确率。
延迟方面，主要影响因素是模型推理时间和工具调用时间。如果工具调用是瓶颈，可以考虑并行调用。如果模型推理是瓶颈，可以换更小的模型或者做量化。
成本方面，要算总token消耗。一个Agent任务可能涉及多轮对话，每轮都要传上下文，token消耗是累积的。我一般会设置一个最大轮次限制，比如10轮，超过就强制结束。
准确率方面，提示词的清晰度比模型大小更重要。我试过用同一个模型，提示词优化前后准确率差了30%以上。
| 调优维度 | 常见手段 | 效果 | 代价 |
|---|---|---|---|
| 延迟 | 并行工具调用 | 高 | 实现复杂 |
| 延迟 | 模型量化 | 中 | 准确率下降 |
| 成本 | 上下文压缩 | 高 | 信息损失 |
| 成本 | 小模型路由 | 高 | 需要路由逻辑 |
| 准确率 | 提示词优化 | 极高 | 需要反复调试 |
| 准确率 | Few-shot示例 | 高 | 增加token消耗 |
5. 常见问题与排查技巧实录
5.1 环境配置类问题
问题一：Claude Code安装后命令找不到。
这是PATH问题。npm全局安装的包默认在~/.npm-global/bin或/usr/local/bin。检查npm config get prefix的输出，把对应的bin目录加到PATH里。
问题二：Windows上Claude Code报虚拟机平台错误。
Claude Code在Windows上需要WSL2支持。开启WSL2的步骤：以管理员身份打开PowerShell，运行wsl --install，重启后设置WSL发行版。然后在WSL里安装Node和Claude Code。
问题三：Gemini Code Assist提示账号不符合资格。
这个报错通常是因为账号区域不在支持列表里，或者个人版资格已满。可以尝试切换账号区域，或者申请企业版。如果只是学习用途，可以先用Gemini的网页版。
5.2 Agent运行类问题
问题四：Agent执行到一半报“execution terminated due to error”。
这是最泛化的错误，需要看具体堆栈。常见原因：工具返回了非预期格式、模型输出了无法解析的内容、上下文超长导致截断。排查方法是打开详细日志，看最后一步的输入输出是什么。
问题五：Agent陷入死循环，反复调用同一个工具。
这通常是提示词里没有明确的终止条件。解决办法是在system prompt里加一条：“如果连续两次调用同一工具且结果相同，必须停止并输出当前结论。”
问题六：模型不按格式输出，解析失败。
两个办法：一是降低temperature，二是用JSON mode或结构化输出功能。如果模型支持function calling，优先用function calling而不是让模型自由生成JSON。
5.3 微调与部署类问题
问题七：微调后模型效果反而变差了。
大概率是数据质量问题。检查你的训练数据是否有标注错误、格式不一致、或者分布偏差。另外，学习率太高也会导致灾难性遗忘，试试降低学习率或者用LoRA只训练部分参数。
问题八：部署后并发一高就超时。
这是推理框架的并发能力问题。Ollama适合单用户，生产环境建议用vLLM，它支持continuous batching，吞吐量能提升好几倍。另外检查GPU显存是否够用，显存不足会导致频繁换页，延迟飙升。
问题九：移动端集成GGUF模型后发热严重。
移动端推理对功耗很敏感。建议用更小的量化版本（比如Q4），限制最大token数，并且做好散热管理。如果只是做简单任务，可以考虑用云端API替代本地推理。
提示：所有环境类问题，第一步都是看日志。90%的报错信息里已经包含了解决方案的线索，只是很多人不看日志直接搜报错。
6. 我个人的选型建议与踩坑心得
做了这么多项目，我最大的体会是：没有最好的模型，只有最合适的组合。
我现在的默认配置是：Claude做代码和长文档，GPT做工具调用和结构化输出，Gemini做多模态，国内模型做成本敏感的场景。Agent框架方面，简单任务用Claude Code直接搞定，复杂任务自己写编排逻辑，不迷信框架。
踩过的坑里，最值得说的是不要过早优化。我见过团队在原型阶段就纠结用哪个模型、哪个框架，结果两周过去了还没跑通一个demo。正确的做法是先用最简单的方案跑通流程，然后再逐步替换组件。
另一个坑是忽视错误处理。Agent项目里，错误处理代码往往比业务逻辑还多。如果你没做好重试、降级、超时控制，上线后会被各种边界情况教做人。
最后分享一个小技巧：如果你不确定选哪个模型，可以写一个简单的评测脚本，用你的真实任务数据跑一遍所有候选模型，看准确率和成本的综合表现。这比看任何排行榜都靠谱。我自己的评测集只有50条数据，但都是真实业务场景，跑一轮下来选型决策就清晰了。
