大模型选型与应用指南：从模型分类到Agent框架的工程实践

1. 这份清单到底在解决什么问题每隔一段时间圈子里就会冒出一份大模型全家福式的整理清单。标题里带着日期说明它是一份持续更新的快照而不是一次性写完就丢在那里的静态文档。我最早接触这类清单是在做技术选型的时候当时团队要为一个客服场景挑底座模型市面上能叫得出名字的就有十来个每个都号称自己某方面最强翻官网、翻榜单、翻论文三天下来脑子是糊的。后来我意识到真正有用的不是哪个模型最强这种问题而是在我这个约束条件下哪个模型最合适。这份清单的价值就在这里。它把模型维度和应用维度分开来看模型维度关注的是底座能力——上下文长度、推理能力、多模态支持、开源与否、部署成本应用维度关注的是这些底座被包装成了什么产品——是聊天助手、是编程工具、还是可编排的Agent框架。这两条线经常被混在一起谈导致很多人在选型时把模型能力和产品体验搞混最后踩坑。适合读这份内容的人大概有三类。第一类是技术负责人需要为团队定技术栈关心的是稳定性、成本、可维护性第二类是开发者想基于某个模型或框架做二次开发关心的是API设计、文档质量、社区活跃度第三类是对这个领域保持关注的从业者不一定马上要用但需要知道当前格局长什么样避免在信息差上吃亏。这三类人的关注点不同但都需要一份结构清晰的参照。我写这篇东西的思路是不重复罗列参数而是把清单背后的分类逻辑讲透把每一类模型和应用的核心差异点拆开再补上我在实际选型和部署中踩过的坑。参数会过时但判断框架不会。2. 模型维度的分类逻辑与选型判断2.1 闭源旗舰、开源权重、垂直专用三条线把当前市面上的大模型按获取方式分基本就是三条线。第一条是闭源旗舰代表是GPT系列、Claude系列、Gemini系列特点是能力上限高、更新快、有官方托管服务但你不能把权重拿回家调用要走API数据要过别人的服务器。第二条是开源权重代表是Llama系列、Qwen系列、DeepSeek系列等权重可以下载能本地部署能微调代价是你得自己搞定算力和运维。第三条是垂直专用比如专门做代码的、专门做数学推理的、专门做多模态理解的这类模型在通用能力上可能不如旗舰但在特定任务上性价比极高。这三条线不是互斥的很多团队的实际做法是混合使用。我见过一个比较典型的配置线上主链路用闭源旗舰保证效果离线批处理和敏感数据场景用开源权重本地跑代码补全这种高频低价值任务用垂直专用模型压成本。这个思路值得参考因为单一模型打天下在成本和效果上都不划算。选型时最容易犯的错是只看榜单分数。榜单上的分数是在特定测试集上跑出来的和你的真实业务分布可能差很远。我的经验是先明确你的任务类型——是生成、是分类、是抽取、还是多轮对话——然后找几个候选模型用你自己的真实数据跑一轮小规模对比看的是实际输出质量而不是榜单排名。这一步花不了多少时间但能避免后面大规模返工。2.2 上下文长度这个参数被高估了吗上下文长度是这两年最卷的参数之一从早期的4K一路卷到现在的百万级。但我在实际使用中发现长上下文和能用好长上下文是两回事。很多模型标称支持128K甚至更长但你真塞进去十万字的文档它在中间部分的信息召回率会明显下降这就是所谓的lost in the middle现象。所以看上下文长度这个参数时我建议关注三个层面。第一是标称上限这个看官方文档就行。第二是有效召回长度这个得自己测方法是把关键信息放在不同位置看模型能不能稳定找到。第三是长上下文下的成本因为注意力机制的关系上下文越长推理成本和延迟增长往往不是线性的。实际场景里如果你的任务是长文档问答与其硬塞长上下文不如先做一轮检索或摘要把真正相关的片段喂给模型。这个思路在RAG架构里已经是标配了但很多人还是会图省事直接全文塞进去结果又慢又贵还不准。2.3 多模态能力的分层理解多模态现在是个热词但不同模型的多模态含金量差别很大。我把它分成三个层次来看。第一层是能看懂图片比如你发一张截图它能描述里面有什么。第二层是能理解图片里的细节和关系比如看懂图表的数据趋势、看懂界面元素的布局逻辑。第三层是能基于图片做推理和操作比如根据一张设计稿生成代码、根据一张流程图规划执行步骤。大部分标称多模态的模型在第一层做得都不错第二层开始分化第三层目前只有少数几个旗舰模型能稳定做到。你在选型时要先想清楚自己的场景需要哪一层能力。如果只是做图片内容审核第一层就够了如果要做UI自动化那得看第三层。还有一个容易被忽略的点是输入和输出的模态组合。有些模型支持图片输入但不支持图片输出有些支持语音输入但不支持语音输出。这些细节在官方文档里通常写得很清楚但选型时容易被多模态三个字带过去。3. 应用维度的真实分野3.1 聊天助手、编程工具、Agent框架的本质差异应用维度上当前最主流的三个形态是聊天助手、编程工具和Agent框架。这三者的差异不只是界面不同底层的交互范式完全不一样。聊天助手是回合制的你问一句它答一句上下文靠对话历史维持。这种形态适合信息查询、内容生成、头脑风暴这类任务。它的局限在于模型本身不主动做事你不问它就不动。编程工具是任务制的你给它一个目标它在代码库里自己找文件、改代码、跑测试。这种形态的核心能力是工具调用和长程规划代表就是各种代码助手。它的难点在于模型要能理解代码库的结构要能判断改动的副作用要能在出错时回滚。Agent框架是流程制的你把一个复杂任务拆成多个步骤每个步骤可以调用不同的工具或模型框架负责编排和状态管理。这种形态适合需要多步骤协作的场景比如自动化的数据处理流水线、多轮调研任务。它的挑战在于可靠性和可观测性因为链路一长出错的地方就多排查起来也麻烦。我见过不少团队在这三者之间选错。比如明明是个简单的问答需求非要上Agent框架结果复杂度上去了效果没提升多少。反过来明明需要多步骤自动化却用聊天助手硬凑最后靠人工在中间传话效率极低。判断标准其实很简单如果你的任务可以用一句话描述清楚且不需要外部工具聊天助手就够了如果任务涉及代码修改用编程工具如果任务需要多个工具按顺序协作才考虑Agent框架。3.2 Agent框架选型时真正该看的指标Agent框架这两年冒出来很多名字我就不一一列了。选型时大家容易盯着功能列表看但功能多不等于好用。我自己的判断顺序是这样的。第一看工具调用的稳定性。Agent的核心就是调工具如果工具调用经常失败或者参数传错后面全白搭。测试方法是拿几个边界case跑一下看它怎么处理参数缺失、返回值异常这些情况。第二看状态管理能力。多步骤任务里中间状态怎么存、怎么恢复、怎么避免重复执行这些决定了框架能不能扛住真实场景。有些框架在demo里跑得很顺一到生产环境遇到超时重试就乱套。第三看可观测性。链路一长你必须能知道每一步发生了什么、耗时多少、失败在哪。没有好的日志和追踪排查问题就是盲人摸象。第四看社区活跃度和文档质量。这个不用多说遇到问题能不能快速找到答案直接决定你的开发效率。至于支持多少种模型、内置多少工具这些反而是次要的因为大部分框架都支持自定义扩展真正卡你的是上面那四条。3.3 从Demo到生产之间隔着什么我参与过几个从零到一的Agent项目最大的感受是Demo和生产之间的距离比想象中大得多。Demo阶段你只需要证明这条路能走通生产阶段你要保证这条路每天走一万次都不出错。具体来说Demo阶段可以忽略的问题在生产阶段都是致命的。比如并发Demo里一个人用生产里可能几百个人同时用模型API的限流、工具调用的排队、状态的并发读写每一个都可能成为瓶颈。再比如异常处理Demo里出错就重跑生产里你得有重试策略、降级方案、人工兜底。还有一个常被低估的问题是成本。Agent的多步骤特性意味着一次用户请求可能触发十几次模型调用token消耗是普通聊天的好几倍。如果不做成本监控和优化账单会很难看。我一般的做法是给每个步骤设token上限对简单步骤用便宜模型只在关键决策点用旗舰模型。4. 部署与微调绕不开的工程问题4.1 本地部署的硬件账怎么算本地部署大模型第一个要算的就是硬件账。很多人上来就问跑某个模型需要什么显卡这个问题其实没法直接回答因为取决于你的量化精度、并发量、上下文长度。我一般按这个顺序估算。先确定模型参数量比如7B、13B、70B。然后确定量化精度FP16大概每B参数需要2GB显存INT8减半INT4再减半。所以一个7B模型FP16大概需要14GB显存INT4大概需要4GB左右。但这只是权重占用的下限实际运行时还要留出KV Cache的空间上下文越长、并发越高这部分占用越大。我的经验是在权重占用基础上至少留50%的余量给KV Cache和运行时开销。比如7B INT4权重约4GB那实际部署建议至少8GB显存起步。如果要支持较长上下文或者多并发还得往上加。除了显存还要考虑内存和存储。模型加载时需要把权重读进内存再传到显存所以内存不能太小。存储方面一个7B INT4模型大概4GB左右多个模型并存的话要提前规划。提示量化会损失精度INT4在通用对话上可能感觉不明显但在需要精确推理的任务上退化会比较明显。如果任务对精度敏感建议用INT8或者FP16。4.2 微调这件事什么时候该做什么时候不该做微调是个诱惑很大的选项因为听起来能让模型更懂你的业务。但我见过太多团队在不需要微调的场景上花了大量精力最后效果还不如好好写提示词。我的判断标准是这样的。如果你的需求是让模型掌握某种输出格式或风格优先用提示词工程成本低见效快。如果你的需求是让模型学会某个领域的知识优先用RAG把知识库外挂更新也方便。只有当你的需求是让模型掌握某种难以用文字描述的手感或者你需要大幅降低推理成本用小模型微调替代大模型才考虑微调。微调本身也有坑。第一是数据质量几百条高质量样本往往比几千条脏数据效果好。第二是过拟合微调过头模型会变得只会回答训练集里的问题泛化能力下降。第三是灾难性遗忘微调后模型可能丢失原有的通用能力。我的做法是保留一部分通用数据混在训练集里缓解遗忘问题。4.3 提示词工程和上下文工程的边界提示词工程和上下文工程经常被混为一谈但我觉得它们关注的点不一样。提示词工程关注的是怎么把话说清楚包括角色设定、任务描述、输出格式约束、few-shot示例。上下文工程关注的是给模型看什么包括检索哪些文档、保留哪些对话历史、如何压缩和摘要。在实际项目里这两者是配合使用的。提示词决定了模型的行为模式上下文决定了模型的信息基础。我见过提示词写得很漂亮但上下文喂了一堆无关内容的情况结果模型被干扰得答非所问。也见过上下文很精准但提示词含糊的情况模型不知道该用什么格式输出。一个实用的做法是把这两块分开调试。先固定上下文调提示词看输出质量的变化再固定提示词调上下文看信息完整度的影响。这样能快速定位问题出在哪一环。5. 那些清单不会告诉你的实操细节5.1 模型切换的成本比想象中高很多团队在选型时会想先用一个不行再换。这个思路本身没错但模型切换的成本经常被低估。不同模型的API格式不一样提示词的最佳写法不一样输出风格不一样甚至对同一个任务的理解方式都不一样。你为一个模型调好的提示词换一个模型可能效果直接腰斩。所以我的建议是在早期就做一轮多模型对比把候选缩小到两三个然后针对这几个分别维护提示词模板。切换时不是简单换个API地址而是要重新调优。如果业务对稳定性要求高甚至可以考虑用路由层做灰度切换先切一小部分流量验证效果。5.2 成本控制要从架构层面做模型调用的成本控制不能等到账单出来才想办法。我一般从三个层面做。第一层是模型分层简单任务用便宜模型复杂任务用旗舰模型这个在前面提过。第二层是缓存对于重复性高的查询把结果缓存起来避免重复调用。第三层是压缩把长上下文做摘要或检索减少token消耗。这三层里缓存是最容易被忽略但收益最明显的。很多业务场景下用户的问题有大量重复比如客服场景里的常见问题。做一个语义缓存命中率能到30%以上成本直接降三成。5.3 评测这件事得自己搭市面上的榜单可以参考但不能作为唯一依据。因为榜单的测试集和你的业务分布不一样榜单上的第一名在你的场景里可能排不进前三。所以自己搭一套评测是必须的。评测集不用很大几百条覆盖主要场景的样本就够。关键是要有明确的评分标准最好是可自动化的比如分类任务看准确率生成任务看关键信息覆盖率。然后每次模型更新或提示词调整都跑一遍评测看指标变化。这样你才能知道改动是变好了还是变坏了而不是凭感觉。我自己的评测集是持续维护的每次线上发现bad case就补进去慢慢就积累成了一个很贴合业务的测试集。这个东西的价值随着时间增长比任何公开榜单都靠谱。6. 关于这份清单的使用建议回到这份清单本身。它是一份快照日期标着2026年9月意味着它反映的是那个时间点的格局。模型领域变化很快几个月就可能有一批新模型出来一批老模型退役。所以看这份清单时不要把它当成永久参考而是当成一个起点。我的用法是先用它建立整体认知知道当前有哪些玩家、各自的位置在哪然后针对自己关心的几个候选去官网看最新文档因为清单可能滞后最后用自己的数据做小规模验证这一步不能省。另外清单里的模型和应用是分开列的但实际使用时两者是绑定的。一个模型可能同时以API形式提供也被包装成聊天产品还被集成进Agent框架。你在选型时要明确自己用的是哪一层是直接用模型能力还是用别人包装好的产品。这两者的灵活性和成本结构完全不同。最后说一点个人体会。这个领域信息更新快但底层判断逻辑其实变化不大。模型能力在涨但选型的框架——明确需求、对比候选、小规模验证、持续评测——这套方法论一直适用。与其追着每个新模型跑不如把这套框架练熟这样无论出什么新东西你都能快速判断它适不适合你。