很多团队做大模型选型时，最大的问题不是“模型不够强”，而是没有先分清主模型、组件模型和系统层各自负责什么。本文试图用一张全景图，把强 CoT、强 Agent、Embedding、Reranker、Guardrail、Harness 这些容易混淆的概念一次讲清楚。

关键词： 大模型选型、强 CoT、Agent、Embedding、Reranker、Harness、LangGraph、MiroThinker、DeepSeek-R1

这两年大模型讨论里，一个很常见的误区是：

总想找“一个最强模型”解决所有问题。

但真正做过工程落地的人，通常会很快发现，事情根本不是这样。

在实际系统中，我们面对的从来不只是“模型聪不聪明”的问题，还包括：

• 它适不适合推理？
• 它适不适合做 Agent？
• 它能不能看图、读代码、处理长文档？
• 它适不适合做知识库检索？
• 它到底是主模型，还是一个组件模型？
• 它是在解决“能力问题”，还是在解决“系统问题”？

如果这些问题不拆开，选型就会非常混乱。

很多团队会在下面几个坑里来回踩：

• 用强推理模型去硬做检索系统，效果不稳定
• 用通用聊天模型做复杂多步 Agent，任务收敛很差
• 把 Embedding 模型当主模型看
• 把 Harness 当作“模型能力”来理解
• 希望一个模型同时承担问答、搜索、代码、审核、排序、评估所有职责

所以，本文想解决的核心问题只有一个：

如果从“功能定位”角度看，大模型到底应该怎么分类？

我的建议是，不要再只用“通用模型”或者“推理模型”这种过于粗糙的分类，而是改用一个更工程化的框架去看：

1. 主模型层
2. 组件模型层
3. 系统层

这三层拆开之后，很多原本看起来很乱的问题，会一下子变得清晰很多。

为了方便快速建立整体认知，你可以先看这张全景图：

如果把上面这张图再压缩成一句话，就是：

主模型层决定“谁来思考”，组件模型层决定“谁来辅助”，系统层决定“谁来把一切稳定组织起来”。

一、为什么“模型分类”不能只看一个维度

很多人说某个模型是“推理模型”，某个模型是“Agent 模型”，这当然没错，但还不够。

因为一个模型往往是多标签的。

例如，一个模型可能同时具备：

• 通用对话能力
• 强 CoT 能力
• 工具调用能力
• 长上下文能力
• 多模态能力

所以，真正有用的问题不是：

• 这个模型属于哪一类？

而是：

• 这个模型的主定位是什么？
• 它的副能力有哪些？
• 它在系统里扮演的是主脑、组件，还是只是被 Harness 调度的一部分？

换句话说，我们更应该问的是：

这个模型在我的系统里，到底是来“想”的、来“辅助”的，还是来“支撑流程”的？

二、先建立一个全景图：三层视角最实用

如果你是开发者，我最推荐你用下面这个三层视角来理解大模型生态。

第一层：主模型层

主模型层解决的是：

• 主要由谁来理解任务？
• 主要由谁来输出答案？
• 主要由谁来承担推理、规划、生成？

这一层通常包括：

• 通用对话模型
• 强 CoT / 强推理模型
• 强 Agent 推理模型
• 编码模型
• 多模态模型
• 长上下文模型
• 垂直领域模型
• 小模型 / 边缘模型

第二层：组件模型层

组件模型层解决的是：

• 谁来做检索向量化？
• 谁来做候选重排？
• 谁来做评估打分？
• 谁来做安全审核？
• 谁来做语音、OCR、结构化提取？

这一层通常包括：

• Embedding 模型
• Reranker 模型
• Judge / Evaluator 模型
• Guardrail / Moderation 模型
• OCR / ASR / TTS 等模态组件模型

第三层：系统层

系统层解决的是：

• 谁来编排任务流程？
• 谁来管理工具调用？
• 谁来做权限控制、回退和重试？
• 谁来做可观测性和评估闭环？

这一层通常包括：

• Harness / Orchestrator
• Workflow / State Machine
• Memory / Retrieval Pipeline
• Evaluation / Observability

你会发现，很多原本混在一起讨论的东西，其实完全不是同一层概念。

例如：

• DeepSeek-R1 是主模型
• bge 是组件模型
• LangGraph 是系统层

它们根本不应该拿来当同类东西比较。

三、主模型层：开发者最熟悉，但也最容易混淆

先看主模型层。

这是很多人平时最常接触的一层，也是讨论最热闹的一层。

1. 通用对话模型

这类模型最大的特点是：

