1-3 RAG、微调、续训与智能体选型

当单靠提示词工程无法满足需求时，就要开始考虑更进一步的工程手段。本篇围绕五大模块中的后四项展开：RAG、微调、续训、智能体开发。它们表面上都在“增强模型能力”，实际解决的问题并不一样。

---

本章课程目标：

• 建立一张清晰的选型地图：知道 RAG、微调、续训、智能体 分别在解决什么问题。
• 理解 RAG 的核心价值是补知识，理解微调的核心价值是改行为，理解续训的核心价值是补领域分布。
• 理解智能体并不是“更强的大模型”，而是大模型 + 工具 + 状态 + 执行流程的系统。
• 能结合真实项目判断：什么时候继续优化 Prompt，什么时候上 RAG，什么时候考虑微调，什么时候再引入工作流（Workflow）或 Agent。

学习建议： 学这章时，建议始终围绕三条线来判断方案：**知识够不够、行为稳不稳、流程会不会动。**如果缺的是知识，先看 RAG；如果缺的是输出风格、格式、指令遵循，先看微调；如果缺的是更底层的领域语言能力，才考虑续训；如果缺的是多步决策、外部工具调用和执行能力，再看智能体。这样你就不会把几种方案混成一团。

官方文档与资源：详见 工具导航与参考资料索引 - 微调与模型对齐、工具导航与参考资料索引 - RAG与向量检索、工具导航与参考资料索引 - 工具调用、MCP与智能体。

---

1、问题诊断

真实项目里，AI 应用回答不好时，最容易犯的错误是：还没判断问题根因，就直接说“要不要微调”“要不要上 Agent”。

先问四个问题会稳很多：

诊断问题	常见现象	优先考虑
模型是不是没看到资料？	不知道公司制度、产品手册、最新公告，回答没有引用依据	RAG
模型是不是行为不稳定？	格式飘、话术不统一、分类标签不稳、JSON 经常错	Prompt 优化，必要时微调
模型是不是不懂这个领域的语言分布？	拿到资料也读不懂，专业术语和行业逻辑经常错	续训，通常再配合 RAG
任务是不是需要多步执行？	需要查资料、调接口、校验、重试、写入系统	工作流或 Agent

1. 先 Prompt：如果只是需求表达不清，先把输入、输出、约束写清楚。
2. 再 RAG：如果缺的是资料、依据、最新信息或私有知识，优先建知识库。
3. 再微调：如果长期行为不稳，并且有高质量样本和评测标准，再考虑微调。
4. 慎用续训：只有当模型对领域语言和知识分布系统性陌生时，才考虑续训。
5. 流程固定先工作流：步骤明确、需要稳定可审计时，优先 Workflow。
6. 流程开放再 Agent：步骤会变化、需要动态选工具和根据中间结果调整路线时，再上 Agent。

后面的方案不是“不高级”，只是成本、风险和维护压力更高。能用轻方案稳定解决的问题，就不要过早引入重方案。

2、RAG

2.1 什么是 RAG

1）定义

RAG（Retrieval-Augmented Generation，检索增强生成）是一种把信息检索与大模型生成结合起来的应用架构。

基本流程并不复杂：

1. 用户先提问。
2. 系统先去外部知识库里找相关资料。
3. 再把“问题 + 检索结果”一起发给大模型。
4. 由模型基于这些资料生成答案。

RAG 的重点不是“修改模型参数”，而是在运行时给模型补充它当前需要的上下文。

先记住这个最短定义：RAG = 先查资料，再回答问题。

这和 1-2 提示词工程基础 的区别也很重要：

• 提示词工程主要依赖你提前写好的 Prompt。
• RAG主要依赖系统在提问时实时检索到的外部资料。

2.2 为什么 RAG 往往是项目里的第一选择

从工程角度看，RAG 之所以常常先于微调和续训，不是因为它“最先进”，而是因为它最符合大量知识类业务问题的真实成因。

真实项目里，大模型答不好，常见原因通常有三类：

• 知识过时：例如最新政策、最新产品说明、最新公告。
• 知识私有：例如企业制度、内部接口文档、项目手册、客户资料。
• 证据不足：模型有通用知识，但没有你当前要它参考的那份资料，因此容易幻觉。

