小微
入口较广供给特点
覆盖综合电商、打车出行、挂号问诊、家政维修、证件办理和硬件设备控制。
办成服务
硬件设备控制达到可核验状态；金融计算能给结果，但不属于外部服务履约。
主要问题
意图多能识别，上下文基本可保持；流程常停在登录、首页或用户接管，入口没有继续转成订单。
0. 先定义同一把尺子
V1、V2 都按三个层次判断。三者不能混在一起：能听懂，不代表有服务；有服务入口，也不代表最终办成。
只有 V1、V2 都测过（或条件几乎一样）的需求，才用来判断有没有进步；V2 才加的需求只说明这次测的范围变大了。
供给
是否进入与 Query 对应的真实服务入口。只有文字建议、无关页面或不能继续操作的卡片，均不算有供给。
服务完成
是否达到该场景规定的办成终点，例如订单确认、支付确认或可核验结果。停在首页、列表页或选择页，都不算办成。
模型能力
意图看条件是否理解正确；上下文看多轮条件是否保持；流程看是否沿正确链路稳定推进、少中断和少绕路。
判断顺序：模型能力决定能不能理解任务、带对条件；供给决定有没有真实路径；服务完成决定最后有没有办成。报告先看供给，再看服务完成，最后用意图、上下文和流程解释原因。
1. V1 回顾
范围为 12 个场景、24 个 Case、4 个 Agent。V1 只回答：能提供什么服务，真正办成了什么，没办成卡在哪里。
“理解需求”与“完成服务”分开判断。只给建议、只打开首页或只声称完成，都不算办成。
千问
交易推进较深供给特点
覆盖餐饮外卖、票务酒店、打车与地图导航，交易和出行入口相对稳定。
办成服务
打车能落实起终点、车型和价格，到确认用车边界；部分金融计算任务完成。
主要问题
流程深度优于纯问答，但指定平台或地址容易被改写，复杂条件仍需用户纠正。
阿宝
生活服务丰富供给特点
覆盖酒店预订、打车出行、挂号问诊和家政维修等生活服务。
办成服务
维修能形成真实服务订单并到支付确认边界。
主要问题
执行入口多，但首轮条件承接与平台匹配会漂移，出现错门店、错商品或错误数字。
豆包
内容能力更强供给特点
以信息查询、解释和内容生成为主，外部交易、出行和生活服务入口较少。
办成服务
金融计算可完成；外部服务大多没有形成可核验订单或状态变化。
主要问题
意图与上下文往往正确，但流程停在文字建议，无法把理解转成真实服务结果。
V1 核心结论：四家都能理解多数任务，但服务供给、流程深度和最终办成并不一致，“理解需求”还没有稳定转化为“完成服务”。
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：打开小程序，未到订单
V2：条件带入并形成待确认订单
V1：没有进入打车服务
V2：车型和价格可核验
V1：把任务理解成小程序方案V2：生成 35×45 白底成品
V1：华凌空调显示制冷 26°C
V2：TCL 面板显示 26°C3.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 仍暴露出“页面未到，声明先到”的问题。