做了几年餐饮数字化系统，我有个很深的体会：餐饮门店最缺的不是系统，而是能把系统串起来干活的人。POS管点餐、进销存管库存、后厨KDS管出餐、会员系统管复购，每个环节都有信息化支撑，可真遇到超卖、食材积压、出餐超时这些事，最后还是得靠店长翻台账、打电话、现场协调。AI Agent这波技术起来之后，我第一次觉得“看不见的店长”这件事值得认真做了。
写这篇内容不聊宏观趋势，只聊我把一个AI Agent放进餐饮管理流程后踩过的坑、趟出来的路。它适合两类人看：一类是餐饮或零售行业的IT负责人，想知道Agent到底能解决什么实际问题；另一类是做Agent开发的技术同学，想看看工具调用、上下文管理、人工兜底这些环节在真实业务场景里是怎么落地的。下面所有内容都是我基于实际项目的经验梳理，里面涉及到具体参数和建议，也都是从真实运营数据里长出来的。
1. 整体设计思路：从单点AI到门店Agent
1.1 餐饮系统智能化的老问题
我之前做过一个“智能推荐菜”的功能，当时用的是很常见的做法：根据用户历史订单算相似度，在首页推荐几道菜。算法上线之后点击率确实涨了，但问题马上来了——用户点了推荐菜，后厨发现食材不够；高峰期推荐了制作时间特别长的复杂菜品，导致整条出餐线被拖慢；会员日优惠套餐里包含的菜，推荐算法完全不知道，结果推荐了和优惠规则互相冲突的菜品。这些问题不是推荐模型本身能解决的，它缺的是对门店实时状态的感知，以及对上下游动作的统筹。
库存预警系统也是同样的毛病。传统进销存设置一个安全库存阈值，低于阈值就触发补货提醒。这个提醒基本不看未来两天有没有暴雨、周六是不是节日、前后桌有没有大桌预订，只会机械地按照历史平均消耗去算。结果要么囤了一批用不完的食材，要么关键食材在高峰时段直接断货。
说白了，单点AI解决的是“某一件事的自动化”，但餐饮经营是一个强耦合的连续流程，前厅、后厨、采购、供应链环环相扣。你只优化其中一环，其他环节反而可能成为新的瓶颈。这也是我后来转向Agent架构的根本原因。
1.2 Agent的核心价值：会拆任务、会用工具、会看结果
我自己的理解是：单点AI像招了一个只会做单一工种的员工，你让它端菜，它就不管菜是不是凉了；Agent更像店长，它能根据你定的经营目标，自己拆解任务、查数据、调工具，发现某个环节有问题，还能换个方案重新试一轮。
技术层面，Agent的核心要素可以归纳成四个：感知、规划、记忆、执行。
感知指的是能接收到真实的业务事件，比如新订单进来、库存减少、顾客退货。规划是根据目标拆解动作，比如发现某道菜库存低于安全线，就决定要不要触发补货、补多少。记忆分短期和长期，短期记住当前这桌客人的需求，长期记住这个门店的消耗规律和顾客偏好。执行则是通过调用外部工具完成实际动作，比如改订单状态、生成采购单、推送通知。
在餐饮场景里，这四件事做到位，价值会非常明显。比如高峰期来了三张加急单，Agent可以根据每道菜的制作时长、当前炉灶占用情况、食材余量，自动排出最优的制作顺序，而不是机械地按下单时间排队。又比如智能采购，Agent不是简单看库存数字，而是综合未来三天的天气预报、节假日、周边活动、历史销量趋势，产出一张经过权衡的采购建议单。
1.3 技术选型：自建编排还是套现成框架
关于框架选择，我前后纠结了很久。市面上现成的Agent框架上手快，内置了规划、调用工具、记忆这些基础能力，社区也活跃。但餐饮场景的定制化需求非常重，你要接POS机、接后厨打印机、接供应链系统，这些老系统的接口风格五花八门，有些甚至只有串口或者CSV导出，框架再强大也救不了底层数据质量。
我最后的方案是：底层用了一个开源Agent运行时做任务编排和工具调度的底座，上层业务逻辑全部自研，工具层自己封装。这样既没有重复造轮子，又能针对餐饮场景做深度定制。
选大模型的时候，我关注三个指标：中文意图识别准确率、结构化输出稳定性、工具调用参数遵循度。餐饮对话里口语很多，“来个不辣的”“少放葱”“能快点上吗”，如果模型连这些日常表达都解析不到位，后面一切都是白搭。结构化输出尤其重要，因为我们要让Agent直接去驱动业务系统，输出必须是严格的JSON，不能有半点自由发挥。
成本方面也要考虑清楚。餐饮门店的订单量是脉冲式的，午晚市瞬间爆发，如果每次请求都把所有历史对话、工具结果、业务文档全部塞给模型，钱烧得很快。我后面做了分级策略：简单场景用轻量模型兜底，复杂决策才上大模型推理，费用能省一半以上。
2. 四大功能模块的落地细节
2.1 智能点餐与推荐模块
这个模块最容易理解，也最容易做砸。传统的推荐算法只考虑“用户可能喜欢什么”，而Agent要考虑的是“用户喜欢的东西能不能做、能不能快速做、做了能不能赚钱”。
我的做法是让Agent对接了三个工具：菜品库查询、实时库存查询、制作时长查询。用户点餐的时候，Agent先理解用户的语言，提取口味偏好和忌口，然后调用菜品库工具缩小候选范围，再调用库存工具筛选掉当前缺货的菜品，最后结合时段和堂食/外卖场景，给出推荐列表。
这里有个关键细节：推荐结果一定要附带理由。我实测下来，带理由的推荐比不带理由的推荐接受率高很多。理由是“这个菜制作只要6分钟，适合您赶时间”比干巴巴一句“推荐您点水煮鱼”有说服力得多。Agent生成的理由可以来自菜品标签和实时信息，比如厨师长在小黑板写了“今日鲜虾到货”，我们把这句手动录入系统，Agent推荐时就能自然带出。
但要注意，推荐绝对不能越权。有的顾客明确说“我就想要烤鱼”，系统已经在库存里查到烤鱼售罄，这时候Agent应该实话实说，然后给替代方案，而不是强行改成推荐毛利最高的菜。顾客信任感一旦破了，推荐就变成骚扰。
2.2 库存预测与自动补货模块
这个模块是我认为性价比最高的一个。餐饮后厨最怕两件事：食材不够卖，和食材囤到坏。传统供应链系统只会做简单阈值判断，Agent方案则是把预测变成一项系统性工作。
我设计的Agent每天凌晨两点跑一次预测流程。它读取近90天的销售明细、未来三天的天气、节假日安排、门店预订量，然后用一个轻量级的时序模型生成基线预测，再让大模型对异常情况做修正。这里我不是完全让大模型去算数字，而是让模型去做归因调整。比如天气预报说两天后有暴雨，模型会把外卖类食材的需求上调15%，把堂食生鲜类的需求下调10%。
补货单生成之后，Agent不会直接下单，而是先推送给店长确认，写明每条补货的依据。比如“三文鱼建议补5公斤，因为周三到周五有三个公司团建预订，合计预计消耗5.2公斤，现有库存1.1公斤”。这个透明的理由让店长更容易相信系统，也方便他基于经验做最后判断。
实测下来，蔬菜类损耗率降了大概两成，紧急叫货的频率大幅下降。但这里有个容易踩的坑：生鲜和冻品要分开建模。生鲜保质期短，预测偏多就是直接损耗；冻品保质期长，稍微多囤一点没有大问题。Agent策略里有针对不同品类的不同容忍系数，这是我初期完全没考虑到的。
2.3 后厨调度与出餐优化模块
后厨调度是我刚开始觉得“AI肯定搞不定”的部分，因为厨房是一个充满不确定性、依赖老师傅经验的地方。但实际做完之后，我发现即使只做精度不高的辅助优化，收益也很大。
这个Agent的逻辑是这样：每当下单事件进来，它会计算每道菜的预计制作时间，结合当前正在制作的订单，给每一份订单打一个“预期超时风险分”。风险分超过阈值的订单，Agent会触发后厨大屏提醒，并且建议调整制作顺序。
具体调度时用的数据包括：菜品标准制作时长、当前炉灶占用状态、厨师当前任务数、订单的目标完成时间。这里我不会让Agent直接指挥厨师，而是让它输出建议，由厨师长确认后执行。因为后厨有太多系统不知道的隐性知识，比如“今天煤气火力不行，油炸类要加时间”，这种信息只能靠人补充。
让我比较意外的是，Agent最大的价值不是“优化顺序”，而是“提前预警”。一桌五个菜里有一个制作时间特别长，传统系统只能等超时了才知道，而Agent可以在下单那一刻就提示前厅：“这一桌建议提前告知顾客等待时间，或推荐更换一个备菜。”这种前置沟通对顾客体验改善极为明显。
2.4 顾客评价分析与投诉处理模块
这个模块是Agent能力最容易显性化的场景。过去人工处理平台差评，需要客服逐条阅读、判断严重程度、分派给责任人、拟写回复，效率极低。Agent让这个流程实现了大半自动化。
流程拆开是这样的：评价数据接入后，先由Agent做情感分析和话题分类，分出门店环境、服务态度、菜品口味、出餐速度、卫生情况这几个维度。然后对负面评价做严重程度分级。普通吐槽归入日报；涉及食品卫生或者人身安全的，直接触发紧急工单，同时推送提醒到店长和区域经理。
最有价值的是回复草稿生成。Agent会结合这条评价的具体内容、用户历史消费记录、餐厅当天的处理记录，生成一个针对性的回复建议。比如用户投诉“点的牛排等了40分钟”，Agent回复草稿会先说清当天确实有大型团餐导致出餐延迟，再说明补偿方案，而不是冷冰冰地道歉。
这个模块我建议永远保留人工确认环节。消费者的情绪是复杂的，机器判得再好也可能误判，特别是涉及过敏原、食物中毒这类出大事的词汇，哪怕只有一丝可能性，也要让人去核实。在这个场景里，Agent是提升效率的助手，而不是承担责任的替身。
3. 实操过程：关键环节的实现与调优
3.1 系统架构与事件流设计
整体架构我采用了事件驱动模式。门店的各种系统实时产生事件，包括POS订单创建、订单修改、支付成功、库存变更、评价提交、供应链出库。这些事件统一进入一个消息队列，Agent运行时订阅自己关心的事件，触发对应的任务流程。
为什么不直接用同步调用？因为餐饮业务峰值极其陡峭，午市晚市瞬间吞吐量可能是平峰的十几倍。同步调用的话，Agent一旦处理不过来，就会阻塞核心交易链路。用事件驱动，Agent处理不过来的事件可以积压并排队，哪怕延迟几分钟，也总比丢事件强。
我需要强调的一点是：Agent不应该直接改主数据库，否则出了问题都找不回是谁干的。所有Agent产生的业务动作，比如生成采购单、调整订单备注、更新库存，都通过原有的业务API去执行。Agent只负责决策和调用，不负责写库。这套设计让后端团队安心不少，因为底账始终在业务系统手里。
3.2 工具定义与权限边界
Agent要真正干活，必须暴露工具给它。但“工具开多了”和“权限给大了”是两件同样危险的事。我这里的工具定义遵循一个原则：每个工具都尽量细、尽量专用，而不是一个大而全的后端接口。
比如库存模块，我不会给Agent一个“查询库存信息”的万能接口，而是拆成“查询单个菜品实时库存”“查询多个菜品可用量”“查询某品类的预算消耗”。接口变多了，但每个接口的参数含义都很清晰，模型犯错的概率会小很多。工具描述字段一定要写清楚，包括使用场景、参数单位、返回值含义、常见报错。
下面是一个工具定义的简化示例：
{ "name": "get_dish_stock", "description": "查询指定菜品当前可售库存量。适合在推荐菜品、确认下单前使用。参数dish_id为菜品唯一标识，传入类似D10086的编号。返回字段stock_qty表示剩余可售份数，单位是份。", "parameters": { "type": "object", "properties": { "dish_id": { "type": "string", "description": "菜品唯一标识，例如 D10086" } }, "required": ["dish_id"] } }写好工具描述是一门功夫活。很多团队跑不通Agent，问题不是模型太弱，而是工具描述太含糊，模型根本不知道什么时候该用哪个工具。我整理过一个内部检查清单：每个工具至少要有使用场景说明、参数约束说明、返回值说明、错误处理说明。这四样缺一不可。
权限方面必须做最小化。某个Agent只负责做菜单推荐，那它就不应该具备修改价格的工具。负责采购的Agent，生成采购单后默认状态是“待确认”，必须由真人点击确认后采购单才会进入供应链系统。敏感操作设计成“永远需要人确认”，这条规则我不允许任何开发同学为追求效率而绕过。
3.3 提示词与上下文管理的几个关键策略
Agent的提示词和传统聊天机器人的提示词完全是两码事。你面对的不是让模型“回答问题”，而是让它“根据业务目标做规划、调工具、验证结果”。
我的System Prompt核心段落大意是：
“你是这家餐厅的智能运营助手。你的目标是在授权范围内帮助门店提升运营效率。你对库存、销量、订单的判断必须基于工具查询结果，严禁自己编造数字。当查询结果为空或失败时，应明确告知用户数据未查到。所有生成采购单的提议必须包含计算依据。所有面向顾客的输出必须礼貌且不承诺超出权限的补偿。”
这套提示词我迭代了十几版，最重要的变化是不断在提示词里补充“什么不要做”。明确告诉模型能做什么，更要明确告诉它哪些做法会出大事，比如私自承诺免单、臆测库存数量、无视过敏原信息。
上下文管理是另一个大坑。门店Agent每天处理成百上千个订单，如果每个请求都把用户完整历史对话塞给模型，成本和时间都扛不住。我采用的策略是三级记忆：第一级是当前会话关键信息，比如这桌人点了什么、有什么忌口；第二级是门店经营摘要，比如今日客流量、库存预警、特殊活动；第三级才是长期画像，比如这位顾客过去三个月的消费偏好。
还有一个细节：工具调用结果一般都很长，特别是查销售表的返回可能有几百行。直接全量塞回上下文，既浪费令牌又干扰模型注意力。我做了结果摘要器，把长表格压缩成关键指标。比如查询近30天销售明细，压缩后就变成“总销售额XX元，日均XX元，TOP3菜品为A/B/C，蔬菜类日销环比下降8%”。模型拿到这个摘要比拿到原始表格好用得多。
3.4 上线的影子模式与评测方法
AI Agent直接接手业务是大忌，我们的做法是先跑影子模式，再跑人工审核模式，最后才进入自动执行。所谓影子模式，就是Agent在后台真实环境下运行，但它的所有输出都不真实生效，只记录日志，拿它和真实运营结果做对比。
影子模式下，我们重点看三类指标：任务完成率、输出可信度、人工介入率。任务完成率指Agent能完整跑完流程的比例；输出可信度靠业务同学去抽查，看生产建议是否合理；人工介入率指运营人员在查看Agent产出时觉得需要修改的比例。
评测集里除了正常流程，必须要有设计过的边界案例。比如库存查询返回0、用户点了已下架菜品、评价内容全是大写字母和表情符号、时段突然有五百人的团餐预订。这些案例看似极端，但餐饮行业真的天天都可能遇到。
上线节奏上，我的建议是别做“大爆炸”式上线。第一个跑正式环境的一定是评价分析Agent，因为它的风险最低，即使判断失误也只是写个回复草稿。等运营团队对Agent建立起基本信任后，再逐步开放库存预测和点餐推荐，最后才轮到后厨调度。每一步都需要建立对应的反馈通道，让人能方便地标记“这个结果不对劲”。这个反馈数据才是持续优化Agent的燃料。
4. 常见问题与排查技巧实录
4.1 工具参数总是填错怎么办
这是所有Agent项目都会遇到的第一道坎。模型明明看着工具描述，却在调用get_dish_stock时把菜品名“清蒸鲈鱼”直接当参数传进去，而不是传D10001这个ID。我排查下来有三种原因：工具描述里参数说明不够明确，模型没意识到要查ID；上下文有多个相似工具，模型搞混了；模型在模仿历史错误样本。
解决方式是三管齐下。一是把工具描述里的参数改成“只接受菜品ID，不接受菜品名称，菜品名称查询使用另一个工具”，把边界写死。二是在容易混淆的工具之间加“工具选择提示”，在System Prompt里补充一句“当用户用菜名表述时，请先调用菜品检索工具获得ID，再调用库存查询工具”。三是历史日志里一旦发现错误调用，马上把正确案例补充进少样本示例里。
还有一种情况，模型会多传参数。工具定义里只有两个参数，它非要多给一个其他内容。这种通常是因为模型见过其他工具的调用格式，产生了混淆。解决办法是对工具调用做schema校验，返回值明确报错，让Agent自己修正。不要指望模型百分百遵守schema，校验层必须随时在线。
4.2 Agent“忘事”和上下文截断
低峰期Agent表现很好，到了高峰期就开始恍恍惚惚。你会发现它三分钟前刚确认了桌号，再问一遍竟然忘了，甚至把A桌的忌口记到B桌头上。这大概率不是模型变傻了，而是你的上下文管理在长会话里失控了。
我遇到过一种典型场景：服务员和Agent对话，中间插入了好几轮工具调用，每个工具结果都占了几百个令牌，等到用户真的需要用到开场信息时，最初那几句已经被截断了。解决思路是把关键状态独立出来，不要让它留在对话历史里等模型自己记住。
我们在会话初始化时会生成一个精简的状态对象，里面包含桌号、人数、忌口、下单进度，每次对话结束和工具调用后都刷新这个状态，并注入到下一个请求的头部。这样就算历史被压缩，核心信息也不会丢。另外要定期压缩历史，比如“用户已确认下单，停止推荐菜品”这种已经完成的任务信息，可以直接从上下文里摘除，降低噪音。
4.3 高峰期的响应延迟怎么压
顾客在点餐界面等着回复，Agent如果3秒不出结果，体验就崩了。Agent每次回复要经过模型推理加工具调用，往返一次常常要一两秒，如果需要多轮工具调用，可能直接超过5秒。高峰期并发上来，排队还得再加时间。
我压延迟的办法有三个。第一是并行工具调用，能同时查的就同时查，比如“查询菜品库存”和“查询制作时长”完全没有依赖，同时发出去，能省大半轮时间。第二是缓存，菜单和菜品时长这类相对静态的数据，单独做一层缓存，不每次都走实时接口。第三是降级方案，高峰期如果模型服务响应变慢，我们有规则让Agent直接使用预设菜单推荐，不再实时推理。顾客感知不到后台换了引擎，但响应时间会稳定下来。
这里有个反直觉的经验：不要一味追求任务全自动。当判断时间紧迫时，Agent可以直接走最简流程，甚至先给顾客一个初步回复“这道菜制作需要12分钟，您可以先下单，我们同步确认食材”，然后再在后台慢慢异步确认。让顾客等着Agent把活干完，是最差劲的设计。
4.4 安全边界与人工兜底
餐饮行业的Agent处理的数据看起来没有金融行业那么敏感，但安全隐患一点都不少。顾客地址、手机号、会员偏好是隐私数据；采购单价、供应商信息是商业数据；经营流水更是核心机密。一开始团队图方便，让Agent直接在对话历史里传递这些数据，后来发现日志里全是敏感信息，这肯定不行。
我最后的做法是敏感信息脱敏后再进入上下文，需要时通过工具里的授权接口去取。比如Agent要处理投诉时，不直接把顾客电话丢给它，而是让Agent读取脱敏后的“顾客姓氏+订单号”。需要真实联系方式时才调用专用工具，并且这个工具只在工单流程中允许调用，调用记录全部留痕。
人工兜底要设计成流程的一部分，不能是出了事才想起来的临时动作。所有高风险操作，比如食品卫生投诉的处理、批量订单的主动取消、超过一定金额的退款建议，都必须进入人工队列，等待负责人确认。Agent可以在这些事件里写建议、列依据、推证据，但绝对不可以自行按下确认按钮。
提示：这个“绝对不可以”不是对Agent能力的不信任，而是对责任边界的清晰划分。AI可以辅助判断，但经营决策的最终责任永远属于人。
我在实际项目里反思最深的一点是：AI Agent在餐饮落地的过程，其实是一个重新梳理业务流程的过程。原来靠人肉传话、靠经验拍板的环节，被迫变得结构化、透明化、可追踪，这个过程中的产出可能比Agent本身更有价值。从最小场景起步，把评价分析做成闭环，再一步步向库存、调度这些核心环节渗透，每一步都要留出足够的人工反馈通道。我自己踩过几次坑之后得出的结论是：别指望Agent一步到位，也别因为初期效果不明显就放弃，它一定会越用越顺手。
