服务型 Agent 评测:V1 到 V2

用同一把尺子回答四件事:V1 的基线是什么,V2 改了什么,四个 Agent 的供给与办成发生了什么变化,以及小微 MCP 到底有没有用。

0. 先定义同一把尺子

能听懂,不代表有服务;有服务入口,也不代表最终办成。

只有 V1、V2 都测过(或条件几乎一样)的需求,才用来判断有没有进步;V2 才加的需求只说明这次测的范围变大了。

一句话总结:三个层次分开看,顺序是「模型能力 → 供给 → 服务完成」——先看有没有真实路径,再看有没有办成,最后用意图、上下文、流程解释原因。

供给

是否进入与 Query 对应的真实服务入口。只有文字建议、无关页面或不能继续操作的卡片,均不算有供给。

服务完成

是否达到该场景规定的办成终点,例如订单确认、支付确认或可核验结果。停在首页、列表页或选择页,都不算办成。

模型能力

意图看条件是否理解正确;上下文看多轮条件是否保持;流程看是否沿正确链路稳定推进、少中断和少绕路。

1. V1 回顾

范围为 12 个场景、24 个 Case、4 个 Agent。V1 只回答三件事:能提供什么服务、真正办成了什么、卡在哪里。

“理解需求”与“完成服务”分开判断。只给建议、只打开首页或只声称完成,都不算办成。

一句话总结:四家加起来只办成 3 个外部服务——小微的硬件设备、千问的打车、阿宝的家政维修,豆包一个都没有。供给最广的小微,办成数也没比别人多。

小微

入口较广
供给特点

覆盖电商、出行、挂号、家政、证件和硬件设备。

办成服务

只办成硬件设备控制;金融计算不算外部服务履约。

主要问题

能听懂、上下文基本保持,但流程常停在登录或首页,没转成订单。

千问

交易推进较深
供给特点

覆盖餐饮外卖、票务酒店、打车和地图导航。

办成服务

只办成打车,到确认用车边界。

主要问题

指定平台或地址容易被改写,复杂条件要用户纠正。

阿宝

生活服务丰富
供给特点

覆盖酒店、打车、挂号和家政维修。

办成服务

只办成家政维修,到支付确认边界。

主要问题

入口多,但条件承接会漂移,出现错门店、错商品。

豆包

内容能力更强
供给特点

以查询、解释和内容生成为主,外部服务入口少。

办成服务

外部服务都没办成,只有金融计算可完成。

主要问题

意图和上下文正确,但流程停在文字建议。

2. V2 变化

V2 有两个客观变化:测试范围扩大,以及小微出现一组可确认接入 MCP 的服务场景。

新增 Query 只能说明覆盖变广,不能直接证明模型进步。模型变化只用 V1、V2 共同或高度相近的 Query 判断。

范围扩大

12场景
26场景
24Case
52Case

新增导航、快递、话费、生活缴费、办公、阅读、招聘、汽车养护等服务。

MCP 加入

本轮确认 9 个 MCP 小程序,覆盖外卖、电商、票务、酒店、话费、生活缴费和挂号。

美团京东购物同程旅行航班管家艺龙会亚朵 ATOUR腾讯手机充值城市通粤妇幼

报告只使用“已确认 MCP 场景”和“未确认 MCP 场景”。未确认不等于一定没有 MCP。

3. 回答三个问题

先看供给,再看办成,最后单独判断小微 MCP 的作用。每个判断都回到 Query 和真实页面。

表内所有状态都可点击查看证据。V1、V2 都测过的服务显示前后变化;只有 V2 才加的服务,只显示这次能不能用。

3.1 哪个 Agent 的哪些服务供给扩大了

支持的唯一判据:进入与 Query 对应的真实服务入口。只有文字建议、错误入口或一张不能继续操作的卡片,均记为不支持。

两次都测过的服务用来判断有没有进步;V2 新加的服务只说明这次测了哪些。

一句话总结:供给增加最多的是阿宝:两次都测过的 11 个服务里,火车票/机票、政务办事、挂号问诊这 3 个以前不能用、现在能用了;V2 新加的 15 个服务里它能用 11 个。豆包补上了打车和证件办理。小微一个都没多,还丢了「证件办理」,是唯一退步的。
V2 服务与 Query小微千问阿宝豆包
支持:真实入口不支持:只有文字、入口错误或无法操作点击状态:查看对应截图

3.2 哪个 Agent 的哪些服务办成了

先比两次都测过的服务,再看 V2 新加的部分。不把“已打开”“已选择”当成完成。

两次都测过的服务按“办成了哪几类”比;V2 新加的部分按“办成了几个 Case”数,两者不混着算。

一句话总结:办成变多的是小微和豆包:小微「餐饮品牌」以前办不成,现在办成了;豆包「打车」以前没有入口,现在能叫车,「证件照」以前理解错,现在能下载成品;小微「硬件设备」两次都办成。