这三类问题，本质上都更像“模型没看到材料”，而不是“模型不会说话”。这时最先应该验证的，往往不是训练模型，而是能不能把资料喂对。RAG 正是解决这个问题的。

它的现实优势主要有：

• 更新快：知识库更新后可以重新建索引，不必重新训练模型。
• 成本低：相比微调和续训，实施门槛和试错成本通常更低。
• 可追溯：检索结果可以保留来源、页码、文件名，方便核验。
• 更贴近业务系统：文档、数据库、FAQ、接口说明等都可以成为外部知识源。

在本仓库里，RAG 不是一个孤立概念，而是后续很多章节的主线能力：

• 2-RAG-搭建企业私有&个人知识库 会从平台角度带你搭建知识库。
• 19-RAG检索增强生成 会从 LangChain 代码角度带你拆开 RAG 的技术链路。
• 电商问数 项目里，系统也不是“直接把问题交给模型”，而是先通过 MySQL + Qdrant + Elasticsearch 组成的元数据知识库做多路召回，再生成 SQL。这属于面向结构化问数场景的 RAG 思路。

2.3 RAG 的工作流程

虽然 RAG 常被一句话概括成“先检索，再生成”，但在工程上，它通常分成两个阶段：

阶段一：知识库构建（离线）

• 读取原始文档
• 做清洗和切分
• 用嵌入模型把文本块转成向量
• 把文本块、向量和元数据写入向量数据库

阶段二：检索与生成（在线）

• 用户发起问题
• 将问题向量化
• 从知识库中召回相关片段
• 把片段与问题一起组装进 Prompt
• 交给大模型生成最终回答

这条链可以拆成：

• 索引阶段解决“资料怎么准备好”
• 问答阶段解决“资料怎么在提问时被找出来并用上”

因此，RAG 从来不只是“向量库 + 大模型”这么简单。文档质量、分块策略、召回方式、重排策略、Prompt 组织方式，都会影响最终效果。

2.4 何时需要 RAG

当你遇到下面这些场景时，优先验证 RAG 通常是比较稳妥的：

• 需要接入企业内部资料、产品文档、FAQ、制度手册、接口说明等私有知识
• 需要回答最新信息、时效性很强的问题
• 希望回答结果能附带依据和来源
• 希望在不改模型参数的情况下，快速迭代知识内容

典型场景包括：

• 企业知识库问答
• 智能客服与售后助手
• 研发文档问答
• 运维排障助手
• 合同、制度、政策、课程讲义等文档问答

2.5 实现方式

RAG 的实现方式大致可以分为三类：

（1）在线平台

例如 Cherry Studio、ima、Dify、FastGPT、RAGFlow 等。优点是上手快、可视化、验证快，适合入门或快速搭原型。

（2）离线客户端

例如本地知识库客户端、桌面 AI 工具，适合个人知识管理和轻量实验。

（3）借助框架或纯代码实现

例如基于 LangChain、LangGraph 或纯 Python 自己搭建完整的文档加载、切分、向量化、检索和生成流程。这种方式灵活度最高，也最接近真实项目开发。

2.6 RAG 的几个常见误区

误区 1：有知识库就一定不会幻觉

不是。RAG 只能显著降低幻觉，不能保证 100% 正确。检索错了、召回噪声太多、Prompt 没约束好，模型仍然可能答错。

误区 2：文档全塞进去就行

不是。RAG 的关键不是“文档数量多”，而是“能不能把相关的那几段稳稳找出来”。

误区 3：RAG = 向量检索

也不完全对。向量检索只是常用手段，真实项目里经常会结合关键词检索、过滤、重排、元数据约束一起使用。

误区 4：RAG 能替代一切训练

不能。RAG 解决的是“模型没看到知识”的问题，不擅长解决“模型不会按固定风格/格式输出”的问题。

2.7 RAG 效果不好时，先看哪里

RAG 上线后效果不理想，不要马上得出“RAG 不行”或“必须微调”的结论。先沿着链路拆问题：

