用餐厅后厨类比讲透AI十大核心概念：LLM、RAG、Agent与编排

餐厅后厨是我能想到的、讲清楚AI技术概念最顺手的类比场景。原因很简单：一个后厨的运转逻辑，和一套AI系统的运转逻辑，在结构上几乎是同构的。后厨有菜单、有食材、有厨师、有传菜员、有备菜流程、有出餐标准、有食品安全检查，AI系统里有模型、有数据、有推理、有工具调用、有编排流程、有评估机制、有安全对齐。你在后厨里能看到的每一个角色和环节，几乎都能在AI系统里找到对应物。

这篇文章面向两类人：一类是刚接触大模型和智能体、被一堆缩写词砸得头晕的开发者；另一类是把AI概念背得滚瓜烂熟、但一到实际项目里就不知道该怎么组合使用的工程师。我会用餐厅后厨这条主线，把LLM、Tool Use、ReAct、Planning、RAG、Agent、Memory、评估、对齐、编排这十个概念串起来讲，每个概念都落到"后厨里对应什么角色""为什么需要它""实际项目里怎么用""容易踩什么坑"这四个问题上。

我自己的经验是，概念之所以难懂，往往不是因为概念本身复杂，而是因为讲概念的人跳过了"它解决了什么问题"这一步。后厨类比的好处在于，每个环节存在的理由都是肉眼可见的——没有备菜，出餐就慢；没有传菜员，厨师就得自己跑堂；没有品控，今天和明天的味道就不一样。AI系统里的每个组件，也都是被某个具体的痛点逼出来的。

1. 大模型是后厨的主厨，但别指望他一个人包办一切

1.1 主厨的能力边界在哪里

把LLM理解成后厨的主厨，是我觉得最贴切的一个类比。主厨的核心能力是什么？是"根据手头的食材和客人的要求，现场决定做什么、怎么做"。你给他一筐青菜、两块豆腐、半斤肉，他能给你变出一桌菜。这种"通用性"正是大模型最值钱的地方——同一个模型，你让它写代码、写文案、做翻译、做总结，它都能接。

但主厨也有明确的边界。第一，他不知道你冰箱里到底有什么。你问他"今天有什么新鲜食材"，他只能靠猜，因为他没有直接查看冰箱的能力。这就是大模型的知识截止问题——训练数据里没有的东西，它不知道。第二，他记不住上一桌客人点了什么。每来一桌新客人，对他来说都是全新的开始，这就是无状态特性。第三，他偶尔会"凭经验瞎编"——明明没有松露，他为了显得专业，硬说这道菜里有松露。这就是幻觉。

理解这三条边界，比记住"LLM是基于Transformer的预训练语言模型"这种定义重要得多。因为你在设计AI系统时做的每一个架构决策，本质上都是在补主厨的短板：知识不够就上RAG，记不住就上Memory，会瞎编就上评估和约束。

1.2 参数规模与"厨艺水平"的关系

大模型有参数量这个说法，7B、13B、70B、405B，这些数字可以类比成主厨的"经验年限和菜系覆盖范围"。参数越多，通常意味着见过的菜谱越多、处理复杂要求的能力越强。但这里有个反直觉的点：参数大不等于在你的场景里表现好。

我见过太多团队一上来就冲着最大的模型去，结果发现成本高得离谱，延迟也扛不住，而实际效果比一个中等模型加一套好的RAG方案还差。这就像你开一家社区小馆子，非要请米其林三星主厨，他做的菜确实精致，但你的客人就想吃个家常小炒，出餐还慢，翻台率上不去。

选模型的正确姿势是：先用中等规模的模型跑通流程，把RAG、Tool Use、评估这些配套做好，然后拿真实业务数据做对比测试。如果中等模型确实搞不定，再往上换。我自己的经验是，大部分业务场景的瓶颈不在模型本身，而在数据质量和流程设计。

1.3 温度参数：主厨的发挥空间

Temperature这个参数，可以理解成"允许主厨自由发挥的程度"。温度低的时候，主厨严格按菜谱来，每次做出来的味道都一样，适合需要稳定输出的场景，比如数据抽取、格式转换。温度高的时候，主厨开始即兴创作，可能给你惊喜，也可能给你惊吓，适合创意写作、头脑风暴。

