项目使用了哪个具体模型与版本？

核心回答

模型要和它承担的任务、接入方式及具体版本一起说明。以研搜系统为例，下面是一种参考配置：

主 Agent 通过阿里云百炼 API 调用 qwen-plus-2025-12-01，负责研究任务拆解、工具选择和资料归纳，接入地域采用华北 2（北京）。这个名字明确到日期快照，比只说“用了 Qwen”更具体。选择时主要看文本任务、Function Calling、结构化输出与接入成本；该快照在这一地域列明支持工具调用和结构化输出，项目是否达标再用自己的任务集、延迟和费用记录验证。固定快照也有利于比较升级前后的行为。

多 Agent 可以共享同一个模型，再通过提示词和工具分工。若系统还有 Embedding、重排或备用模型，应分别说明它们负责什么、用了哪个型号；开发时使用的 AI 编程助手也应与业务模型分开。

若项目采用本地部署，则把 API 供应商换成模型仓库、权重修订、量化方式和推理服务版本。模型系列名、代码中的配置名与实际部署版本不能混在一起回答。

先分清问的是项目中的哪个环节

面试中“用了什么模型”可能指业务系统运行时的模型，也可能承接“用 AI 写项目”，询问开发助手背后的模型。回答时先说清用途，再给标识：

• 主 Agent 与子 Agent：分别负责规划、工具选择、总结或专项处理，是否共享模型，以及路由或降级后是否会切换。
• Embedding 与重排：给出各自模型 ID；它们负责向量化或候选排序，不能用聊天模型名称代替。
• AI 编程助手：说明使用的工具及当时选择的模型。如果使用自动路由，应结合该次任务记录说明，不把工具品牌直接当作固定模型版本。

例如“主 Agent 和检索 Worker 使用同一聊天模型，但提示词和工具权限不同”，就已经说明了角色与模型的关系；不需要为了体现多 Agent 而给每个角色配一个不同型号。

从配置名追到实际 model ID

工程中通常有几层名字：业务配置名如 research_main，环境变量名如 CHAT_MODEL，发送给接口的 model，以及网关或推理服务真正绑定的模型。它们可能相同，也可能经过映射。

可以沿代码初始化、配置解析和网关路由追踪：CHAT_MODEL 只是取值入口，只有看到当前环境生效的值，才能确认请求中配置了什么；如果后面还有路由、备用模型或自动选择，还要继续确认这次请求实际走了哪一条路径。

同样，ChatOpenAI 或 model_provider="openai" 可以用于 OpenAI 兼容接口，不能据此认定底层就是某个 GPT 模型。公开教程的 HelloWorld 示例同时配置了 model="qwen-plus" 和百炼地址，说明客户端封装与实际服务供应商需要分别看。

模型自述“我是谁”也不是可靠的版本证据。响应中的 model 字段可以辅助关联，但某些服务返回的是对外服务名；例如 vLLM 的 --served-model-name 可设置 API 名称，响应也使用这个名称，因此仍需回到部署映射确认权重。vLLM 官方说明

云 API：说明快照、地域与生效时间

云模型要区分系列、稳定名称、滚动别名和日期快照。只知道 qwen-plus，不能仅凭名字补出历史调用时的日期版本；名称对应关系可能随平台更新而变化。

截至 2026-10-17，百炼的 qwen-plus 页面说明其当时功能等同于 qwen-plus-2025-12-01，并单列该日期快照。这是当前页面的对应关系，不足以证明几个月前某次调用也用了相同快照。若要控制变更，应在平台支持的范围内指定快照，并记录使用时间与地域。百炼模型文档

能力还需要按实际服务地域和接口核对。不能因为同名模型在一个地域支持 Function Calling，就推断所有接入地域、所有部署形态都支持。固定快照也不等于完整复现：Prompt、工具定义、检索内容、参数和服务实现变化，都可能影响输出。

本地部署：仓库名称还不是完整版本

以官方模型仓库 Qwen/Qwen3-8B 为例，它能明确模型系列与具体型号，但仓库的 main 分支仍可以更新。需要进一步记录实际加载的仓库提交或权重校验信息、Tokenizer 与聊天模板修订、精度或量化方式，以及是否叠加 LoRA 等适配器。

推理引擎和模型权重也应分开：vLLM 的版本不是 Qwen 权重的版本；API 对外服务名也不是权重仓库名。部署记录还可以保存容器镜像标识、关键启动参数和硬件信息，便于解释当时的上下文配置、并发和资源条件。Hugging Face 下载接口支持用 revision 指定分支、标签或提交；若需要固定文件版本，应使用实际提交，而不是只留下可移动的 main。

回答“用了量化版”时，也要说明具体模型文件及量化配置。相同系列、相同参数规模，可能因权重修订、量化和服务配置产生不同表现，不能直接套另一个部署的延迟或效果数字。

配置与实际调用怎样对应？

可以沿模型初始化、发布配置和调用记录确认实际生效的型号。如果代码只有 os.getenv("CHAT_MODEL")，它说明了配置入口，还需要看该环境配置的值。经过网关、自动路由或备用模型切换时，再结合对应请求的路由记录确认实际落点。

因此，保留用途、时间、请求 model ID 和模型或部署修订，通常就能把版本说明落到具体运行。源码默认值与实际请求可能不同；模型自己回答“我是谁”，也不能代替这些信息。

追问：为什么选这个版本，而不是更强或更新的模型？

先说该环节需要什么：是否可靠输出结构化结果、是否支持所需工具调用或模态、上下文是否容纳实际请求，以及目标延迟、费用和部署限制。再说明候选模型在同一任务集、Prompt 与预算下的比较结果。

如果项目尚未完成对照实验，可以解释已经核实的能力与接入条件，以及下一步如何比较；不必用排行榜或“最新最强”替代选型依据。主模型升级后也要覆盖工具调用、格式、长上下文和备用路由等回归，不能只验证一次普通对话。完整成功口径见如何量化评估 Agent 输出质量或任务成功率。

对应教程

参考资料