餐厅后厨是我能想到的、讲清楚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概念核心作用缺失后果主厨LLM理解需求、生成方案系统没有大脑厨具设备Tool Use执行精确操作只能空谈不能做事边做边尝ReAct动态调整步骤一条路走到黑备菜流程Planning拆解和排序任务效率低、易漏步骤采购库存RAG引入外部知识知识过时、瞎编记住老客Memory保持跨轮次信息每次从零开始品控尝菜评估衡量输出质量不知道好坏食品安全对齐约束行为边界可能出事故独立主厨Agent自主完成任务只能被动执行动线设计编排协调组件配合流程混乱这张表我建议刚入门的朋友存下来。每次遇到一个新的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概念时先问自己它在后厨里对应什么它解决了哪个环节的问题没有它会怎样想清楚这三个问题概念就不再是抽象的名词而是有血有肉的组件。 
长河君 · 2026/10/28 11:52:16 · 阅读 1.2k 用餐厅后厨类比讲透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概念核心作用缺失后果主厨LLM理解需求、生成方案系统没有大脑厨具设备Tool Use执行精确操作只能空谈不能做事边做边尝ReAct动态调整步骤一条路走到黑备菜流程Planning拆解和排序任务效率低、易漏步骤采购库存RAG引入外部知识知识过时、瞎编记住老客Memory保持跨轮次信息每次从零开始品控尝菜评估衡量输出质量不知道好坏食品安全对齐约束行为边界可能出事故独立主厨Agent自主完成任务只能被动执行动线设计编排协调组件配合流程混乱这张表我建议刚入门的朋友存下来。每次遇到一个新的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概念时先问自己它在后厨里对应什么它解决了哪个环节的问题没有它会怎样想清楚这三个问题概念就不再是抽象的名词而是有血有肉的组件。