服务型 Agent 评测:V1 到 V2

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

0. 统一判断标准

所有比较只看三件事:

1. 供给

能不能进入真实服务。

2. 服务完成

是否到达可执行终点:交易到确认/付款边界,查询有真实结果,内容有真实交付,设备有状态变化。参数是否正确另看模型能力。

3. 模型能力
  • 意图:是否理解正确;
  • 多轮上下文:是否保持;
  • 流程:是否顺畅推进。

1. V1 回顾

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

V1 整体结论:四家基本都能理解用户意图,但多数事情仍办不成,尚未形成稳定的服务完成能力。
分 Agent 看:小微服务供给最广,但流程闭环较弱;千问和阿宝仅在少数垂类服务中能够办成;豆包仍主要停留在内容回答。

小微

入口较广
供给特点

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

办成服务

办成硬件设备控制和证件照交付。

主要问题

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

千问

交易推进较深
供给特点

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

办成服务

餐饮到付款,打车到确认,酒店到预订,并交付证件照。

主要问题

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

阿宝

生活服务丰富
供给特点

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

办成服务

打车到确认、家政维修到付款边界。

主要问题

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

豆包

内容能力更强
供给特点

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

办成服务

外部服务仅办成证件照交付。

主要问题

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

2. V2 变化

2.1 评测范围扩大

12场景
26场景
24Case
52Case

新增服务范围

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

这些新增 Query 只能说明覆盖变广,不能直接证明 V1 到 V2 的模型进步。

2.2 本轮 MCP 覆盖

7 个场景 · 9 个小程序 · 14 个 Case

评测场景已确认 MCP 小程序
外卖平台美团
综合电商京东购物
火车票 / 机票同程旅行、航班管家
订酒店艺龙会、亚朵 ATOUR
运营商话费腾讯手机充值
生活缴费城市通
挂号问诊粤妇幼

3. 回答三个问题

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

3.1 服务供给:谁扩大了,方向有什么不同

支持只看是否进入 Query 对应的真实服务入口。

整体结论

阿宝的供给扩大最明显:从酒店、打车、家政,进一步扩到票务、政务和挂号。豆包开始补打车和证件办理;千问仍集中在票务、出行和酒店;小微仍是广覆盖,但可比服务没有扩大,证件办理反而退步。

小微 · 广覆盖未扩大

原有电商、出行、挂号、家政和设备入口基本保持,证件办理出现退步

千问 · 深耕票务出行

餐饮、票务、打车和酒店等入口保持稳定,没有新增可比服务

阿宝 · 扩大最多

在原有生活服务基础上,新增火车票/机票、政务办事、挂号问诊

豆包 · 开始补执行入口

从内容回答向真实服务延伸,新增打车、证件办理

演进方向:小微继续做广覆盖与服务衔接;千问深耕票务和出行;阿宝从生活服务扩向更多交易与办事场景;豆包从内容能力开始补少数可执行服务。

控制变量案例:阿宝 · 火车票/机票

同类多轮 Query:不支持 → 支持都要求查询并购买指定日期与行程的机票,只比较是否进入真实票务入口。
V1 阿宝票务V1:停在对话查询,没有进入票务服务
V2 阿宝票务V2:进入飞猪机票真实服务页
展开查看 26 个场景的完整供给明细与截图
V2 服务与 Query小微千问阿宝豆包
支持:真实入口不支持:只有文字、入口错误或无法操作点击状态:查看对应截图

3.2 服务完成:谁真正办成得更多

只看有没有到达可执行终点:交易到确认/付款边界,查询有真实结果,内容有真实交付,设备有状态变化。参数对不对另看意图与上下文。

整体结论

当前办成范围最广的是阿宝,也是提升最明显的一家,已从打车、家政进一步扩展到电商、票务、挂号、外卖、电影票、导航、快递、充值和租房等服务;小微办成范围居次,优势集中在餐饮、外卖、生活缴费、办公和设备控制;千问仍以票务和出行为主;豆包开始办成打车、导航、办公和证件照,但整体范围仍较小。

小微 · 覆盖较广,生活服务提升

继续保持设备控制优势,新增餐饮点单、打车和家政维修;目前还能办成外卖、电影票、导航、快递、生活缴费和办公,但证件照交付出现退步。

千问 · 稳在票务与出行

打车和酒店保持稳定,新增电商和火车票/机票;目前还能办成电影票、导航、快递、生活缴费和办公,但餐饮点单与证件照交付有所退步。

阿宝 · 办成最多,提升最大

在原有打车和家政维修基础上,进一步办成电商、火车票/机票和挂号;目前还覆盖外卖、买菜、电影票、导航、快递、话费充值和租房。