问题位置	典型表现	优先排查
文档质量	原文过期、冲突、缺页、扫描件 OCR 错误	更新资料、清洗文档、保留版本和来源
文档解析	表格、标题、层级、图片说明被解析乱	更换解析器，必要时引入人工校验
文本切分	检索片段太碎或太长，答案上下文不完整	调整 chunk size、overlap、按标题层级切分
召回策略	找不到正确片段，或者召回一堆无关内容	调整 Embedding、Top-K、关键词检索、元数据过滤
重排序	正确片段被排到后面	引入 Reranker 或调整重排模型
Prompt 增强	检索到了资料，但模型没按资料答	明确要求引用资料、缺依据时说明“不确定”
生成模型	资料正确但推理仍错	更换模型、加强约束，必要时再看微调或续训

这张表背后的原则是：

RAG 失败先修检索链路，再看生成模型；不要把所有问题都归因于“模型不够强”。

---

3、微调（Fine-tuning）

3.1 什么是微调

微调（Fine-tuning）是指在已经训练好的基础模型上，继续用特定数据做训练，使模型在某类任务、某种风格或某种输出形式上表现更稳定。

在工程语境里，可以记住这句话：微调主要是在改模型的“行为方式”，而不是在给模型外挂一套知识库。

它最常见的目标包括：

• 让模型更稳定地遵循指令
• 让模型输出固定格式，例如 JSON、SQL、标签、分类结果
• 让模型更符合某种业务风格、品牌口吻或术语习惯
• 让模型在某类任务上更稳，例如分类、抽取、代码补全、客服回复

需要特别提醒的是，微调虽然也可能让模型“记住一些样例”，但它并不适合承载高频变化的知识。如果知识经常变，仍然应该优先考虑 RAG 或外部知识源。

你可能会问： 微调是不是把企业资料“灌进模型里”？
更贴切的说法是：微调更擅长让模型“按你想要的方式做事”，而不是“记住所有最新资料”。知识经常变化的场景，优先考虑 RAG；风格、格式、任务习惯长期不稳的场景，再考虑微调。

3.2 何时需要微调

当你遇到下面这些问题时，微调才更可能是对路的方案：

（1）模型行为不稳定

比如：

• 明明已经写了输出格式，还是经常不按格式来
• JSON、SQL、分类标签这类输出经常飘
• 多轮提示后仍然经常漏字段、漏步骤

（2）风格和话术需要长期固化

例如：

• 客服回复要长期保持统一口吻
• 某行业报告要始终遵循同一种写作规范
• 品牌文案需要稳定体现品牌语气

（3）提示词已经很重，但效果还是不稳

如果你已经反复优化 Prompt、增加示例、做结构化约束，效果仍然不理想，说明问题可能不只是“提示没写好”，而是模型对这类任务的行为模式还不够稳定。

3.3 何时可以微调

不是所有团队都适合上来就微调。一般至少要满足下面两个前提：

（1）数据足够

微调依赖的是高质量、任务相关、标注明确的数据。没有好数据，微调很容易沦为“把噪声训练进模型”。

（2）评测标准清楚

如果你连“什么叫变好了”都说不清，就很难知道微调到底有没有价值。真实项目里，先做清楚评测集和验收标准，往往比先开始训练更重要。

（3）算力与预算可接受

虽然微调远比续训便宜，但依然需要训练资源、数据清洗和评测成本。

3.4 微调的技术方法

随着模型越来越大，全参数微调并不是大多数团队的首选。工程上更常见的是参数高效微调。

（1）全参数微调（Full Fine-tuning）

更新模型全部参数，理论上上限更高，但训练资源和显存开销都很大，适合资源充足、目标明确的场景。

（2）参数高效微调（PEFT, Parameter-Efficient Fine-Tuning）

这类方法的核心思路是：尽量少改参数，用更低成本获得可接受的效果。

最常见的两种是：

• LoRA：冻结原模型大部分参数，只训练新增的低秩适配参数。
• QLoRA：在 LoRA 基础上结合低比特量化，进一步降低显存占用。

（3）其他高效方法

• Adapter Tuning：在模型层间插入小型适配器模块
• Prefix Tuning：在输入前添加可学习的虚拟前缀
• P-Tuning v2：在模型每一层添加可训练的提示向量

这些方法你在入门阶段不必死记公式，但要建立一个工程认知：
今天大多数团队如果自己做微调，优先考虑的通常不是全参，而是 LoRA / QLoRA 这类 PEFT 路线。

3.5 主要风险

微调并不是“只要训一下就更强”，它的常见风险包括：