• 综合能力比较均衡
• 日常对话、写作、问答、总结都不错
• 不一定在某一项能力上极端突出，但整体很好用

最适合的场景：

• 助手类应用
• 日常办公
• 客服问答
• 普通知识问答
• 轻量内容生成

典型代表：

• GPT-4o
• Claude 3.5 / 3.7 Sonnet
• Qwen2.5-Instruct

它们的优点是“好用、均衡、适配面广”，缺点是如果你遇到特别重的推理、特别重的 Agent 流程，往往还不够极致。

2. 强 CoT / 强推理模型

这类模型更擅长脑内推理。

它们的核心优势通常是：

• 长链路逻辑推演
• 数学推理
• 代码推理
• 在给定材料基础上做复杂分析

适合的场景：

• 复杂分析任务
• 数学与逻辑问题
• 编程难题拆解
• 给定资料后的深度比较和总结

典型代表：

• DeepSeek-R1
• QwQ-32B
• OpenAI o3

这一类模型，更像“坐在会议室里深度思考的人”。

它们擅长：

• 把问题想清楚

但它们不一定天然擅长：

• 主动出去查证据
• 连续做很多轮工具调用
• 在复杂外部环境反馈里持续修正任务路径

3. 强 Agent 推理模型

这是最近越来越值得单独讨论的一类。

这类模型的核心不是单纯“会思考”，而是：

• 会规划下一步做什么
• 会调用工具
• 会观察工具结果
• 会根据环境反馈修正思路
• 会在长任务中持续推进直到收敛

适合的场景：

• Deep Research
• 多来源搜索与查证
• 复杂故障排障
• 安全事件调查
• 复杂工单分析

典型代表：

• MiroThinker-v1.5
• OpenAI Deep Research 背后的 agent 形态
• 一些 browser/search-first agent 系统

这类模型更像：

会边查边想边行动的调查型大脑。

它和强 CoT 模型的关系，不是替代，而是重心不同：

• 强 CoT 更偏“想明白”
• 强 Agent 更偏“边做边想明白”

4. 编码模型

编码模型是非常独立的一类。

很多开发者会误以为：

• 强推理模型 = 强编码模型

这其实不完全成立。

好的编码模型除了推理，还需要：

• 理解项目上下文
• 生成可运行代码
• 熟悉 API 和框架
• 做补全、重构、测试生成
• 对工程风格更友好

适合的场景：

• IDE 辅助
• 代码补全
• Bug 修复
• 单元测试生成
• 重构建议

典型代表：

• Claude 3.7 Sonnet
• DeepSeek-Coder
• Qwen2.5-Coder

5. 多模态模型

多模态模型解决的问题，不是“纯文本推理”，而是：

• 看图
• 看截图
• 看图表
• 看票据和表单
• 图文联合理解

适合的场景：

• 读截图定位问题
• 分析界面设计
• 表格和图表理解
• OCR 增强任务
• 视觉问答

典型代表：

• GPT-4o
• Qwen2-VL
• Gemini 1.5 / 2.x

6. 长上下文模型

长上下文模型的价值并不只是“上下文更长”，而是：

• 能处理很长的文档
• 能跨很多材料保持上下文连续性
• 能在较长对话或文档里维持较好的理解能力

适合的场景：

• 合同与法务文档分析
• 代码库级别理解
• 长报告分析
• 大型会议纪要整理

这类模型和强推理模型可能重叠，但也可能不重叠。

也就是说：

• 上下文长，不代表推理一定强
• 推理强，也不代表长上下文一定最好

7. 垂直领域模型

这一类模型更强调：

• 行业术语适配
• 专业知识贴合
• 某类特定任务表现稳定

例如：

• 医疗模型
• 金融模型
• 法律模型
• 安全模型
• 运维模型

适合的场景：

• 术语壁垒高
• 行业数据格式复杂
• 通用模型在领域表达上不稳定

但要注意：

垂直领域模型并不一定意味着“底层能力更强”，很多时候它的核心价值是：

• 更懂领域

而不是：

• 天生更聪明

8. 小模型 / 边缘模型

这一类模型常常被低估。

很多业务场景里，最重要的问题不是“极限能力”，而是：

• 延迟低不低
• 成本能不能接受
• 能不能私有化
• 能不能跑在本地或者边缘环境

适合的场景：

• 本地部署
• 实时任务
• 高频低成本自动化
• 设备侧 AI

典型代表：

• Qwen2.5-7B / 14B
• Llama 3.x 8B
• Phi 系列

四、组件模型层：很多团队忽视了这层，结果系统天花板很低