豆包 · 开始补齐执行能力

从证件照交付进一步扩展到打车、导航和办公,开始从内容回答走向真实服务,但目前能办成的范围仍然较小。

怎么读:“办成”只说明已经到用户可确认、可付款或可拿到结果的终点,不代表条件都正确。例如影院、时间或平台选错,仍记办成,但会在意图与上下文维度扣分。

控制变量案例:豆包 · 打车

同一清晰 Query:未办成 → 办成起终点和打车需求一致,只比较有没有进入真实打车链路并到确认叫车。
V1 豆包打车V1:只有文字说明,没有进入打车服务
V2 豆包打车V2:起终点、车型和价格确定,只剩确认叫车
展开查看 26 个服务的办成明细与对应截图
服务与办成要求小微千问阿宝豆包
统计:清晰或多轮任一办成,该服务即算办成办成:确认/付款边界、真实查询结果、内容交付或设备状态变化点击状态:只展示与判定匹配的清晰/多轮截图

3.3 MCP:服务推荐更准、流程更顺,但还没有形成稳定的办成优势

选取一期和二期均有对应 Query 的外卖、电商、机票、酒店和挂号 5 个场景,先看小微自身变化,再看 V2 四家横向表现。

3.3.1 评测标准

本节选取一期和二期均有对应 Query 的外卖、电商、机票、酒店和挂号 5 个 MCP 场景。

评测分为两部分:

  1. 小微自身对比:比较小微从 V1 到 V2,接入 MCP 后服务是否更容易办成,流程是否更顺、耗时是否缩短。
  2. V2 横向对比:在相同 Query 下,对比小微、千问、阿宝和豆包的服务完成情况与流程体验。

这些场景在 V2 均已具备真实服务入口,供给只作为评测前提,不再单独比较。本节主要看三个方面:

服务完成是否到达用户可确认、可付款或可取得结果的终点。
流程顺畅是否完整承接用户条件,过程中是否出现绕路、中断、重复确认或需要用户手动接管。
推进效率在完成相同任务的前提下,比较整体耗时以及等待、返回和重复操作;更快结束但没有继续推进,不算效率提升。

一期与二期 Query 对照

同一业务场景对齐;Query 不要求逐字一致。

场景第一期(V1)Query第二期(V2)Query
外卖用美团帮我点个吃的 → 附近评分高的店有哪些 → 那还是选个咖啡帮我点个外卖 → 请一定要使用美团小程序 → 附近评分高的咖啡 → 送到现在这个地址
电商想买个硬盘 → 2TB 的,要 Type-C → 京东和拼多多比一下,选便宜的想买个硬盘 → 2TB,要 Type-C → 京东和拼多多比一下,选便宜的 → 就京东吧,下单
机票帮我看下周末去北京的机票 → 要早上出发的 → 返程改到周日晚上帮我看下周末去北京的机票 → 要早上出发的 → 就用航班管家下单
酒店订个杭州的酒店 → 靠近西湖的 → 改成住两晚 → 要能免费取消的订个杭州的酒店 → 靠近西湖 → 改成住两晚 → 要能免费取消的
挂号杭州市萧山区第二人民医院肛肠外科挂号,2026 年 9 月 8 日请一定要使用粤妇幼小程序,挂妇科 9 月 19 日上午的号;补充多轮:挂个号 → 消化内科 → 要明天上午的专家号 → 换成周二

3.3.2 评测结论

整体结论

MCP 对小微最明显的提升,首先体现在服务衔接和流程推进,而不是稳定办成。外卖、电商和酒店从 V1 到 V2 的耗时明显缩短,其中酒店由约 381 秒降至 127 秒;挂号也从打开服务首页进一步推进到绑卡和查询号源。机票是例外:两期均约 2 分钟,V2 虽进入指定小程序,却丢失路线和日期,流程与办成均未改善。横向来看,小微的优势主要是服务推荐更准确、条件承接更完整、流程更连贯;但在进入确认或付款终点方面,其他 Agent 在部分场景中仍推进得更深。因此,MCP 已经让部分场景的服务流程更快、更顺,但尚未形成稳定的办成优势。

3.3.3 评测详情(按场景)

外卖|改善最明显,小微推进最完整

小微从推荐与选品推进到美团订单确认;横向看,小微条件保留更完整,阿宝虽到付款边界,但平台条件发生偏移。

小微:V1 → V2

