Agent 项目如何选择底层模型，依据和验证方法是什么？｜阿里巴巴后端开发面经解析

60 秒回答模板

Agent 项目选底层模型不能只看榜单分数，而要看它在具体 Agent 任务中的可靠性。我会先定义任务画像：是问答、代码、数据分析、工具调用、长文理解还是多轮规划；再列模型能力要求，包括指令遵循、函数调用或工具调用稳定性、结构化输出、上下文长度、中文和领域理解、推理能力、安全拒答、延迟、吞吐和成本。验证方法上，要构造贴近业务的 eval set，覆盖正常任务、边界输入、工具失败、权限限制和多轮场景，比较任务成功率、工具参数正确率、JSON 合法率、幻觉率、平均耗时和单位成本。上线时可以用灰度、canary、模型路由和 fallback，不同任务用不同模型，避免一个模型承担所有场景。

考点 Agent 模型选型要基于具体任务

难度 真实面经题

回答目标 建立 Agent 模型选型依据

深入解析

从 Agent 任务画像出发

模型选型首先要看 Agent 要做什么。客服问答、数据分析、代码修复、自动化办公和工具执行对模型要求不同。不要只拿通用 benchmark 排名做决定，而要把业务任务拆成理解、规划、调用工具、生成结果和校验几个能力。

工具调用可靠性很关键

Agent 不是普通聊天，底层模型要稳定选择工具、生成正确参数、遵守 schema、理解工具返回并继续决策。评估时要重点看工具选择准确率、参数完整率、JSON 合法率、重复调用率、失败后恢复能力和是否会伪造工具结果。

上下文和结构化输出影响落地

如果任务需要读取长文档、历史会话或多份资料，就要评估上下文长度和长上下文中的定位能力。如果下游系统需要结构化结果，就要评估输出格式稳定性。模型能回答问题不代表能稳定作为系统组件。

成本延迟和吞吐要一起算

Agent 往往一次任务会多轮调用模型和工具，因此单次模型价格不是全部成本。要估算平均调用次数、token 消耗、首 token 延迟、总耗时、并发能力和失败重试成本。高质量模型可以用于关键节点，轻量模型用于分类、改写或预处理。

用业务评测集验证

评测集应来自真实任务、历史工单、人工构造边界 case 和安全样本，覆盖成功路径、工具异常、权限不足、信息缺失、多轮澄清和长上下文。指标包括任务成功率、人工接管率、幻觉率、工具错误、延迟、成本和用户满意度。

上线后做路由和 fallback

生产中可以按任务类型、风险等级、成本预算和用户层级做模型路由。低风险任务用便宜模型，高风险或复杂任务用强模型；当主模型超时、输出不合法或质量低时，切换备用模型、降级为人工或进入安全模板。

易错点

只按模型榜单或参数规模选型，没有结合 Agent 任务。
只看回答质量，忽略工具调用、结构化输出和失败恢复。
没有估算多轮调用带来的总延迟和总成本。
评测集只覆盖成功样本，不覆盖权限、异常和边界输入。
所有任务强行使用同一个模型，缺少路由和分层。
上线后没有灰度、监控和 fallback，模型波动会直接影响业务。

面试官追问

通用 benchmark 分高的模型为什么不一定适合 Agent？

普通聊天更看重语言理解、回答质量和安全；Agent 还要看工具调用、结构化输出、计划能力、长上下文、状态保持、错误恢复和成本延迟。不能只用通用榜单。

如何评估模型的工具调用稳定性？

用真实工具 schema 和任务集测试函数选择、参数填写、JSON 合法率、工具调用成功率、错误恢复和多步任务完成率。还要看模型是否会编造工具结果或越权调用。

如果强模型质量好但成本高，你会如何设计模型路由？

先按任务价值和风险分层。高价值复杂任务可以用强模型，简单分类、路由和抽取用小模型；同时设置缓存、批处理、降级模型和预算阈值。

Agent 模型上线前的 eval set 应该包含哪些异常样本？

不要只看平均分。要构造业务任务、工具调用、多轮失败恢复、安全边界和长尾样本，用同一套输入比较模型的质量、延迟、成本和稳定性。

模型输出 JSON 偶发不合法，工程上如何处理？

可以做模型路由：按任务类型、风险、上下文长度、用户等级和实时负载选择模型。切换时要保证输出契约一致，并监控质量回归和成本变化。

主模型超时或拒答时，fallback 应该怎么设计？

至少要有旧模型回退、低风险降级、人工接管或只读模式。新模型灰度前要通过离线评测、影子流量和小流量线上监控。