• 过拟合：训练集表现很好，真实场景一塌糊涂
• 灾难性遗忘：模型学了新任务，原有能力被冲掉
• 样本偏差：把团队自己的偏见、噪声、错误格式一起学进模型
• 评测幻觉：只看少量样例感觉“效果不错”，但没有系统评测

所以微调前后都要问自己：
我到底是在解决一个长期、稳定、可评测的行为问题，还是只是暂时觉得 Prompt 写得不够顺手？

3.6 RAG vs 微调

RAG 和微调常被混在一起。工程上先看这条分工：

• RAG 更偏补知识
• 微调更偏改行为

先用下面这张工程对照表来建立判断：

维度	RAG	微调（Fine-tuning）
核心目标	给模型补充外部知识	让模型更稳定地按目标做事
是否修改参数	否	是
更适合解决什么	私有知识、最新知识、可追溯	风格、格式、指令遵循、分类
更新速度	快，改知识库即可	慢，需要重新训练
成本结构	系统开发成本为主	数据、训练、评测成本为主
典型场景	文档问答、知识库、客服知识	结构化输出、统一话术

最常见的判断口诀是：

• 缺知识：先看 RAG
• 缺行为：再看微调

---

4、续训（Continued Training）

4.1 什么是续训

续训通常对应的是 Continued Pretraining，也就是在模型已经完成通用预训练后，再用某一领域的大规模原始语料继续训练，让模型更熟悉该领域的语言分布、术语体系和知识结构。

简要概括：续训是让模型“更懂某个世界”，微调是让模型“更会按要求做事”。

和微调相比，续训更接近预训练逻辑，通常使用的是海量无标注文本，而不是精心整理的“指令 - 答案”样本。

4.2 何时需要续训

只有在下面这类场景里，续训才比较值得考虑：

• 模型对某个领域语言分布存在明显系统性缺失
• 不是只差几个术语，而是整套领域表达都“不像这个行业的人”
• RAG 和微调都无法很好弥补这种底层缺口

例如：

• 大规模法律、医疗、金融、代码语料的领域适配
• 新语言、冷门编程语言、专业文献体系的长期能力增强
• 需要让模型在某个垂直领域具有更自然的基础表达和理解能力

4.3 何时可以续训

续训对资源要求比微调高得多，通常需要同时满足：

（1）数据充足

需要的是大量高质量原始文本，而不是少量指令样本。规模往往是 GB 到 TB 级。

（2）硬件充足

续训通常需要更长训练时间、更高显存、更强的数据处理能力。

（3）业务收益足够大

多数企业项目用不到续训。因为它成本高、风险高、迭代慢，很多问题用 RAG + Prompt 或 RAG + 微调 已经能解决。

4.4 工程实践中的常见误区

误区 1：把 SFT 样本拿去做续训

续训更接近语言建模，不是拿“问答对”硬灌进去。

误区 2：把领域知识缺失问题全都交给微调

如果模型连该领域“说话方式”都不熟，单靠微调往往不够稳。

误区 3：企业项目动不动就想续训

这是最常见的误区。绝大多数业务问题，没必要一上来就碰续训。

4.5 微调 vs 续训

很多团队之所以“做了训练但效果一般”，往往就是把本该续训的问题拿去微调，或者反过来。

1）先做区分

微调：让模型“按你想要的方式做事”。具体的：行为对齐／风格对齐／任务对齐。

续训：让模型“知道它原来不知道的世界”。具体的：知识扩充／语言分布补全／能力下沉。

2）核心对比总览

维度	微调（Fine-tuning）	续训（Continued Pre-training）
训练目标	改行为方式	改知识分布 / 语言分布
数据形式	指令数据、对话数据、标签	大规模原始文本
是否依赖标注	强依赖	通常不依赖
数据规模	千级、万级、十万级	十万级、百万级、海量语料
算力成本	低到中	高
常见方法	LoRA / QLoRA / PEFT	更接近预训练流程
典型问题	格式、风格、指令遵循	领域语言理解和分布偏差

3）典型应用场景对照

场景	正确选择
客服机器人更像「某公司风格」	微调
模型学会某行业黑话	续训
提高 SQL 生成稳定性	微调
让模型理解行业文档	通常先 RAG；模型读不懂领域语言时再评估续训
新语言/新编程语言	续训
工具调用意图和参数格式更稳定	微调或更强工具调用模型

