用后厨类比讲透AI系统：LLM、Tool Use、ReAct、Planning、RAG十大概念

餐厅后厨是理解AI系统最好的隐喻现场。一口灶、一个墩子、一个传菜口，每个位置各司其职，又必须协同出菜。AI系统也一样——LLM是那个掌勺的厨师，Tool Use是他手里的刀和锅，ReAct是他边炒边尝的工作节奏，Planning是开餐前的备料清单，RAG是墙上那本随时翻看的菜谱。这套类比不是硬凑的，我在带团队做AI应用落地的过程中反复用这个框架跟非技术背景的同事沟通，效果比画架构图好得多。下面我把这十个概念一个一个拆开，用后厨的逻辑讲清楚它们各自解决什么问题、怎么配合、以及实际搭建时容易在哪儿翻车。

1. 为什么用后厨来讲AI：一套让非技术同事秒懂的类比框架

1.1 后厨与AI系统的结构对应关系

先把这个类比框架的完整映射关系摆出来，后面所有章节都围绕它展开。

这张表建议你收藏。每次团队里有人问"RAG和Fine-tuning有什么区别"或者"Agent和Workflow怎么选"，直接对着这张表解释，沟通成本能降一大半。

1.2 这个类比为什么比技术架构图更有效

我试过两种方式给产品经理讲AI系统架构。第一种是画标准的Agent架构图：Perception层、Planning层、Action层、Memory模块，箭头连来连去。讲完之后对方点头说"懂了"，然后问了一个让我崩溃的问题："那这个Memory是数据库吗？"

第二种就是后厨类比。我说：你走进一家餐厅点了一道宫保鸡丁。传菜员把你的需求告诉后厨，掌勺厨师（LLM）接到单子，先看墙上菜谱（RAG）确认做法，然后从冰箱拿食材（Tool Use调API），边炒边尝味道（ReAct循环），炒完让试菜员尝一口（LLM as Judge），合格了才端出去。对方立刻就理解了每个环节的作用和它们之间的依赖关系。

关键差异在于：架构图描述的是"是什么"，后厨类比解释的是"为什么需要它"。人理解一个新系统，永远是从"它解决什么问题"入手的，而不是从"它由哪些模块组成"入手的。

1.3 用这个框架跟不同角色沟通的调整策略

跟研发沟通时，重点放在"厨师的刀不够快怎么办"——也就是工具调用的性能和可靠性问题。跟产品沟通时，重点放在"菜谱本更新了厨师怎么知道"——也就是RAG的知识更新机制。跟老板沟通时，重点放在"怎么保证每道菜口味一致"——也就是输出质量控制和评估体系。

同一个框架，不同的切入角度，这是我用了两年多之后觉得最顺手的地方。下面逐层拆解。

2. LLM：那个掌勺的厨师到底会做什么、不会做什么

2.1 LLM的能力边界：一个厨师的真实水平

把LLM比作厨师，得先说清楚这个厨师的特点。他阅遍天下菜谱（训练数据），你报一个菜名他就能说出做法（文本生成），你给他描述一个口味偏好他能即兴发挥（零样本推理）。但他有几个硬伤：

第一，他没见过今天的食材。训练数据有截止日期，今天市场上新到的松茸他不认识。这就是LLM的知识截止问题，也是RAG存在的根本原因。

第二，他有时候会凭想象编菜谱。你问他"松茸配什么酱料最好"，他可能给你编一个听起来很有道理但实际不存在的搭配。这就是幻觉问题。

第三，他没有手。你让他炒菜，他只能告诉你"先热锅再倒油"，但他没法真的去开火。这就是为什么需要Tool Use。

第四，他的工作记忆有限。你一次性给他报二十道菜的做法，他记到第八道就开始混淆了。这就是上下文窗口的限制。

理解这四个边界，后面的所有技术概念就都有了落脚点——每个概念本质上都是在补厨师的某个短板。

2.2 从"会聊天"到"能干活"：LLM在系统中的实际定位

很多人第一次接触LLM，觉得它就是个高级聊天机器人。这个认知会让你在设计系统时把LLM放在错误的位置。

正确的定位是：LLM是整个系统的推理引擎和决策中枢，但它不是执行者。它负责"想"，不负责"做"。就像厨师负责决定这道菜怎么炒，但真正翻锅的是锅铲——锅铲就是Tool。

我见过一个典型的错误设计：让LLM直接输出数据库查询结果。用户问"上个月销售额是多少"，LLM根据训练数据里的统计常识编了一个数字。正确做法是让LLM生成一个SQL查询语句，然后由外部工具去执行这个查询，把真实结果返回给LLM，LLM再组织成自然语言回答。