如果说主模型层决定的是“大脑”，那组件模型层决定的是：

这个大脑获取信息、筛选信息、评估结果、管理风险的能力边界。

这一层被忽视，是很多 RAG 和 Agent 系统做不好的真正原因之一。

1. Embedding 模型

Embedding 模型负责把文本转换成向量，用于相似度检索。

它的核心价值是：

• 提高知识召回能力
• 支撑向量检索
• 帮助系统从海量资料里找到最相关内容

适合的场景：

• 知识库问答
• 文档检索
• 相似内容匹配
• 语义搜索

典型代表：

• bge
• gte
• jina-embeddings

很多时候，RAG 做不好，并不是主模型不够强，而是 Embedding 质量或者切片策略出了问题。

2. Reranker 模型

Reranker 模型负责对初步召回的候选结果重新排序。

它解决的是：

• 召回出来了很多东西，但不够准

适合的场景：

• RAG 精排
• 搜索结果排序
• 提高证据片段质量

典型代表：

• bge-reranker
• jina-reranker

在很多知识库系统里，是否引入 Reranker，对最终回答质量影响非常大。

3. Judge / Evaluator 模型

Judge 模型用来做这些事：

• 比较两个答案谁更好
• 判断答案是否满足要求
• 评估输出质量
• 给结果打分

适合的场景：

• A/B 测试
• 自动评估
• 批量质检
• Prompt 与系统回归测试

它通常不是独立某个固定模型，而是一种系统角色，常常由较强模型通过特定评估 prompt 来承担。

4. Guardrail / Moderation 模型

这类模型不是来“生成价值”，而是来“控制风险”的。

它们负责：

• 风险内容识别
• 越权请求拦截
• 输入输出过滤
• 安全策略判断

适合的场景：

• 企业级上线系统
• 高风险问答
• 合规与内容审核
• Agent 高风险动作前置判断

很多团队容易把安全能力全寄托在主模型上，但成熟系统通常都会把 Guardrail 单独设计。

5. OCR / ASR / TTS 等模态组件模型

这类模型虽然常常不被纳入“大模型讨论”，但它们在系统里非常重要。

包括：

• OCR：图片转文字
• ASR：语音转文本
• TTS：文本转语音

这些能力常常与主模型组成完整产品链条。

例如：

• 语音助手
• 票据识别系统
• 图像问答系统

五、系统层：为什么说 Harness 不是模型，但比模型更像“生产力放大器”

很多团队做 Agent 时，最容易忽略的不是模型，而是系统层。

模型再强，如果没有好的系统层，最后也可能变成：

• 偶尔很好用
• 但不稳定
• 不可观测
• 不可回退
• 风险不可控

这就是 Harness 的价值所在。

1. Harness / Orchestrator

Harness 负责的是：

• 工作流控制
• 工具调度
• 状态管理
• 重试与超时
• 高风险动作隔离
• 日志和审计

它不负责“想”，但它决定模型“能不能稳定工作”。

典型代表：

• LangGraph
• AutoGen
• CrewAI
• 企业自研 orchestrator

2. Workflow / State Machine

如果业务流程很复杂，单靠 prompt 往往不够。

这时需要明确的：

• 状态流转
• 分支条件
• 中断恢复
• 错误回退

尤其是在：

• 复杂排障
• 工单流转
• 企业审批
• 风险操作控制

这种场景里，状态机往往比“全靠模型自由发挥”稳定得多。

3. Memory / Retrieval Pipeline

很多人把记忆和检索看成“附属能力”，其实它们在系统层里非常关键。

因为模型真正落地时，几乎一定会涉及：

• 短期上下文
• 长期记忆
• 历史任务记录
• 文档检索
• 用户画像

这部分如果设计不好，哪怕模型本身很强，效果也会非常不稳定。

4. Evaluation / Observability

成熟系统一定会问：

• 为什么这次成功了？
• 为什么上次失败了？
• 哪一步性能最差？
• 哪个工具最容易出错？
• 哪个 prompt 版本效果更好？

这就是评估与可观测性的价值。

没有这层能力，Agent 系统很容易变成一个“玄学黑箱”。

六、从“岗位分工”角度看，会更容易理解

如果你还是觉得这些分类有点抽象，可以把它们想象成一个 AI 团队的岗位。

角色	对应类型
总指挥 / 主脑	通用模型、强 CoT 模型、强 Agent 模型
代码专家	编码模型
图像分析员	多模态模型
资料索引员	Embedding 模型
情报精排员	Reranker 模型
质检员	Judge / Evaluator 模型
风险审计员	Guardrail / Moderation 模型
作战系统 / 调度中心	Harness / Workflow / Observability