4）工程上的组合拳

实际项目中，很少“二选一”，而是：

一条常见训练路线可以理解为：通用基座模型 → 领域续训（补领域分布）→ 指令微调（对齐行为）→ RLHF / RLAIF（优化偏好）

这不是每个企业项目都要完整走一遍的固定流程，而是理解训练层次的参考路线。大多数应用团队更常见的路径是：先选合适基座模型，再用 Prompt + RAG + 工作流 / Agent 做应用层增强；只有当行为稳定性、领域语言分布或工具调用数据确实成为瓶颈时，才进入微调或续训。

如果确实要组合训练，顺序通常不能随意反过来。因为如果你先微调，再做大规模续训，前面学到的行为模式可能会被冲掉。

记法： 续训 = 让模型更熟悉某个领域的语言和分布；微调 = 让模型更稳定地按你想要的方式做事；RAG = 在运行时把资料和证据补给模型。工程上多数知识类场景先用「RAG + 提示词」验证，行为类问题再评估微调，续训放在更重、更后的位置。

---

5、智能体开发

5.1 什么是智能体？

在经典 AI 语境里，智能体（Agent）指能够感知环境、做出决策并执行动作，以实现目标的系统。

放到大模型应用开发里，更工程化的定义是：

智能体 = 大模型 + 工具 + 状态 + 执行流程

智能体并不只是“会聊天的模型”，而是一个能够：

• 理解用户目标
• 决定下一步做什么
• 选择是否调用工具
• 接收工具结果
• 基于结果继续决策
• 直到完成任务的系统

五大核心要素通常包括：

• 大语言模型（LLM）
• 记忆系统（Memory）
• 工具调用（Tools）
• 规划决策（Planning）
• 行动执行（Action）

OpenAI 前安全系统团队负责人翁丽莲于 2023 年 6 月在个人博客系统化总结了当时流行的 LLM Agent 典型架构。

与单纯大模型的本质区别：

• 大模型主要负责“生成回答”
• 智能体负责“围绕目标持续决策并执行动作”

例如：

• 单纯大模型会告诉你“可以查天气 API”
• 智能体会真的去调天气 API，再把结果组织成回答

5.2 何时需要智能体

当任务开始呈现下面这些特征时，就要认真考虑智能体：

• 任务是多步骤的，而不是一句话能答完
• 需要调用外部工具，例如天气、搜索、数据库、浏览器、发消息
• 中间结果会影响后续动作，流程不是完全固定的
• 需要一定的状态管理、规划、失败重试或反思机制

例如：

• “先查知识库，再查数据库，再生成一份报告”
• “先查库存，再查价格，再决定推荐哪一款商品”
• “先检索用户资料，再调外部系统完成操作，再返回结果”

在本仓库里，智能体这条主线后续会继续展开：3-基于 Coze&Dify 平台的智能体开发、20-MCP模型上下文协议、21-Agent智能体、22-LangGraph概述与快速入门

电商问数 项目里，虽然主体是面向 SQL 生成的工作流（Workflow），但它本质上也体现了“检索、筛选、生成、校验、执行”的多步智能体 / 工作流思路。

粗略区分： Prompt 更像“把问题问清楚”，RAG 更像“先给模型补资料”，Agent 更像“把一件事做完”。

5.3 工具调用的实现方式

5.3.1 Tool Calls / Function Calling

1、定义

Tool Calls / Function Calling（函数调用，也常写作 Function Call、Tool Calling、工具调用）是模型和外部工具交互的一种标准能力。模型不会自己真的调用天气接口、数据库或发邮件接口，而是会根据工具描述，先输出“应该调用哪个工具、传什么参数”，然后由你的代码真正执行。

这里的分工是：

• 模型负责决定
• 程序负责执行

这就是 Function Calling 的本质。

2、流程

3、演示

以 DeepSeek 官方 API 为例演示 Tool Calls / Function Calling。整体流程共五步：

① 告诉模型「有哪些工具、用户说了什么」；

② 模型决定「要调哪个工具、传什么参数」并返回；

③ 我们的代码真正执行工具拿到结果；

④ 把工具结果塞回对话发给模型；

⑤ 模型根据结果生成最终回复。

（1）步骤一：定义工具 + 发用户消息