这个区别看起来简单，但实际项目中至少有三分之一的问题出在"让LLM做了它不该做的事"。

2.3 选模型就像选厨师：不同场景的选型逻辑

不是所有后厨都需要米其林大厨。炒个蛋炒饭用不着请国宴师傅，同样，做一个简单的文本分类任务用不着上最大的模型。

选型的核心维度是三个：任务复杂度、延迟要求、成本预算。

任务复杂度低（如意图识别、实体抽取）、延迟要求高（如实时对话）、成本敏感的场景，选小模型或者蒸馏模型就够了。任务复杂度高（如多步推理、代码生成）、对质量要求极高的场景，才需要上大模型。

我的一般原则是：先用小模型跑baseline，如果效果差距在可接受范围内，就不升级。很多团队一上来就用最贵的模型，结果发现80%的请求用便宜模型就能处理，白白烧了钱。

还有一个容易被忽略的点：同一个系统里可以混用不同模型。简单任务路由到小模型，复杂任务路由到大模型。就像后厨里切菜配菜用墩子，掌勺调味用大厨，各司其职。

3. Tool Use：给厨师配上刀和锅，他才能真正出菜

3.1 为什么光有LLM不够：从"说菜"到"做菜"的鸿沟

LLM最本质的限制是：它只能输出文本。你让它查天气，它只能根据训练数据猜一个温度；你让它发邮件，它只能给你写一封邮件草稿；你让它算一个复杂的数学表达式，它可能在中间步骤算错。

Tool Use解决的就是这个问题。它的核心思路是：让LLM生成一个结构化的调用请求（通常是JSON格式），由外部系统执行这个请求，再把结果返回给LLM。

用后厨的话说：厨师说"给我拿三个鸡蛋"，打荷的人就去冰箱拿三个鸡蛋递过来。厨师不需要知道冰箱在哪儿、鸡蛋放在哪一层，他只需要说清楚要什么。

3.2 Tool Use的三种典型模式与后厨对应

模式一：函数调用（Function Calling）。这是最基础的模式。你预先定义好一组函数（工具），告诉LLM每个函数的名字、参数、用途。LLM在需要的时候生成调用请求。就像后厨里固定的几个岗位——切菜找墩子、蒸菜找蒸箱、烤菜找烤箱，各司其职。

模式二：代码解释器（Code Interpreter）。LLM生成一段代码，在沙箱环境中执行，返回结果。这相当于给厨师配了一个万能料理机——他不需要知道具体怎么切丝切片，写个程序让机器去执行就行。数据处理、图表生成、复杂计算这类任务特别适合。

模式三：API编排（API Orchestration）。多个工具按一定顺序组合调用。比如先调用搜索工具获取信息，再调用数据库工具存储结果，最后调用通知工具发送消息。这就像一道复杂菜品需要多个工位配合——先腌后炸再浇汁，每个步骤调不同的设备。

3.3 工具定义的质量决定调用成功率

这是实操中最大的坑：很多人把工具定义写得太随意，导致LLM根本不知道怎么调。

一个好的工具定义包含四个要素：

• 名称：动词开头，语义明确。search_orders比order_func好一百倍。
• 描述：说清楚这个工具做什么、什么时候用、什么时候不用。描述是给LLM看的，不是给人看的。
• 参数：每个参数的类型、含义、是否必填、取值范围都要写清楚。
• 返回值：返回的数据结构要明确，方便LLM理解执行结果。

我踩过的一个坑：定义了一个叫query的工具，描述只写了"查询数据"。结果LLM在用户问天气的时候也调这个工具，在用户问股票的时候也调这个工具，因为它不知道这个工具到底查什么。后来改成query_product_inventory，描述写清楚"查询商品库存信息，仅用于用户询问某商品的库存数量或库存状态时调用"，误调用率直接降了70%。

提示：工具描述里一定要写"什么时候不要用这个工具"，这比写"什么时候用"更能减少误调用。

4. ReAct：边炒边尝，而不是照着菜谱一条道走到黑

4.1 ReAct的本质：推理与行动的交替循环

ReAct是Reasoning + Acting的缩写。它的核心思想非常朴素：让LLM不要一次性想完所有步骤再执行，而是想一步、做一步、看结果、再想下一步。

用后厨的话说：新手厨师会照着菜谱从头到尾做一遍，中间不尝味道。老师傅是边炒边尝，咸了加糖、淡了加盐、火大了关小一点。ReAct就是让AI学会"边炒边尝"。

一个典型的ReAct循环长这样：