小微 · 9 个

  • 餐饮品牌
  • 外卖平台
  • 电影票
  • 地图导航 2 个 Case
  • 快递查询
  • 生活缴费
  • 办公工具
  • 硬件设备

千问 · 7 个

  • 火车票/机票
  • 打车
  • 地图导航 2 个 Case
  • 快递查询
  • 生活缴费
  • 办公工具

阿宝 · 5 个

  • 打车 2 个 Case
  • 快递查询
  • 手机充值 2 个 Case

豆包 · 5 个

  • 打车
  • 地图导航 2 个 Case
  • 办公工具
  • 证件照
小微美团订单确认页
小微 · 外卖平台商品、规格和地址已进入真实订单确认页。
千问机票支付确认页
千问 · 机票真实订单已进入付款确认边界。
阿宝手机充值支付页
阿宝 · 手机充值手机号和 50 元金额正确,已到支付确认。
豆包证件照成品
豆包 · 证件照35×45 白底成品已生成,可下载并可继续换底。

共同或高度相近 Query:V1 实际页面与 V2 实际页面

小微 · 餐饮品牌:未办成 → 办成意图和规格均能理解,变化发生在流程是否进入订单。
V1 小微餐饮品牌V1:打开小程序,未到订单
V2 小微餐饮品牌V2:条件带入并形成待确认订单
豆包 · 打车:不支持 → 办成从文字建议变成真实车型、价格和确认叫车边界。
V1 豆包打车V1:没有进入打车服务
V2 豆包打车V2:车型和价格可核验
豆包 · 证件照:未办成 → 办成从误解任务变成可下载的真实成品。
V1 豆包证件照V1:把任务理解成小程序方案
V2 豆包证件照V2:生成 35×45 白底成品
小微 · 硬件设备:办成 → 办成能力保持稳定,页面都出现可核验状态变化。
V1 小微硬件设备V1:华凌空调显示制冷 26°C
V2 小微硬件设备V2:TCL 面板显示 26°C

3.3 小微 MCP 有没有用,有用在哪里

先把场景聚成 5 类;每类分别比较已确认 MCP 与未确认 MCP Case 中,四个 Agent 在四项指标上的名次。

数字越小越靠前;同分并列。每组下方直接列出参与比较的具体 Case。

一句话总结:MCP 有用,但只帮在“办事”这一环:接了 MCP 的商品类场景里,小微四项指标都排第 1;没接 MCP 的场景里,“听懂需求”还是第 1,但“流程推进”和“办成”掉到第 3——MCP 帮的是把商品、规格、平台、地址带进真实订单,不是帮它听懂。

商品类

已确认:外卖平台、综合电商|未确认:餐饮品牌、买菜生鲜、到店预约

已确认 MCP 4 Case

Case:外卖平台、综合电商;均含清晰与多轮。

上下文
1 小微2 千问3 阿宝4 豆包
意图
1 小微2 千问3 豆包4 阿宝
流程
1 小微2 阿宝3 千问4 豆包
服务完成
1 小微2 阿宝3 千问4 豆包
未确认 MCP 6 Case

Case:餐饮品牌、买菜生鲜、到店预约;均含清晰与多轮。

上下文
1 小微2 豆包3 千问3 阿宝
意图
1 小微2 豆包3 千问3 阿宝
流程
1 千问1 阿宝3 小微4 豆包
服务完成
1 阿宝2 千问3 小微4 豆包

出行住宿类

已确认:火车票/机票、订酒店|未确认:电影票、门票/演出、打车、地图导航

已确认 MCP 4 Case

Case:火车票/机票、订酒店;均含清晰与多轮。

上下文
1 豆包2 小微2 千问4 阿宝
意图
1 阿宝1 豆包3 小微3 千问
流程
1 阿宝2 小微2 千问4 豆包
服务完成
1 小微1 千问3 阿宝4 豆包
未确认 MCP 8 Case

Case:电影票、门票/演出、打车、地图导航;均含清晰与多轮。

上下文
1 豆包2 小微3 阿宝4 千问
意图
1 豆包2 千问3 小微4 阿宝
流程
1 千问2 阿宝3 小微4 豆包
服务完成
1 千问2 小微3 豆包4 阿宝

生活服务类

已确认:运营商话费、生活缴费|未确认:家政维修、查寄快递、租房找房、汽车养护

已确认 MCP 4 Case

Case:运营商话费、生活缴费;均含清晰与多轮。

上下文
1 千问1 阿宝3 小微3 豆包
意图
1 小微1 豆包3 千问4 阿宝
流程
1 阿宝2 小微3 千问4 豆包
服务完成
1 阿宝2 千问3 小微4 豆包
未确认 MCP 8 Case