**作用：**把「用户问了什么」和「你现在允许模型用哪些工具」一次性交给模型。模型没有内置天气接口，只有你通过 tools 传了 get_weather 的 name、description 和 parameters，它才知道可以调用这个工具。

curl https://api.deepseek.com/chat/completions \
 -H "Content-Type: application/json" \
 -H "Authorization: Bearer ${API_KEY}" \
 -d '{
 "model": "deepseek-v4-flash",
 "messages": [
    {
     "role": "system",
     "content": "你是个智能天气查询助手，根据用户的提问自主调用工具"
    },
    {
     "role": "user",
     "content": "北京市天气如何？"
    }
  ],
   "tools": [
    {
     "type": "function",
     "function": {
      "name": "get_weather",
      "description": "根据用户输入的城市信息，获取该城市的天气",
      "parameters": {
       "type": "object",
       "properties": {
        "city": {
         "type": "string",
         "description": "城市名称，只保留最细粒度的地区名称"
        }
       },
       "required": ["city"]
      }
     }
    }
   ]
  }'

（2）步骤二：模型返回“要调哪个工具、参数是什么”

**作用：**模型根据上下文判断需要查天气，于是返回 tool_calls。注意这里它只是“提出调用请求”，并没有真的去执行天气接口。

{
  "id": "7cccd00d-f0a5-4b2e-872c-a54bdb767796",
  "object": "chat.completion",
  "created": 1767176438,
  "model": "deepseek-v4-flash",
  "choices": [
    {
      "index": 0,
      "message": {
        "role": "assistant",
        "content": "我来帮您查询北京市的天气情况。",
        "tool_calls": [
          {
            "index": 0,
            "id": "call_00_Kpq3g6mPl9BYlZIe1NSNm3Cs",
            "type": "function",
            "function": {
              "name": "get_weather",
              "arguments": "{\"city\": \"北京\"}"
            }
          }
        ]
      },
      "logprobs": null,
      "finish_reason": "tool_calls"
    }
  ],
  "usage": {
    "prompt_tokens": 336,
    "completion_tokens": 52,
    "total_tokens": 388,
    "prompt_tokens_details": {
      "cached_tokens": 0
    },
    "prompt_cache_hit_tokens": 0,
    "prompt_cache_miss_tokens": 336
  },
  "system_fingerprint": "fp_eaab8d114b_prod0820_fp8_kvcache"
}

（3）步骤三：在本地/服务端真正执行工具

**作用：**你的程序根据步骤二里的 name 和 arguments 去真正执行天气函数或第三方 API 请求，并得到真实结果。这里为了教学，直接给出假设返回值。

{
  "temp": "2℃",
  "text": "晴",
  "wind": "西北风3级"
}

（4）步骤四：把工具结果塞回对话，再请求模型

**作用：**模型必须“看到”工具执行结果，才能生成最终面向用户的自然语言回答。

curl https://api.deepseek.com/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer ${API_KEY}" \
  -d '{
  "model": "deepseek-v4-flash",
  "messages": [
        {
          "role": "system",
          "content": "你是个智能天气查询助手，根据用户的提问自主调用工具"
        },
        {
          "role": "user",
          "content": "北京市天气如何？"
        },
        {
            "role": "assistant",
            "content": "我来帮您查询北京市的天气情况。",
            "tool_calls": [
                {
                    "index": 0,
                    "id": "call_00_Kpq3g6mPl9BYlZIe1NSNm3Cs",
                    "type": "function",
                    "function": {
                        "name": "get_weather",
                        "arguments": "{\"city\": \"北京\"}"
                    }
                }
            ]
        },
        {
          "role": "tool",
          "tool_call_id": "call_00_Kpq3g6mPl9BYlZIe1NSNm3Cs",
          "content": "{\"temp\":\"2℃\",\"text\":\"晴\",\"wind\":\"西北风3级\"}"
        }
      ],
      "tools": [
        {
          "type": "function",
          "function": {
            "name": "get_weather",
            "description": "根据用户输入的城市信息，获取该城市的天气",
            "parameters": {
              "type": "object",
              "properties": {
                "city": {
                  "type": "string",
                  "description": "城市名称，只保留最细粒度的地区名称"
                }
              },
              "required": ["city"]
            }
          }
        }
      ]
    }'