1. Thought（思考）：用户想知道北京今天适不适合户外运动，我需要先查天气。
2. Action（行动）：调用天气查询工具，参数是城市=北京、日期=今天。
3. Observation（观察）：返回结果——晴，25度，微风。
4. Thought（思考）：天气不错，但我还需要知道空气质量才能判断是否适合户外运动。
5. Action（行动）：调用空气质量查询工具。
6. Observation（观察）：AQI 85，良。
7. Thought（思考）：天气和空气质量都查到了，可以给出建议了。
8. Answer（回答）：今天北京晴天25度，空气质量良，适合户外运动，建议做好防晒。

这个循环可以一直持续到LLM认为信息足够、可以给出最终答案为止。

4.2 ReAct和普通Prompt Chain的区别在哪里

普通的Prompt Chain是线性的：步骤A → 步骤B → 步骤C，每一步的输出是下一步的输入，路径固定。

ReAct是动态的：LLM根据每一步的观察结果决定下一步做什么。如果查天气发现下雨了，它可能直接给出"不适合户外运动"的结论，跳过空气质量查询这一步。

这个区别在实际应用中非常关键。固定流程的Chain适合步骤明确、不需要分支的场景（比如"翻译→润色→格式化"）。ReAct适合需要根据中间结果动态调整策略的场景（比如客服对话、故障排查、研究分析）。

我的一般判断标准是：如果你能用流程图把整个处理过程画出来且没有分支，用Chain；如果流程中有"根据X的结果决定做Y还是Z"，用ReAct。

4.3 ReAct的常见失效模式与修复思路

ReAct不是银弹，实际用起来有几个高频翻车场景：

死循环。LLM反复调用同一个工具，每次得到相似的结果，但就是不给最终答案。修复方法是在Prompt里加最大迭代次数限制，以及在系统提示里明确写"如果已经获取了足够的信息，请直接给出最终答案"。

工具选择错误。LLM选了一个不相关的工具。这通常是工具描述不够清晰导致的，回到上一章说的工具定义质量问题上。

推理链断裂。LLM在Thought阶段说了要做A，但在Action阶段做了B。这是模型能力问题，换更强的模型或者用Few-shot示例引导可以缓解。

观察结果被忽略。工具返回了错误信息，但LLM当作没看见继续往下走。需要在Prompt里强调"如果工具返回错误，请分析错误原因并决定是重试还是换一种方式"。

5. Planning：开餐前的备料清单，决定出菜效率

5.1 Planning解决的是什么问题

ReAct是"走一步看一步"，Planning是"先想清楚再动手"。两者不矛盾，而是配合使用。

一个复杂的用户请求，比如"帮我分析上个月的销售数据，找出下降最严重的三个品类，然后给每个品类写一份改进建议"，如果直接上ReAct，LLM可能会在数据查询阶段就迷失方向。Planning的作用是先把这个大任务拆成子任务：

1. 查询上个月各品类的销售数据
2. 计算每个品类的环比变化
3. 排序找出下降最严重的前三个
4. 针对每个品类，查询相关背景信息
5. 生成改进建议

拆完之后，每个子任务可以用ReAct来执行。这就是"先规划后执行"的模式。

5.2 任务拆解的粒度控制：太粗和太细都是坑

拆解粒度是个经验活。拆得太粗，每个子任务还是太复杂，执行时容易出错。拆得太细，子任务数量太多，协调成本高，而且容易在拆解阶段就引入错误。

我的经验法则是：每个子任务应该是一个"单一职责"的操作，能用一句话描述清楚输入和输出。如果一个子任务需要用到"并且"或者"然后"来描述，说明它还可以继续拆。

但也不要拆到"打开数据库连接""执行SQL语句""关闭数据库连接"这种程度——那是代码层面的事，不是Planning层面的事。Planning拆的是业务逻辑步骤，不是技术实现步骤。

5.3 动态重规划：菜炒到一半发现食材不够怎么办

Planning不是一次性的。执行过程中如果发现某个子任务无法完成（比如查询的数据不存在），或者发现了新的信息需要调整计划，就需要动态重规划。

这就像炒菜炒到一半发现酱油用完了。你可以选择：换一种调味方式（调整计划）、去隔壁借酱油（调用替代工具）、或者告诉客人这道菜做不了（返回失败并说明原因）。

好的Planning模块应该支持这三种应对方式，而不是死板地执行原始计划。实现上，通常是在每个子任务执行完后加一个"检查点"，让LLM判断当前状态是否偏离了预期，如果是则触发重规划。

6. RAG：墙上那本随时翻看的菜谱，解决厨师的记忆盲区

