1. 项目要解决的问题与核心价值周一早上八点食堂管理员老张打开手机一条推送已经躺在对话框里下周的七天菜单排好了每天两荤两素一汤一点心附带每顿的热量、蛋白质数据还有一张按供应商报价算好的采购清单。老张只需要扫一眼把个别菜品换掉点个确认整个流程就算结束了。放在以前这事他得花一个下午翻聊天记录、查库存、问厨师、再想想上周吃过啥动不动还得被员工吐槽怎么又是这几个菜。这个变化背后不是什么神秘系统而是一个跑在食堂业务里的AI Agent智能体。它做的事听起来简单——把下周吃什么这个决策自动排出来——但真正落地的时候牵涉到的技术点远比想象中多大模型怎么跟结构化约束结合、菜谱知识库怎么设计、营养和成本怎么算才算数、反馈怎么回流到下一周的生成里。这篇文章就把我从0到1做这个食堂膳食决策智能体的完整思路、架构、踩坑过程都复盘一遍。如果你正好在管食堂、做后勤系统或者你想把AI Agent真正用到一个传统业务场景里而不是停留在聊天机器人层面这篇内容应该能给你不少可以抄作业的东西。1.1 真实痛点排菜这件事到底难在哪先别急着上技术我把排菜的难点拆开说你才能理解为什么这个场景值得做。第一这是典型的多约束决策问题。一份食堂周菜单要考虑荤素搭配、营养均衡热量、蛋白质、脂肪、碳水要控制成本每天预算区间要照顾时令食材冬天不能老用夏天菜还要避开重复同一个菜这周不能出现两次最好是两周内不重样。同时不同人群还有特殊需求——糖尿病餐、减脂餐、过敏源回避。这些条件互相纠缠人工排菜很容易顾此失彼。第二人的记忆和精力是有限的。一个100人的小食堂每周大概要排20道菜一个月就是80道。管理员要记住上上周三吃过红烧肉本来就不容易再加上临时供应商说某种菜缺货、突然来了十几个加班员工要加餐整个菜谱就得推翻重来。我见过很多食堂管理员的排菜方式其实就是手机备忘录脑子记问厨师根本没有系统化。第三反馈是滞后的。排菜好不好只能等员工打完饭、看到剩菜多少才知道。但这时候下周菜单往往已经排完了经验无法及时沉淀。时间一长管理员只能靠感觉判断大家爱吃什么排出来的菜越来越保守员工越来越没胃口。1.2 这个项目到底做了什么我做的这个系统本质上是把排菜—采购—反馈这个闭环交给AI来转。具体分成几步需求输入。把食堂的基础信息喂给系统——人数、餐标、是否有特殊人群、预算区间、后厨设备和人力、供应商报价单。这些不需要管理员手写从现有报单和系统中同步即可。菜谱生成。AI基于约束条件生成下周完整菜单包含菜品名称、主料配料、烹饪方式、营养估算、成本估算。校验与修订。菜单不是AI说了就算系统会逐项检查营养是否达标、成本有没有超、菜品是否在白名单里、有没有重复不合格的地方打回重排直到满足或触发人工介入。输出与执行。生成结果直接转换成采购清单、后厨备餐提示甚至能联动供应商下单接口管理员只需要确认。反馈沉淀。员工打菜的残食率、售罄时间、线上评价都会流回系统成为下一周生成菜谱的权重因子——某道菜剩得多下次就降低权重甚至直接降频。[这个项目的价值不是让AI替代管理员而是把管理员从绞尽脑汁想菜谱的重复劳动里解放出来变成一个审核者和决策者。]2. 整体架构设计与方案选型确定了要做什么接下来是核心问题技术上怎么落地我先说结论——这不是套个大模型写提示词那么简单而是一个需要把大模型、规则引擎、知识库、数据反馈串起来的小型工程。2.1 为什么不能用一个聊天机器人搞定很多人第一反应是我直接把食堂数据丢给ChatGPT让它生成菜单不就完了吗我刚开始也这么试过结果发现有三个硬伤。第一无约束生成等于瞎排。你让大模型排个一周菜单它确实能排但它不知道你的食堂有40个餐标不知道厨师只有两口炒锅不知道青椒这几天进价涨了。排出来的东西好看但执行不了。第二大模型不会算数。让它算每道菜的蛋白质含量和总成本它经常编数字。营养数据不是靠模型感觉出来的必须查结构化数据库。成本也是一样价格每天变模型不可能知道实时报价。第三没有闭环就等于一次性的范文。AI排完这周就完了从不关心这周的菜剩了多少、大家爱不爱吃。没有反馈生成的菜单永远是拍脑袋。所以这个系统的核心设计原则是大模型负责编排和组合算数和校验交给程序反馈流入数据。大模型只在它擅长的地方发力——理解约束、组合菜品、生成自然语言描述、做灵活的计划调整。2.2 五层架构拆解整个系统的架构我按层次拆成五块每一块都相对独立方便后续替换和升级。数据底座层。这部分是最重的没有好的数据AI就是无源之水。包括三类菜谱知识库包含食材、营养、做法、成本、季节属性、食堂业务数据人数、餐标、特殊人群、后厨配置、供应商价格、历史反馈数据历次菜单、残食率、点击率、人工修改记录。Agent决策层。这是核心由主Agent和若干子Agent组成。主Agent负责理解本周约束条件拆解任务调度子Agent子Agent分角色干活——营养师Agent检查均衡性成本Agent评估预算口味Agent参考偏好反馈主厨Agent判断菜品在现有设备条件下是否可做。这其实就是多Agent协作的一种落地。执行输出层。把生成结果转换成下游可用的东西包括菜单表、采购清单、营养报告、后厨温馨提示。这一步尽量做成结构化数据方便对接已有的食堂管理系统。反馈沉淀层。把残食率、售罄时间、品名评价、管理员修改记录全部收集起来清洗后写回数据底座形成闭环。管理界面层。给管理员一个简单的后台用于查看AI生成的菜谱、修改个别项、设置约束条件、标注特殊事件比如下周有团建不加餐。2.3 模型选型要点模型是Agent的大脑我当时的选型标准有三条第一中文菜谱生成能力要好能理解清淡下饭少辣蒸菜多些这类口语化指令。我先后对比了几款主流大模型最终选了国产开源底座作为主力——在私有化部署和中文理解上平衡得比较好同时用另一款闭源API做对照测试。第二结构化输出能力要强。我需要模型稳定输出JSON格式的菜单数据菜名、分类、克重、烹饪方式等而不是一堆散文。模型如果经常把JSON输出断掉或者乱加字段后面解析校验全是坑。实测下来主流的几款大模型都有这个能力就是稳定性有差异建议做一个批量JSON解析率测试再定。第三部署成本和稳定性。食堂数据虽然敏感度不算高但食堂管理系统普遍在内网运行直接调用外网API在很多单位会遇到审批问题。所以我的方案是内网部署一个开源底座当作主力外网API作为备选。两者功能一致只是部署位置不同。我还考虑过用微调Fine-tuning——拿历史菜谱数据去微调模型让它更懂本食堂的排菜习惯。但后来放弃了原因是菜谱库和食堂偏好数据量太小变化太快微调不划算。今天换了一个供应商明天加了一个特殊餐窗口微调模型跟不上。相比之下RAG检索增强生成更合适——把菜谱和偏好规则放在外部知识库里随时增删改模型每次生成时动态检索引用。[这里给个经验如果你也要做类似的Agent应用尽量优先RAG而不是微调尤其是业务规则频繁变化的时候。RAG的维护成本远低于重新训练而且还能溯源——管理你能查到这个菜谱是哪条知识记录引出来的。]3. 核心功能的实现细节架构搭好了接下来是让Agent真正干活的核心实现。这部分我讲几个关键环节每个环节都踩过坑我会把过程原原本本写出来。3.1 菜谱知识库怎么建才扛用菜谱库是整个系统最大的地基。我一开始很天真以为把网上公开的几千道家常菜导入数据库就行。真正用起来才发现网上的菜谱数据太野了——有的菜名叫法五花八门同一道菜叫地三鲜也叫烧茄子土豆有的根本没标注食材克重和营养数据。后来我把菜谱库的字段重新设计了一遍每一个菜品都包含这些信息{ dish_id: D10241, name: 西红柿炒鸡蛋, alias: [番茄炒蛋], category: 热菜/素菜, main_ingredients: [ {name: 西红柿, amount_g: 200}, {name: 鸡蛋, amount_g: 100} ], season: [春, 夏, 秋], flavor: 咸鲜, spicy_level: 0, cooking_method: 炒, cooking_time_min: 10, required_equipment: [炒锅], nutrition: { calories_kcal: 180, protein_g: 8.5, fat_g: 12, carbs_g: 10 }, estimated_cost_yuan: 3.2, preference_score: 0.0, allergens: [鸡蛋] }有几个字段需要注意克重必须明确。光写西红柿不够得写西红柿200克。因为营养计算和成本核算都依赖克重没有克重就是拍脑袋。季节属性要标。这决定了AI会不会在冬天给你排一堆凉菜。我按食材的应季月份做了标注冬季默认降低凉菜权重。过敏原必须单独列。食堂里有人对花生、海鲜过敏这在生成菜谱时候就要避开而不是等到员工吃了才出问题。成本不是固定值。菜谱库里的estimated_cost_yuan只是基础参考真正计算成本的时候系统会去查当天的供应商报价替换掉菜谱里的默认值。所以我把成本拆成菜谱参考成本和实时计算成本两层。菜谱数据来源方面我整理了三个渠道一是食堂过去两年的历史菜单和采购记录这是最贴合本单位的金矿二是公开的菜谱网站和营养学参考数据做基础扩充三是管理员和厨师手写的常用菜清单这些人脑里的土方子往往最受欢迎。3.2 约束条件怎么编码给AI食堂排菜的核心难点是所有约束条件要同时满足而且它们之间经常打架。我的做法是把约束条件全部转换成结构化参数喂给Agent而不是让AI自己在自然语言里猜。下面是我实际用的一个约束配置示例{ week: 2025-W12, meal_days: [周一, 周二, 周三, 周四, 周五], meal_structure: { lunch: {main_dishes: 2, side_dishes: 2, soup: 1, staple: 1} }, daily_budget: {min_yuan: 6.5, max_yuan: 9.0}, nutrition_standard: { lunch_calories: [700, 900], protein_g: [30, 50], fat_g: [20, 40] }, avoid_repeat_days: 3, avoid_repeat_weeks: 2, special_requirements: { low_sugar_dishes_per_day: 1, low_spicy_dishes_per_day: 3, allergen_exclude: [花生, 海鲜] }, preferred_flavors: [咸鲜, 酸辣, 清淡], local_style: 本帮菜偏甜, unavailable_ingredients: [青椒, 带鱼] }这个JSON就是Agent每周接收到的任务书。它明确了一共排5天每天两荤两素一汤每人每餐成本在6块5到9块之间午餐热量700到900千卡蛋白质30到50克同一个菜3天内不重复、2周内尽量不重复每天必须有低糖菜至少3个不辣的菜避开花生和海鲜偏好口味是咸鲜、酸辣、清淡单位在本地菜系偏本帮甜口本周青椒和带鱼缺货。这套配置跑通之后AI生成菜谱的可执行性一下子高了很多。关键思路是约束越明确幻觉和意外越少你想让AI不犯错就得先把规则喂清楚。3.3 生成—校验—修订的循环机制菜谱生成不是一次生成就完事而是跑一个循环。我把每一步都记录日志方便排查AI到底怎么做出的决定。第一步草稿生成。主Agent读取约束配置从菜谱知识库检索符合条件的菜品生成一周菜单草稿。这一步模型自由度最大我会在提示词里明确要求优先选择知识库里已有的菜不要自创菜名。第二步结构化校验。草稿出来后不直接给管理员看先进校验器。校验器是一套纯规则代码不经过大模型包括菜名白名单校验。每个生成的菜名必须在菜谱知识库里能找到搜不到就标红剔除。这一步专门防大模型编造菜品——AI偶尔会生成一个听起来很好吃但根本不存在的菜。营养校验。根据菜谱库里的营养字段按克重累加每顿饭的总热量和营养素看是否落在约束区间内。成本校验。用最新的供应商报价重新计算每个菜的成本再累计全天总成本。重复度校验。把本周已生成的菜和近两周的菜单做文本相似度比对重复的踢出去。可行性与禁忌校验。比如后厨没有蒸箱蒸菜就不能排缺货清单里的食材一旦出现就替换。第三步修订重排。校验器把不合格项打回给主Agent附上具体原因西红柿炒鸡蛋成本超出预算0.6元、这道菜与上周三重复让AI重新生成替换方案。系统设定最大重试次数我默认设5次。第四步保底策略。如果重试满5次仍然无法满足全部约束系统不会无限循环而是采用模板兜底在历史最受欢迎的菜单模板上仅替换其中2到3个菜品生成一版可接受但有瑕疵的菜单同时标记需要管理员介入通知管理员人工微调。这个保底机制非常重要它保证了系统在极端情况下也不会空转。3.4 多Agent协作到底怎么协作前面提过我用了多Agent架构。这里说说具体怎么协作因为我发现很多项目落地时在这里容易乱套。我的设计是一个主Agent 四个子Agent主Agent不直接参与具体决策而是做任务编排主Agent读取任务书拆解子任务先让营养师Agent对本周结构做初步建议再让主厨Agent根据后厨条件筛选候选菜接着让成本Agent按报价做预算分配最后让口味Agent参考历史偏好打分。营养师Agent输出的是约束性建议比如周三晚餐需要增加一道高蛋白菜因为当天有篮球赛活动。主厨Agent输出的是可行性判断比如蒸鱼可以但是后厨只有一台蒸箱不能同时排三道蒸菜。成本Agent输出的是成本分配方案比如周一预算偏紧建议主荤控制单价在8元以内。这4个子Agent各自的输出汇总到主Agent主Agent生成完整菜单再交给校验器跑一遍规则校验。这里有个很重要的实践心得子Agent不要直接给主Agent决策结果要给建议依据。比如成本Agent的职责是提示超预算风险而不是直接说必须换成麻婆豆腐。因为最终决策权要留给主Agent做全局权衡否则几个子Agent之间容易产生冲突指令主Agent反而无所适从。4. 实操过程复盘从原型到可用系统理论讲了一堆这块说说我是怎么实际把它从零搭起来的方便你跟着复现。4.1 落地实施分几步走我按照六步走每一步都有明确的交付物和验证标准。第一步数据清洗与入库。先把食堂过去一年的历史菜单和采购记录翻出来整理成结构化表格再补充菜品的营养数据和季节属性。这一步占我总工作量的40%——数据质量决定了整个系统的上限务必耐心清理。第二步搭一个最小原型。不接任何系统直接用Jupyter Notebook调用大模型API喂一份模拟的约束配置看AI能不能生成一份像样的菜单。这一步验证的是大模型菜谱库的基本可行性。第三步加入校验器和保底机制。把白名单、营养、成本、重复度校验用代码跑起来和模型生成串联成循环。这一步验证生成—校验—修订闭环是否稳定重点观察重试次数。我当时的优化目标是把平均重试次数压到2次以内。第四步对接食堂管理系统。把输出的菜单转成食堂管理系统能导入的Excel/JSON格式让管理员可以在原有系统里直接看到结果。这一步打通后才真正进得了日常使用。第五步灰度试运行。先只在其中一个食堂跑两周管理员全程监督任何AI生成的菜单都保留人工修改痕迹并记录修改原因。两周后根据修改记录调优约束配置和提示词。第六步上线与反馈接入。跑通之后再把员工评价、残食率等反馈数据接进来让AI生成的菜谱逐步有记忆。4.2 关键的提示词长什么样我给主Agent写的提示词模板大概是这样的去掉模型名称通用写法你是一名经验丰富的食堂营养师和菜单规划师。请根据以下约束条件生成一周午餐菜单。 要求只能使用提供的菜谱库中的菜品不得自创菜名每天两荤两素一汤注意荤素搭配、颜色搭配、烹饪方式多样化避免三天内重复菜品尽量参考近两周的偏好数据。 约束条件如下 {constraints_json} 菜谱库检索结果如下 {retrieved_dishes} 请以JSON格式输出字段包括day、category、dish_name、dish_id、reason。 reason字段请简要说明为什么选择这个菜例如高蛋白、成本适中。这里两个细节很关键一是**理由字段**让模型输出每个选择的原因。这不仅是给管理员看的更方便开发者在排查时理解模型到底在想什么。二是**菜谱库检索结果**这是动态填入的由RAG根据本周约束从菜谱库检索候选菜。模型只能在检索结果里选不允许自己凭空创造——这就从源头上堵住了幻觉。4.3 试运行中的三个重要发现灰度试运行那两周我发现了很多纸上谈兵看不出的问题挑三个最典型的说。第一个发现管理员最想要的是能不能直接变成采购清单。AI排出来的菜单是给管理员看的文本但管理员真正要的是能交给采购的清单——供应商、数量、价格、到货日期。所以我把输出层改成直接生成采购清单格式菜单只是中间产物。这让我意识到AI落地最大的阻力往往不是技术而是产出物跟用户的日常工作流不匹配。第二个发现AI生成偏安全但缺少特色。大模型倾向于选择大众熟知的做法比如番茄炒蛋、青椒肉丝、紫菜蛋花汤确实稳妥但员工很快会觉得怎么天天就这些。我后来在约束配置里加了一个特色菜机制每周强制排入2道本地风味菜或创新菜从菜谱库的创新推荐分类里选口味Agent会给这2道菜额外加权就算验证期内残食率高一点也接受先在新鲜感上做突破。第三个发现没有一键修改界面管理员根本不想用。最开始我让管理员在Excel里改AI生成的菜单结果一个多星期没人愿意打开。后来我专门做了一个非常简单的后台——就是把AI生成的菜单以卡片形式展示出来每条后面跟一个下拉框可以做替换旁边是菜谱库里适合替换的候选菜。管理员三秒就能改好一个菜。工具再聪明如果交互不符合用户习惯也是白搭。5. 上线后的常见问题与排查技巧实录系统跑起来之后问题并没有消失只是换了一波新问题。我把实际遇到的最典型的几个问题整理成速查表附带排查思路和针对性解决手段。问题现象根因解决方案幻觉菜品出现香菜炒火龙果这类知识库里不存在的菜模型不受控地自由发挥白名单校验生成后强制映射知识库standard name不在库则剔除重排营养数据离谱某天蛋白质含量高达90克明显超标大模型心算营养值而不是查库营养值全部从结构化数据计算模型不做任何数值计算只做菜品选择成本反复超支连续几天成本超预算10%以上菜谱成本用默认值而不是实时报价接入最新采购报价成本Agent做预算分配先分每天额度再选菜重复率仍然偏高一周内出现宫保鸡丁和辣子鸡丁两种相近菜文本完全匹配检测不出近似菜引入菜名语义相似度校验同主料且同做法的菜视为重复员工反馈没新意虽然不重复但全是熟悉的大众菜模型在约束中自选安全路径每周强制2道特色菜/创新菜并加权初期允许残食率稍高高峰期生成慢多个食堂同时请求单个菜单生成耗时过长Agent串行执行子任务导致阻塞改为预生成异步审批模式每个食堂单独跑定时任务避开集中请求管理员改完又丢失人工修改的菜被AI下一次自动覆盖缺少人工修改记录沉淀人工修改直接写入历史偏好库作为下周生成的参考权重5.1 让AI学会算账的秘诀这一条我单独拎出来讲因为踩的坑最深。刚开始我天真地想让模型直接输出每道菜的成本和热量结果10次里有6次的数字是错的——而且错得很自然不是那种一眼看出来的离谱而是看起来差不多但实际对不上。这种数字是隐性隐患管理员照着采购可能会出事。解决办法让模型彻底告别计算器角色。模型只做两件事选菜、写理由。选完菜之后程序自动从菜谱知识库调营养数据、从供应商报价表调实时价格再用统一的公式累加。也就是说模型输出的是菜名和克重算数是代码的事。菜品如果换了克重程序会按新的克重重新计算营养和成本不需要模型参与。这套设计跑通之后营养和成本的准确率直接到了100%——因为本质上是查表不是计算。这也是整个项目里我认为最重要的一条经验。5.2 反馈闭环的调试心得反馈闭环做起来比想象中复杂主要难在怎么定义好吃。残食率并不是完美的指标——有时候是因为菜量打多了不是因为不好吃有时候大家觉得某道菜味道不错但因为有骨头吐起来麻烦所以剩得多。如果直接用残食率做升降权会得出很多反直觉的结论。最后我采用的是多信号加权机制残食率只占50%权重另外50%来自员工的主动反馈——比如食堂点餐小程序里喜欢/不喜欢按钮、线上评价关键词情感分析以及管理员的人工判断管理员通过走访能知道剩菜是因为分量大还是口味差。每个信号独立清洗再合成一个综合偏好分写回菜谱库的preference_score字段。下周围绕这个分数对菜品做升降权效果比单看残食率可靠很多。提示反馈信号越多元越不容易被单一指标的噪声带偏。如果只能接一种数据我建议优先接线上评价情感分析因为它的信息量比残食率大很多。6. 最后再分享几点实在的经验项目做完之后我最大的体会是AI进食堂这件事难度不在AI而在能不能把食堂的真实约束翻译成AI能理解的结构化语言。那些看似玄乎的Agent、大模型、多模态概念落到食堂这个场景里本质上就是把约束写清楚、把知识库存好、把校验闭环跑稳、把反馈喂回来这四件事。如果你也想在自己单位做类似的尝试我建议你千万别一步到位追求全自动。先从半自动开始——AI负责生成几套候选菜谱人来做最终选择。哪怕AI只帮你把下周吃什么从空白文档变成三个可选项已经比从零开始强十倍。等跑顺了再逐步增加校验、增加反馈、增加自动采购。我实际运营中发现管理员并没有因为AI的存在而没事干反而把精力花在了更有价值的地方——去后厨盯出品质量、去员工中间收集意见、去跟供应商谈判。工具替人思人才有时间做真正需要人的事。这个系统后续还能扩展的方向也挺多跟智能点餐机联动根据当天备餐量反推采购量降低损耗跟炒菜机器人对接把AI排好的菜单直接变成机器可执行的烹饪参数再往后还可以按每个员工的健康数据做个性化推荐。AI在食堂的想象力远不止下周吃什么这一件事。