实际项目里我一般这样设：结构化输出任务用0到0.3，对话类用0.5到0.7，创意类用0.8到1.0。超过1.0基本就是"主厨喝多了"的状态，输出会开始胡言乱语。这个参数看起来简单，但很多线上事故就是因为它设错了——一个做合同信息抽取的服务，温度设了0.9，结果同一个合同每次抽出来的金额都不一样。

2. Tool Use是给主厨配的厨房设备，不是装饰品

2.1 为什么主厨需要工具

一个主厨再厉害，你让他用手切土豆丝，他也切不过一台切丝机。你让他心算一道菜的卡路里，他算不过计算器。Tool Use的本质，就是让模型在需要精确计算、实时查询、外部操作的时候，把活交给专门的工具去做。

后厨里的工具分几类：切菜机、烤箱、温度计、收银系统。AI系统里的工具也分几类：搜索引擎、计算器、数据库查询、API调用、代码执行器。每一类工具解决的都是模型本身不擅长的问题——搜索解决知识时效性，计算器解决数学精度，数据库解决私有数据访问，代码执行器解决逻辑推理的可靠性。

我经常看到的一个误区是：把Tool Use当成"锦上添花"的功能，觉得模型能力强就不需要工具。这就像觉得主厨刀工好就不需要切菜机一样。实际上，工具不是能力的替代，而是能力的放大器。一个会用工具的主厨，出餐速度和稳定性远超一个只靠双手的主厨。

2.2 工具描述写得好不好，直接决定调用成功率

Tool Use最容易踩的坑，是工具描述写得含糊。模型决定调不调用一个工具、怎么填参数，全靠你给的描述。描述写得烂，模型要么不调用，要么参数填错。

举个例子，你有一个查询订单状态的工具。描述写成"查询订单"，模型可能在你问"帮我看看昨天那单到哪了"的时候，不知道该传什么参数。描述写成"根据订单号查询订单的当前物流状态，订单号格式为18位数字，以'DD'开头"，模型就能准确提取订单号并调用。

这里有个实操技巧：工具描述里要包含"什么时候用"和"什么时候不用"。比如"当用户询问实时信息时使用此工具，如果问题涉及的是通用知识，不要调用"。这能显著降低误调用率。我在一个客服项目里加上了这句"什么时候不用"，误调用率从15%降到了4%左右。

2.3 工具调用的错误处理

工具会失败。网络会断，API会超时，参数会不合法。后厨里切菜机卡住了，主厨得知道怎么处理——是换手工切，还是等维修。AI系统里也一样，工具调用失败后的兜底逻辑，比工具调用本身更重要。

我的做法是给每个工具配一个"失败预案"：超时了重试几次、重试还失败就降级到备用方案、备用方案也没有就明确告诉用户"这个功能暂时不可用"。最怕的是工具失败了，模型不知道，继续基于错误的结果往下编，最后给用户一个看起来合理但完全错误的答案。

3. ReAct是主厨的"边做边尝"工作法

3.1 ReAct到底在解决什么问题

ReAct这个词拆开就是Reason和Act，推理和行动。它的核心思想是：不要一次性想好所有步骤再动手，而是走一步、看一步、想一步。

后厨里的对应场景特别形象。一个主厨做一道新菜，他不会站在那想十分钟把每个步骤都规划好，而是先尝一口汤底，觉得淡了加点盐，再尝一口，觉得可以了再下配菜。这个"尝—判断—调整"的循环，就是ReAct。

为什么需要这个模式？因为很多任务没法一次性规划好。你让模型"帮我分析这份销售数据并给出建议"，它没法在第一步就知道数据里有什么问题、需要查哪些维度。它必须先看一眼数据，发现某个区域异常，再去查那个区域的明细，再根据明细决定下一步查什么。这种动态调整的能力，是ReAct的价值所在。

3.2 ReAct循环的四个阶段

一个完整的ReAct循环包含四个阶段：思考、行动、观察、再思考。

思考阶段，模型分析当前状态，决定下一步做什么。行动阶段，模型调用一个工具或执行一个操作。观察阶段，模型接收行动的结果。再思考阶段，模型根据新信息调整计划，进入下一轮循环。

