1. 引言在构建 Agent 应用时选择合适的大语言模型LLM是决定系统效果、成本与延迟的关键决策。开发者往往面临一个核心问题什么时候该用大模型什么时候该用小模型本文将从选择考量维度、关键评估指标、调试方法以及资料查阅渠道四个方面系统梳理 Agent 开发中模型选型与优化的完整思路。2. 大模型与小模型的核心差异在深入选择策略之前先明确大模型与小模型在能力上的本质差异。维度大模型如 GPT-4o、Claude 3.5 Sonnet、Llama 3 70B小模型如 GPT-4o mini、Llama 3 8B、Qwen 2.5 7B参数量通常 70B 以上通常 7B~13B推理能力强复杂多步推理表现好较弱简单任务够用指令遵循更稳定能处理复杂指令对复杂指令容易偏离工具调用更可靠能处理多工具组合简单工具调用尚可复杂场景易出错上下文理解长上下文处理更好长上下文易丢失信息成本高按 token 计费贵低适合高频调用延迟较高低响应快部署要求需要高端 GPU本地部署门槛高可在消费级硬件或边缘设备运行3. 选择模型时的核心考量维度3.1 任务复杂度这是最优先的判断维度。Agent 的核心任务类型决定了模型能力下限简单任务如单轮信息提取、文本分类、关键词抽取、格式化输出小模型即可胜任。中等任务如多步骤工具调用、需要遵循复杂指令格式、需要一定推理能力建议使用中等规模模型或大模型。复杂任务如多轮规划、代码生成与调试、长文档分析、需要深度推理的决策必须使用大模型。一个实用经验先用大模型跑通流程再逐步尝试用小模型替换部分环节观察效果退化程度。3.2 工具调用与函数调用的可靠性Agent 的核心能力是工具调用Function Calling / Tool Use。不同模型在这方面的表现差异显著检查模型是否原生支持结构化工具调用如 OpenAI 的 function calling、Anthropic 的 tool use。评估模型在「多工具并行调用」「工具参数填充准确性」「工具返回结果后的下一步决策」上的表现。小模型在工具参数格式上更容易出错需要更严格的校验与重试机制。3.3 成本与延迟预算需要结合业务场景量化评估调用频率Agent 每轮对话可能触发多次模型调用规划、工具调用、总结高频场景下成本差异会被放大。延迟敏感度面向用户的交互场景对延迟敏感小模型优势明显离线批处理任务则更看重成本与质量。预算约束大模型按 token 计费可能是小模型的 10~30 倍需要估算单次任务的平均 token 消耗。3.4 上下文长度需求Agent 经常需要携带较长的对话历史、工具返回结果或检索到的文档片段如果任务需要处理长文档或长对话历史优先选择支持长上下文如 128K、200K的模型。小模型在长上下文下更容易出现「中间遗忘」问题需要配合摘要或截断策略。3.5 部署与隐私要求云端 API使用大模型最便捷但数据会离开本地需评估合规风险。本地部署对数据敏感场景需选择可在自有硬件上运行的模型此时模型规模受限于 GPU 显存往往只能选择小模型或中等模型。混合架构常见做法是「大模型做复杂推理 小模型做简单预处理/后处理」兼顾质量与成本。3.6 智能客服场景的模型选型智能客服是 Agent 最常见的落地场景之一其选型策略需要结合具体业务形态判断简单 FAQ 问答用户问题多为高频、固定模式如查订单、改地址、退换货规则意图识别和答案检索相对简单小模型即可胜任成本低、响应快。多轮对话与复杂工单涉及上下文理解、多轮追问、情绪识别、跨系统工具调用查库存、下单、转人工需要较强的推理与指令遵循能力建议使用大模型。混合路由架构推荐入口用小模型做意图识别与路由简单问题直接由小模型回答识别到复杂问题或高价值用户时再升级到大模型处理。这样能在保证体验的同时显著降低成本。3.7 GLM 系列模型的定位智谱 AI 的 GLM 系列覆盖从轻量到旗舰的多个档位选型时需结合参数量与能力定位判断GLM-4.6属于大模型。它是 GLM-4 系列的最新旗舰版本参数量大、推理与工具调用能力强适合复杂多轮对话、深度推理、代码生成等高质量场景。若智能客服需要处理复杂工单或高价值用户对话GLM-4.6 是合适选择。GLM-4-Plus同样属于大模型是 GLM-4 系列中能力较强的版本定位在旗舰与轻量之间综合性能优秀适合对质量要求较高、但预算相对可控的中大型业务场景。GLM-4-Flash / GLM-4-Air属于小模型轻量档位参数量小、延迟低、成本低适合高频简单的意图识别、FAQ 问答、格式整理等任务。判断一个模型是「大」还是「小」不能只看名称关键看参数量、能力定位与价格档位。同一系列内通常有多个档位选型时应结合任务复杂度、成本预算和延迟要求综合判断。4. 评估模型的关键指标4.1 通用能力基准MMLU多任务语言理解衡量模型在 57 个学科上的综合知识水平。HumanEval / MBPP衡量代码生成能力对 Agent 中的代码类任务有参考价值。GSM8K / MATH衡量数学推理能力间接反映模型的逻辑推理水平。BBHBig-Bench Hard衡量复杂推理能力对 Agent 规划类任务有较强参考意义。4.2 Agent 专项评估通用基准不能完全反映 Agent 场景下的真实表现需要关注专项指标工具调用成功率模型正确选择工具并填充参数的比例。任务完成率Agent 在端到端任务中成功达成目标的比率。规划正确率多步任务中每一步决策的正确性。错误恢复能力工具调用失败后模型能否正确修正并重试。4.3 工程指标首 token 延迟TTFT从请求发出到收到第一个 token 的时间。吞吐量每秒处理的 token 数影响批处理效率。可用性与稳定性API 的 SLA、限流策略、错误率。价格输入/输出 token 单价以及是否有批量折扣。4.4 质量评估方法人工评估建立评测集由人工对模型输出打分最可靠但成本高。LLM-as-a-Judge用强模型如 GPT-4对输出质量打分适合大规模自动化评估但需注意偏见问题。A/B 测试在真实流量中对比不同模型的效果最贴近实际但周期长。回归测试建立固定的评测集每次更换模型或提示词后运行防止效果退化。5. 调试大模型的方法5.1 提示词调试迭代优化从简单提示开始逐步增加约束、示例和格式要求。Few-shot 示例在提示中给出 2~5 个输入输出示例显著提升小模型的表现。结构化输出约束明确要求 JSON 格式、字段定义配合输出解析器使用。思维链Chain-of-Thought引导模型逐步推理提升复杂任务准确率。5.2 参数调试temperature控制随机性。Agent 任务通常建议 0~0.3减少随机输出创意类任务可调高。top_p核采样与 temperature 配合使用一般保持默认或与 temperature 二选一调整。max_tokens限制输出长度避免模型生成过长内容浪费 token。frequency_penalty / presence_penalty控制重复性对长文本生成有帮助。5.3 结构化调试流程推荐使用「评估驱动」的调试方法建立包含典型任务场景的评测集20~50 条即可起步。记录当前模型的基线表现成功率、错误类型分布。针对失败案例分析原因是提示词不清、模型能力不足还是工具定义有问题修改提示词或参数重新运行评测集对比效果。反复迭代直到达到目标指标。5.4 常见问题与排查问题现象可能原因调试方向输出格式不符合要求提示词约束不足增加格式示例、使用结构化输出工具参数填错工具描述不清或模型能力不足优化工具描述、增加参数示例多步任务中途跑偏模型推理能力不足拆分子任务、增加中间检查点输出重复或空洞temperature 过高降低 temperature长上下文丢失信息模型上下文处理能力有限精简上下文、增加摘要机制5.5 日志与可观测性记录每次调用的输入输出、token 消耗、延迟便于事后分析。使用 LangSmith、Langfuse 等工具进行 trace 追踪可视化 Agent 的每一步决策。对失败案例建立标签体系持续积累调试素材。6. 模型比较与选型资料查阅渠道6.1 权威基准榜单LMArenaChatbot Arena基于人类投票的模型对战榜单反映真实用户体验。Open LLM LeaderboardHugging Face 上的开源模型评测榜单覆盖多种基准。Artificial Analysis综合对比模型的性能、速度与价格适合工程选型。MMLU / HumanEval 官方榜单各模型论文中通常报告这些基准分数。6.2 官方文档与模型卡OpenAI / Anthropic / Google 官方文档查看模型能力边界、上下文长度、价格、限流策略。Hugging Face Model Card开源模型的详细说明包括训练数据、评测结果、已知限制。各模型的技术报告Technical Report深入了解模型的设计思路与能力边界。6.3 社区与评测文章Hugging Face 博客经常发布模型评测与对比文章。Reddit r/LocalLLaMA开源模型社区讨论本地部署与模型对比。Vellum、Patterson 等公司的模型对比报告定期发布主流模型的横向评测。CSDN、知乎等技术社区中文场景下的模型选型经验分享。6.4 实际测试建议资料只能提供参考最终选型必须结合自身场景实测从榜单中筛选 3~5 个候选模型。用自己业务场景的典型任务构建评测集。在候选模型上分别运行对比成功率、延迟、成本。结合预算与体验要求做最终决策。7. 实践建议混合模型架构在实际 Agent 系统中很少只用一个模型。推荐采用分层策略入口层用小模型做意图识别、路由判断快速且便宜。核心推理层用大模型处理复杂规划、代码生成、深度推理。后处理层用小模型做格式整理、摘要、校验。这种架构可以在保证质量的同时显著降低成本。例如一个客服 Agent 可以用小模型判断用户意图只有遇到复杂问题时才升级到大模型处理。8. 总结选择 Agent 的 LLM 模型没有「一刀切」的答案需要综合任务复杂度、工具调用可靠性、成本延迟预算、上下文需求和部署约束五个维度权衡。评估时既要参考通用基准更要建立自己的业务评测集。调试过程应遵循「评估驱动」的迭代方法善用提示词、参数和结构化流程优化。最后通过权威榜单、官方文档和社区资料获取候选模型信息并用真实场景实测做最终决策。记住一个核心原则先用大模型验证可行性再用小模型优化成本。在保证任务质量的前提下尽可能选择更小、更快的模型是 Agent 工程化的长期方向。
Agent 开发中 LLM 大模型与小模型的选择、评估与调试指南
1. 引言在构建 Agent 应用时选择合适的大语言模型LLM是决定系统效果、成本与延迟的关键决策。开发者往往面临一个核心问题什么时候该用大模型什么时候该用小模型本文将从选择考量维度、关键评估指标、调试方法以及资料查阅渠道四个方面系统梳理 Agent 开发中模型选型与优化的完整思路。2. 大模型与小模型的核心差异在深入选择策略之前先明确大模型与小模型在能力上的本质差异。维度大模型如 GPT-4o、Claude 3.5 Sonnet、Llama 3 70B小模型如 GPT-4o mini、Llama 3 8B、Qwen 2.5 7B参数量通常 70B 以上通常 7B~13B推理能力强复杂多步推理表现好较弱简单任务够用指令遵循更稳定能处理复杂指令对复杂指令容易偏离工具调用更可靠能处理多工具组合简单工具调用尚可复杂场景易出错上下文理解长上下文处理更好长上下文易丢失信息成本高按 token 计费贵低适合高频调用延迟较高低响应快部署要求需要高端 GPU本地部署门槛高可在消费级硬件或边缘设备运行3. 选择模型时的核心考量维度3.1 任务复杂度这是最优先的判断维度。Agent 的核心任务类型决定了模型能力下限简单任务如单轮信息提取、文本分类、关键词抽取、格式化输出小模型即可胜任。中等任务如多步骤工具调用、需要遵循复杂指令格式、需要一定推理能力建议使用中等规模模型或大模型。复杂任务如多轮规划、代码生成与调试、长文档分析、需要深度推理的决策必须使用大模型。一个实用经验先用大模型跑通流程再逐步尝试用小模型替换部分环节观察效果退化程度。3.2 工具调用与函数调用的可靠性Agent 的核心能力是工具调用Function Calling / Tool Use。不同模型在这方面的表现差异显著检查模型是否原生支持结构化工具调用如 OpenAI 的 function calling、Anthropic 的 tool use。评估模型在「多工具并行调用」「工具参数填充准确性」「工具返回结果后的下一步决策」上的表现。小模型在工具参数格式上更容易出错需要更严格的校验与重试机制。3.3 成本与延迟预算需要结合业务场景量化评估调用频率Agent 每轮对话可能触发多次模型调用规划、工具调用、总结高频场景下成本差异会被放大。延迟敏感度面向用户的交互场景对延迟敏感小模型优势明显离线批处理任务则更看重成本与质量。预算约束大模型按 token 计费可能是小模型的 10~30 倍需要估算单次任务的平均 token 消耗。3.4 上下文长度需求Agent 经常需要携带较长的对话历史、工具返回结果或检索到的文档片段如果任务需要处理长文档或长对话历史优先选择支持长上下文如 128K、200K的模型。小模型在长上下文下更容易出现「中间遗忘」问题需要配合摘要或截断策略。3.5 部署与隐私要求云端 API使用大模型最便捷但数据会离开本地需评估合规风险。本地部署对数据敏感场景需选择可在自有硬件上运行的模型此时模型规模受限于 GPU 显存往往只能选择小模型或中等模型。混合架构常见做法是「大模型做复杂推理 小模型做简单预处理/后处理」兼顾质量与成本。3.6 智能客服场景的模型选型智能客服是 Agent 最常见的落地场景之一其选型策略需要结合具体业务形态判断简单 FAQ 问答用户问题多为高频、固定模式如查订单、改地址、退换货规则意图识别和答案检索相对简单小模型即可胜任成本低、响应快。多轮对话与复杂工单涉及上下文理解、多轮追问、情绪识别、跨系统工具调用查库存、下单、转人工需要较强的推理与指令遵循能力建议使用大模型。混合路由架构推荐入口用小模型做意图识别与路由简单问题直接由小模型回答识别到复杂问题或高价值用户时再升级到大模型处理。这样能在保证体验的同时显著降低成本。3.7 GLM 系列模型的定位智谱 AI 的 GLM 系列覆盖从轻量到旗舰的多个档位选型时需结合参数量与能力定位判断GLM-4.6属于大模型。它是 GLM-4 系列的最新旗舰版本参数量大、推理与工具调用能力强适合复杂多轮对话、深度推理、代码生成等高质量场景。若智能客服需要处理复杂工单或高价值用户对话GLM-4.6 是合适选择。GLM-4-Plus同样属于大模型是 GLM-4 系列中能力较强的版本定位在旗舰与轻量之间综合性能优秀适合对质量要求较高、但预算相对可控的中大型业务场景。GLM-4-Flash / GLM-4-Air属于小模型轻量档位参数量小、延迟低、成本低适合高频简单的意图识别、FAQ 问答、格式整理等任务。判断一个模型是「大」还是「小」不能只看名称关键看参数量、能力定位与价格档位。同一系列内通常有多个档位选型时应结合任务复杂度、成本预算和延迟要求综合判断。4. 评估模型的关键指标4.1 通用能力基准MMLU多任务语言理解衡量模型在 57 个学科上的综合知识水平。HumanEval / MBPP衡量代码生成能力对 Agent 中的代码类任务有参考价值。GSM8K / MATH衡量数学推理能力间接反映模型的逻辑推理水平。BBHBig-Bench Hard衡量复杂推理能力对 Agent 规划类任务有较强参考意义。4.2 Agent 专项评估通用基准不能完全反映 Agent 场景下的真实表现需要关注专项指标工具调用成功率模型正确选择工具并填充参数的比例。任务完成率Agent 在端到端任务中成功达成目标的比率。规划正确率多步任务中每一步决策的正确性。错误恢复能力工具调用失败后模型能否正确修正并重试。4.3 工程指标首 token 延迟TTFT从请求发出到收到第一个 token 的时间。吞吐量每秒处理的 token 数影响批处理效率。可用性与稳定性API 的 SLA、限流策略、错误率。价格输入/输出 token 单价以及是否有批量折扣。4.4 质量评估方法人工评估建立评测集由人工对模型输出打分最可靠但成本高。LLM-as-a-Judge用强模型如 GPT-4对输出质量打分适合大规模自动化评估但需注意偏见问题。A/B 测试在真实流量中对比不同模型的效果最贴近实际但周期长。回归测试建立固定的评测集每次更换模型或提示词后运行防止效果退化。5. 调试大模型的方法5.1 提示词调试迭代优化从简单提示开始逐步增加约束、示例和格式要求。Few-shot 示例在提示中给出 2~5 个输入输出示例显著提升小模型的表现。结构化输出约束明确要求 JSON 格式、字段定义配合输出解析器使用。思维链Chain-of-Thought引导模型逐步推理提升复杂任务准确率。5.2 参数调试temperature控制随机性。Agent 任务通常建议 0~0.3减少随机输出创意类任务可调高。top_p核采样与 temperature 配合使用一般保持默认或与 temperature 二选一调整。max_tokens限制输出长度避免模型生成过长内容浪费 token。frequency_penalty / presence_penalty控制重复性对长文本生成有帮助。5.3 结构化调试流程推荐使用「评估驱动」的调试方法建立包含典型任务场景的评测集20~50 条即可起步。记录当前模型的基线表现成功率、错误类型分布。针对失败案例分析原因是提示词不清、模型能力不足还是工具定义有问题修改提示词或参数重新运行评测集对比效果。反复迭代直到达到目标指标。5.4 常见问题与排查问题现象可能原因调试方向输出格式不符合要求提示词约束不足增加格式示例、使用结构化输出工具参数填错工具描述不清或模型能力不足优化工具描述、增加参数示例多步任务中途跑偏模型推理能力不足拆分子任务、增加中间检查点输出重复或空洞temperature 过高降低 temperature长上下文丢失信息模型上下文处理能力有限精简上下文、增加摘要机制5.5 日志与可观测性记录每次调用的输入输出、token 消耗、延迟便于事后分析。使用 LangSmith、Langfuse 等工具进行 trace 追踪可视化 Agent 的每一步决策。对失败案例建立标签体系持续积累调试素材。6. 模型比较与选型资料查阅渠道6.1 权威基准榜单LMArenaChatbot Arena基于人类投票的模型对战榜单反映真实用户体验。Open LLM LeaderboardHugging Face 上的开源模型评测榜单覆盖多种基准。Artificial Analysis综合对比模型的性能、速度与价格适合工程选型。MMLU / HumanEval 官方榜单各模型论文中通常报告这些基准分数。6.2 官方文档与模型卡OpenAI / Anthropic / Google 官方文档查看模型能力边界、上下文长度、价格、限流策略。Hugging Face Model Card开源模型的详细说明包括训练数据、评测结果、已知限制。各模型的技术报告Technical Report深入了解模型的设计思路与能力边界。6.3 社区与评测文章Hugging Face 博客经常发布模型评测与对比文章。Reddit r/LocalLLaMA开源模型社区讨论本地部署与模型对比。Vellum、Patterson 等公司的模型对比报告定期发布主流模型的横向评测。CSDN、知乎等技术社区中文场景下的模型选型经验分享。6.4 实际测试建议资料只能提供参考最终选型必须结合自身场景实测从榜单中筛选 3~5 个候选模型。用自己业务场景的典型任务构建评测集。在候选模型上分别运行对比成功率、延迟、成本。结合预算与体验要求做最终决策。7. 实践建议混合模型架构在实际 Agent 系统中很少只用一个模型。推荐采用分层策略入口层用小模型做意图识别、路由判断快速且便宜。核心推理层用大模型处理复杂规划、代码生成、深度推理。后处理层用小模型做格式整理、摘要、校验。这种架构可以在保证质量的同时显著降低成本。例如一个客服 Agent 可以用小模型判断用户意图只有遇到复杂问题时才升级到大模型处理。8. 总结选择 Agent 的 LLM 模型没有「一刀切」的答案需要综合任务复杂度、工具调用可靠性、成本延迟预算、上下文需求和部署约束五个维度权衡。评估时既要参考通用基准更要建立自己的业务评测集。调试过程应遵循「评估驱动」的迭代方法善用提示词、参数和结构化流程优化。最后通过权威榜单、官方文档和社区资料获取候选模型信息并用真实场景实测做最终决策。记住一个核心原则先用大模型验证可行性再用小模型优化成本。在保证任务质量的前提下尽可能选择更小、更快的模型是 Agent 工程化的长期方向。