6.1 RAG的核心逻辑：不改变厨师，改变他能看到的信息

RAG（Retrieval-Augmented Generation）的思路极其简单：LLM不知道的东西，你查出来放在他面前，他就能基于这些信息回答。

用后厨的话说：厨师没做过松茸炖鸡，但你给他一本松茸菜谱翻到那一页，他照着做就能做出来。你不需要送他去培训（Fine-tuning），只需要给他一本菜谱（知识库）。

RAG的完整流程是：

1. 用户提问
2. 系统在知识库中检索相关内容
3. 把检索结果和用户问题一起塞进Prompt
4. LLM基于检索结果生成回答

关键点在于：LLM本身没有变化，变化的是它接收到的上下文信息。

6.2 知识库构建：菜谱本怎么编才有用

RAG的效果，七分靠知识库质量，三分靠模型能力。知识库构建有几个核心决策：

切块策略（Chunking）。文档不能整篇塞进去，要切成合适大小的块。切太大，检索精度低；切太小，上下文不完整。一般建议256-512个token为一块，相邻块之间保留10%-20%的重叠区域。但这不是铁律——技术文档适合按段落切，对话记录适合按轮次切，代码适合按函数切。

向量化模型选择。切好的块要用Embedding模型转成向量存起来。中文场景下，建议用专门针对中文优化的Embedding模型，通用多语言模型在中文语义相似度上的表现可能差10%-20%。

检索策略。最简单的做法是向量相似度检索（找语义最接近的块）。但纯向量检索有个问题：它擅长找"意思相近"的内容，不擅长找"关键词精确匹配"的内容。实际项目中通常用混合检索——向量检索+关键词检索，两路结果合并后重排序。

6.3 RAG的典型瓶颈与突破思路

RAG用起来之后，最常见的瓶颈有三个：

检索不到。用户问的问题和知识库里的表述方式差异太大，向量相似度匹配不上。解决办法是加一层Query改写——让LLM先把用户问题改写成多个不同表述的查询，分别检索后合并结果。

检索到了但没用上。检索结果塞进Prompt了，但LLM忽略了这些信息，还是用自己的知识回答。这通常是Prompt设计问题——需要在系统提示里明确要求"优先基于提供的参考资料回答，如果参考资料中没有相关信息，请明确说明"。

检索到了不相关的。检索精度不够，返回了一堆噪音。除了优化切块和检索策略，还可以加一个重排序（Rerank）步骤——用一个专门的模型对检索结果做精排，把最相关的排在最前面。

6.4 RAG、知识图谱与结构化知识库的选型对比

这三种知识存储方式经常被混为一谈，但适用场景完全不同：

实际项目中，这三者经常组合使用。比如一个企业知识助手，用RAG处理产品文档和FAQ，用知识图谱处理组织架构和人员关系，用结构化知识库处理销售数据和报表查询。LLM作为统一入口，根据用户问题类型路由到不同的知识源。

7. LLM as Judge：试菜员的味觉标准怎么定

7.1 为什么需要自动评估

AI系统的输出质量需要持续监控。人工评估准确但成本高、速度慢，不可能对每一条输出都人工检查。LLM as Judge的思路是：用一个LLM来评估另一个LLM的输出质量。

这就像后厨里设一个试菜员岗位。每道菜出锅前，试菜员尝一口，判断咸淡是否合适、火候是否到位、摆盘是否合格。试菜员不需要会炒菜，但他需要知道好菜的标准是什么。

7.2 评估Prompt的设计要点

LLM as Judge的效果几乎完全取决于评估Prompt的质量。一个好的评估Prompt包含：

• 评估维度：明确列出要评估哪些方面（准确性、完整性、相关性、格式合规性等）。
• 评分标准：每个维度的评分细则，最好给出具体示例。
• 参考标准：如果有标准答案或参考答案，一并提供。
• 输出格式：要求LLM按固定格式输出评分和理由。

我踩过的一个坑：评估Prompt里只写了"请评估回答质量，给出1-10分"。结果LLM的打分波动极大，同一个回答今天打7分明天打9分。后来改成按三个维度分别打分（事实准确性、信息完整性、表达清晰度），每个维度给出具体的评分标准，打分稳定性明显提升。

7.3 LLM as Judge的偏差与校准

LLM as Judge有几个已知的系统性偏差：

位置偏差。对比两个回答时，LLM倾向于给排在前面的回答更高分。解决办法是交换顺序评估两次，取平均。

长度偏差。LLM倾向于给更长的回答更高分，即使长回答里有很多废话。解决办法是在评估标准里明确写"简洁性也是评分维度之一"。