这个循环听起来简单，但实际实现时有几个关键点。第一，循环要有终止条件。不能让它无限循环下去，一般设一个最大轮数，比如10轮，到了就强制输出当前最好的结果。第二，每一轮的观察结果要完整传给模型。有些实现为了省token，只传摘要，结果模型丢失了关键细节，做出错误判断。第三，思考过程要可见。把模型的思考过程打印出来，出问题的时候你才知道它是在哪一步走偏的。

3.3 ReAct和普通函数调用的区别

很多人分不清ReAct和普通的工具调用。区别在于：普通工具调用是"你告诉我调什么，我就调什么"，ReAct是"我自己决定调什么、调几次、按什么顺序调"。

后厨类比：普通工具调用像是服务员拿着客人写好的单子进厨房，单子上写着"切土豆、炒土豆、装盘"，主厨照做就行。ReAct像是客人说"我想吃个土豆做的菜"，主厨自己决定是切丝炒还是切块炖，做的时候尝一尝，不行再调整。

实际项目里，简单任务用普通工具调用就够了，复杂任务才需要ReAct。我见过有人把"查询天气"这种一步就能完成的任务也套上ReAct循环，结果延迟翻了三倍，效果没变好。工具要用在刀刃上。

4. Planning是主厨的备菜流程，决定出餐效率

4.1 没有Planning的后厨有多乱

想象一个没有备菜流程的后厨。客人点一份宫保鸡丁，主厨才开始洗菜、切菜、腌肉、调酱。一份菜做下来二十分钟，客人等得掀桌子。这就是没有Planning的AI系统——每一步都临时决定，整体效率极低，而且容易漏步骤。

Planning的核心是把一个大任务拆成有序的子任务，并安排好执行顺序。后厨的备菜流程就是典型的Planning：早上先把所有蔬菜洗好切好，肉类腌好，酱料调好，中午高峰期只管下锅炒。这样出餐速度能快好几倍。

AI系统里的Planning也是这个逻辑。你让模型"帮我写一份市场分析报告"，它应该先规划：第一步收集数据，第二步分析趋势，第三步对比竞品，第四步写结论。每一步的输出作为下一步的输入，而不是想到哪写到哪。

4.2 任务拆解的粒度怎么把握

Planning最难的地方是拆解粒度。拆得太粗，等于没拆；拆得太细，管理成本比执行成本还高。

后厨里的经验是：拆到"一个人能独立完成、不需要中途请示"的粒度。比如"切配菜"是一个合理的粒度，"把胡萝卜切成3毫米见方的丁"就太细了，"准备所有配菜"又太粗。

AI系统里我一般这样把握：每个子任务应该是一个独立的、有明确输入输出的操作。比如"从数据库查询上季度销售数据"是一个合理的子任务，"连接数据库"就太细，"分析销售情况"就太粗。判断标准是：这个子任务能不能用一句话说清楚它的输入和输出？能，粒度就合适。

4.3 Planning和ReAct的配合

Planning和ReAct不是二选一的关系，而是配合使用。Planning负责宏观的路线图，ReAct负责微观的每一步调整。

后厨类比：备菜流程是Planning，决定了今天先做什么后做什么。但具体炒菜的时候，主厨尝味道、调火候，这是ReAct。没有Planning，主厨不知道先备哪些菜；没有ReAct，主厨炒糊了也不知道补救。

实际项目里，我通常的做法是：先用Planning把任务拆成几个大阶段，每个阶段内部用ReAct循环来执行。这样既有全局的秩序，又有局部的灵活。纯Planning的系统太死板，遇到意外就卡住；纯ReAct的系统太随机，容易跑偏。

5. RAG是后厨的食材采购和库存管理

5.1 RAG解决的是"主厨不知道你家冰箱有什么"的问题

回到最开始说的主厨边界：他不知道你冰箱里有什么。RAG就是解决这个问题的——在回答问题之前，先去冰箱里把相关食材找出来，放到主厨面前。

RAG的全称是检索增强生成，拆开看就是"检索"加"生成"。检索负责从知识库里找到相关内容，生成负责基于这些内容组织答案。后厨类比：检索是采购员去仓库找食材，生成是主厨用这些食材做菜。

