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. 实操：从零搭建一个可用的Agent

4.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_steps=10): 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编排，本质上都是在弥补模型能力的不足。随着模型本身越来越强，很多现在需要复杂编排才能实现的功能，未来可能一句提示词就够了。所以在架构设计上，我会尽量把“模型能力”和“编排逻辑”解耦，这样模型升级时，编排层不用大改。

最后说一个具体的技巧。如果你在评估多个模型，不要只看它们在标准评测集上的分数。建一个你自己的小评测集，二十到三十条你真实场景的输入，人工标注期望输出，然后让候选模型都跑一遍。这个自建评测集的价值，远高于任何公开榜单。因为你的场景是独特的，公开榜单测的是通用能力，而你要的是在你的场景里好用。