步语 BuYu · 设计文档 — 美团 AI Hackathon 赛题06

▶ 在线试玩完整可交互 Demo

左侧手机界面（接受 / 换一个 / 看详情 / 多轮对话 / 一键执行）+ 右侧 Agent 实时思考链路双栏视图。完整 Tool 实现代码（含 Mock API）见 jxtse/buyu-meituan。

检测服务状态…

步语 BuYu 面向「周末半天不知道去哪儿」这一高频本地生活场景，把一句含糊需求转化为一条可确认、可解释、可执行的本地生活方案。系统设计的核心不是生成推荐文案，而是把 LLM 放在规划中枢：在真实商户候选、实时可用性与用户反馈之间持续权衡，并把推荐、确认与执行连成闭环。本文聚焦比赛要求的三件事：Planning 策略、工具调用链路、异常处理机制；并补充记忆与技能内化的设计依据。

01Planning 策略

规划不是一次性吐出整张行程，而是 LLM 作为 tools orchestrator，在 ReAct 循环（Reason → Act → Observe）里分段、软固定、渐进式确认地推进。每一段都是一轮「Reason（结合已知 memory 想清楚这段要什么）→ Act（按需调用地图定位、地点检索、详情、团购、评论、种草帖、查位等工具）→ Observe（读结果、必要时改主意）」。接受、换选、追问、查位和下单都被视作同一条规划链上的状态变化；每一次用户反馈都会写入单会话上下文（Session memory），让下一段推荐继续沿着本次出行的真实意图收敛：

stage · locate定位

读取当前位置与商圈，作为后续距离计算的原点。

meituan_locate工具调用

stage · intent意图解析

自然语言 → 结构化约束：场景 / 人群 / 饮食 / 时间窗 / 预算，写入 memory。

LLM · JSONAgent 推理

stage · plan分段编排

软固定三段「玩→吃→额外」，按约束灵活增删；硬上限 3 段。

segment_planAgent 规划

stage · search+reason逐段出卡

段内检索真实候选 → 结合 memory 权衡 → 选 1 个生成可执行卡片。

dianping_searchReAct 一轮

stage · execute一键执行

逐站调用下单工具，命中异常当场自动调整。

execute_booking工具调用

软固定三段框架

play → eat → extra：默认「先玩、再吃、轻松收尾」。段的顺序即推荐顺序。
场景自适应：约会把 extra 设计成「鲜花惊喜」，家庭设为「亲子手作 / 环湖消食」，朋友设为「续摊收尾」。
可裁剪：时间紧（hours≤3）砍掉 extra，只想吃饭则只留 eat。
动线感知：每段决策都把「从上一站过去的摩擦成本」纳入，下一张卡不是孤立推荐，而是接住整条路线的后续选择。

渐进式总结 + memory（人机协同）

每段出一张卡，用户只需接受 / 换一个 / 看详情三选一，不必从长列表里挑。
每次选择都进 memory：accept → 当前卡写入行程并沉淀为偏好信号，推进下一段；reject → 拉黑该 id 写入 memory，同段换次优候选，下段也据此调整。
多轮对话渐进式总结：用户补充偏好或质疑推荐，Agent 把新信息并入 memory，判定 keep / switch / refine 并更新约束——越聊越懂这次要什么。
推理可见：每一步通过 SSE 推 thinking / stage / tool / self_heal 事件，右侧链路实时展示 Agent「为什么这么选」。其中自动调整（internal: self_heal）事件解释每一次实时改选。

02工具调用链路

所有外部能力收敛为一组统一签名的工具（name / description / parameters / invoke()），LLM 作为 tools orchestrator 在 ReAct 循环里按需调度——它读工具描述、自己决定何时调哪个、用上一步的 observation 决定下一步。覆盖地图 / 地点检索 / 地点详情 / 团购套餐 / 用户评论 / 大众点评种草帖 / 实时订位 / 下单全链路。右侧 Agent 链路由事件总线驱动；公网环境下，为避免 SSE 被代理缓冲，关键预设和用户点击动作会随接口响应返回 agent_events，由前端按时间线回放，保证链路与卡片生成同步。商户数据全部走 Mock 美团 / 点评层，保证无真实交易、可复现、低延迟。

阶段	工具	角色	输入 → 输出
定位	meituan_locate	地图工具	∅ → 当前坐标 + 商圈，作为距离原点
理解	intent_parse (LLM)	Agent 推理	query → 结构化约束 JSON，写入 memory（失败则启发式兜底）
检索	dianping_search	地点检索工具	段 + 场景 + 排除集 → 真实候选（按距离、评分排序，top-6）
决策	recommend (LLM)	Agent 决策	候选集 + memory → 选 1 个 id + 卡片话术（只在候选内选择，不编造地点）
详情	meituan_detail	详情 / 团购 / 评论 / 种草帖	poi_id → 种草帖 / 团购套餐 / 评论 + 同段可切换候选
查位	meituan_query_queue	实时订位工具	poi_id + 人数 → 实时排队 / 有无可订桌位
执行	meituan_buy_ticket / book_table / order_delivery	下单工具	按段类型逐站下单 → 状态 + 订单号 / 确认号