为什么需要RAG？因为大模型的知识是训练时固定的，你公司的内部文档、最新的产品信息、私有的业务数据，它都不知道。你直接问它，它要么说不知道，要么瞎编。RAG让它在回答之前先查资料，答案就有了依据。

5.2 检索质量决定RAG的上限

RAG系统里，检索环节的重要性被严重低估。很多人把精力全花在生成上，调prompt、换模型，结果检索出来的内容根本不对，生成再强也是白搭。

后厨类比：采购员买回来的食材不新鲜，主厨手艺再好也做不出好菜。检索就是采购，检索质量决定了RAG系统的天花板。

提升检索质量有几个实操点。第一，文档切分要合理。切得太碎，上下文丢失；切得太大，噪声太多。我一般按语义段落切，每段300到500字，相邻段落之间留一点重叠。第二，要加元数据过滤。比如按时间、按部门、按文档类型过滤，能大幅提升相关性。第三，混合检索比单一检索好。向量检索擅长语义匹配，关键词检索擅长精确匹配，两者结合效果更稳。

5.3 RAG的常见失败模式

RAG最常见的失败模式有三种。第一种是检索到了但没用上——检索结果明明在上下文里，模型却忽略它，按自己的知识回答。这通常是prompt没写好，没有明确要求"必须基于提供的资料回答"。

第二种是检索到了错误的内容——知识库里有多个版本的文档，检索到了过时的那版。这需要在元数据里加版本标记，检索时过滤掉旧版本。

第三种是知识库里根本没有——用户问的问题超出了知识库范围，检索返回一堆不相关的内容，模型硬着头皮编。这需要在检索后加一个相关性阈值，低于阈值就明确告诉用户"这个问题我查不到相关资料"。

提示：RAG不是万能药。知识库覆盖不到的问题，RAG解决不了。上线前一定要用真实问题测一遍，看看有多少问题是知识库里根本没有答案的。

6. Memory是主厨记住老客人口味的能力

6.1 没有Memory的系统像失忆的服务员

一个没有Memory的AI系统，每次对话都是全新的开始。用户上一句说"我住在北京"，下一句问"明天适合穿什么"，系统不知道他在北京，给出的建议可能完全不适用。这就像一个失忆的服务员，每次客人回来都得重新自我介绍。

Memory解决的是跨轮次、跨会话的信息保持问题。后厨类比：一个好的服务员记得张先生不吃辣、李女士对花生过敏、王老板每次都要靠窗的位置。这些信息不是这一顿饭才有的，是长期积累的。

AI系统里的Memory分几种。短期Memory是当前对话的上下文，一般用对话历史来实现。长期Memory是跨会话的用户偏好、历史行为，需要存到数据库里，每次对话开始时检索出来。

6.2 Memory的存储和检索策略

Memory的难点不在存，在什么时候存、存什么、什么时候取。

存什么？不是所有对话都值得存。我一般只存三类信息：用户的明确偏好（"我不吃香菜"）、重要的事实（"我的订单号是XXX"）、以及任务的关键状态（"这个流程走到第三步了"）。闲聊内容不存，存了也是噪声。

什么时候存？我倾向于在对话结束时做一次总结，把值得记的信息提取出来存进去。实时存的话，容易把临时信息也存进去，比如用户随口说的一句"今天好热"，存进去下次对话可能就误导模型了。

什么时候取？不是每次对话都把全部Memory拉出来，那样token扛不住。一般是根据当前问题做相关性检索，只取最相关的几条。这又回到了RAG的思路——Memory的检索本质上也是一种RAG。

6.3 Memory的隐私和一致性问题

Memory涉及用户数据，隐私是绕不开的。我的原则是：只存必要的信息，存的时候脱敏，取的时候鉴权。用户的身份证号、银行卡号这类敏感信息，绝对不进Memory。

一致性问题也很常见。用户在第一次对话说"我住在北京"，第二次说"我搬到上海了"，Memory里就有两条冲突的记录。处理方式是给Memory加时间戳，检索时优先取最新的。或者更激进一点，检测到冲突时主动问用户"您之前说住在北京，现在更新为上海吗"。

7. 评估是后厨的品控环节，没有它一切白搭

7.1 为什么评估最容易被跳过

我见过太多团队，花三个月搭系统，上线前一天才想起来"怎么判断它好不好"。这就是典型的没有品控的后厨——菜做出来了，但没人尝，好不好吃全凭感觉。

