一、从一句话到一笔订单：问题定义

在通义千问 App 里，用户可以直接说：

「帮我点一杯混果汁外卖，尽快送到家。」

看似一句自然语言请求，系统需要完成的却是完整的「下单工作流」：

• 理解用户意图：外卖，而不是堂食或买生鲜；

• 补全缺失信息：口味偏好、价格区间、配送地址、送达时间；

• 选择平台与店铺：去哪点、选哪家性价比更高；

• 生成点单方案：点哪一款、需不需要加小料、怎么用券更省；

• 拉起支付并确认结果：保证整个过程安全、可控、可追踪。

本质上，这是一个典型的「大模型驱动任务型 Agent」问题：用自然语言驱动一组结构化工具，完成多步骤的真实世界任务。

---

二、整体架构：大模型 + 工具 + 编排

从工程视角看，通义千问的自动点餐可以抽象成以下几层：

1. 交互层（UI & 会话）

   • 接入语音/文本输入，处理录音转写、分句、节流等；

   • 维护会话上下文，支持多轮澄清和偏好记忆；

   • 把后端返回的推荐、订单方案渲染成卡片、按钮、列表等交互形式。

2. 智能层（LLM + Agent）

   • 使用大模型（通义千问）做自然语言理解与意图识别；

   • 将复杂任务拆解成一系列工具调用步骤（意图 → 计划 → 行动）；

   • 在多轮对话中，根据用户反馈动态调整计划。

3. 工具层（外卖/电商/支付 API）

   • 将「查餐厅、查菜品、创建订单、发起支付」封装为一组统一协议的工具；

   • 定义清晰的入参与出参结构，供模型调用；

   • 管理调用频率、重试、降级与错误处理。

4. 平台与风控层

   • 与淘宝、支付宝、闪购、高德等生态服务打通，实现账号绑定与授权；

   • 落地风控策略，防止误触发高金额支付、重复下单等风险；

   • 做日志、审计与异常报警，保证线上稳定可靠。

可以把这一整体架构理解为：LLM Orchestrator + Tool Hub + Super App 容器。

---

三、任务执行链路：一次点餐的生命周期

以下用一个具体示例串起全流程：用户语音输入「帮我点一杯混果汁外卖，20 块左右，尽快送到家」。

1. 意图识别与信息抽取

通路通常如下：

• 语音 → 文本：ASR 模块完成转写；

• 文本 → 结构化槽位：

  • 任务类型：点外卖

  • 品类：混果汁

  • 预算：约 20 元

  • 收货地址：最近使用的家庭地址

  • 配送时间：尽快送达（未指定时间则走默认策略）

若信息不完整，例如用户没说预算或口味，Agent 会驱动模型主动追问：

「你更喜欢偏甜一点还是少糖？预算大概是多少？」

在实现上，这一步可以通过微调意图分类模型 + 通用大模型抽取槽位实现，也可以完全交给大模型通过提示词完成。

2. 任务拆解与计划生成

在拿到结构化的用户需求后，Agent 会生成一份「任务计划」，类似于：

1. 选择一个支持配送用户地址的果汁商家；

2. 在候选商家中，根据评分、销量、距离和价格选出若干家；

3. 在选中的商家菜单里选择一款符合「混果汁 + 预算约 20 元」的商品；

4. 创建订单草稿；

5. 展示订单卡片给用户确认；

6. 经用户确认后发起支付。

这里有几个关键点：

• 计划是可中断、可回退的：如果用户看到推荐不满意，可以要求「换一家便宜点的」，Agent 会在既有计划基础上调整；

• 计划通常以「自然语言 + 机器可读结构」的混合形式存在，方便模型理解和编排器执行；

• 复杂任务（如多人拼单、跨平台比价）可以拆成子计划，由子 Agent 执行。

3. 工具调用与状态管理

有了计划，接下来是不断在「模型思考」和「工具调用」之间来回切换：

• 工具定义示例（伪代码）：

  json

  { "name": "search_restaurants", "description": "根据品类和位置搜索可配送餐厅", "parameters": { "type": "object", "properties": { "category": {"type": "string"}, "location": {"type": "string"}, "price_range": {"type": "array", "items": {"type": "number"}} }, "required": ["category", "location"] } }

• 模型在推理中生成工具调用指令：

  json

  { "tool": "search_restaurants", "arguments": { "category": "混合果汁", "location": "上海市徐汇区XXX", "price_range": [10, 30] } }

• 编排器执行调用，将返回结果（店铺列表、评分、配送费等）写入上下文，再交给模型进行下一步决策。

整个过程中，Agent 需要维护一份「会话状态」，包括：

• 当前任务阶段（检索中 / 选品中 / 下单中 / 支付中）；

• 中间结果（候选商家列表、选中商家、订单草稿等）；

• 用户偏好（口味、预算、历史常点店铺等）。

这使得 Agent 不仅能回答「现在帮我再点一杯」，还能理解这是「基于刚刚那家店再下单」。

4. 用户确认与支付闭环

在订单草稿准备好后，系统会渲染一张包含关键信息的卡片：

• 店铺名、评分、配送时间；

• 商品名、规格、数量；

• 商品价格、配送费、优惠后总价；

• 收货地址、联系电话。

用户仅需点击「确认下单」，Agent 即可调用支付工具完成支付。完成后，系统再以自然语言反馈状态：

「已经帮你在 X 店下单一杯混果汁，预计 30 分钟送达。」

这一设计保证了「关键动作由用户拍板」，既保留自动化带来的便利，又避免完全黑箱代扣。

---

四、工具内置与「对话即操作」

要让模型在自然语言流程中顺畅调用工具，需要对「工具内置」进行设计。

1. 工具描述与协议统一

所有工具都需要一套统一的描述协议，例如：

