餐厅后厨是理解AI系统最好的隐喻现场。一口灶、一个墩子、一个传菜口每个位置各司其职又必须协同出菜。AI系统也一样——LLM是那个掌勺的厨师Tool Use是他手里的刀和锅ReAct是他边炒边尝的工作节奏Planning是开餐前的备料清单RAG是墙上那本随时翻看的菜谱。这套类比不是硬凑的我在带团队做AI应用落地的过程中反复用这个框架跟非技术背景的同事沟通效果比画架构图好得多。下面我把这十个概念一个一个拆开用后厨的逻辑讲清楚它们各自解决什么问题、怎么配合、以及实际搭建时容易在哪儿翻车。1. 为什么用后厨来讲AI一套让非技术同事秒懂的类比框架1.1 后厨与AI系统的结构对应关系先把这个类比框架的完整映射关系摆出来后面所有章节都围绕它展开。后厨角色/环节AI技术概念核心职责掌勺厨师LLM大语言模型理解需求、生成方案、输出结果厨师的刀/锅/烤箱Tool Use工具调用执行模型本身做不到的操作边炒边尝的工作方式ReAct推理行动交替推理与执行动态调整开餐前的备料清单Planning规划拆解任务、排优先级、分配资源墙上的菜谱本RAG检索增强生成按需查阅外部知识补充模型盲区菜品标准手册Prompt Engineering约束输出格式和质量标准试菜员LLM as Judge自动评估输出质量厨房管理制度AI Agent框架协调以上所有组件运转食材溯源体系知识图谱KG结构化存储实体关系传菜口的出菜检查输出验证与容错确保最终交付物合格这张表建议你收藏。每次团队里有人问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查询语句然后由外部工具去执行这个查询把真实结果返回给LLMLLM再组织成自然语言回答。这个区别看起来简单但实际项目中至少有三分之一的问题出在让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循环长这样Thought思考用户想知道北京今天适不适合户外运动我需要先查天气。Action行动调用天气查询工具参数是城市北京、日期今天。Observation观察返回结果——晴25度微风。Thought思考天气不错但我还需要知道空气质量才能判断是否适合户外运动。Action行动调用空气质量查询工具。Observation观察AQI 85良。Thought思考天气和空气质量都查到了可以给出建议了。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是先想清楚再动手。两者不矛盾而是配合使用。一个复杂的用户请求比如帮我分析上个月的销售数据找出下降最严重的三个品类然后给每个品类写一份改进建议如果直接上ReActLLM可能会在数据查询阶段就迷失方向。Planning的作用是先把这个大任务拆成子任务查询上个月各品类的销售数据计算每个品类的环比变化排序找出下降最严重的前三个针对每个品类查询相关背景信息生成改进建议拆完之后每个子任务可以用ReAct来执行。这就是先规划后执行的模式。5.2 任务拆解的粒度控制太粗和太细都是坑拆解粒度是个经验活。拆得太粗每个子任务还是太复杂执行时容易出错。拆得太细子任务数量太多协调成本高而且容易在拆解阶段就引入错误。我的经验法则是每个子任务应该是一个单一职责的操作能用一句话描述清楚输入和输出。如果一个子任务需要用到并且或者然后来描述说明它还可以继续拆。但也不要拆到打开数据库连接执行SQL语句关闭数据库连接这种程度——那是代码层面的事不是Planning层面的事。Planning拆的是业务逻辑步骤不是技术实现步骤。5.3 动态重规划菜炒到一半发现食材不够怎么办Planning不是一次性的。执行过程中如果发现某个子任务无法完成比如查询的数据不存在或者发现了新的信息需要调整计划就需要动态重规划。这就像炒菜炒到一半发现酱油用完了。你可以选择换一种调味方式调整计划、去隔壁借酱油调用替代工具、或者告诉客人这道菜做不了返回失败并说明原因。好的Planning模块应该支持这三种应对方式而不是死板地执行原始计划。实现上通常是在每个子任务执行完后加一个检查点让LLM判断当前状态是否偏离了预期如果是则触发重规划。6. RAG墙上那本随时翻看的菜谱解决厨师的记忆盲区6.1 RAG的核心逻辑不改变厨师改变他能看到的信息RAGRetrieval-Augmented Generation的思路极其简单LLM不知道的东西你查出来放在他面前他就能基于这些信息回答。用后厨的话说厨师没做过松茸炖鸡但你给他一本松茸菜谱翻到那一页他照着做就能做出来。你不需要送他去培训Fine-tuning只需要给他一本菜谱知识库。RAG的完整流程是用户提问系统在知识库中检索相关内容把检索结果和用户问题一起塞进PromptLLM基于检索结果生成回答关键点在于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向量知识库知识图谱KG结构化知识库存储内容非结构化文本块实体-关系-实体三元组表格/JSON等结构化数据擅长回答是什么怎么做类问题谁和谁有什么关系类问题多少什么时候类问题典型场景文档问答、客服知识库企业关系网络、推荐系统报表查询、数据分析构建成本中需要切块和向量化高需要本体设计和关系抽取低直接导入现有数据更新频率高随时增删文档低关系变更需要重新抽取中定期同步数据实际项目中这三者经常组合使用。比如一个企业知识助手用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系统处理用户请求的流程是这样的用户问帮我查一下上个月华东区销售额下降最多的三个产品并分析原因。Agent框架接收请求启动处理流程。Planning模块把任务拆解为查数据 → 算变化 → 排序 → 查原因 → 生成报告。LLM作为推理引擎决定第一步需要调用数据查询工具。Tool Use调用数据库API获取华东区上月销售数据。ReAct循环LLM观察返回数据发现需要计算环比调用计算工具。RAG检索产品背景资料和历史分析报告补充上下文。LLM综合所有信息生成分析报告。LLM as Judge评估报告质量确认信息准确、逻辑完整。Agent框架把最终结果返回给用户。这个链路里每个环节都可能出问题每个环节也都需要前面讲的容错机制。9.2 每个环节的常见故障与排查思路环节常见故障排查方向LLM推理幻觉、格式错误检查Prompt、换模型、加Few-shotTool Use调用失败、参数错误检查工具定义、加参数校验ReAct死循环、推理断裂加迭代上限、优化系统提示Planning拆解过粗/过细调整拆解粒度、加示例RAG检索不准、信息遗漏优化切块、加Rerank、Query改写Judge评分偏差、标准不一致校准评估Prompt、多模型交叉验证这张表建议打印出来贴在工位上。出问题的时候按表排查比凭感觉猜效率高得多。9.3 从后厨到AI这套类比框架的适用边界最后说清楚这个类比框架的边界。它适合用来做概念沟通和架构设计讨论但不适合用来做技术决策。比如选哪个Embedding模型这种问题后厨类比帮不了你还是得看MTEB排行榜和实际测试结果。类比的价值在于降低沟通成本不在于替代技术判断。我一般是在项目启动阶段用这个框架对齐认知进入技术选型阶段就切换到实际的技术文档和benchmark。另外这个框架对LLM、Tool Use、RAG这几个概念的映射非常自然但对Planning和ReAct的映射稍微牵强一些——后厨里没有完全对应的角色。不过作为沟通工具够用了。我在实际带团队的过程中发现非技术背景的同事用这个框架理解AI系统之后提需求的质量明显提升。他们不再说我要一个AI功能而是会说我需要一个能查数据库、能生成报告、并且报告要经过质量检查的Agent。这个转变就是类比框架最大的价值。