评估之所以容易被跳过，是因为它不产生直接的功能，看起来像是"额外工作"。但没有评估，你根本不知道系统是在进步还是在退步。你改了一个prompt，感觉好像好了，但到底好了多少？没有评估数据，全靠感觉，这是很危险的。

后厨的品控有明确的流程：每道菜出锅前尝一口，每天抽查几次，每周做一次全面检查。AI系统的评估也应该分层：单次输出的即时检查、批量测试的定期评估、以及线上真实数据的持续监控。

7.2 评估方法的选择

评估方法分两大类：自动评估和人工评估。

自动评估适合大规模、可量化的场景。比如分类任务看准确率，抽取任务看字段匹配率，生成任务可以用另一个模型来打分（这就是LLM as Judge的思路）。自动评估的优点是快、便宜、可重复，缺点是对于主观性强的任务，打分可能不准。

人工评估适合小规模、主观性强的场景。比如文案质量、对话自然度，这些很难用自动指标衡量。人工评估的缺点是慢、贵、不一致——不同的人标准不一样。

我的做法是两者结合：用自动评估做日常的快速迭代，用人工评估做关键节点的质量把关。自动评估发现异常时，再拉人工来复核。

7.3 评估集的建设

评估集的质量决定了评估的价值。我见过有人随便找几个问题就当评估集，结果系统在评估集上表现很好，上线后一塌糊涂。问题出在评估集不具代表性。

好的评估集应该覆盖：常见场景、边界场景、以及已知的失败场景。常见场景占大头，保证基本盘；边界场景测试系统的鲁棒性；失败场景是之前踩过的坑，防止回归。

评估集要持续更新。线上发现新的失败案例，就加进评估集。这样评估集越来越贴近真实分布，评估结果也越来越可信。我一般每个月更新一次评估集，把当月线上出现的bad case加进去。

8. 对齐是后厨的食品安全标准，底线不能破

8.1 对齐到底在约束什么

对齐这个词听起来很学术，说白了就是让AI的行为符合人类的期望和价值观。后厨类比：食品安全标准。主厨手艺再好，如果用了过期食材、生熟不分、卫生不达标，这家店迟早出事。

AI系统的对齐约束几个层面。第一是安全：不能输出有害内容、不能泄露隐私、不能执行危险操作。第二是诚实：不知道就说不知道，不能瞎编。第三是有用：在安全的前提下，尽可能帮用户解决问题。

这三个层面有时候会冲突。比如用户问一个敏感问题，诚实地说"我不知道"是安全的，但可能不够有用。对齐的工作就是在这三者之间找平衡。

8.2 对齐的实现手段

对齐的实现分几个层次。最底层是训练阶段的对齐，通过人类反馈强化学习等技术，让模型本身的行为倾向就符合期望。这一层是模型厂商做的，应用开发者一般碰不到。

中间层是系统提示词的对齐。你在system prompt里写清楚行为准则，比如"不要讨论政治话题""不确定的信息要标注""涉及金额的计算必须调用计算器"。这一层是应用开发者最常用的手段。

最上层是输出过滤和审核。模型输出后，再过一道规则或模型检查，不合规的就拦截或改写。这一层是兜底，防止前两层漏网。

我的经验是三层都要有。只靠提示词，模型偶尔会不听话；只靠输出过滤，体验会很差，因为经常误杀。三层配合，才能既安全又流畅。

8.3 对齐和能力的权衡

对齐会损失一部分能力。你让模型"不确定就说不确定"，它在某些场景下就会变得过于保守，明明知道答案也说不知道。你让模型"不要输出敏感内容"，它可能把正常的医学讨论也当成敏感内容拦掉。

这个权衡没有标准答案，取决于你的场景。面向大众的产品，对齐要严一些；面向专业用户的产品，可以松一些。比如一个医疗咨询系统，宁可保守也不能给出错误建议；一个内部研发助手，可以放开一些，让工程师自己判断。

我的做法是分级处理：高风险场景严格对齐，低风险场景宽松对齐。同时保留一个"人工复核"的通道，被拦截的内容可以转人工，避免误杀影响体验。

9. Agent是能独立掌勺的主厨，不是只会切菜的帮工

