昨天，一个朋友在微信上问我：
「RAG 和 Function Call 到底是啥？我今天面试被问到了，答得稀碎。」
我盯着屏幕，打了三个字，删掉；又打了五个字，删掉。
最后回过去一句：「就是……检索增强生成，和函数调用。」
朋友秒回：「谢谢，等于没说。」
关掉对话框，坐在椅子上愣了半天。不是因为答不上来——而是我突然想起来：这两个词，我两年前就玩过了，还写过两篇教程。 我当时只是不知道它们有这个学术名字。
晚上我把旧文翻出来重读了一遍，越看越想笑。于是有了这篇文章。
两年前的旧文，现在看内容已经有点土了，但坑是真踩过：
微信公众号接入 AI：原文地址
公众号接入DeepSeek：原文地址
两个词，两句话
先把这两个词讲明白。都是人话，不难。
RAG，一句话总结：让模型开卷考试。
大模型本身是闭卷考生。它的知识全在训练时背下来的那堆参数里，背到哪天算哪天，之后发生的事它一概不知，问它你们公司的部署文档更是要命——它没见过。
RAG 干的事，就是允许它考试时翻书。但这个「翻书」有讲究：你得提前把书拆成一页页（切片），给每一页编好目录（向量索引），考试时它拿着题目快速翻到最相关的那几页（检索），然后照着那几页的内容组织答案（生成）。
整条链路里，翻书那一步是 RAG 的命门。翻错了页，后面写得再流畅也是胡说八道。
Function Call，一句话总结：让模型学会点菜，而不是自己做菜。
模型很聪明，但它没有手脚。它不会算账、不知道今天济南下不下雨、查不了你的订单号。以前的办法是把这些信息塞进提示词里硬问，笨重且不可靠。
Function Call 的思路是：模型发现自己缺什么，就举手说「这个我需要调个工具」。程序接到这个请求，去调真正的接口，把结果喂回去，模型再接着往下答。
打个比方，模型是个坐在屋里、脑子极好但四肢被绑住的顾问。Function Call 就是给他一根能按铃的绳子——铃那头有什么，取决于你给他配了几个按钮。
这活儿我干过
2024 年 6 月，我在扣子（Coze）上搭过一个机器人，挂到自己的公众号上做智能问答。
当时我的操作是这样的：新建一个 Bot，写上人设和回复逻辑，选一个模型（那篇里用的是 Kimi，moonshot 32k），然后在「技能」里挂上 bingWebSearch，最后发布、填公众号 AppID，搞定。
全程没有写一行代码，也没有任何一个地方出现过「RAG」或者「Function Call」这些字眼。
但它就是这两件事。
我把提示词写好——那叫 System Prompt。
我挂了个联网搜索技能——那叫 Function Call。
我让它能回答超出训练数据的问题——那叫检索增强。
我当时觉得自己在玩一个很轻的玩具。两年后再看，我只是把五个概念用鼠标点了一遍，没给它们起名字。
换了身马甲
这几年 AI 圈有个习惯：同一件事，每半年换一个更贵的名字。我把对照表列一下，你一看就懂了。
| 今天叫 | 当年在扣子上叫 | 实际干的事 |
|---|---|---|
| System Prompt | 人设与回复逻辑 | 定角色、定脾气、定说话边界 |
| Function Call | 技能 / 插件 | 让模型能搜网页、能查数据 |
| RAG | 知识库 | 把资料喂进去，让它照着答 |
| LLM | 选模型 | 挑一个脑子来干活 |
| 渠道分发 | 发布到公众号 | 让它真被人用上，而不只是能跑 |
我第一次看到这张表的时候，感觉像小时候做过的趣味物理题，长大后在大学课本里看到了标准答案和公式推导。
事情本身没变，变的是你有没有底气把它说清楚。
说句实在的，我那天答不上来，不是不会，是「会用不会说」。这在技术圈挺常见——尤其对一线干活的工程师来说，我们习惯先让东西跑起来，再回头补名词。但面试和对外沟通不这么算账，你说不出那个词，对方就默认你没做过。
再说 Dify
前段我在折腾 Dify。
起因很实际：我要在公司的内网环境里搭一个 K8s 专属知识库，把部署、升级、运维这些文档灌进去，让同事能直接问。
打开画布那一刻，我第一反应是——「这不就是扣子上那套吗？」
对，也不对。
做法上确实一样：挂知识库、写提示词、选模型、配工具。但有个根本区别，我把它叫做**「谁说了算」**。
在扣子上我用的是单 Agent 模式。我给人设、给技能，然后就放手了，让它自己决定什么时候去搜、什么时候不搜。这很省事，但我控制不了它走哪条路，出了问题也很难复现——同一个问题问两遍，回答的路径可能完全不一样。
在 Dify 上我画的是工作流：开始节点 → 知识检索 → LLM → 直接回复，一根线一根线连起来。哪一步查什么、查不到走哪条分支、上下文怎么注入，全是我画死的。
这两种范式不是新旧关系，是两种控制方式。
Agent 像是给员工一份岗位说明书，剩下靠他自己判断。Workflow 像给流水线装好了传送带，每一站都在你算好的位置上。
做 Demo 的时候，第一种爽。做生产、要排障、要可复现的时候，第二种救命。
顺带说一个我踩过的坑：在 Dify 里用兼容 OpenAI 接口的插件接进来的模型，添加时必须显式指定「函数调用类型」。选错了，模型就永远不会去调工具，而且它不会报错，只是沉默地假装自己不会。我为了确认这一点，翻了官方仓库的 yaml 才找到依据。
差别不在功能
如果只看功能，公平地讲，Dify 能做的扣子基本都能做，很多地方扣子还更好用——毕竟是大厂产品，界面顺滑、上手快、模板多。这一点没必要嘴硬。
真正的差别是一个词：控制权。
扣子是把整套东西放在别人的云上。你的应用、你的知识库、你的对话记录、你调的模型，全在别人机房里。管理只能通过网页后台。
Dify 是把整套东西放在我自己机器上。我可以 ssh 进去改源码，可以把它塞进一个完全没有外网的内网环境，模型换成自己部署的，数据全程不出门。
我这次的项目立项，根源就是这个区别——公司内网的机器连不上外网，数据也不允许出去。 不是「扣子不好用所以换一个」，是「这件事扣子在我这儿办不了，我得自己盖一间房」。
（注：扣子有没有面向企业的私有化版本，我没找到可靠来源，搜到的说法互相矛盾，这里不展开，只说我自己用过的云端版。）
现在我会怎么答
回到开头那个问题。
如果今天再有人问我 RAG 和 Function Call 是什么，我大概会这么说：
RAG 和 Function Call，说白了就是给大模型装的两只手。RAG 让它能翻资料，Function Call 让它能按按钮。这两个概念一点都不新——我 2024 年就在扣子上用过，只不过那时候它们一个叫「知识库」，一个叫「插件」。
工具换过名字，事情没变。真正在变的是另一件事：以前你只能用别人搭好的平台，现在你可以把同一套东西搬进自己的机房。
那两个词我算是记住了。代价是被朋友说了一句「等于没说」。
这一课我认。下次再有人问，我至少能先递一张对照表过去。
评论区