130 秒 → 95 秒缩短 35 秒;条件承接更完整,平台调用与地址授权连续完成。
同类场景:推荐商品 → 订单确认比较真实服务进入深度,不把参数正确性混入办成判断。
V1 小微外卖V1:停留在推荐与选品
V2 小微外卖V2:商品与地址进入订单确认

V2:四家对比

外卖小微

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

外卖千问

千问:有商品结果,但没有形成待确认订单。

外卖阿宝

阿宝:到付款边界,算办成,但平台条件偏移。

外卖豆包

豆包:仍以门店与操作建议为主,没有订单。

机票|千问推进最深,小微进入服务后丢失条件

小微能够进入航班服务,但路线和日期没有继续带入;千问保留行程条件并推进到付款边界。本次多轮 Query 中阿宝未办成,但其清晰 Query 已到确认订单。

小微:V1 → V2

126.4 秒 → 129.6 秒增加 3.2 秒,整体耗时基本不变;两期均未形成订单,V2 进入指定小程序后反而丢失路线与日期。
同类场景:给出航班候选 → 进入指定小程序但条件丢失V1 与 V2 都没有推进到可确认订单;V2 的指定服务入口更明确,但流程效率和完成结果没有提升。
V1 小微机票V1:给出早去晚回航班候选,未形成订单
V2 小微机票V2:进入小程序,但路线和日期回到默认状态

V2:四家对比 · 多轮 Query

票务小微

小微:进入服务,但路线和日期丢失,未办成。

票务千问

千问:保留行程并进入付款边界,办成。

票务阿宝

阿宝:本次多轮条件偏移;另一清晰 Query 办成。

票务豆包

豆包:停留在文字说明,没有进入订单。

酒店|千问办成,小微仍停在选择阶段

小微能够进入酒店服务,但没有把酒店、日期和房型推进到预订确认;横向看,千问是四家中唯一到达预订终点的 Agent。

小微:V1 → V2

381.0 秒 → 126.9 秒缩短 254.1 秒、降幅约 67%;V2 更快进入正确酒店列表,但仍未核验免费取消,也没有形成可确认的房型订单。
同类场景:约 6 分钟才进详情 → 约 2 分钟进入酒店列表V2 明显减少等待和手动接管,但用户仍需纠正一次服务渠道,完成度没有跨过预订确认线。
V1 小微酒店V1:约 6 分钟后停在酒店详情,未核验免费取消
V2 小微酒店V2:更快进入酒店列表,仍未形成可确认订单

V2:四家对比 · 多轮 Query

酒店小微

小微:进入酒店服务,未形成可确认的房型订单。

酒店千问

千问:日期、房型和价格明确,并出现预订入口,办成。

酒店阿宝

阿宝:进入服务,但未形成可确认订单。

酒店豆包

豆包:停留在推荐或操作说明,未办成。

电商|流程更顺,但小微仍未办成

小微从较长的搜索与跳转推进到稳定的京东商品结果,但没有形成订单;横向看,千问和阿宝已经到付款边界。

小微:V1 → V2

143 秒 → 81 秒缩短 62 秒;从搜索反复、等待用户接管,变为连续进入稳定商品结果。
同类场景:搜索反复 → 稳定商品结果规格、自营和平台条件被带入真实电商页面,但还没有到确认订单。
V1 小微电商V1:搜索和跳转较长,未形成订单
V2 小微电商V2:进入稳定商品结果,仍未下单

V2:四家对比

电商小微

小微:进入京东商品结果,未形成订单。

电商千问

千问:到订单确认或付款边界,办成。

电商阿宝

阿宝:到订单确认或付款边界,办成。

电商豆包

豆包:以商品建议为主,没有进入订单。

挂号|进入服务更深,但清晰 Query 下四家都未办成

小微从官方小程序首页推进到健康卡和号源结果;横向看,小微到达的页面最深,但仍缺最终确认,其他三家也没有完成挂号。

小微:V1 → V2

22 秒 → 137 秒增加 115 秒;V2 推进更深,但中途需要填写验证并返回对话确认,不能视为流程更顺。
同类清晰 Query:首页 → 号源结果两期都要求指定医院、科室和日期,只比较真实挂号流程的推进深度。
V1 小微挂号V1:进入官方服务,但停在首页
V2 小微挂号V2:进入健康卡与号源结果,仍未确认

V2:四家对比

挂号小微

小微:到健康卡和号源结果,未确认挂号。

挂号千问

千问:给出说明或入口,未形成挂号结果。

挂号阿宝

阿宝:进入科室或号源选择,仍未确认。

挂号豆包

豆包:主要停留在流程说明,没有挂号结果。

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. 小微的核心问题:理解了需求,但没有把条件带进服务

