1. 项目概述本项目面向 Rokid 智能眼镜场景构建一个通过语音即可完成滴滴打车流程的智能 Agent。用户只需对眼镜说出出发地、目的地和车型需求系统即可通过滴滴 MCP Sandbox 完成路线地点解析、价格预估、用户确认、订单创建和订单状态查询并将关键结果以短文本卡片形式展示在眼镜屏幕上。项目核心体验是用户说帮我从北京西站叫辆快车去西二旗。眼镜显示滴滴预估北京西站 → 西二旗快车约 22 元说“确认叫车”用户确认后系统创建 Sandbox 订单并继续展示“正在匹配司机”“司机已接单”“司机已到达”“行程中”“行程完成”等状态。2. 方案目标本项目的目标是在智能眼镜这个轻交互设备上完成语音 Agent MCP 工具 工作流编排 眼镜端显示。核心目标包括用户通过语音发起打车请求。Agent 自动理解起点、终点、城市和车型。工作流调用滴滴 MCP 完成地点搜索和价格预估。眼镜端展示简洁的价格确认信息。用户明确确认后系统通过 Sandbox 创建订单。创建订单后系统可查询并展示订单状态。整个流程不产生真实订单所有 MCP 调用真是使用滴滴Sandbox环境。3. 技术架构整体架构分为三层Rokid 智能眼镜端 ↓ Agent 智能体层 ↓ 无代码工作流编排层 ↓ 滴滴 MCP Sandbox 服务3.1 端侧Rokid 智能眼镜端侧主要负责用户交互采集用户语音指令。将语音输入传递给 Agent。接收 Agent 返回的短文本结果。在眼镜屏幕上展示价格、订单状态、司机信息和行程进度。通过语音继续触发“确认叫车”“刷新状态”“取消订单”等操作。眼镜端不直接处理复杂业务逻辑仅作为轻量交互入口和信息展示屏。3.2 云端Agent 智能体Agent 负责自然语言理解和流程路由判断用户意图叫车、确认下单、查询状态、取消订单。提取参数起点、终点、城市、车型。在会话中保存关键变量例如estimate_trace_id、selected_product_category、order_id。调用对应工作流。将工作流结果改写成适合眼镜展示的短句。Agent 不直接创建订单而是必须通过工作流执行避免绕过确认门。3.3 云端无代码工作流工作流负责稳定执行业务步骤调用滴滴 MCP 插件。解析 JSON 数据。保存中间变量。判断参数是否完整。强制执行“预估 → 确认 → 下单”的安全顺序。根据订单状态生成不同展示文案。3.4 外部能力滴滴 MCP Sandbox滴滴 MCP Server 通过 Streamable HTTP 向 AI Agent 暴露网约车和地图能力包括maps_textsearch、taxi_estimate、taxi_create_order、taxi_query_order等工具。开发调试阶段调用滴滴接口但使用 Sandbox 端点返回 Mock 数据不产生真实订单。4. MCP 工具使用说明本项目主要使用以下滴滴 MCP 工具。4.1maps_textsearch用于根据关键词和城市搜索 POI获取地点名称、地址和经纬度。所有需要坐标的操作都必须先通过该工具获取坐标不能使用模型记忆中的坐标。使用场景搜索起点北京西站 搜索终点西二旗地铁站关键输出字段display_name address_all location.lng location.lat4.2taxi_estimate用于查询可用车型和价格预估并返回创建订单所需的traceId。下单前必须先调用该工具。关键输出字段structuredContent.traceId structuredContent.items[].productName structuredContent.items[].productCategory structuredContent.items[].priceText字段映射关系traceId → estimate_trace_id productCategory → product_category4.3taxi_create_order用于在用户确认后创建订单。调用前必须已经展示车型和价格并收到用户明确确认。关键输入字段product_category estimate_trace_id关键输出字段structuredContent.orderId structuredContent.status structuredContent.from.name structuredContent.to.name structuredContent.phoneNumberSuffix4.4taxi_query_order用于查询订单状态、司机信息和行程进度。Sandbox 环境会按照查询次数依次返回完整订单生命周期适合演示。状态流转第 1 次匹配中 第 2 次司机已接单 第 3 次司机已到达 第 4 次行程中 第 5 次行程完成5. 工作流设计本项目采用三个核心工作流RideEstimateWorkflow 打车预估工作流 RideCreateOrderWorkflow 确认下单工作流 RideQueryStatusWorkflow 查询订单状态工作流以下内容计划中但暂未开展RideCancelWorkflow 取消订单工作流6. 工作流一RideEstimateWorkflow6.1 目标完成起点、终点解析和价格预估不创建订单。6.2 输入参数from_name起点例如 北京西站 to_name终点例如 西二旗 city城市默认 北京市 product_name车型默认 快车6.3 节点设计参数提取 ↓ 变量初始化 ↓ 分支检查起点/终点是否完整 ↓ 插件maps_textsearch 搜索起点 ↓ JSON反序列化解析起点 POI ↓ 插件maps_textsearch 搜索终点 ↓ JSON反序列化解析终点 POI ↓ 文本处理经纬度转字符串 ↓ 插件taxi_estimate 获取价格预估 ↓ 代码/文本处理筛选车型 ↓ 变量保存 traceId、productCategory、价格 ↓ 直接回复返回眼镜展示文案6.4 输出字段{success:true,need_user_confirm:true,estimate_trace_id:{{estimate_trace_id}},selected_product_category:{{selected_product_category}},selected_product_name:{{selected_product_name}},selected_price:{{selected_price}},from_name:{{from_name}},to_name:{{to_name}},screen_text:滴滴预估从 {{from_name}} 到 {{to_name}}约 {{selected_price}}\n\n说“确认叫车”}6.5 眼镜展示滴滴预估 北京西站 → 西二旗 快车约 22 元 说“确认叫车”7. 工作流二RideCreateOrderWorkflow7.1 目标在用户明确说“确认叫车”后调用滴滴 MCP 创建 Sandbox 订单。7.2 输入参数confirm_text用户当前输入例如 确认叫车 estimate_trace_id上一个工作流返回的 traceId selected_product_category上一个工作流返回的车型 category selected_product_name车型名 selected_price价格 from_name起点 to_name终点7.3 节点设计意图识别判断是否确认下单 ↓ 分支非确认则停止 ↓ 变量保存输入参数 ↓ 分支检查 traceId 和 productCategory 是否存在 ↓ 插件taxi_create_order 创建订单 ↓ 变量提取 orderId、订单状态、手机号尾号 ↓ 分支检查 orderId 是否返回 ↓ 文本处理生成眼镜展示文案 ↓ 直接回复返回订单创建结果7.4 确认意图识别意图识别分为三类confirm_order确认下单 reject_order拒绝或暂不下单 other其他只有当意图为confirm_order时工作流才允许继续调用taxi_create_order。7.5 输出字段{order_created:true,order_id:{{order_id}},order_status:{{order_status}},selected_product_name:{{selected_product_name}},selected_price:{{selected_price}},from_name:{{from_name}},to_name:{{to_name}},screen_text:订单已创建\n{{selected_product_name}} · {{selected_price}}\n\n正在匹配司机…}7.6 眼镜展示订单已创建 快车 · 22 元 正在匹配司机…8. 工作流三RideQueryStatusWorkflow8.1 目标根据order_id查询订单状态并返回适合眼镜展示的状态卡片。8.2 输入参数order_id第二个工作流返回的订单 ID8.3 节点设计分支检查 order_id 是否存在 ↓ 插件taxi_query_order 查询订单 ↓ 变量提取 statusCode、司机信息、车辆信息、ETA ↓ 分支根据 statusCode 生成不同文案 ↓ 直接回复返回眼镜展示内容8.4 状态展示设计匹配中正在匹配司机 请稍候…司机已接单司机已接单 {{car_model}} 车牌{{car_plate}} 约 {{eta}} 分钟到司机已到达司机已到达 请前往上车点 车牌{{car_plate}}行程中行程中 剩余 {{distance_km}} km 预计 {{eta}} 分钟行程完成行程完成 已到达目的地 感谢使用9. Agent 智能体设计9.1 Agent 职责Agent 负责自然语言入口和工作流调度不直接执行下单逻辑。Agent 需要完成1. 判断用户意图 2. 提取起点、终点、车型、城市 3. 调用对应工作流 4. 保存工作流返回的关键变量 5. 将工作流返回结果展示给眼镜端9.2 Agent 路由规则用户说“帮我叫车 / 打车 / 去某地” → 调用 RideEstimateWorkflow 用户说“确认叫车 / 确认叫快车 / 就这个 / 帮我叫吧” → 调用 RideCreateOrderWorkflow 用户说“司机到哪了 / 车来了吗 / 刷新状态 / 还有多久” → 调用 RideQueryStatusWorkflow 用户说“取消订单 / 不打了” → 调用 RideCancelWorkflow9.3 Agent 会话变量Agent 需要保存from_name to_name city selected_product_name selected_product_category selected_price estimate_trace_id order_id last_order_status其中最关键的是estimate_trace_id selected_product_category order_id10. 端侧与云端插件运用10.1 端侧能力Rokid 眼镜端主要使用语音输入 屏幕展示 用户确认交互 状态刷新交互端侧展示遵循四行以内原则第一行状态 第二行核心信息 第三行价格/车牌/ETA 第四行下一步提示例如司机已接单 黑色轿车 京A12345 约 3 分钟到10.2 云端插件能力云端通过 Agent 平台接入滴滴 MCP 插件主要调用maps_textsearch taxi_estimate taxi_create_order taxi_query_order taxi_cancel_order 可选云端插件负责真实业务能力工作流负责调用顺序和字段传递。10.3 端云协同方式用户语音 ↓ Rokid 眼镜端上传文本 ↓ Agent 判断意图 ↓ 工作流调用滴滴 MCP ↓ 工作流返回结构化结果 ↓ Agent 生成短文案 ↓ Rokid 眼镜展示11. 技术方案说明11.1 为什么使用 MCPMCP 让 Agent 可以用标准方式接入滴滴的网约车和地图能力。滴滴 MCP Server 已经提供地点搜索、价格预估、创建订单、查询订单、取消订单和司机位置等工具Agent 平台只需完成接入配置即可调用。11.2 为什么使用工作流打车不是一次性问答而是强顺序业务流程地点解析 → 价格预估 → 用户确认 → 创建订单 → 查询状态如果完全依赖大模型自由调用工具容易出现跳过确认、变量丢失、字段错传等问题。工作流可以把关键步骤固定下来保证流程安全、稳定、可复现。11.3 为什么使用 SandboxSandbox 环境返回 Mock 数据开发和调试过程中不产生真实订单不影响真实账户。并且 Sandbox 的订单状态会按查询次数依次变化可以完整展示打车生命周期。11.4 为什么拆分三个工作流拆成三个工作流的原因是用户确认通常发生在多轮对话中第一轮用户发起叫车 → 返回价格 第二轮用户确认叫车 → 创建订单 第三轮及以后用户查询状态 → 更新订单信息这种拆分方式更符合真实对话也更适合无代码平台调试。12. 安全与约束设计12.1 不自动下单系统必须先展示价格和车型等待用户明确确认后才能调用taxi_create_order。这是核心安全约束。12.2 不猜测坐标所有起终点坐标必须通过maps_textsearch获取不能使用模型记忆或手写坐标。12.3 经纬度转字符串滴滴 MCP 要求经纬度参数用字符串传递否则可能触发参数校验错误。12.4 traceId 失效处理traceId有时效性。如果用户确认太晚或下单失败需要重新调用taxi_estimate获取新的价格预估。13. 黑客松 Demo 流程Step 1发起叫车用户帮我从北京西站叫辆快车去西二旗眼镜滴滴预估 北京西站 → 西二旗 快车约 22 元 说“确认叫车”Step 2确认下单用户确认叫车眼镜订单已创建 快车 · 22 元 正在匹配司机…Step 3查询状态用户刷新状态眼镜正在匹配司机 请稍候…用户再次说刷新状态眼镜司机已接单 车辆信息 车牌号 约 3 分钟到Step 4完成演示继续刷新状态依次展示司机已到达 行程中 行程完成项目总结本项目通过 Rokid 智能眼镜、Agent 智能体、无代码工作流和滴滴 MCP Sandbox构建了一个从语音叫车到订单状态展示的完整闭环。它验证了智能眼镜作为出行服务入口的可行性也展示了 MCP 工具生态和工作流编排在真实生活服务场景中的落地能力。最终体验可以概括为用户一句话发起叫车Agent 自动完成预估、确认、下单和状态追踪眼镜一眼显示关键信息。
