针对当下大模型比较成熟的几种应用模式，包括智能问答、RAG、Agent、Agent+MCP等等，大家理解时容易陷入两种极端：
当你刚开始入门时，看到这些概念一定很混淆，往往把大模型LLM想的很神奇，感觉它什么都能干，什么业务场景都能用。
当你通过cherrystudio或dify等工具，按照网上一些教程来实现过一些场景时，往往又会感觉很僵硬，只会照着做，并没有理解大模型LLM的本质。
本文以容易理解的信息化视角，将LLM视作一个黑盒的文字系统，通过比较输入提示词+输出成果在几种LLM应用模式下的不同，来分析这些应用模式的差异，本质上也是对使用LLM的过程做一个“祛魅”。
个人觉得哪怕我们对LLM内部的encode、decode、transformer、attention、MoE等概念和架构一知半解、似懂非懂，也不妨碍我们从使用角度去理解不同场景下LLM的应用模式。
基础问答提示词（系统指令+用户输入）
一些最基础的问答场景中，你会要求LLM模仿某种角色来回答用户的提问，或者要求LLM根据用户的输入来生成相应的内容，同时要求遵守某种结构进行生成答案，并做一些限制（比如不能随意发挥）等。
以上这些要求，其实就对应LLM的系统提示词，在Dify中配置界面大致如下：
上图system系统提示词就对应高阶指令，它是用来告诉LLM要如何响应用户诉求，要输出何种格式等等，是由LLM应用开发者预先设置好的，所以它被称之为system系统级指令，而user提示词对应是用户实际输入信息。其底层实现逻辑可以这样理解：
以适配OpenAI的接口规范为例，在这种最基础场景下，具体访问LLM的输入参数结构是：
可以看到输入该服务的messages包括两部分组成，一个是开发者提前设置好的role:system指令内容，一个是用户实际输入问题role:user内容。
既然通过信息化视角来理解，那有输入就必然有输出，进一步看看LLM服务的输出格式：
在choices/message结构内部，role:assistant这个节点的作用，是用来标记大模型输出信息（为啥要这么标记下，后面会讲），然后才是具体LLM生成内容的content节点。
多轮对话提示词（增加上下文的输入）
以上是最基础的一次对话过程，如果你还要反复进行追问，也就是要实现多轮对话，其底层实现逻辑是这样：
如图，核心就是要把上一轮对话结果也作为提示词的一部分再次输入给LLM，具体输入参数结构是：
RAG方式提示词（增加知识的输入）
在以上利用LLM进行对话的基础上，当你发现LLM缺少最新知识、或者缺乏某个行业领域内部知识时，通常就需要采用RAG方案了（RAG含义是知识检索增强），也就是要通过检索外挂知识库来增强LLM的生成能力，其底层实现逻辑是：
其核心就是要把知识检索到的内容，也作为提示词的一部分输入给LLM，对应输入参数结构是：
Tips：并不是所有需要用到知识的地方，都要使用向量化外挂知识库去做分片向量存储和语义相似度检索的，也并不是LLM对向量知识库有什么特殊依赖，这些组合方案都只是一种工程化范式而已。
比如一些简单场景要用到固定的几条知识，完全可以不用分片，不向量化，不用检索，每次调用LLM时，都自动附加到role:user中，输入给LLM就可以了。
调用工具提示词（早期function方式）
在以上RAG的基础上，如果你还需要在AI Agent中进一步调用工具，比如要调用工具查询数据库，比如要根据用户意图，调用查询天气、订票的工具等，其底层实现逻辑是：
其核心就是要把可以提供的工具描述信息，也作为提示词的一部分输入给LLM，对应输入参数结构是：
对应图中增加了一个functions输入节点，来输入工具或函数的描述信息，包括函数名称、和对应入参信息，注意这里functions节点是个数组，意味着可以输入多个可用的工具描述信息，供LLM选择和判断。
和前面几个小节略有不同的是，之前system、user、assistant等role的输入，都是在messages这个节点里面，而这里funtions节点则是和messages节点同级并列。
对于这种有工具描述的输入，LLM会根据用户的问题，自行判断是否需要调用工具，以及要调用哪个合适的工具，最终在LLM的输出信息中反馈要调用的工具，其对应输出结构是：
和前面基础对话场景中LLM的输出结构做个对比，可以看到对应的role还是assistant，但content为null，额外增加了funtion_call的节点。
你的AI Agent中通过解析LLM反馈信息中funtion_call节点，就可以得到要调用的函数名和要用到的参数值，再去执行这个函数即可。
后来改成tools方式
以上是LLM早期的function call机制，自从24年底Anthropic推出MCP协议以后，各厂商最新推出的LLM，经过强化训练后，也都支持标准的工具调用模式，其底层实现逻辑和上节funcnion call机制基本类似，但具体输入参数结构有所调整：
输入结构看起来变化不大，就是把functions节点换成了tools节点，同样也是一个数组。但LLM的输出结构就变化比较大了：
输出结构中用tool_calls节点替代了function_call节点，同时从原来输出单个function，变为现在输出tool数组，意味着LLM认为根据用户意图，有可能需要调用一组工具，所以通过数组方式输出。 更复杂场景场下，当你的AI Agent需要根据工具调用结果，让LLM决策下一步的动作时，也就是笔者之前在有关ReAct模式自主决策AI Agent文章中介绍的底层实现逻辑，就需要将调用结果再次输入给LLM，其对应输入参数结构是：
和前面提到的多轮对话场景的输入有点类似，也是通过在role:assistant节点将上一轮LLM的输出结果反馈给LLM，同时通过role:tool节点，将工具实际调用结果信息，再反馈给LLM。
当然实际使用MCP框架时，输入给LLM的tools数组不用手动组织了，都是框架会自动从mcp server中拉取工具描述信息，包括调用工具的环节，也是在mcp client的sdk中封装好了。