9.1 Agent和普通AI应用的区别

Agent这个词被用得很泛，我的定义是：能自主决定做什么、怎么做、做多久的系统。后厨类比：普通AI应用是帮工，你让他切菜他就切菜，切完就停。Agent是主厨，你告诉他"今晚有十桌客人"，他自己决定先备什么菜、怎么安排灶台、什么时候开始炒。

Agent的核心特征是自主性。它不只是执行预设的流程，而是能根据情况调整。这需要几个能力支撑：Planning（会拆任务）、Tool Use（会用工具）、Memory（记得住状态）、ReAct（会边做边调整）。前面讲的这些概念，组合起来就是一个Agent。

9.2 Agent的架构设计

一个典型的Agent架构包含几个部分：大脑（LLM）、工具集、记忆模块、执行循环。

大脑负责决策，工具集是它能调用的能力，记忆模块保存状态和历史，执行循环驱动整个流程运转。后厨类比：主厨是大脑，厨具是工具，菜谱笔记是记忆，炒菜流程是执行循环。

设计Agent时最容易犯的错是给太多工具。工具越多，模型选择越困难，误调用率越高。我的经验是：工具数量控制在10个以内，每个工具职责清晰，不要有功能重叠。如果确实需要很多工具，就分组，让Agent先选组再选工具。

9.3 Agent的失败模式

Agent最常见的失败模式是陷入循环。它在两个状态之间来回跳，比如查了A发现要查B，查了B发现要查A，无限循环。解决办法是设最大轮数，以及检测重复状态。

第二种失败模式是目标漂移。Agent在执行过程中逐渐偏离原始目标，最后做了一堆事但没解决用户的问题。解决办法是在每一轮循环开始时，把原始目标重新注入上下文，提醒它"你的任务是XXX"。

第三种失败模式是过度行动。Agent为了完成任务，调用了不该调用的工具，或者执行了危险操作。解决办法是给敏感操作加人工确认，以及设置操作权限边界。

10. 编排是后厨的动线设计，决定整体效率

10.1 编排解决的是"多个角色怎么配合"的问题

前面讲的都是单个组件，编排讲的是这些组件怎么串起来。后厨类比：动线设计。洗菜区、切菜区、炒菜区、出餐区怎么排布，决定了传菜员走多少冤枉路，决定了高峰期会不会堵。

AI系统里的编排，就是决定LLM、工具、RAG、Memory这些组件按什么顺序、什么条件调用。简单的编排是线性的：先RAG检索，再LLM生成，再输出过滤。复杂的编排是有分支和循环的：根据问题类型走不同的流程，根据执行结果决定是否重试。

10.2 编排框架的选择

编排框架这两年出了很多，从早期的LangChain到后来的各种Agent框架。选框架的核心标准是：能不能清晰地表达你的流程逻辑，以及出问题的时候好不好调试。

我自己的经验是，简单流程不要上框架。一个"检索—生成—过滤"的三步流程，用几十行代码就能写清楚，上框架反而增加了一层抽象，调试的时候要穿透好几层才能看到实际执行的东西。

复杂流程才需要框架。比如有十几个步骤、有分支、有循环、有并行，这时候框架的价值就体现出来了——它帮你管理状态、处理异常、记录日志。但即便如此，我也建议先用代码把流程跑通，再考虑要不要换成框架。过早引入框架，容易被框架的设计限制住。

10.3 编排的可观测性

编排最怕的是黑盒。流程跑起来了，但中间发生了什么你不知道。出了问题只能看最终输出，根本不知道是哪一步错了。

后厨类比：一家餐厅如果厨房是封闭的，客人投诉菜咸了，你都不知道是哪个环节放的盐。好的后厨是透明的，每个环节都有记录，出了问题能追溯到具体的人和时间。

AI系统的可观测性包括：每一步的输入输出、每个工具的调用记录、每次决策的思考过程、以及整体的耗时和成本。这些数据要能方便地查看和检索。我一般会在编排层加一个日志中间件，把每个环节的关键信息都记下来，出问题的时候按trace id一查，整条链路清清楚楚。

11. 把这十个概念串起来看一个完整案例

11.1 场景：一个智能客服系统的搭建

假设你要搭一个电商智能客服系统，用户问"我上周买的那个耳机怎么还没到"。