小微多数时候能够正确理解并承接用户需求,也能调起对应的小程序;真正的问题出现在对话与服务页的交接环节:型号、金额、地址等关键条件没有稳定写入页面,导致流程停在搜索结果、条件选择或地址确认,无法继续推进到订单确认或付款。

电商|声称下单,但商品没有进入结算

商品规格只变成搜索关键词,“选便宜的并下单”没有真正执行。

电商需求条件被正确理解
1. 需求条件型号、容量、自营和 PLUS 券已识别。
电商流程声称已推进下单
2. 服务调用流程声称点击商品、领券购买并进入确认。
电商实际停在商品搜索结果
3. 真实终点仍停在搜索结果,无购物车、结算或订单。
问题判断

对话里正确承接了“帮我下单”,页面却只完成搜索,回复中的流程进度与真实页面不一致。

充话费|号码和金额理解正确,但金额没有带入页面

手机号进入了充值服务,50 元没有转成页面中的已选状态。

充值号码和金额被正确理解
1. 需求条件指定手机号、运营商与 50 元已识别。
调用腾讯手机充值服务
2. 服务调用已调用腾讯手机充值,但仍需等待和重新选择。
充值页未选中50元且没有待支付订单
3. 真实终点正确号码可见,50 元未选中,也没有待支付订单。
问题判断

号码完成了跨页面传递,但金额没有落成页面状态,用户必须再次手动选择。

打车|地址没有稳定带入,最终仍需人工确认

起终点和舒适型需求已被理解,但地址条件在对话与服务页之间传递不稳定。

打车起终点和车型需求被理解
1. 需求条件起点、终点和舒适型已识别。
进入滴滴后需要重复确认地址
2. 服务调用进入滴滴后仍需重复确认地址,过程中一度出现错误上车点。
打车最终停在车型选择和立即打车页面
3. 真实终点虽到车型与“立即打车”页面,但没有完成确认叫车。
问题判断

地址条件无法稳定地从对话写入服务页,流程不能直接走到确认叫车,仍依赖用户接管。

最终结论小微当前的主要问题不是听不懂,而是“对话里理解了,服务页里没有落下去”;页面状态没有达到目标时,回复却已经声称完成了推进。

附录:各场景的“办成”标准

办成只判断有没有到达用户可以确认、付款、使用或核验的结果,不与参数正确性混在一起。

统一规则

清晰 Query 或多轮 Query 只要一个办成,该服务就记为办成。参数、平台、时间或地点是否正确,另在意图与上下文中判断;只到首页、列表页、登录/授权页,或仍需继续补充核心条件,均不算办成。

场景办成标准
餐饮品牌商品、规格和地址已确定,进入订单确认或付款边界。
综合电商商品、SKU、渠道和价格已确定,进入订单确认或付款边界。
火车票/机票日期、行程、班次和席别已确定,进入确认订单或付款边界。
打车起终点、车型和价格已确定,出现可确认叫车的真实操作。
订酒店酒店、日期、房型和价格已确定,进入预订确认或在线付款。
政务办事进入正确官方流程,并到提交、预约或可核验回执。
挂号问诊医院、科室、日期、号源和就诊人已确定,进入确认挂号或付款。
硬件设备进入真实控制面板,并完成目标设备的状态变化。
到店预约形成真实取号结果,并可查看排队号码或进度。
家政维修服务、地址、时间和订单已确定,进入预约确认或付款。
证件办理生成可下载、保存或打印的真实证件照成品。
外卖平台平台、商品和地址已确定,进入订单确认或付款边界。
买菜生鲜商品、数量和地址已确定,进入订单确认或付款边界。
电影票影片、影院、场次、票数和座位已确定,进入付款边界。
门票/演出城市、场次、票档和数量已确定,进入确认订单或付款。
地图导航进入真实路线页,或给出完整且可核验的路线结果。
查寄快递展示真实物流轨迹,或形成可确认的寄件订单。
运营商话费手机号和金额已确定,进入充值确认或付款边界。
生活缴费户号、账单和金额已确定,进入缴费确认或付款边界。
租房找房展示符合核心条件的真实房源,并可进入房源详情。
汽车养护服务、车辆、门店和时间已确定,进入预约确认或付款。
招聘求职展示符合核心条件的真实职位,并可进入职位详情或投递。
公积金/社保/医保进入正确官方账户,展示余额、参保或可核验查询结果。
办公工具实际生成可编辑或可下载的文件。
金融记账指定账目已写入真实账本并保存。
阅读打开目标书籍,并恢复到上次阅读位置。
金融计算(V1)给出完整、可核验的计算过程与结果。