基于 LiveKit Agents 的酒店客房送餐策略设计以 hotel_receptionist 知识库条目为例【免费下载链接】agentsA framework for building realtime voice AI agents ️项目地址: https://gitcode.com/GitHub_Trending/agen/agents导读在 LiveKit Agents 的 hotel_receptionist 实时语音前台 Agent 示例中客房送餐Room Service并非写死在提示词里的硬编码事实而是以一份独立 Markdown 策略文件的形式存在由「渐进式披露」工具在通话中按需加载。本文以 room_service.md 为核心讲解这条策略的知识结构、它如何被 Agent 路由与调用、与餐厅策略家族的关系以及账单争议处理等周边机制帮助读者理解 LiveKit Agents 中「长尾知识外置、热路径内联」的落地模式。一、策略条目的原始内容与事实解读room_service.md全文只有三行分为两部分Room service hours and menu; takeout and delivery policy. Room service: same menu as the restaurant, 5:30 to 9:30 PM. Takeout and delivery: not offered.第一行是整份文件的一句话摘要在知识库体系中它还有特殊用途见下文其余部分是需要回答的关键事实事实维度策略内容送餐时间每天 17:3021:305:30 to 9:30 PM菜单来源与餐厅菜单完全一致same menu as the restaurant外卖与自提配送不提供not offered这份策略的实际含义酒店有现场餐厅但不提供把餐食送出酒店的「外卖/外带配送」服务客房送餐仅在晚餐时段开放且菜品与店内餐厅共用一套菜单。对照 instructions.py 中给出的餐厅快速事实「Restaurant: on-site, dinner only, 5:30 to 9 PM last seating」以及 hotel_db.py 中餐厅可用时段 SQL 枚举的17:30:00到21:00:00八个时段可以推断客房送餐的 21:30 截止时间比餐厅最后入座时间21:00晚半小时是独立于餐厅叫号体系之外的一条服务窗口。二、这份文件在知识库体系中的角色渐进式披露room_service.md位于 policies/ 目录。该目录的模块文档字符串policies/init.py明确说明了设计原则The receptionists prompt keeps only hot-path facts inline; everything long-tail lives here as one markdown file per topic.也就是说前台 Agent 的提示词只内联高频事实check-in/check-out、取消窗口、早餐时段等所有长尾知识按主题拆成一个个 Markdown 文件存放于此。room_service.md正是「餐厅详情」这一长尾主题中的一员。其核心机制在build_lookup_policy_tool()中实现启动时遍历目录下所有*.md文件把每个文件的第一行解析为该主题在工具 schema 中的索引条目描述其余内容作为模型查询时返回的正文动态构造lookup_policy函数工具的 raw schema其topic参数是一个由全部文件名构成的enum因此索引永远与语料库保持一致不会漂移查询时若 topic 不在policies字典中会抛出ToolError并列出合法主题引导模型修正调用。这意味着新增一个主题比如「泳池开放时间」只需在policies/下增加一个*.md文件无需改动任何代码——索引、枚举、工具描述在启动时自动重建。三、Agent 如何路由到客房送餐话题策略文件本身不会自动生效它需要提示词把话题路由到lookup_policy工具。instructions.py 的路由规则明确写出「Detail beyond the quick facts: lookup_policy. Its topic index covers hotel detail…, restaurant detailmenu, dietary, dining, room service, payments and currency exchange, and group bookings. Look the topic up before answering - dont improvise policy.」——即凡是超出快速事实的细节必须先查策略再回答禁止凭记忆即兴发挥政策。persona.py 在「What you can help with」中把可答复范围声明为「restaurant info (menu, dietary, dress code, private dining,room service, celebrations)」与policies/下的restaurant_menu.md、restaurant_dietary.md、restaurant_dining.md、room_service.md一一对应。因此当来电者询问「你们客房送餐到几点能点牛排吗能送外卖到楼下吗」这类问题时Agent 的调用链为识别话题属于长尾策略 → 调用lookup_policy(topicroom_service)→ 工具返回正文 → Agent 据此组织自然语言回答。工具调用对来电者不可见persona 中明确「Tool interactions are invisible to the caller」模型只把结论性内容说出口。四、客房送餐与餐厅策略家族的联动room_service.md中「same menu as the restaurant」一句决定了它必须与餐厅策略家族的其余文件配合解读策略文件覆盖内容与客房送餐的关联restaurant_menu.md菜品构成前菜/沙拉、主菜、配菜、甜点、吧台、菜品价格会变动送餐菜单即此菜单价格同样「不记在脑子里」restaurant_dining.md着装要求、座位区、订位规则、私人包间、庆祝甜点送餐场景通常不涉及着装与订位但庆祝甜点、私人包间等属于同一餐饮体系restaurant_dietary.md素食与多数饮食需求可满足严重/过敏性过敏需在订位时告知厨房送餐点单同样适用此过敏告知逻辑从restaurant_menu.md的措辞「specific dish prices rotate and I dont keep them memorized; if the caller asks about a particular dish or price I dont have, offer to note the question for the kitchen via record_followup (kindother)」可以看出一个通用模式策略文件负责「是什么」具体菜品价格等易变信息不硬编码而是通过record_followup记录给厨房。这是 LiveKit Agents 中工具化知识库的常见写法——把「稳定策略」与「易变数据」分层。五、客房送餐账单争议策略之外的数据库支撑客房送餐不只是「知识问答」它还牵涉到账单争议处理。hotel_db.py 中定义了DisputeCategory枚举其中包含room_service_restaurant分类对应的争议处理策略为actionverify_explain_then_offer_credit先调出订单核实若确有异常可申请信用抵扣或升级给餐饮经理escalationmanager升级到经理。种子数据 fake_data/seed.py 中提供了一个现成的争议示例(DSP-2H6T, HTL-ZP19, Room service, 8800, room_service_restaurant, Charged for a dinner they didnt order., escalated_to_manager, 0, open)—— 一笔 88 美元的客房送餐费用被客人否认当前状态为已升级经理、待处理。这印证了「客房送餐」在整个示例中是一条贯通知识库、账单表、争议流程的完整业务线而非孤立的问答条目。六、运行示例并验证客房送餐问答要实际观察 Agent 如何应答客房送餐问题可参照 README.md 的启动方式uv run examples/hotel_receptionist/fake_data/seed.py uv run examples/hotel_receptionist/agent.py console # 或使用 LiveKit Playground 进行带界面调试 uv run examples/hotel_receptionist/agent.py devfake_data/seed.py会打印可供试用的示例确认码例如取消流程的last name Smith, code HTL-AB12。在 console 模式下可以尝试如下提问来触发策略查询链路「你们客房送餐几点到几点」→ 期望回答 5:30 到 9:30 PM「客房送餐能点菜单上没有的东西吗」→ 期望回答菜单与餐厅一致、价格会变动「你们提供外卖吗」→ 期望明确回答不提供。需要注意的是Agent 的语音与模型栈在 agent.py 中配置为inference.STT(deepgram/nova-3)、inference.LLM(google/gemma-4-31b-it)、inference.TTS(inworld/inworld-tts-2)并显式指定了 Silero VAD运行前请确保相应的云端推理凭据已就绪示例通过.env.local加载环境变量。七、小结一份三行策略文件背后的设计方法论room_service.md篇幅虽短却是 LiveKit Agents 中「策略外置 渐进式披露」模式的微型样板其方法论可以归纳为四点长尾外置只有热路径事实进提示词其余全部以「一主题一文件」的形式放目录提示词只保留路由规则自描述索引文件第一行即工具 schema 的索引条目目录扫描自动构建 enum语料与索引永不漂移禁止即兴提示词强制「查了再答」杜绝模型凭记忆编造政策业务贯通知识条目与账单、争议分类、种子数据协同形成可运行、可评测的完整闭环。如果要在自己的 LiveKit Agents 项目中复用这套机制只需参照 policies/init.py 的build_lookup_policy_tool()实现并在 instructions.py 中加入对应的路由提示即可。【免费下载链接】agentsA framework for building realtime voice AI agents ️项目地址: https://gitcode.com/GitHub_Trending/agen/agents创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考