• 工具名：create_order；

• 能力描述：根据选中的店铺和商品创建订单草稿；

• 入参声明：店铺 ID、商品列表、地址 ID、优惠券 ID 等；

• 出参声明：订单 ID、金额明细、预计送达时间、可用支付方式等。

通过这些结构化描述，模型才能在没有死记硬背每个接口细节的前提下，推断应该传什么参数、如何理解返回字段。

2. Few-shot 教学与思考模式

在系统提示词（System Prompt）中，通常会写入若干「示例对话」：

• 用户表达需求；

• 模型思考当前要做什么（用隐藏的「思考链」或简化版本）；

• 模型决定调用哪个工具、传入什么参数；

• 工具返回结果后，模型如何解释并给用户反馈。

经过这些示例，模型逐渐学会一个「默认思维路径」：

「先确定意图 → 判断信息是否完整 → 不完整就追问 → 完整则调用检索工具 → 在检索结果基础上做推荐 → 再调用下单/支付工具。」

这就是「对话即操作」的核心：自然语言只是表层，底层是有纪律、有结构的工具编排。

---

五、拟人化决策：情绪、偏好与风险控制

与传统「表单式点单」不同，通义千问更追求一种拟人的点单体验。

1. 情绪与语气感知

系统会在对话中识别用户的情绪倾向，例如：

• 「好累，来点甜的犒劳一下自己」：偏正向犒劳情绪；

• 「最近在减脂，别给我推太甜的」：有明确的健康和控制需求。

模型在推荐时，会考虑这些因素：

• 对「犒劳」类语境，可能偏向口碑更好、口味更丰富的选项；

• 对「减脂」语境，则优先推荐低糖、低热量商品，并给出相应解释。

情绪识别本身可以通过多任务训练或独立情绪识别模块完成。

2. 偏好记忆与个性化推荐

随着用户多次使用自动点餐，系统可以逐步积累一些偏好记忆：

• 常点品类、常点店铺；

• 口味偏好（偏辣/少辣、偏甜/少糖、加冰/去冰）；

• 对配送时间和价格的敏感度。

当用户简单说一句「帮我点个晚饭」时，Agent 就能结合历史行为自动缩小搜索空间，推荐与以往习惯一致的方案，同时保留一定探索度（偶尔推荐新店）。

3. 风险控制与「善意提醒」

由于自动点餐带有一定「代替决策」的意味，风控和善意提醒尤为关键，例如：

• 当订单金额异常高时，主动提醒用户：

  「这单价格有点高，你确认要下吗？」

• 当一次点餐数量明显过多，提示用户是否要分单或减少菜品；

• 对低评分或差评集中提及「不干净」「拉肚子」的店铺，默认降低排序权重。

这些逻辑通常由规则系统与模型共同驱动：规则负责「硬约束」，模型负责「软引导」。

---

六、生态打通：为什么它能在一个 App 里做完一切

通义千问自动点餐的一大特点，是用户大部分时候不需要跳 App。背后依赖的是对现有生态的深度整合。

1. 账号与授权体系

• 用户安装千问 App 后，可以与淘宝、支付宝等账号关联；

• 在首次数字人代下单、代支付时，需要显式授权；

• 授权范围与操作上限（如单笔金额上限、每日次数上限）可通过界面提示给用户。

这使得 Agent 能够在授权范围内，调用外卖、支付等服务，而不需要频繁让用户输入密码或短信验证码。

2. 多服务聚合与统一入口

在千问中，点餐只是一个能力之一。相同的 Agent 架构还可以用于：

• 订机票、订酒店；

• 买日用品、代购活动门票；

• 叫网约车、查路线并预订餐厅；

• 交水电费、办业务、查快递。

对用户而言，只需一个入口（对话框）；对工程团队而言，则通过统一的工具协议和编排逻辑，把后端的多条业务线「挂」在同一套 Agent 基础设施上。

3. 可观测性与运维

在工程实践中，自动点餐还需要良好的可观测性：

• 每一步工具调用的入参和出参日志；

• 任务链路跟踪（trace id）；

• 用户取消/修改/投诉的闭环反馈，用于改进推荐和风险规则；

• 离线分析哪些环节最容易中断（如价格不满意、配送时间太长等）。

这些数据既是产品优化的依据，也是改进大模型提示词和工具设计的重要素材。

---

七、与「云手机型点外卖 Agent」的对比

行业里还存在另一种路线：通过云手机 + 屏幕识别 + 辅助点击，让 Agent 像真人一样在美团/饿了么 App 里点外卖。

两种路径各有特点：

维度	通义千问式（API/工具型）	云手机式（屏幕操作型）
能力接入方式	直连官方 API / 服务接口	在云端运行真实 App，识别 UI 并模拟点击
操作可控性	高，可精确限制每一步调用与参数	较低，受 UI 变化影响大
生态要求	需要平台开放接口或在自家生态内	可在任何第三方 App 上操作
可观测性	强，天然结构化日志、链路清晰	弱，更多是像人一样在界面上「点」
性能与稳定性	高，可优化为专用接口、专用推荐	取决于云手机性能和网络状况

通义千问选择的路线，更适合作为「超级入口」整合自家及合作伙伴生态，打磨长期可维护的基础设施。

---

八、写在最后：从「自动点餐」到「自动生活」

自动点餐只是一个入口，它背后的通用能力是：

• 用自然语言描述任务；

• 由大模型理解并拆解任务；

• 驱动一组工具在现实世界中「执行」这些任务；

• 将过程结果以自然、透明的方式反馈给用户。

当这套能力逐步成熟并普及后，「帮我订晚饭」「帮我安排明天的出差」「帮我续费一下快到期的服务」都可以变成一句对话的事。自动点餐，只是未来「自动生活」的一个缩影。