1. 项目背景与需求拆解1.1 九添菜菜的原始痛点说句实在话刚接到“服范”这个项目时团队内部其实吵过一轮。原因很简单九添菜菜是一家快速扩张的连锁餐饮品牌日均订单量上去了但门店客服和点餐引导的人力完全跟不上。消费者的需求很琐碎比如“今天有没有不辣的套餐”、“下午三点还能不能用下午茶券”、“孩子生日想订个小包间”这些事听起来简单但要靠人轮班盯消息成本很高。我们把项目代号起成“服范”意思是服务范式想做的不是又一个聊天机器人而是一套真正能接到业务流程里的AI智能体。这里有个关键区别传统对话机器人是根据关键词匹配答案用户话说得稍微绕一点就废掉而大模型Agent智能体有理解、有规划、能调用工具它能把一个模糊需求拆成几步然后完成这里的操作比如查库存、算优惠、锁座位。项目启动时我们定的目标很收敛先不碰供应链预测这种高难度的事只做顾客侧高频场景点餐推荐、优惠查询、售后问答、订座信息录入。这样既能让Agent立刻产生业务价值又不会因为一开始铺得太大导致烂尾。1.2 为什么这个场景必须上大模型Agent可能有人会问门店点餐用小程序点就行了为什么还要一个Agent我当时的判断是小程序菜单是“人找功能”的设计顾客得自己翻半天而Agent是“功能找人”顾客只要用自然语言说出意图它就能完成整个操作流程。这个体验差异在高峰期特别明显。更深一层的原因是需求里包含了大量动态变量。比如顾客说“两个人吃饭预算一百五最好有个辣菜”传统系统需要三五个下拉框去筛选而Agent只需要把这句话解析成结构化条件人数2、预算150、口味偏好辣然后动态查菜单、计算推荐组合。再比如顾客问“上次那个牛肉券现在还能用吗”这涉及订单记录、优惠券状态、有效期三个数据源普通规则脚本很难穷举所有说法但Agent可以把问题拆成身份确认、券状态查询、规则校验三个动作。也就是说我们需要的不只是“能回答”而是“能把事情办完”。这正是大模型Agent智能体相比单轮问答的核心优势它把语言理解、任务规划、工具调用串在了一起。1.3 功能边界与预期效果为了避免项目失控我们给“服范”划了一条很明确的边界只做能“用系统动作闭环”的事情不能闭环的宁可先不做。比如推荐菜品最终要落到下单链接查优惠最终要落到优惠券可用状态订座最终要落到座位锁定。凡是需要店长人工确认的问题Agent只做信息收集和工单转交不承诺结果。预期效果也定得比较务实人工客服的重复性咨询量要减少百分之六十以上点餐转化率不要求立刻暴增但顾客咨询到完成下单的时间不能比原来手动浏览菜单更久。上线后我们再做数据复盘发现Agent平均一次会话能触发二到三次工具调用真实解决了问题而不只是陪聊。2. 技术选型模型、框架与集成形态2.1 大模型选型的关键决策点现在市面上知名的大模型很多从闭源API到开源权重都有但选型不能只看榜单分数得看真实业务场景里的表现。我当时的筛选维度有三条指令遵循能力、工具调用稳定性、单位成本。指令遵循能力决定Agent会不会“自作主张”。比如我们要求模型只能基于工具返回结果回答库存不能凭空捏造有的模型在简单对话里表现很好但一进到多轮工具调用就乱了开始编造“系统显示有货”。工具调用稳定性更重要它决定函数参数能不能正确抽取。我们踩过不少模型的坑表面支持function calling但一旦用户表达里有省略、指代参数就抽不齐。最终我们选了DeepSeek作为主力模型把通义千问和智谱GLM作为备用切换。选DeepSeek不是因为它在某个公开榜单上分数最高而是它在中文口语化表达、工具调用格式、费用三点上取得了平衡。如果预算充足我也建议企业客户试试更大参数的旗舰模型但在餐饮这种高频低客单场景成本是必须算的账。这里还要聊一下本地部署和GGUF端侧方案。我们一度想用Ollama部署开源模型把数据完全留在内网但跑了几个7B和14B的量化模型后发现单轮问答勉强能用一旦牵扯复杂工具调用和多轮记忆效果明显下滑。所以最后的方案是核心Agent走云端API门店本地只部署一个轻量版意图识别模型做第一道分流把简单问题直接答掉复杂问题再交给大模型Agent。这个混合架构省了不少成本后面会细说。2.2 自研轻量框架还是直接套Dify做Agent开发第一种思路是直接用Coze、Dify这类智能体平台拖拽编排见效快第二种思路是从LangGraph、LangChain这类开源框架起步自己掌控流程第三种是干脆自己写一个极简的Agent调度核心。我们最后选择了第三种为主、参考第二种思路但刻意控制了依赖。原因在于项目要深入集成餐饮业务的私有系统包括菜单数据库、订单系统、优惠券系统、订座系统。这些系统之间有大量定制化规则比如“生日券和新人券能不能叠加”这种判断放在通用平台里特别别扭。我们用Dify做过一个小型PoC做问答可以但要精确控制每个工具的执行顺序、回滚逻辑、并发策略时平台反而成了阻碍。所以“服范”现在的Agent内核其实只有三个部分模型接口适配层、工具注册与调度层、上下文管理模块。这个设计参考了LangChain的Tool架构但代码量少得多调试起来也直观得多。对大部分中小团队来说我建议不要一上来就上重型框架先理解Agent从模型调用到工具执行的本质再决定要引入多少抽象。2.3 服务形态后端API、H5和浏览器插件产品形态是另一个战略决策。最开始有人提出来要做独立App但我们问了自己一个问题顾客凭什么为了点餐专门装一个App答案是不能。所以最终形态是三条线并行后端提供一套RESTful API供门店平板上的H5页面调用顾客扫码进入对话式点餐界面。运营人员需要一个批量配置菜品和查看对话记录的界面这个界面不能只给开发用于是顺手做了一个轻量管理后台。运营团队在电脑上经常需要查顾客反馈我们把Agent能力封装成一个浏览器插件选中一段聊天记录就能一键提取顾客情绪、问题分类和工单摘要。这个浏览器插件算是意外亮点本来只是为了内部提效后来发现对Agent的评测也有用我们可以在插件里快速改写测试用例发给模型跑批量回归。这件事说明Agent开发不只是写后端逻辑交付形态想清楚了使用频率才会高。3. 开发实战从零搭起一个可用的Agent3.1 提示词工程角色设定比想象中重要所有Agent都始于一段提示词但我们最初的提示词写得像岗位说明书堆了很多功能描述结果模型行为很僵硬。后来我总结出一条经验提示词里要区分“身份定义”、“任务场景”、“工作流程”、“硬性约束”四层。我给你们看一个删减过的实际模板你是九添菜菜的点餐助手名字叫菜菜。 你的任务是帮助顾客完成点餐、优惠查询、订座登记。 工作流程 1. 先识别顾客意图判断是否在服务范围内。 2. 如果需要查询菜单或库存必须调用menu_query工具。 3. 如果顾客提到优惠券必须调用coupon_query工具。 4. 最终回答必须包含菜品名称、价格和可下单方式。 硬性约束 - 不编造菜单中不存在的菜品。 - 不回答与点餐无关的问题。 - 每次回答控制在80字以内适合手机屏幕阅读。这里最关键的其实是“不编造菜单中不存在的菜品”一句简单约束能避免Agent在幻觉问题上失控。我们还试过在提示词里加入两三个少样本示例比如顾客说“上次吃的那个鸡肉套餐还有吗”期望输出先调用订单查询再调用菜单查询。加了示例后工具调用准确率明显提高。另有几个提示词细节值得说。一是温度参数要调低我们设置在0.2到0.3之间保证输出稳定二是要给模型“承认能力不足”的退路当工具查询失败时必须说“这个信息我需要再确认”而不是强行编一个答案三是不要让提示词过于死板允许模型用自然口语跟顾客交流否则回答会像机器人念说明书转化率并不好。3.2 工具调用让Agent真正能动手Agent和普通聊天机器人拉开差距的地方就是工具调用。这个环节的原理是我们把每个业务动作定义成一个函数并附上JSON Schema描述模型看到用户问题后会决定调用哪个函数、传什么参数。然后我们再执行函数、把真实结果返回给模型模型基于结果生成最终回复。这里给一段简化后的Python示例方便理解核心循环while True: response llm.chat(messages, toolsTOOLS) if response.tool_calls: tool_result execute_tool(response.tool_calls) messages.append(tool_result) continue else: return response.content代码看起来简单但实际开发里有三个容易翻车的地方。第一工具描述必须写清楚“什么时候不该调用”比如顾客问“营业时间”没有必要调用菜品查询工具描述里可以加一条“仅当需要查询菜品库存或价格时调用”。第二函数参数要设计成宽松类型比如价格区间用字符串来接收模型输出的“一百五十左右”比直接要求浮点数更抗错然后再在后端解析。第三所有工具都必须有超时和异常返回不能让Agent一直等一个失败接口。我们把工具分成了两类查询型工具和数据变更型工具。查询型工具幂等随便调数据变更型比如创建订座、提交订单必须增加用户确认环节。这是Agent设计里的红线不能因为模型判断“可以下单”就直接下单得把最终确认权留给用户。3.3 上下文管理与短期记忆大模型API本身没有记忆每次调用都是独立状态所以上下文管理就是Agent的记忆系统。一开始我们图省事把整个对话历史一股脑全传给模型结果很快撞到上下文窗口上限而且历史越长模型越容易把早期信息搞混回答变得飘忽。后来我们做了三层策略滑动窗口只保留最近八到十轮对话。餐饮点餐场景里顾客讨论到第三四个菜时第一轮提到的偏好基本已经沉淀到结构化信息里了不需要重复保留原文。关键信息提取每轮对话结束后用一个轻量模型把“人数、时间、菜品、预算、座位要求”抽取成结构化槽位槽位一直保留原始对话可以丢。这样即使聊了半小时模型也能记住顾客最初说“不能吃辣”。摘要记忆当对话超过一定轮次把前面的历史用模型生成一段摘要代替全部原文。这招对长会话特别好用但要注意摘要里不能丢工具调用的结果至少要把已验证的菜品名和订单号记录下来。有人问我要不要上向量数据库做长期记忆我的回答是看场景。如果顾客半年后回来还能记住偏好那确实需要长期记忆但如果只是单次点餐短期记忆用滑动窗口加槽位就够了。我们目前只在会员画像模块里用了向量检索把顾客历史订单的文本特征存起来供推荐系统使用这部分属于后期迭代。3.4 流程编排单Agent还是多Agent“服范”早期用的是单Agent一把梭所有工具都注册给同一个模型结果模型经常选错工具。后来我们把工具分组采用了一个类似路由加子Agent的结构主Agent负责意图识别和对话管理它本身不直接调用所有工具而是把任务路由给三个子Agent。点餐Agent负责菜品推荐、菜单查询、下单。客服Agent负责售后问题、退款流程。订座Agent负责座位查询、包间预订。这样做的好处是每个子Agent的提示词和工具列表短而聚焦模型选错的概率大幅下降。坏处是增加了调用次数和复杂度调试时得多看一层日志。所以我们没有盲目追多Agent而是只做了必要的拆分目前线上跑的其实是“主Agent 点餐/客服两个子Agent”订座场景直接内联在主Agent流程里。我们借鉴了现在行业里常说的Agent设计模式包括规划、记忆、工具使用、反思。反思这个环节我们做得比较轻每当工具调用失败一次会在下一轮给模型补一句“上次查询失败了请换一种方式询问用户是否需要重试”这样能避免Agent一条路走到黑。更多重的自我反思对餐饮场景太重了试过之后发现延迟太明显。4. 部署上线与性能优化4.1 服务架构与接口设计“服范”的后端服务没有用什么复杂微服务就是一个Flask应用配了两个Worker进程。为什么选Flask因为团队里最快能把项目跑起来的语言就是PythonFlask的轻量特性足够应对我们的并发量。初期预估单店每个小时最多几十个并发会话所有门店加起来也就在千级QPS下沿用不着上Go或Java。接口设计遵循了一个原则对前端暴露的是“任务式接口”而不是“模型聊天接口”。也就是说前端只调用/agent/chat后端内部自己处理工具调用循环、上下文拼装和状态存储。这样前端不需要关心模型是什么也不需要在浏览器里暴露API Key。返回格式统一是SSE流式输出顾客那边看到的是一个字一个字蹦出来的回复体验比等一整段结果好很多。SSE流式输出的实现并不难难点在于工具调用过程中不能断流。我们的做法是第一次流式输出模型说“我帮您查一下”这样的过渡语工具调用完成后再把最终回复继续从同一个SSE连接里推给前端。如果中途遇到工具异常就推一个特殊的tool_error事件前端接收到后显示“稍等一下我再试一次”这比让整段对话失败要温和得多。4.2 并发控制与限流策略Agent类应用和普通接口最大的区别是一个请求内部可能要调用大模型两三次甚至更多每次调用耗时一两秒所以并发很容易就堆起来了。我们做过一次压测二十个并发请求直接把DeepSeek的API速率限制打到顶然后开始出现大量429错误。解决思路是在网关层加分布式限流按门店维度给配额。每家门店一个小时内最多发起两百次Agent会话请求超出后返回提示“当前咨询人数较多请稍后”。这个配额经过了测算一家门店高峰期最多同时几个顾客咨询两百次会话足够覆盖同时又不会因为某个门店异常刷量而拖垮整体预算。另一个经验是给所有大模型调用加本地缓存。比如同一道菜的热量问题顾客可能问一百次答案完全一样。我们直接把这类静态问答结果缓存到Redis里TTL设二十四小时key由“用户问题的语义向量 门店ID”组成。哈希到同一语义的问题直接走缓存不再请求模型成本下降得很明显。4.3 成本控制与降本手段成本是餐饮行业落地AI方案绕不开的话题。我们的做法分三层能不用模型就不用模型门店常见问题比如营业时间、WiFi密码、停车指引直接走传统规则匹配只有规则匹配不到时才进Agent。用小模型做前置路由低价API负责意图分类和关键信息抽取复杂生成和工具调用才交给主力大模型。记录每轮真实Token消耗我们把每次会话的输入输出Token数、工具调用次数都打到日志里月底按门店汇总。这样才能发现有些会话其实一句话就能答完却被Agent走了三四个工具白白烧掉Token。这里有一个容易被忽略的点工具调用的返回内容也会占Token。如果菜品查询工具返回了整个菜单三千字模型就算只取其中一句话这些Token也已经计费了。所以要优化工具返回格式精简字段、只回需要的内容能大幅节省成本。我们的menu_query工具一开始返回全部字段后来改成只返回菜品ID、名称、价格、月销量、是否售罄Token消耗直接少了百分之四五十。5. 踩坑实录与排查技巧5.1 模型指令遵循差问题出在结构化输出项目开发到第三周时我们遇到一个特别诡异的Bug顾客问“有情侣套餐吗”Agent能正常调用查询工具但回答里总是会加一句“建议您到店咨询店员”明明提示词里禁止这类话术。排查了很久最后发现问题不在提示词而在于我们没有把回复格式约束成结构化输出。大模型API在流式输出时模型有时会把一些内部推理碎片也输出出来。后来我们给系统设定了一个强约束所有最终回复必须以JSON格式返回字段包括reply_text和suggested_actions前端解析后只渲染reply_text。这样即使模型想“自由发挥”结构校验也能把它拦下来。实测之后乱回答的比例立刻下降。这个坑的教训是写代码时一定要假设模型是“有能力但会开小差”的实习生不能只靠prompt约束要在输出层做硬性校验。5.2 Agent陷入工具调用死循环上线第二天我们就发现一个线上事故顾客问“你们家的鱼香肉丝多少钱”Agent居然连续调了三次菜单查询工具每次参数都一样最后因为工具循环次数上限才停下来。原因是模型在第一次调用后没有正确对工具结果做判断又重复生成了同样的工具调用。解决办法是在Agent循环里加一个最大轮次限制我们设置为三次工具调用超过后强制停止对话并回复“我这边查询有点慢请您稍后再试”。同时每轮工具调用后会追加一条系统消息“你已经查询过该菜品请直接使用已有结果回答”。这两个改动一起上死循环基本绝迹。另外我们也在日志里加了工具链跟踪每轮调用都记录调用顺序、函数名、耗时和返回结果摘要。这样一旦再遇到类似问题可以快速回放Agent的“思考过程”而不是只看最终回复。5.3 上下文窗口溢出与长短记忆取舍有段时间有顾客投诉聊到十分钟后Agent开始“失忆”连刚才点的菜都忘了。我们检查日志发现上下文窗口已经快满了系统自动把最早的对话丢弃但关键信息也被扔掉了。后来我们把槽位提取逻辑前置了很多只要顾客提到“不要香菜”“五个人”“七点来”这类信息立刻写入会话状态不再依赖原始对话。模型只要读槽位状态就能回答“有没有适合五个人、不放香菜的套餐”。这个改动让长会话的稳定性提升非常明显。如果你的Agent场景更复杂我建议把“记忆”拆成工作记忆和长期记忆工作记忆用结构化槽位长期记忆用向量库而不是把所有内容都塞进模型上下文。系统的健壮性来自清晰的记忆分层而不是一味加大模型窗口。5.4 延迟高到用户流失的排查第一次联调时Agent平均响应时间超过六秒顾客基本等不住流失率很高。我们逐段压测后发现延迟主要来自三块大模型API调用本身两到三秒、工具调用里的数据库查询有几次慢查询、加上前端SSE渲染额外缓冲整体就爆了。针对大模型延迟我们把首字延迟压了进去模型先输出几个字“好的”给用户即时反馈后续内容一边生成一边流式输出。针对慢查询我们给菜单表加了索引热门菜品数据放Redis缓存。针对前端缓冲我们取消了累积一定字数才输出的逻辑改成收到一个token就渲染一个。最终平均响应时间压到三秒以内高峰期也能保持在四秒上下。5.5 高频问题速查表下面这张表是我们整理给后来接手的开发同学用的包含了很多新手容易踩的坑现象常见原因解决方案Agent答非所问提示词中工具描述不清晰细分工具职责增加“何时不该调用”说明工具参数解析错误用户口语表达有歧义参数设计用宽类型后端再做归一化对话越久越不准上下文窗口溢出滑动窗口 关键信息槽位 摘要记忆工具调用重复模型未意识到已查过设置最大工具循环次数追加提示信息回复包含多余内容未限制输出格式强制JSON结构化输出并校验API返回429并发超限门店维度限流 缓存热点问题回答一直延迟多轮工具串行优化工具返回字段启用SSE流式输出模型编造库存缺少硬性约束提示词中禁止无根据回答工具结果为空时要明说排查这些问题时别光看线上表现要建立完善的日志体系把每轮对话的模型请求、工具调用、Token消耗全部记录下来。我看到很多团队Agent效果不稳定就是因为系统像一个黑盒出了问题只能靠猜。5.6 上线后的真实体会与一个小技巧“服范”上线运行一个多月后我最真实的体会是这类项目的难度不在模型而在工程化。模型能力的边界我们控制不了但工具的稳定性、上下文的取舍、提示词的迭代速度都是可以依靠工程手段持续改善的。每优化一个环节用户体验都是肉眼可见地变好。最后再分享一个我们一直在用的小技巧每次修改提示词或工具逻辑之后不要只做手工测试一定要准备一套回归集把过去三个月里顾客问过的疑难问题沉淀成几十条测试用例用脚本批量跑一遍对比新旧版本的工具调用准确率和回答合格率。这套回归集看起来简单但真的能拦住很多“修好一个Bug引出三个Bug”的翻车情况。Agent开发是一场持续迭代的长跑留好自动化测试的种子后面会省下大量时间。 
长河君 · 2026/9/28 9:38:35 · 阅读 1.2k 餐饮业大模型Agent智能体实战：从工具调用到上下文管理的工程化指南
1. 项目背景与需求拆解1.1 九添菜菜的原始痛点说句实在话刚接到“服范”这个项目时团队内部其实吵过一轮。原因很简单九添菜菜是一家快速扩张的连锁餐饮品牌日均订单量上去了但门店客服和点餐引导的人力完全跟不上。消费者的需求很琐碎比如“今天有没有不辣的套餐”、“下午三点还能不能用下午茶券”、“孩子生日想订个小包间”这些事听起来简单但要靠人轮班盯消息成本很高。我们把项目代号起成“服范”意思是服务范式想做的不是又一个聊天机器人而是一套真正能接到业务流程里的AI智能体。这里有个关键区别传统对话机器人是根据关键词匹配答案用户话说得稍微绕一点就废掉而大模型Agent智能体有理解、有规划、能调用工具它能把一个模糊需求拆成几步然后完成这里的操作比如查库存、算优惠、锁座位。项目启动时我们定的目标很收敛先不碰供应链预测这种高难度的事只做顾客侧高频场景点餐推荐、优惠查询、售后问答、订座信息录入。这样既能让Agent立刻产生业务价值又不会因为一开始铺得太大导致烂尾。1.2 为什么这个场景必须上大模型Agent可能有人会问门店点餐用小程序点就行了为什么还要一个Agent我当时的判断是小程序菜单是“人找功能”的设计顾客得自己翻半天而Agent是“功能找人”顾客只要用自然语言说出意图它就能完成整个操作流程。这个体验差异在高峰期特别明显。更深一层的原因是需求里包含了大量动态变量。比如顾客说“两个人吃饭预算一百五最好有个辣菜”传统系统需要三五个下拉框去筛选而Agent只需要把这句话解析成结构化条件人数2、预算150、口味偏好辣然后动态查菜单、计算推荐组合。再比如顾客问“上次那个牛肉券现在还能用吗”这涉及订单记录、优惠券状态、有效期三个数据源普通规则脚本很难穷举所有说法但Agent可以把问题拆成身份确认、券状态查询、规则校验三个动作。也就是说我们需要的不只是“能回答”而是“能把事情办完”。这正是大模型Agent智能体相比单轮问答的核心优势它把语言理解、任务规划、工具调用串在了一起。1.3 功能边界与预期效果为了避免项目失控我们给“服范”划了一条很明确的边界只做能“用系统动作闭环”的事情不能闭环的宁可先不做。比如推荐菜品最终要落到下单链接查优惠最终要落到优惠券可用状态订座最终要落到座位锁定。凡是需要店长人工确认的问题Agent只做信息收集和工单转交不承诺结果。预期效果也定得比较务实人工客服的重复性咨询量要减少百分之六十以上点餐转化率不要求立刻暴增但顾客咨询到完成下单的时间不能比原来手动浏览菜单更久。上线后我们再做数据复盘发现Agent平均一次会话能触发二到三次工具调用真实解决了问题而不只是陪聊。2. 技术选型模型、框架与集成形态2.1 大模型选型的关键决策点现在市面上知名的大模型很多从闭源API到开源权重都有但选型不能只看榜单分数得看真实业务场景里的表现。我当时的筛选维度有三条指令遵循能力、工具调用稳定性、单位成本。指令遵循能力决定Agent会不会“自作主张”。比如我们要求模型只能基于工具返回结果回答库存不能凭空捏造有的模型在简单对话里表现很好但一进到多轮工具调用就乱了开始编造“系统显示有货”。工具调用稳定性更重要它决定函数参数能不能正确抽取。我们踩过不少模型的坑表面支持function calling但一旦用户表达里有省略、指代参数就抽不齐。最终我们选了DeepSeek作为主力模型把通义千问和智谱GLM作为备用切换。选DeepSeek不是因为它在某个公开榜单上分数最高而是它在中文口语化表达、工具调用格式、费用三点上取得了平衡。如果预算充足我也建议企业客户试试更大参数的旗舰模型但在餐饮这种高频低客单场景成本是必须算的账。这里还要聊一下本地部署和GGUF端侧方案。我们一度想用Ollama部署开源模型把数据完全留在内网但跑了几个7B和14B的量化模型后发现单轮问答勉强能用一旦牵扯复杂工具调用和多轮记忆效果明显下滑。所以最后的方案是核心Agent走云端API门店本地只部署一个轻量版意图识别模型做第一道分流把简单问题直接答掉复杂问题再交给大模型Agent。这个混合架构省了不少成本后面会细说。2.2 自研轻量框架还是直接套Dify做Agent开发第一种思路是直接用Coze、Dify这类智能体平台拖拽编排见效快第二种思路是从LangGraph、LangChain这类开源框架起步自己掌控流程第三种是干脆自己写一个极简的Agent调度核心。我们最后选择了第三种为主、参考第二种思路但刻意控制了依赖。原因在于项目要深入集成餐饮业务的私有系统包括菜单数据库、订单系统、优惠券系统、订座系统。这些系统之间有大量定制化规则比如“生日券和新人券能不能叠加”这种判断放在通用平台里特别别扭。我们用Dify做过一个小型PoC做问答可以但要精确控制每个工具的执行顺序、回滚逻辑、并发策略时平台反而成了阻碍。所以“服范”现在的Agent内核其实只有三个部分模型接口适配层、工具注册与调度层、上下文管理模块。这个设计参考了LangChain的Tool架构但代码量少得多调试起来也直观得多。对大部分中小团队来说我建议不要一上来就上重型框架先理解Agent从模型调用到工具执行的本质再决定要引入多少抽象。2.3 服务形态后端API、H5和浏览器插件产品形态是另一个战略决策。最开始有人提出来要做独立App但我们问了自己一个问题顾客凭什么为了点餐专门装一个App答案是不能。所以最终形态是三条线并行后端提供一套RESTful API供门店平板上的H5页面调用顾客扫码进入对话式点餐界面。运营人员需要一个批量配置菜品和查看对话记录的界面这个界面不能只给开发用于是顺手做了一个轻量管理后台。运营团队在电脑上经常需要查顾客反馈我们把Agent能力封装成一个浏览器插件选中一段聊天记录就能一键提取顾客情绪、问题分类和工单摘要。这个浏览器插件算是意外亮点本来只是为了内部提效后来发现对Agent的评测也有用我们可以在插件里快速改写测试用例发给模型跑批量回归。这件事说明Agent开发不只是写后端逻辑交付形态想清楚了使用频率才会高。3. 开发实战从零搭起一个可用的Agent3.1 提示词工程角色设定比想象中重要所有Agent都始于一段提示词但我们最初的提示词写得像岗位说明书堆了很多功能描述结果模型行为很僵硬。后来我总结出一条经验提示词里要区分“身份定义”、“任务场景”、“工作流程”、“硬性约束”四层。我给你们看一个删减过的实际模板你是九添菜菜的点餐助手名字叫菜菜。 你的任务是帮助顾客完成点餐、优惠查询、订座登记。 工作流程 1. 先识别顾客意图判断是否在服务范围内。 2. 如果需要查询菜单或库存必须调用menu_query工具。 3. 如果顾客提到优惠券必须调用coupon_query工具。 4. 最终回答必须包含菜品名称、价格和可下单方式。 硬性约束 - 不编造菜单中不存在的菜品。 - 不回答与点餐无关的问题。 - 每次回答控制在80字以内适合手机屏幕阅读。这里最关键的其实是“不编造菜单中不存在的菜品”一句简单约束能避免Agent在幻觉问题上失控。我们还试过在提示词里加入两三个少样本示例比如顾客说“上次吃的那个鸡肉套餐还有吗”期望输出先调用订单查询再调用菜单查询。加了示例后工具调用准确率明显提高。另有几个提示词细节值得说。一是温度参数要调低我们设置在0.2到0.3之间保证输出稳定二是要给模型“承认能力不足”的退路当工具查询失败时必须说“这个信息我需要再确认”而不是强行编一个答案三是不要让提示词过于死板允许模型用自然口语跟顾客交流否则回答会像机器人念说明书转化率并不好。3.2 工具调用让Agent真正能动手Agent和普通聊天机器人拉开差距的地方就是工具调用。这个环节的原理是我们把每个业务动作定义成一个函数并附上JSON Schema描述模型看到用户问题后会决定调用哪个函数、传什么参数。然后我们再执行函数、把真实结果返回给模型模型基于结果生成最终回复。这里给一段简化后的Python示例方便理解核心循环while True: response llm.chat(messages, toolsTOOLS) if response.tool_calls: tool_result execute_tool(response.tool_calls) messages.append(tool_result) continue else: return response.content代码看起来简单但实际开发里有三个容易翻车的地方。第一工具描述必须写清楚“什么时候不该调用”比如顾客问“营业时间”没有必要调用菜品查询工具描述里可以加一条“仅当需要查询菜品库存或价格时调用”。第二函数参数要设计成宽松类型比如价格区间用字符串来接收模型输出的“一百五十左右”比直接要求浮点数更抗错然后再在后端解析。第三所有工具都必须有超时和异常返回不能让Agent一直等一个失败接口。我们把工具分成了两类查询型工具和数据变更型工具。查询型工具幂等随便调数据变更型比如创建订座、提交订单必须增加用户确认环节。这是Agent设计里的红线不能因为模型判断“可以下单”就直接下单得把最终确认权留给用户。3.3 上下文管理与短期记忆大模型API本身没有记忆每次调用都是独立状态所以上下文管理就是Agent的记忆系统。一开始我们图省事把整个对话历史一股脑全传给模型结果很快撞到上下文窗口上限而且历史越长模型越容易把早期信息搞混回答变得飘忽。后来我们做了三层策略滑动窗口只保留最近八到十轮对话。餐饮点餐场景里顾客讨论到第三四个菜时第一轮提到的偏好基本已经沉淀到结构化信息里了不需要重复保留原文。关键信息提取每轮对话结束后用一个轻量模型把“人数、时间、菜品、预算、座位要求”抽取成结构化槽位槽位一直保留原始对话可以丢。这样即使聊了半小时模型也能记住顾客最初说“不能吃辣”。摘要记忆当对话超过一定轮次把前面的历史用模型生成一段摘要代替全部原文。这招对长会话特别好用但要注意摘要里不能丢工具调用的结果至少要把已验证的菜品名和订单号记录下来。有人问我要不要上向量数据库做长期记忆我的回答是看场景。如果顾客半年后回来还能记住偏好那确实需要长期记忆但如果只是单次点餐短期记忆用滑动窗口加槽位就够了。我们目前只在会员画像模块里用了向量检索把顾客历史订单的文本特征存起来供推荐系统使用这部分属于后期迭代。3.4 流程编排单Agent还是多Agent“服范”早期用的是单Agent一把梭所有工具都注册给同一个模型结果模型经常选错工具。后来我们把工具分组采用了一个类似路由加子Agent的结构主Agent负责意图识别和对话管理它本身不直接调用所有工具而是把任务路由给三个子Agent。点餐Agent负责菜品推荐、菜单查询、下单。客服Agent负责售后问题、退款流程。订座Agent负责座位查询、包间预订。这样做的好处是每个子Agent的提示词和工具列表短而聚焦模型选错的概率大幅下降。坏处是增加了调用次数和复杂度调试时得多看一层日志。所以我们没有盲目追多Agent而是只做了必要的拆分目前线上跑的其实是“主Agent 点餐/客服两个子Agent”订座场景直接内联在主Agent流程里。我们借鉴了现在行业里常说的Agent设计模式包括规划、记忆、工具使用、反思。反思这个环节我们做得比较轻每当工具调用失败一次会在下一轮给模型补一句“上次查询失败了请换一种方式询问用户是否需要重试”这样能避免Agent一条路走到黑。更多重的自我反思对餐饮场景太重了试过之后发现延迟太明显。4. 部署上线与性能优化4.1 服务架构与接口设计“服范”的后端服务没有用什么复杂微服务就是一个Flask应用配了两个Worker进程。为什么选Flask因为团队里最快能把项目跑起来的语言就是PythonFlask的轻量特性足够应对我们的并发量。初期预估单店每个小时最多几十个并发会话所有门店加起来也就在千级QPS下沿用不着上Go或Java。接口设计遵循了一个原则对前端暴露的是“任务式接口”而不是“模型聊天接口”。也就是说前端只调用/agent/chat后端内部自己处理工具调用循环、上下文拼装和状态存储。这样前端不需要关心模型是什么也不需要在浏览器里暴露API Key。返回格式统一是SSE流式输出顾客那边看到的是一个字一个字蹦出来的回复体验比等一整段结果好很多。SSE流式输出的实现并不难难点在于工具调用过程中不能断流。我们的做法是第一次流式输出模型说“我帮您查一下”这样的过渡语工具调用完成后再把最终回复继续从同一个SSE连接里推给前端。如果中途遇到工具异常就推一个特殊的tool_error事件前端接收到后显示“稍等一下我再试一次”这比让整段对话失败要温和得多。4.2 并发控制与限流策略Agent类应用和普通接口最大的区别是一个请求内部可能要调用大模型两三次甚至更多每次调用耗时一两秒所以并发很容易就堆起来了。我们做过一次压测二十个并发请求直接把DeepSeek的API速率限制打到顶然后开始出现大量429错误。解决思路是在网关层加分布式限流按门店维度给配额。每家门店一个小时内最多发起两百次Agent会话请求超出后返回提示“当前咨询人数较多请稍后”。这个配额经过了测算一家门店高峰期最多同时几个顾客咨询两百次会话足够覆盖同时又不会因为某个门店异常刷量而拖垮整体预算。另一个经验是给所有大模型调用加本地缓存。比如同一道菜的热量问题顾客可能问一百次答案完全一样。我们直接把这类静态问答结果缓存到Redis里TTL设二十四小时key由“用户问题的语义向量 门店ID”组成。哈希到同一语义的问题直接走缓存不再请求模型成本下降得很明显。4.3 成本控制与降本手段成本是餐饮行业落地AI方案绕不开的话题。我们的做法分三层能不用模型就不用模型门店常见问题比如营业时间、WiFi密码、停车指引直接走传统规则匹配只有规则匹配不到时才进Agent。用小模型做前置路由低价API负责意图分类和关键信息抽取复杂生成和工具调用才交给主力大模型。记录每轮真实Token消耗我们把每次会话的输入输出Token数、工具调用次数都打到日志里月底按门店汇总。这样才能发现有些会话其实一句话就能答完却被Agent走了三四个工具白白烧掉Token。这里有一个容易被忽略的点工具调用的返回内容也会占Token。如果菜品查询工具返回了整个菜单三千字模型就算只取其中一句话这些Token也已经计费了。所以要优化工具返回格式精简字段、只回需要的内容能大幅节省成本。我们的menu_query工具一开始返回全部字段后来改成只返回菜品ID、名称、价格、月销量、是否售罄Token消耗直接少了百分之四五十。5. 踩坑实录与排查技巧5.1 模型指令遵循差问题出在结构化输出项目开发到第三周时我们遇到一个特别诡异的Bug顾客问“有情侣套餐吗”Agent能正常调用查询工具但回答里总是会加一句“建议您到店咨询店员”明明提示词里禁止这类话术。排查了很久最后发现问题不在提示词而在于我们没有把回复格式约束成结构化输出。大模型API在流式输出时模型有时会把一些内部推理碎片也输出出来。后来我们给系统设定了一个强约束所有最终回复必须以JSON格式返回字段包括reply_text和suggested_actions前端解析后只渲染reply_text。这样即使模型想“自由发挥”结构校验也能把它拦下来。实测之后乱回答的比例立刻下降。这个坑的教训是写代码时一定要假设模型是“有能力但会开小差”的实习生不能只靠prompt约束要在输出层做硬性校验。5.2 Agent陷入工具调用死循环上线第二天我们就发现一个线上事故顾客问“你们家的鱼香肉丝多少钱”Agent居然连续调了三次菜单查询工具每次参数都一样最后因为工具循环次数上限才停下来。原因是模型在第一次调用后没有正确对工具结果做判断又重复生成了同样的工具调用。解决办法是在Agent循环里加一个最大轮次限制我们设置为三次工具调用超过后强制停止对话并回复“我这边查询有点慢请您稍后再试”。同时每轮工具调用后会追加一条系统消息“你已经查询过该菜品请直接使用已有结果回答”。这两个改动一起上死循环基本绝迹。另外我们也在日志里加了工具链跟踪每轮调用都记录调用顺序、函数名、耗时和返回结果摘要。这样一旦再遇到类似问题可以快速回放Agent的“思考过程”而不是只看最终回复。5.3 上下文窗口溢出与长短记忆取舍有段时间有顾客投诉聊到十分钟后Agent开始“失忆”连刚才点的菜都忘了。我们检查日志发现上下文窗口已经快满了系统自动把最早的对话丢弃但关键信息也被扔掉了。后来我们把槽位提取逻辑前置了很多只要顾客提到“不要香菜”“五个人”“七点来”这类信息立刻写入会话状态不再依赖原始对话。模型只要读槽位状态就能回答“有没有适合五个人、不放香菜的套餐”。这个改动让长会话的稳定性提升非常明显。如果你的Agent场景更复杂我建议把“记忆”拆成工作记忆和长期记忆工作记忆用结构化槽位长期记忆用向量库而不是把所有内容都塞进模型上下文。系统的健壮性来自清晰的记忆分层而不是一味加大模型窗口。5.4 延迟高到用户流失的排查第一次联调时Agent平均响应时间超过六秒顾客基本等不住流失率很高。我们逐段压测后发现延迟主要来自三块大模型API调用本身两到三秒、工具调用里的数据库查询有几次慢查询、加上前端SSE渲染额外缓冲整体就爆了。针对大模型延迟我们把首字延迟压了进去模型先输出几个字“好的”给用户即时反馈后续内容一边生成一边流式输出。针对慢查询我们给菜单表加了索引热门菜品数据放Redis缓存。针对前端缓冲我们取消了累积一定字数才输出的逻辑改成收到一个token就渲染一个。最终平均响应时间压到三秒以内高峰期也能保持在四秒上下。5.5 高频问题速查表下面这张表是我们整理给后来接手的开发同学用的包含了很多新手容易踩的坑现象常见原因解决方案Agent答非所问提示词中工具描述不清晰细分工具职责增加“何时不该调用”说明工具参数解析错误用户口语表达有歧义参数设计用宽类型后端再做归一化对话越久越不准上下文窗口溢出滑动窗口 关键信息槽位 摘要记忆工具调用重复模型未意识到已查过设置最大工具循环次数追加提示信息回复包含多余内容未限制输出格式强制JSON结构化输出并校验API返回429并发超限门店维度限流 缓存热点问题回答一直延迟多轮工具串行优化工具返回字段启用SSE流式输出模型编造库存缺少硬性约束提示词中禁止无根据回答工具结果为空时要明说排查这些问题时别光看线上表现要建立完善的日志体系把每轮对话的模型请求、工具调用、Token消耗全部记录下来。我看到很多团队Agent效果不稳定就是因为系统像一个黑盒出了问题只能靠猜。5.6 上线后的真实体会与一个小技巧“服范”上线运行一个多月后我最真实的体会是这类项目的难度不在模型而在工程化。模型能力的边界我们控制不了但工具的稳定性、上下文的取舍、提示词的迭代速度都是可以依靠工程手段持续改善的。每优化一个环节用户体验都是肉眼可见地变好。最后再分享一个我们一直在用的小技巧每次修改提示词或工具逻辑之后不要只做手工测试一定要准备一套回归集把过去三个月里顾客问过的疑难问题沉淀成几十条测试用例用脚本批量跑一遍对比新旧版本的工具调用准确率和回答合格率。这套回归集看起来简单但真的能拦住很多“修好一个Bug引出三个Bug”的翻车情况。Agent开发是一场持续迭代的长跑留好自动化测试的种子后面会省下大量时间。