（5）步骤五：模型根据工具结果生成最终回复

**作用：**这一步模型不再返回 tool_calls，而是直接给用户最终答案。

{
  "id": "4f5f2133-6519-497e-aecc-2bd25a37c747",
  "object": "chat.completion",
  "created": 1767177264,
  "model": "deepseek-v4-flash",
  "choices": [
    {
      "index": 0,
      "message": {
        "role": "assistant",
        "content": "根据查询结果，北京市当前的天气情况如下：\n\n- **温度**：2℃\n- **天气状况**：晴\n- **风力**：西北风3级\n\n今天北京天气晴朗，温度在2℃左右，风力不大，是个不错的天气。建议您外出时适当保暖，虽然天气晴朗但温度还是偏低的。"
      },
      "logprobs": null,
      "finish_reason": "stop"
    }
  ],
  "usage": {
    "prompt_tokens": 422,
    "completion_tokens": 70,
    "total_tokens": 492,
    "prompt_tokens_details": {
      "cached_tokens": 384
    },
    "prompt_cache_hit_tokens": 384,
    "prompt_cache_miss_tokens": 38
  },
  "system_fingerprint": "fp_eaab8d114b_prod0820_fp8_kvcache"
}

4）Function Calling 的不足

（1）工具实现与复用成本高

很多工具是某个项目自己定义的，和业务环境耦合较重，不容易跨团队、跨客户端复用。

（2）规范碎片化

不同模型厂商的工具调用格式、字段命名、细节行为并不完全一致，维护成本会逐渐上升。

（3）可靠性依赖工具描述质量

工具描述不清、参数 schema 不完整时，模型就更容易调错工具或传错参数。

5.3.2 MCP

1、定义

MCP（Model Context Protocol，模型上下文协议）是一套面向 AI 应用与外部能力连接的开放协议。它的核心含义是：

MCP 是把“工具、资源、提示模板”等能力按统一方式暴露出来的一层标准接口。

MCP 更关注的是“怎么统一接入和复用外部能力”，而不仅仅是“模型会不会调某个函数”。

MCP 就像 AI 世界的 USB-C 接口。只要某个能力按 MCP 标准暴露出来，支持 MCP 的不同 AI 应用就可以更容易地发现和使用它。

Function Calling 与 MCP 的关系与区别

Function Calling 和 MCP 不是同一个东西，但经常会一起出现。

	Function Calling	MCP
是什么	模型调用工具的能力	一套标准化通讯协议
关注点	模型怎么表达“我要调哪个工具”	工具和资源怎么统一暴露、发现和复用
作用	让模型能调用外部能力	让外部能力能被不同 AI 应用统一接入
适用层	更偏模型调用层	更偏应用接入层 / 工具生态层

更容易记的方式是：

• Function Calling：模型侧的调用能力
• MCP：工具侧的标准化暴露方式

2、流程

MCP 本质上是对“工具接入”做了进一步标准化。除了 Tools，它还支持 Resources 和 Prompts。

最常用的是 Tools，但它的设计范围比传统 Function Calling 更大。

MCP 使用理解（以 Cherry Studio + 天气为例）

可以按这个关系理解：

• MCP 是协议
• 天气 MCP Server 是实现了该协议的服务
• Cherry Studio 是支持该协议的客户端
• DeepSeek / 其他模型仍然在负责理解用户意图并决定是否调用工具

所以当你在 Cherry Studio 里连接了天气 MCP Server，再问“北京天气怎么样”时，背后不是模型自己突然学会了天气接口，而是：

1. 客户端把可用工具列表告诉模型
2. 模型决定调用 get_weather
3. 客户端通过 MCP 调用对应 Server
4. Server 返回天气结果
5. 模型再把结果组织成自然语言

大模型如何知道“什么时候调”“调哪一个”？

• 什么时候调？
  因为客户端会把当前所有可用工具及其描述发给模型，模型根据用户问题和工具描述，判断是否需要调用。

• 调哪一个？
  因为每个工具都有 name、description、parameters，模型会根据用户问题和工具描述进行匹配。

所以模型并不是“认识 MCP”本身，而是认识“这次请求里有哪些可用工具”。

3、相较于 Function Calling 的优势

MCP 一定程度上弥补了 Function Calling 在生态层面的不足：

