1. 这份清单到底在解决什么问题每隔一段时间圈子里就会有人问现在到底有哪些大模型值得关注哪些应用真的能上手用。这个问题看着简单实际上特别难回答。原因在于大模型这个领域的变化速度已经快到了一种离谱的程度——上个月还在讨论某个模型的上下文窗口这个月大家已经在聊Agent编排和工具调用了。你如果拿一份三个月前整理的清单去跟人交流大概率会被指出一堆过时信息。我做这份清单的初衷很朴素给自己和团队一个可以定期更新的参照系。不是那种“十大模型排行榜”式的营销内容而是一份从实际使用角度出发的、区分模型层和应用层的梳理。模型层关注的是底层能力——推理、代码、多模态、上下文长度、部署方式应用层关注的是这些能力被封装成了什么形态的产品普通人能不能直接用开发者能不能集成。这份清单适合几类人看。第一类是刚进入这个领域、面对满屏名词不知道从哪下手的新人你需要一个结构化的地图而不是零散的新闻。第二类是在做技术选型的开发者或产品经理你需要知道某个场景下有哪些候选方案各自的取舍是什么。第三类是已经在用某些工具、但想了解全局的人你可能一直在用某一个模型但不清楚它在整个版图里的位置。需要提前说明的是这份清单的定位是“模型/应用维度”的梳理不是深度评测。每个条目我会给出核心特征、适用场景和上手门槛但不会逐项跑分。跑分这件事本身争议就很大不同评测集出来的结论经常互相矛盾我更倾向于从实际使用体验和工程落地的角度来判断。另外清单里会涉及一些部署和配置的内容比如本地跑模型、配置开发工具链这些。这些部分我会尽量给出可复现的步骤但你要知道这个领域的工具更新极快命令和配置项可能过几周就变了。所以我的建议是把步骤当作思路参考具体参数以你安装时的官方文档为准。2. 模型层从通用能力到垂直专精2.1 通用大模型的第一梯队格局聊模型层绕不开的就是那几个名字。GPT系列、Gemini系列、Claude系列这三家基本构成了通用大模型的第一梯队。它们共同的特点是参数规模大、训练数据广、多模态能力强、API生态成熟。但三者的侧重点差异也很明显。GPT系列的优势在于生态最完整。从API到插件系统到各种第三方集成你几乎可以在任何工具里找到GPT的身影。它的函数调用能力function calling是目前最成熟的之一这让它在Agent开发场景里特别受欢迎。缺点是使用成本相对较高而且部分地区访问有限制这个后面会细说。Gemini系列的特点是原生多模态做得比较彻底。它不是先做一个文本模型再往上加图像能力而是一开始就按多模态架构设计。这让它在处理图文混合任务时表现更自然。另外Gemini和办公套件的集成度很高如果你日常重度使用文档、表格、邮件这类工具它的嵌入体验会比其他模型顺滑。Claude系列在长文本处理和代码理解上口碑很好。它的上下文窗口给得比较大方而且对长文档的“注意力保持”做得不错——很多模型在处理超长输入时后半段的信息会被稀释Claude在这方面的衰减相对小。代码方面它在重构、解释复杂逻辑、生成测试用例这些任务上表现稳定。提示不要迷信“哪个模型最强”这种说法。同一个模型在不同任务上的表现差异可能比不同模型之间的差异还大。选型的正确姿势是拿你自己的真实任务去测而不是看别人的评测结论。2.2 开源模型与私有化部署的现实考量第一梯队之外开源模型是另一个重要维度。开源模型的价值不在于“免费”而在于可控。你可以把它部署在自己的服务器上数据不出内网这对很多企业来说是硬性要求。目前开源模型里比较活跃的几个方向一是以Llama系列为代表的基础模型社区生态大微调资源多二是各种经过指令微调的对话模型开箱即用的体验更好三是一些垂直领域的专精模型比如专门做代码的、专门做数学推理的。私有化部署这件事我踩过的坑不少。最核心的问题是硬件。一个70B参数级别的模型即使用量化技术压缩推理时也需要相当可观的显存。很多人一开始低估了这一点买了一张消费级显卡发现跑不动又得重新规划。部署工具方面Ollama是目前上手门槛最低的选择之一。它把模型下载、量化、推理服务封装成了一条命令的事。你不需要懂CUDA、不需要配环境变量装好就能跑。缺点是它对硬件的利用效率不是最优的追求极致性能的话还是要用更底层的方案。# Ollama 基本使用流程 # 安装后拉取模型 ollama pull llama3 # 直接对话 ollama run llama3 # 作为服务启动供其他程序调用 ollama serve这段命令看起来简单但背后有几个决策点。第一是模型选择不同参数量的模型对硬件要求差别很大7B和70B完全不是一个量级。第二是量化等级Q4量化比Q8量化省显存但精度有损失这个取舍要看你的任务对精度的敏感度。第三是并发Ollama默认的并发能力有限如果要支撑多人使用需要额外配置。2.3 微调什么时候需要什么时候不需要微调fine-tuning是很多人一上来就想做的事但我的经验是大部分场景不需要微调。微调适合的是那种“通用模型怎么调提示词都做不好、但任务本身很明确且你有大量标注数据”的情况。举个例子如果你想让模型按照特定格式输出结构化的数据提示词工程加少样本示例通常就够了。如果你想让模型掌握某个垂直领域的专业术语和推理逻辑检索增强RAG往往比微调更划算——因为知识更新时你只需要更新检索库不用重新训练。真正需要微调的场景通常是风格和格式的深度定制或者任务本身需要模型内化某种特定的推理模式。而且微调有代价你需要准备高质量的数据集需要算力需要评估微调后模型有没有“灾难性遗忘”——也就是在新任务上变强了但在通用任务上变弱了。注意微调的数据质量比数量重要得多。一千条精心标注的数据效果往往好过一万条粗糙抓取的数据。我见过太多人花大力气搞了几万条数据结果因为标注不一致微调出来的模型表现还不如原版。3. 应用层Agent与工具链的爆发3.1 Agent到底是什么和普通调用有什么区别Agent这个词现在被用得很泛但它的核心含义其实很清晰Agent是能自主决策、调用工具、多步执行任务的系统。普通的大模型调用是“你问一句它答一句”Agent是“你给一个目标它自己规划步骤、调用工具、检查结果、必要时调整策略”。这个区别听起来简单但工程上的复杂度差了一个数量级。普通调用你只需要处理输入输出Agent你需要处理任务规划、工具选择、错误恢复、上下文管理、执行循环的终止条件。任何一个环节出问题Agent就可能陷入死循环或者做出莫名其妙的操作。Agent和普通工作流workflow的区别也值得说清楚。工作流是预先定义好的步骤序列每一步做什么是固定的。Agent是动态的它根据当前状态决定下一步做什么。工作流的优点是可控、可预测、容易调试Agent的优点是灵活能处理你没预料到的情况。实际项目里我倾向于用工作流处理确定性高的部分用Agent处理需要灵活判断的部分两者混合使用。3.2 主流Agent框架的选型对比Agent框架这块目前比较活跃的有几个方向。一类是通用编排框架提供任务规划、工具调用、记忆管理这些基础能力一类是特定场景的Agent比如专门做代码的、专门做数据分析的还有一类是低代码平台让你用可视化方式搭建Agent流程。选框架的时候我主要看几个维度一是工具调用的灵活性能不能方便地接入自定义工具二是调试体验出问题的时候能不能看到中间步骤三是部署方式能不能私有化部署四是社区活跃度遇到问题有没有人讨论。这里有个常见的误区很多人一上来就选功能最全的框架结果发现学习成本太高简单任务反而被复杂化了。我的建议是从最简单的方案开始需要什么加什么。一个只用几个工具、逻辑清晰的Agent用最基础的框架就能搭没必要上重型编排系统。3.3 开发工具链从配置到调试Agent开发离不开工具链。目前比较主流的开发方式是在IDE里集成AI助手让它帮你写代码、解释代码、调试问题。这类工具的核心能力是代码理解和生成以及和开发环境的深度集成。配置这类工具的时候有几个点容易出问题。第一是运行环境有些工具需要特定的运行时支持在Windows上可能需要开启某些系统功能。第二是网络访问部分工具需要连接外部服务网络不通会导致功能不可用。第三是权限配置工具需要读取你的项目文件权限设置不当会导致它看不到该看的文件。# 以命令行方式安装开发助手工具的典型流程 # 检查运行环境 node --version # 全局安装 npm install -g anthropic-ai/claude-code # 验证安装 claude --version # 在项目目录中启动 cd your-project claude这段流程里node --version这一步经常被跳过但它很重要。很多安装失败的原因是Node版本太老不满足最低要求。另外全局安装和局部安装的选择也有讲究全局安装方便在任何目录使用但版本管理麻烦局部安装版本隔离好但每个项目都要装一遍。提示安装这类工具时如果遇到权限报错不要直接加sudo了事。先看看是不是npm的全局目录权限配置有问题用sudo安装可能导致后续更新时出现更麻烦的权限混乱。4. 实操从零搭建一个可用的Agent4.1 环境准备与依赖安装假设我们要搭建一个能查资料、能执行简单计算的Agent。第一步是环境准备。你需要一个Python环境3.10以上比较稳妥然后安装核心依赖。依赖的选择上我倾向于用轻量的方案。核心就是一个模型调用库加一个Agent编排库。模型调用库负责和模型API通信编排库负责管理任务循环和工具调用。不要一上来就装一堆框架依赖越多版本冲突的概率越大。# 核心依赖安装 pip install openai # 模型调用 pip install langchain # 编排框架可选轻量场景可以不用 pip install requests # 工具调用需要安装完之后第一件事是验证模型调用能不能通。写一个最简单的脚本发一条消息看能不能收到回复。这一步看起来多余但能帮你排除掉大部分配置问题。很多人卡在Agent逻辑上调试半天最后发现是API密钥配错了。4.2 工具定义与注册Agent的核心是工具。工具就是一个函数Agent可以调用它来完成特定任务。定义工具的时候有几个要点函数名要清晰参数要有类型标注要有文档字符串说明这个工具是干什么的、什么时候用。def search_knowledge(query: str) - str: 搜索知识库输入查询关键词返回相关文档片段。 适用于需要查找事实性信息的场景。 # 实际实现略 return results def calculate(expression: str) - str: 计算数学表达式输入如 2 3 * 4返回计算结果。 适用于需要精确计算的场景不要用模型自己算。 return str(eval(expression))这里有个关键经验不要让模型自己做数学计算。大模型在算术上经常出错尤其是多步计算。正确做法是把计算交给工具模型只负责决定“什么时候需要计算”和“计算什么表达式”。工具的描述文字也很重要。模型是根据描述来判断该不该调用某个工具的。如果描述写得含糊模型可能在该调用的时候不调用或者在不该调用的时候乱调用。我一般会把“什么时候用”和“什么时候不用”都写清楚。4.3 任务循环的实现Agent的任务循环是整个系统的核心。基本逻辑是把用户目标和可用工具列表发给模型模型返回下一步动作调用某个工具或者给出最终答案执行动作把结果加回上下文继续循环直到模型给出最终答案或达到最大步数。def run_agent(goal, tools, max_steps10): messages [{role: user, content: goal}] for step in range(max_steps): response call_model(messages, tools) if response.is_final: return response.content # 执行工具调用 result execute_tool(response.tool_name, response.tool_args) messages.append(response.message) messages.append({role: tool, content: result}) return 达到最大步数限制任务未完成max_steps这个参数很关键。没有它Agent可能在某个循环里出不来一直调用同一个工具。设置多少合适看任务复杂度简单任务5步够了复杂任务可以给到15到20步。但也不要设太大步数越多累积的错误越多而且token消耗也越大。注意Agent的每一步都会把之前的完整上下文发给模型这意味着token消耗是随步数平方级增长的。一个跑了20步的Agent消耗的token可能是一个单次调用的几十倍。做成本预估的时候一定要把这一点算进去。4.4 调试与可观测性Agent最难的部分不是搭建是调试。当Agent做出一个错误决策时你需要知道它为什么这么决策。所以可观测性特别重要——每一步的输入、输出、工具调用、返回结果都要记录下来。我的做法是在开发阶段把每一步都打印出来包括发给模型的完整消息列表。这样当Agent行为异常时你能看到它“看到”的是什么从而判断是上下文里混入了干扰信息还是工具描述有歧义还是模型本身理解错了。常见的Agent异常有几类一是工具调用参数错误比如该传字符串传了数字二是陷入循环反复调用同一个工具三是过早终止明明还有步骤没完成就给出了答案四是幻觉调用调用了一个根本不存在的工具。每一类的排查思路不一样但共同点是先看日志看模型在每一步接收到了什么信息。5. 常见问题与排查实录5.1 访问与配置类问题问题一模型服务连不上。这是最高频的问题。排查顺序是先确认网络能通ping一下服务地址再确认密钥有效用最简单的脚本测最后确认配额没用完。很多时候不是技术问题是账户余额或者配额限制。问题二本地部署的模型响应特别慢。先看硬件占用GPU利用率是不是满了显存是不是爆了。如果显存不够模型会退到CPU上跑速度会慢几十倍。解决办法是换更小的模型或者更高的量化等级。另外检查一下是不是有多个进程在抢GPU。问题三开发工具在Windows上装不上。这类问题通常和系统组件有关。有些工具依赖特定的运行时环境需要先在系统设置里启用相关功能。另外路径里有中文或空格也可能导致问题建议把项目放在纯英文路径下。5.2 效果与稳定性类问题问题四Agent总是调用错误的工具。先检查工具描述是不是有歧义。两个功能相近的工具如果描述区分度不够模型就会混淆。解决办法是把描述写得更具体明确各自的适用边界。另一个办法是减少同时暴露给模型的工具数量工具太多会增加选择难度。问题五模型输出格式不稳定。如果你需要模型输出特定格式比如JSON光在提示词里说“请输出JSON”是不够的。更可靠的做法是给出格式示例并且在解析端做容错处理。有些模型API支持强制JSON输出模式能用就用这个。问题六长对话后模型“忘记”了前面的内容。这是上下文窗口的限制。解决办法有几种一是做上下文压缩把早期对话总结成摘要二是用检索的方式只把相关的历史片段放进上下文三是换上下文窗口更大的模型。每种方案都有代价压缩会丢信息检索需要额外的索引维护换模型增加成本。问题类型典型表现首选排查方向常用解决手段连接失败请求超时、认证错误网络、密钥、配额逐项验证用最小脚本测试响应慢延迟高、吞吐低硬件占用、模型大小降量化、换小模型、加硬件工具误调调用不该调的工具工具描述、工具数量细化描述、减少暴露工具数格式不稳输出不符合预期结构提示词、解析逻辑给示例、用强制格式模式上下文丢失忘记早期信息上下文长度压缩、检索、换大窗口模型5.3 成本与安全类问题问题七token消耗远超预期。除了前面说的Agent步数问题还有一个常见原因是把整个文档塞进了上下文。如果只是要回答文档里的某个问题应该先做检索只把相关片段放进去而不是全文塞入。问题八Agent执行了危险操作。这是Agent安全的核心问题。如果Agent能调用执行命令、写文件、发请求这类工具就必须有权限控制。我的做法是危险操作需要人工确认或者限制在沙箱环境里执行。不要给Agent无限制的系统权限。问题九敏感数据泄露风险。如果Agent处理的是内部数据要确认模型调用走的是私有部署还是外部API。走外部API的话数据会离开你的控制范围。对数据敏感的场景私有化部署是必须的。提示Agent安全这件事我的原则是“最小权限”。Agent只需要完成当前任务所需的最小工具集和最小权限。不要图省事给它开一堆用不到的工具每一个多余的工具都是一个潜在的风险点。6. 我个人的一些使用体会这份清单我会持续更新因为每周都有新东西出来。但更新的时候我越来越倾向于做减法而不是加法——新模型新工具层出不穷但真正值得纳入日常工作流的其实不多。大部分新东西是现有能力的微调或者包装核心范式没有变。选型这件事我的经验是不要追新要追稳。一个工具如果社区活跃、文档清晰、有实际项目在用那它大概率比一个刚发布、功能列表很炫但没人踩过坑的工具更值得投入。大模型领域尤其如此很多项目发布时声势浩大几个月后就没人维护了。另外一个体会是提示词工程和Agent编排本质上都是在弥补模型能力的不足。随着模型本身越来越强很多现在需要复杂编排才能实现的功能未来可能一句提示词就够了。所以在架构设计上我会尽量把“模型能力”和“编排逻辑”解耦这样模型升级时编排层不用大改。最后说一个具体的技巧。如果你在评估多个模型不要只看它们在标准评测集上的分数。建一个你自己的小评测集二十到三十条你真实场景的输入人工标注期望输出然后让候选模型都跑一遍。这个自建评测集的价值远高于任何公开榜单。因为你的场景是独特的公开榜单测的是通用能力而你要的是在你的场景里好用。