1 文章概述
大家在接触AI相关概念时，可能会被其中繁多的技术名词所困扰，例如LLM、Tool Use、ReAct、Planning、Memory、RAG等等，导致望而却步不敢深入。
本文以餐厅后厨为例，采用类比方式介绍AI技术相关概念，你会发现一家稳定出餐的餐厅与一个稳定运行的AI智能体，具有很多相似之处。
2 十个概念
2.1 主厨 VS LLM
主厨是这家餐厅的灵魂 ，他有着显著的优点和缺点。这位主厨优点是极其聪明，经验极其丰富。他读过海量的菜谱，见识过各式各样的烹饪技法，且可以迅速理解客人意图，例如客人说想吃点清淡的，他就可以迅速找到相关菜谱。
同时缺点也很明显，第一个是由于年轻时运动受过伤，行动不便 ，不方便拿调料和食材。第二个是现在年纪大了，记忆力不好 ，菜做到哪一步了有时候会忘记。第三是比较自负，不愿意承认自己不知道，遇到不知道的菜谱，也会胡说两句。
对应技术概念是LLM（Large Language Model，大语言模型），第一其有着极强推理能力，海量的知识储备。但是本质上是个封闭思维体，没法直接进行查天气，看地图，下单等操作。第二上下文或者会话轮次过长，可能记不得之前做过什么了。第三可能会产生幻觉，遇到不会的东西不愿意承认，而是倾向于编造看似合理的答案。
2.2 配菜员 VS Tool Use
既然主厨有着如此明显的缺点，餐厅只有他一个人肯定无法运转，此时就要有很多帮手。配菜员就是其中一员。
主厨在做菜时喊：我要葱、我要盐、我要冰箱里的牛肉，配菜员会迅速拿取相关物品，递到主厨手里。
对应技术概念是Tool Use（工具调用），大模型无法直接与外部交互，但是可以下发指令：帮我查询杭州天气，这时工程系统就会调用天气查询API，返回天气信息给大模型，供其决策。
一般流程是模型输出结构化调用指令，由工程侧执行外部操作，再把结果返回给模型，让模型的能力延伸到外部世界。
2.3 记单员 VS Memory
今天中午又接了几百单，此时主厨记性不好的问题更加明显了：第29桌刚才牛排要几分熟？第56桌要什么辣度？刚才95桌的菜放盐了没有？
这时记单员出场了。他手里有两个本子：一个是手边的小记事本 ，专门记录当前正在做的几桌菜，随时翻随时看，但空间有限，写满了就得把最早的擦掉。另一个是放在柜台的大台账，记着所有老客人的忌口、常点菜，哪怕客人三个月没来，只要报出当时的桌号，也能立刻翻到记录。
对应技术概念是Memory（记忆系统），目的是解决模型失忆问题。记忆分为短期记忆和长期记忆。
短期记忆对应模型的上下文窗口，就像记事本一样有容量限制，对话轮次太多，最早的信息就会被挤出窗口，模型就忘了。
长期记忆则依靠外部存储介质如向量数据库，可以把用户的历史偏好、历史对话、关键信息永久保存，需要的时候再检索出来，作为上下文传给模型。
短期记忆和长期记忆往往配合使用：短期记忆保证当前对话的连贯性，长期记忆让模型拥有跨会话的记忆能力，让AI不再是每次对话都从零开始的陌生人。
2.4 菜谱管理员 VS RAG
主厨会做的菜很多，确实很厉害，但是有三个局限：第一个是他会的菜局限于当学徒时受训所学的菜，第二个是菜谱管理员知道一些私房菜，这些菜谱主厨是不知道的。第三网络上新出的菜主厨不能随时更新。
这时菜谱管理员就发挥作用了，他管着很多网上最新的菜谱，也有很多私房菜谱。当客人点了一个主厨不会做的菜时，他就把详细步骤告诉主厨。
对应技术概念是RAG （Retrieval-Augmented Generation，检索增强生成）。大模型在训练时学习了海量知识，但存在两个问题：一是知识有截止日期 ，大模型对于训练之后发生的事一无所知。二是大模型没有私有数据，例如产品文档、公司内部数据。
RAG的解决思路是在让模型回答之前，先去外部知识库里把相关资料找出来，一并放入上下文中，让模型根据资料回答，而不是凭空编造。知识通常有以下来源:
向量数据库：存储企业私有文档、产品手册、内部数据等知识。
网络搜索：通过搜索引擎 API 获取新闻、天气等实时信息。
2.5 安全员 VS 安全护栏
主厨做菜水平高，所谓艺高人胆大，喜欢在菜品里加一些自己的创意，甚至在未经客人允许的情况下，改动菜品底味，做出所谓创新菜品。有的客人喜欢，但是有的客人无法接受这一种行为。
更麻烦的是，偶尔会有不怀好意的客人，故意用话术诱导主厨把后厨的秘方说出来，或者让主厨在菜里加一些不该加的东西。
这时安全员就出场了，他站在传菜口旁边，手里拿着餐厅的规章制度手册。他的工作分两部分：第一部分盯着客人，发现有客人试图套话、诱导主厨说违规内容，立刻拦住，不让这些请求传到主厨耳朵里。
第二部分盯着出去的菜，每道菜端出去之前都要过一遍检查：有没有放错调料？有没有泄露后厨秘方？有没有遵循客人忌口要求？一旦发现问题，要么打回去让主厨重做，要么直接替换成一份安全的标准菜品。
对应技术概念是Guardrails（安全护栏），大模型能力再强也得有边界，安全护栏确保模型不能让它随意调用敏感接口，不能访问无权限数据，不能输出违规内容。
安全护栏工作方式也是双向的：输入护栏在用户请求进入模型之前做检查，拦截提示词注入攻击、越狱诱导、敏感信息泄露等恶意意图，不合规的请求根本不会触发模型推理，省token又安全。
输出护栏在模型生成回答之后、返回用户之前做检查，识别幻觉、违规内容、隐私泄露等问题，不通过就拦截、改写或替换成安全回复。
护栏有多种实现方式，简单场景直接使用关键词拦截，复杂场景使用小模型做语义识别，也可以用大模型做内容裁判。工程实践中往往采用组合方式，先用规则筛掉明显违规的内容，再有大模型进行内容校验。
2.6 试菜员 VS Reflection
一道菜在端给顾客之前，需要试菜员进行品控，如果有一项没有达标，就要打回重做。试菜员会具体指出问题在哪，然后主厨根据这些反馈针对性调整，调整完再端给试菜员重新检查，直到各项指标都合格才放行。
对应技术概念是Reflection（反思机制），大模型输出的内容不一定每次都完美，反思机制会先校验一遍结果，发现问题就触发重试或者修正，直到输出合格才会放行，避免错误内容直接给用户。
反思本质是一套自校验循环 ：先产出结果，再单独评估好坏。评估模块会站在第三方角度检查：信息是否属实、输出格式是否符合要求、有没有遵守用户指令。发现问题后，模型重新修改，反复校验直到达标。重复次数不是没有限制的，要么达到满足预设标准后停止，要么达到最大迭代次数后停止。
反思过程是工程侧全自动的，不需要用户手动触发。反思机制由工程代码在后台自动编排执行，用户只看到最终优化后的结果。
工程上通常采用分层触发策略：每步输出都做轻量检查（格式对不对、工具调用成没成功），关键节点才启动深度反思（工具调用失败、代码执行报错、搜索结果与原假设矛盾），兼顾效果与效率。
2.7 炒蛋炒饭 VS ReAct
客人点了一碗蛋炒饭，虽然看着简单，但主厨做得也很费心。操作流程如下:
- 思考：先炒蛋还是先炒饭？还是先炒蛋，让蛋裹住米饭。
- 行动：热锅倒油，打两个鸡蛋进去炒散。
- 观察：看锅里，蛋炒有点老了。
- 再思考：这次火太大了，下次得调小火，这次先加米饭中和一下。
- 再行动：倒入米饭，快速翻炒，撒点盐。
- 观察：尝一口，感觉太淡了。
- 继续循环：再加点盐，味道正合适，出锅装盘。
主厨不是机械地按菜谱操作，而是在每一步都观察锅里的状态、尝味道、再决定下一步怎么调整，循环往复，直到炒饭达标。
对应技术概念是ReAct（Reasoning+Acting），这是AI Agent的经典范式，不是直接输出最终答案，而是先思考我该做什么，然后执行一个动作（如调用工具），观察执行结果，再基于结果思考下一步该做什么。如此循环往复，直到任务完成。
ReAct与管理学中PDCA概念（Plan计划 Do执行 Check检查 Act行动）高度相似：先规划方案，小规模落地执行，核查结果差异，再采取改进动作，循环持续优化。我们可以看到不同行业很多标准都殊途同归。
ReAct是边做边调整，在执行过程中根据观察结果决定下一步动作。Reflection是做完再复盘，对整体结果进行评估和优化。一个关注过程，一个关注结果，两者配合使用效果更佳。
2.8 做宴席 VS Planning
客人订了一桌宴席，要求8道菜，包含凉菜、热炒、炖汤，这时主厨不会一上来直接炒菜，而是先进行规划：
- 拆解任务：8道菜，哪些是凉菜？哪些是热炒？哪些是炖汤？
- 排优先级：炖汤最耗时最先开始；凉菜可以提前备好；热炒最后做，保证上桌是热的。
- 分配资源：让配菜员先去准备炖鸡汤食材，让自己先去做凉菜。
- 动态调整：做到一半食材不够，及时调整策略，同时通知配菜员补货。
面对复杂任务，主厨把做宴席这个大目标，拆解成一个个可执行的步骤，并安排好先后顺序和资源配置。
对应技术概念是Planning（规划），这是AI Agent 核心能力之一，面对一个复杂目标，它不会直接动手，而是先拆解任务，确定执行顺序再开工。
ReAct是边想边做，适合短流程、交互式任务（炒蛋炒饭）。
Planning 是先想清楚整体方案再动手，适合多步骤、长链路任务（做宴席）。
在实际 Agent 系统中，Planning 和 ReAct 往往组合使用，先用 Planning 拆解出可执行任务，再用 ReAct 逐步执行每个子任务。
2.9 监控 VS Tracing
在厨房顶上装了一个监控探头，记录着整个厨房人员的一举一动。例如主厨做了什么菜？用了多少酱油和盐？配菜员递了哪些菜？一旦菜品出现问题，可以通过监控定位到环节与责任人。
对应技术概念是Tracing（链路追踪）。AI Agent 执行过程是一个黑盒，出现问题很难排查，所以工程侧可以基于 OpenTelemetry等标准，记录从请求到输出的完整执行链路，包括每一步例如工具调用、模型推理、记忆读写、Token 消耗、延迟等，让智能体运行过程具备可观测性。
2.10 Agent与Harness
Agent是智能体，LLM是大模型，Harness是驾驭系统，三者关系如下：
Agent = LLM + Harness
在本文中Agent代表整个可以稳定出餐的厨师团队，LLM代表处于灵魂地位的主厨，Harness代表除主厨外厨师团队其他成员+设备+厨房环境+整套工作流程。
3 工程能力与大模型同样重要
我们知道大模型有以下短板：记性不好，不能执行工具，知识过期，无工作环境。驾驭工程（Harness）就是通过工程化补齐这些短板，让大模型长出手脚，变成可落地、可管控、可复用的智能体。
目前业内除了提升大模型参数之外，也在提升工程能力，你可以看到，在两种不同的工具中使用同一种大模型，执行效果可能大不相同。
因为主厨再厉害也无法一个人撑起一家餐厅，无论菜品设计得多么精美，要有人做出来才算数。