• 复用更强：一个 MCP Server 可以被多个客户端复用
• 适配更统一：不同 AI 应用按同一协议接能力
• 更利于形成工具生态：工具不再只服务某个单一应用

5.4 智能体开发方式

当前常见的智能体开发方式主要有两类：

（1）在线平台开发

例如 Dify、Coze。这类方式上手快，适合做可视化编排和快速原型。

（2）基于框架开发

例如 LangChain、LangGraph。这类方式自由度更高，更适合真实项目开发和复杂业务逻辑落地。

5.5 工作流（Workflow）

1、什么是工作流

工作流（Workflow）是一种更强调固定步骤和可控执行的设计模式。它通常用于把复杂任务拆成一系列明确步骤，并按预设顺序执行。

例如：先分类、再检索、再生成、再校验、再输出。

这类场景不一定需要 Agent 临场自由决策，更适合工作流。

比如：讯飞星辰 Agent 平台：https://agent.xfyun.cn/home

2、工作流（Workflow）和 Agent 怎么区分

这是实际项目里的常见判断。

场景特征	更适合什么
步骤固定、顺序明确、强调可控和稳定	工作流（Workflow）
步骤不固定、需要动态选工具和持续决策	Agent

所以很多真实系统并不是“只做 Agent”或者“只做工作流（Workflow）”，而是：

固定部分用工作流（Workflow），动态部分再交给 Agent。

电商问数 就很适合拿来理解这件事。它不是放任模型完全自由发挥，而是先做召回、再做生成、再做校验和执行，整体更接近 工作流（Workflow）主导 + 大模型参与关键节点决策 的工程思路。

3、工作流开发方式

（1）Dify、Coze 等在线平台开发工作流

（2）基于 LangChain / LangGraph 等框架开发工作流

---

章节思考题：

1. 当一个 AI 应用回答不好时，你如何判断问题是“缺知识”“行为不稳”，还是“流程没设计好”？

   参考思路： 先看错误类型：不知道公司资料、引用过时信息，多半缺知识，优先 RAG；格式、语气、分类口径反复飘，多半行为不稳，可先优化 Prompt，再评估微调；需要多步查找、校验、执行，则是流程问题，优先工作流或 Agent。

2. 为什么内部知识库问答通常不应该一上来就做微调？

   参考思路： 内部资料经常变化，微调把知识写进模型参数，更新成本高且可追溯性弱。RAG 可以保留资料来源，更新文档即可生效，更适合私有知识、制度、FAQ、产品手册这类场景。

3. 续训、微调和 RAG 都能让模型“更懂业务”，但代价和风险有什么不同？

   参考思路： RAG 代价最低，主要风险在检索质量；微调代价中等，风险在数据质量和行为泛化；续训最重，涉及大规模语料、算力、稳定性和评测。项目选型时应先用轻方案验证，再考虑重方案。

4. 什么时候固定工作流比 Agent 更合适？

   参考思路： 当步骤稳定、责任清晰、需要审计和可解释时，工作流更合适，比如先召回、再过滤、再生成、再校验。Agent 更适合步骤不固定、需要临场选工具和根据中间结果调整路线的任务。

本章小结：

• RAG 解决的是“模型没看到知识”的问题，尤其适合私有知识、最新知识、可追溯问答。它不改模型参数，而是在运行时补上下文。
• 微调 解决的是“模型行为不稳定”的问题，更适合风格、格式、指令遵循、结构化输出等长期一致性要求高的场景。
• 续训 解决的是“模型底层领域分布不熟”的问题，成本高、门槛高，不应成为大多数项目的第一选择。
• 智能体 解决的是“怎么围绕目标做多步决策并调用外部能力”的问题；Function Calling 偏模型调用能力，MCP 偏统一接入协议，工作流（Workflow）偏固定流程编排。
• 从选型顺序看，比较稳的思路通常是：先 Prompt，再看 RAG，再看微调，续训放到更后面；流程固定先工作流（Workflow），流程开放再上 Agent。

建议下一步： 建议按你最关心的能力线继续往下走：想把 RAG 落到代码里，就看 第 19 章 RAG 检索增强生成；想理解工具接入和协议层，就看 第 20 章 MCP 模型上下文协议；想理解多步决策与执行，就看 第 21 章 Agent 智能体。