编排层接收请求，判断这是一个订单查询类问题，走订单查询流程。Memory先被调用，检索这个用户的历史信息，发现他上周确实下过一个耳机订单，订单号是XXX。RAG被调用，从知识库里检索物流查询的相关规则和话术模板。LLM作为大脑，决定需要调用订单查询工具。Tool Use执行，传入订单号，返回物流状态"已发货，预计明天到达"。ReAct循环检查结果，发现信息完整，不需要进一步查询。LLM组织语言，生成回复"您的耳机已发货，预计明天到达"。评估模块检查回复是否包含订单号、是否准确、是否友好。对齐模块检查是否有敏感信息泄露。最后输出给用户。

这个流程里，十个概念全部用上了。Planning体现在流程的分支设计上，Agent体现在整个系统的自主决策能力上。

11.2 每个环节出问题会怎样

如果Memory出问题，系统不知道用户的历史订单，可能会问"请问您的订单号是多少"，体验下降。

如果RAG出问题，检索到了过时的话术模板，回复可能不符合最新的服务标准。

如果Tool Use出问题，订单查询失败，系统可能编一个假的物流状态，这是最严重的。

如果评估出问题，回复里有错别字或格式错误，用户会觉得不专业。

如果对齐出问题，回复里泄露了其他用户的信息，这是事故。

每一个环节都不是可选项，而是必选项。这就是为什么我说这十个概念要串起来看——它们不是十个独立的知识点，而是一个系统里互相依赖的十个部件。

11.3 从后厨到AI系统的映射总结

这张表我建议刚入门的朋友存下来。每次遇到一个新的AI概念，先想想它在后厨里对应什么角色，理解起来会快很多。

12. 几个我踩过的坑和对应的经验

12.1 不要为了用概念而用概念

我见过一个团队，做一个简单的文档问答，非要上Agent架构，结果系统复杂得没人能维护，效果还不如一个朴素的RAG。概念是工具，不是目标。你的系统需要什么就上什么，不需要的坚决不加。

判断标准很简单：加上这个组件，解决了什么具体问题？如果答不上来，就是不需要。RAG解决知识时效性，Memory解决跨轮次，Agent解决自主决策，每个都有明确的适用场景。场景不匹配，硬上就是给自己找麻烦。

12.2 评估要趁早，不要等上线

我自己的教训是，第一个AI项目上线前一周才开始想评估的事，结果发现系统在真实数据上表现和测试时差很多，但已经没时间大改了。后来我养成的习惯是：项目启动的第一周就把评估集建起来，哪怕只有几十条数据。有了评估集，每次改动都能看到效果，迭代方向清晰得多。

12.3 提示词不是越长越好

很多人写system prompt，恨不得把所有规则都塞进去，写了两三千字。结果模型记不住，重要的规则被淹没在噪声里。我的经验是：核心规则不超过十条，每条不超过两句话。剩下的细节，通过工具描述、输出格式约束、后处理来保证。提示词是给模型看的，不是给你自己看的，要站在模型的角度想它能不能记住。

12.4 工具调用失败要显式处理

前面提过，这里再强调一次。工具调用失败是常态，不是异常。网络抖动、API限流、参数不合法，这些都会发生。每个工具调用都要有try-catch，每个失败都要有明确的处理逻辑。最怕的是失败了不处理，模型基于错误结果继续往下走，最后给用户一个看似合理实则错误的答案。这种错误最难排查，因为表面上看不出问题。

12.5 上线只是开始，不是结束

AI系统和传统软件不一样，它的行为会随着输入分布的变化而变化。今天表现好，不代表明天表现好。用户的问题在变，知识库的内容在变，模型的行为也可能因为各种原因漂移。上线后要持续监控，定期评估，发现问题及时迭代。我一般会设几个监控指标：调用成功率、平均延迟、用户反馈率、以及关键场景的准确率。任何一个指标异常，都要及时排查。

这套后厨类比，我用了好几年，带过好几个新人，效果一直不错。它的价值不在于精确，而在于给你一个思考的框架。当你面对一个新的AI概念时，先问自己：它在后厨里对应什么？它解决了哪个环节的问题？没有它会怎样？想清楚这三个问题，概念就不再是抽象的名词，而是有血有肉的组件。