Agent 与工具的边界：工具负责确定性操作——检索召回真实存在的候选、算距离、匹配团购、查实时队列、执行下单、注入故障，结果可复现、可审计。 LLM 不碰这些数字，而是做tools orchestration 与多维权衡：读工具回来的 observation，结合 memory 里积累的偏好，在真实候选里（被严格约束「只能选一个，绝不编造」）综合 同行人结构（如两大一小、5 岁孩子）、时间与体力状态（玩完后孩子体力下降）、实时约束（无桌、等待时长）、体验风险（孩子等位哭闹、行程失控）、执行确定性（可订、可下单、可替换）——挑出最合适的候选并生成用户可理解的解释，再决定下一步调哪个工具。

03实时调整机制

规划与执行中遇到的落地障碍，目标是不中断流程、当场自动调整，并把每一次调整显式推给用户（自动调整事件，internal: self_heal），可见、可解释。机制贯穿规划期（风险前置）与执行期（逐站调整）两个阶段。

类型	触发条件	处理策略	发生阶段
模型降级	意图解析 / 对话的 LLM 调用异常或返回非法 JSON	捕获异常 → 切换启发式规则兜底（关键词判场景/人数），流程继续不报错	规划期
无座 no_table	下单前查位无可订桌 / 等待 ≥30min，或下单返回满座	出卡前预过滤降权高风险店；执行期则在同段候选自动改约，保留时间轴	规划 + 执行
无票 sold_out	下单返回票 / 名额售罄	同段顺路候选自动替换重试，沿用已选时间，成功即写回行程	执行期
时间冲突 conflict	同一时段已有预约	自动错峰 +15min 重排该站，避免撞车	执行期
无候选	某段在场景约束下检索为空	放宽场景再搜；仍为空则跳过该段，不阻塞整体方案	规划期

典型链路 · 家庭晚饭段实时调整
用户确认 Kiddo Lab（亲子手作）后，Agent 进入吃饭段。系统先按距离和评价召回 Green Bowl——它离上一站最近，也符合轻食需求；但在下单前调用 meituan_query_queue，发现当前无可订桌位、预计等待 35min。 Agent 读到这条 observation 后重新推理：5 岁孩子刚完成一场高参与度活动、体力已下降，继续等位会显著放大「孩子哭闹、行程失控」的体验风险，因此主动降权 Green Bowl，改选 Sprout Table。虽然 Sprout Table 距离更远，但有可订座位、等待更短、热食与轻食选择更稳，更贴合「省心吃顿好的」目标。整个调整推自动调整事件呈现在右侧链路，用户全程可见为什么改。

规划期：风险前置

出卡前即调用查位工具，对「评分高但实时落地风险高」的餐厅主动降权，优先把可订、等待短的候选放进卡片——避免把一个看起来不错、到店却坐不下的选项推给用户。每一次降权都附带一段思考，解释「我原本会选 A，但实时队列显示它没桌，所以改 B」。

执行期：逐站调整

一键执行时逐站下单，命中无座 / 无票立即在同段合法候选里改约重试，命中时间冲突自动错峰；每次调整推自动调整（internal: self_heal → self_heal_ok）两段事件，告诉用户「原选满座，已自动改为 X」。整条链路 Pass@1，不回退到「请稍后再试」。

04记忆与技能内化

步语 BuYu 的记忆分两层：会话记忆（运行中）让「这次出行越聊越懂」；参数化技能内化（演进方向）把跨场景复用的通用规划能力沉淀为模型自身的认知基础。两层的分工遵循一条原则——有规律、可复用的通用技能适合内化进参数；精确、易变的事实适合留在外部按需检索。

通用技能内化 → 认知基础

把通用技能内化进参数：分段规划范式、动线与体力常识、五类自动调整策略这类跨场景复用的「策略模式」，通过 LoRA + RL 内化为模型能力，而非每次写入上下文。
为困难任务奠定认知基础：Agent 必须先具备基础策略图式，才谈得上灵活调用细粒度规则——通用技能内化正是这层底座。
表现远超外挂方案：相比把技能全留在 context（prompt 膨胀、长程推理退化）或纯靠 in-context learning，先内化通用技能、再利用专项技能在分布内与分布外任务上都更强，OOD 泛化提升尤其显著。

结构化事实 → 极致参数效率

结构化记忆极省参数：LoRA 作为参数化记忆，对有规律的结构化事实参数效率极高——极少的参数即可承载数十万 token 量级的内容。
强依赖内容规律性：同样的参数预算，在毫无规律的精确串（随机 token、逐字密钥）上效率断崖式下降，单个低规律 token 就可能触发逐字记忆崩溃。
落到步语 BuYu 的分工：商户、团购、常识性偏好这类结构化知识适合廉价内化；实时排队、库存、价格这类精确且易变的事实必须留在工具侧实时检索，不进参数——否则既贵又不可靠。

设计依据：上述「内化 vs 外挂」的边界不是主观设定，而是两条经验规律共同界定—— (1) 在多轮交互 Agent 上，先内化通用技能构建认知基础、再利用专项技能的方案，系统性地优于把技能全外挂在 context 或纯 in-context learning； (2) LoRA 的参数化记忆容量遵循 ΔL ∝ rank^α · 长度^−β 的幂律：对结构化内容以极小 rank 承载长序列，对无规律精确记忆则需跨过 p>0.5 的确定性相变才能逐字复现。二者共同回答了「什么该内化、什么该外挂」——这正是步语 BuYu 把通用策略内化、把易变事实留给工具检索的理论基础。

05性能与约束

商户数据全 Mock、不接真实交易；API Key 仅存服务端环境变量，前端零暴露；在线服务经隧道从作者本机暴露，仅供评审试玩，比赛结束后一并下线。