用这个视角看，你就会明白：

企业级 AI 系统，几乎从来不是“一个模型解决一切”，而是一套分工明确的组合体系。

七、面向开发者的实用选型表

下面这张表，适合做项目初期的快速判断。

任务特征	优先考虑
日常问答、写作、总结、普通助手	通用对话模型
数学、逻辑、复杂分析、静态推理	强 CoT / 强推理模型
Deep Research、排障、安全调查、复杂多步任务	强 Agent 推理模型
IDE 辅助、补全、重构、测试生成	编码模型
截图理解、图表分析、票据识别	多模态模型
超长文档、长上下文分析	长上下文模型
知识库问答、语义搜索	Embedding + RAG + Reranker
自动评估、质量打分、A/B 比较	Judge / Evaluator 模型
高风险上线、审核合规、越权控制	Guardrail + Harness
生产落地、复杂工作流、权限控制	Harness / Workflow / Observability

这张表背后的核心逻辑是：

先判断任务属于哪种能力问题，再去找对应层的模型或系统。

而不是一上来就问：

• 哪个大模型最强？

八、一个开发者最该记住的原则：不要把所有问题都当成“主模型问题”

这是本文最想强调的一点。

很多系统做不好，不是因为主模型不够强，而是因为问题根本不在主模型那里。

举几个最常见的误区：

误区 1：知识库问答效果差，一定是主模型不行

其实常见真因可能是：

• 切片策略不合理
• Embedding 质量不够
• 召回太杂
• 没有做 Reranker
• Prompt 拼接结构有问题

误区 2：Agent 经常跑偏，一定是模型太笨

常见真因可能是：

• Harness 不够好
• 工具设计不清晰
• 状态机缺失
• 没有失败回退
• 权限和目标边界不明确

误区 3：系统输出不稳定，就去换更大的模型

常见真因可能是：

• 缺少评估闭环
• 没有可观测性
• 缺少输入输出 guardrail
• 系统流程本身没有固化

所以，大模型工程里一个非常重要的能力，就是：

学会判断问题属于主模型层、组件模型层，还是系统层。

九、回到一开始的问题：还有其他功能定位不同的模型分类吗？

答案当然是有，而且很多。

如果把本文压缩成最值得记忆的一套全景图，可以概括成下面这张表。

层次	类别	核心价值	典型代表
主模型层	通用对话模型	综合能力均衡	GPT-4o、Claude Sonnet、Qwen2.5-Instruct
主模型层	强 CoT / 强推理模型	深度脑内推理	DeepSeek-R1、QwQ-32B、o3
主模型层	强 Agent 推理模型	边查边想边行动	MiroThinker-v1.5、Deep Research 形态
主模型层	编码模型	代码生成与重构	DeepSeek-Coder、Qwen-Coder、Claude
主模型层	多模态模型	图文联合理解	GPT-4o、Qwen2-VL、Gemini
主模型层	长上下文模型	长文档与长代码理解	Gemini 1.5、部分长上下文 Qwen
主模型层	垂直领域模型	行业术语与场景适配	各类行业微调模型
主模型层	小模型 / 边缘模型	低成本、低延迟、私有化	Qwen 7B/14B、Llama 8B、Phi
组件模型层	Embedding 模型	语义检索召回	bge、gte、jina-embeddings
组件模型层	Reranker 模型	候选精排	bge-reranker、jina-reranker
组件模型层	Judge 模型	自动评估与打分	强模型 + Judge Prompt
组件模型层	Guardrail 模型	风险控制与审核	各类 moderation / classifier
系统层	Harness / Workflow	编排、回退、权限、可观测	LangGraph、AutoGen、CrewAI

十、写在最后：以后再看模型，不妨先问这五个问题

如果你以后再遇到一个新模型，不知道该怎么判断定位，我建议先问自己下面五个问题：

1. 它最擅长的是分析、行动，还是生成？
2. 它主要处理的是文本、代码，还是图像和多模态？
3. 它更适合单轮任务，还是长链路任务？
4. 它在系统里扮演主脑、组件，还是只是被调度的一部分？
5. 它解决的是能力问题、检索问题、评估问题，还是系统问题？

如果这五个问题答清楚了，模型定位通常就不会太偏。

最后用一句话收尾：

大模型时代最重要的，不是找到“唯一最强模型”，而是搞清楚每一类模型和系统各自负责什么。

只有先分清主模型、组件模型和系统层，你的技术选型、系统设计和工程落地，才会真正开始变得清晰。