自我偏好。用GPT-4评估GPT-4的输出时，它倾向于给自己的输出更高分。解决办法是用不同模型做评估，或者用人工标注数据做校准。

8. Agent框架：把厨师、工具、菜谱、试菜员串成一个后厨团队

8.1 Agent的本质：LLM + 工具 + 记忆 + 规划

前面讲的LLM、Tool Use、ReAct、Planning、RAG，单独拿出来都是有用的技术。Agent框架是把这些技术组合成一个完整系统的工程实践。

一个Agent的典型架构包含四个模块：

• 大脑（LLM）：负责推理和决策。
• 手脚（Tools）：负责执行具体操作。
• 记忆（Memory）：短期记忆存当前对话上下文，长期记忆存历史交互和知识。
• 规划（Planner）：负责任务拆解和动态调整。

这四者缺一不可。没有工具，Agent只能纸上谈兵；没有记忆，Agent每次对话都从零开始；没有规划，Agent处理复杂任务时容易迷失。

8.2 从单Agent到多Agent：后厨团队的协作模式

单Agent就像一个全能厨师，什么菜都自己做。适合任务简单、流程固定的场景。

多Agent就像一个分工明确的后厨团队：一个负责接单和分派（Router Agent），一个负责炒菜（Executor Agent），一个负责检查质量（Critic Agent），一个负责和前台沟通（Interface Agent）。

多Agent的优势是每个Agent可以专注于自己的领域，用更小的模型、更精准的Prompt。劣势是协调成本高，Agent之间的通信可能出错。

我的建议是：先用单Agent跑通流程，当单Agent的Prompt变得过于复杂（超过2000字）或者工具数量超过10个时，再考虑拆分成多Agent。

8.3 Agent容错：菜炒糊了怎么补救

Agent系统一定会出错。工具会超时、API会限流、LLM会幻觉、检索会返回噪音。容错机制的设计决定了系统是"偶尔出错但能恢复"还是"一错就崩"。

几个实用的容错策略：

• 重试机制：工具调用失败时自动重试，设置最大重试次数和退避策略。
• 降级方案：主工具不可用时切换到备用工具。比如主搜索API挂了，切换到备用搜索API。
• 超时熔断：某个工具连续多次超时，暂时熔断该工具，避免拖垮整个系统。
• 人工兜底：当Agent连续多次无法完成任务时，转人工处理，而不是无限循环。

9. 把这十个概念串起来：一个完整后厨的运转日常

9.1 从用户提问到最终回答的完整链路

把前面所有概念串起来，一个完整的AI系统处理用户请求的流程是这样的：

用户问："帮我查一下上个月华东区销售额下降最多的三个产品，并分析原因。"

1. Agent框架接收请求，启动处理流程。
2. Planning模块把任务拆解为：查数据 → 算变化 → 排序 → 查原因 → 生成报告。
3. LLM作为推理引擎，决定第一步需要调用数据查询工具。
4. Tool Use调用数据库API，获取华东区上月销售数据。
5. ReAct循环：LLM观察返回数据，发现需要计算环比，调用计算工具。
6. RAG检索产品背景资料和历史分析报告，补充上下文。
7. LLM综合所有信息，生成分析报告。
8. LLM as Judge评估报告质量，确认信息准确、逻辑完整。
9. Agent框架把最终结果返回给用户。

这个链路里，每个环节都可能出问题，每个环节也都需要前面讲的容错机制。

9.2 每个环节的常见故障与排查思路

这张表建议打印出来贴在工位上。出问题的时候按表排查，比凭感觉猜效率高得多。

9.3 从后厨到AI：这套类比框架的适用边界

最后说清楚这个类比框架的边界。它适合用来做概念沟通和架构设计讨论，但不适合用来做技术决策。比如"选哪个Embedding模型"这种问题，后厨类比帮不了你，还是得看MTEB排行榜和实际测试结果。

类比的价值在于降低沟通成本，不在于替代技术判断。我一般是在项目启动阶段用这个框架对齐认知，进入技术选型阶段就切换到实际的技术文档和benchmark。

另外，这个框架对LLM、Tool Use、RAG这几个概念的映射非常自然，但对Planning和ReAct的映射稍微牵强一些——后厨里没有完全对应的角色。不过作为沟通工具，够用了。

我在实际带团队的过程中发现，非技术背景的同事用这个框架理解AI系统之后，提需求的质量明显提升。他们不再说"我要一个AI功能"，而是会说"我需要一个能查数据库、能生成报告、并且报告要经过质量检查的Agent"。这个转变，就是类比框架最大的价值。