Case:家政维修、查寄快递、租房找房、汽车养护;均含清晰与多轮。

上下文
1 豆包2 千问3 小微3 阿宝
意图
1 小微2 豆包3 千问4 阿宝
流程
1 小微2 阿宝3 千问3 豆包
服务完成
1 小微2 阿宝3 千问4 豆包

政务医疗类

已确认:挂号问诊|未确认:政务办事、公积金/社保/医保

已确认 MCP 2 Case

Case:挂号问诊,包含清晰与多轮。

上下文
1 小微2 豆包3 千问3 阿宝
意图
1 阿宝2 小微3 千问3 豆包
流程
1 阿宝2 小微2 千问2 豆包
服务完成
1 小微1 阿宝3 千问3 豆包
未确认 MCP 4 Case

Case:政务办事、公积金/社保/医保;均含清晰与多轮。

上下文
1 小微2 豆包3 千问3 阿宝
意图
1 小微2 阿宝3 豆包4 千问
流程
1 小微1 阿宝1 豆包4 千问
服务完成
1 阿宝2 小微2 千问2 豆包

工具内容类

没有已确认 MCP 对照;仅展示未确认 MCP 组

已确认 MCP 无 Case

暂无已确认 MCP Case,不能比较。

未确认 MCP 12 Case

Case:办公工具、金融记账、证件办理、招聘求职、阅读、硬件设备;均含清晰与多轮。

上下文
1 豆包2 小微2 千问4 阿宝
意图
1 小微2 豆包3 千问4 阿宝
流程
1 豆包2 千问3 小微4 阿宝
服务完成
1 小微2 千问3 豆包4 阿宝

为什么先看商品类

商品类已确认 MCP 组中,小微在上下文、意图、流程、服务完成四项均位于第 1;未确认组中,意图和上下文仍为第 1,但流程和服务完成降到第 3。差异集中在“把条件带进订单”,不是“有没有听懂”。

已确认 MCP · 4 个 Case

  • 外卖平台:美团黄焖鸡,指定地址和送达时间。
  • 外卖平台多轮:平台、品类和地址逐轮补充。
  • 综合电商:京东自营指定型号硬盘,使用 PLUS 券。
  • 综合电商多轮:容量、接口、比价和下单平台逐轮补充。

未确认 MCP · 6 个 Case

  • 餐饮品牌:瑞幸、喜茶,含清晰与多轮 Query。
  • 买菜生鲜:商品、数量、地址和配送时效。
  • 到店预约:门店取号、人数和排队进度。

同一个已确认 MCP Case:外卖平台 · 清晰 Query

外卖平台小微

小微:商品、地址进入订单确认,办成。

外卖平台千问

千问:生成商品卡,地址缺失,未到付款。

外卖平台阿宝

阿宝:进入点单,但平台和商品条件发生偏移。

外卖平台豆包

豆包:只有门店与步骤建议,没有订单。

同一个未确认 MCP Case:买菜生鲜 · 清晰 Query

买菜生鲜小微

小微:条件听懂,但只有文字,未进购物车。

买菜生鲜千问

千问:有真实商品入口,但未锁定指定平台。

买菜生鲜阿宝

阿宝:进入订单页,但门店和商品不完整。

买菜生鲜豆包

豆包:停留在购物清单和操作建议。

MCP 在商品类呈现出明确的正向迹象:它没有显著改变小微“听懂需求”的能力,却更容易把商品、规格、平台和地址带入真实订单链路。其他行业的结果并不一致,因此目前不能把全部提升都归因于 MCP。

4. 小微的一些问题

小微当前最需要解决的不是“听不懂”,而是页面状态、流程终点和结果声明之间不一致。

三项都用意图、上下文、流程拆开看,避免把不同问题揉成一句“模型能力不稳定”。

小微电商停在搜索结果

声称推进,但页面没有到

意图型号、容量、自营和 PLUS 券理解正确。
上下文二轮“帮我下单”承接正确。
流程最终仍停在搜索结果,不能写成已下单或已确认。
小微打车停在选车页

选车页不等于已叫车

意图起终点和打车需求理解正确。
上下文地址在多轮中基本保持。
流程有车型和价格,但仍需点击“立即打车”,未进入接单状态。
小微手机充值停在选号页

有入口,仍缺最后一段闭环

意图本机号和 50 元金额识别正确。
上下文条件没有丢失。
流程停在面额选择页,没有形成待支付订单。
最终结论V2 的主要进步是四家都出现了更多真实服务入口和更深的执行。真正拉开差距的不是谁更会回答,而是谁能把条件稳定带入正确页面,并推进到该场景的办成终点。小微在商品类已确认 MCP 场景中最接近这一目标,但电商、打车、充值等 Case 仍暴露出“页面未到,声明先到”的问题。