千问Go 技术解析：从问答到代办的架构、边界与评估方法
Agent 闭环 · 生态直连 vs 网页自动化 · 授权顺序设计 · pass^k 评估
| 厂商 | 阿里巴巴（千问 C 端事业群） | 形态 | 千问 App 内入口，非独立 App |
|---|---|---|---|
| 模型底座 | Qwen 3.8 系列 Agentic 能力 | 执行环境 | 云端（官方口径） |
| 公开时间 | 2026-09-22 云栖大会宣布 2026-10-13 开放体验申请 | 当前状态 | 灰度测试，需在 App 内申请 |
| 国内可用性 | 零门槛（国内直连、手机号账号、境内服务）—— 不涉及网络/账号/合规三道门槛 | ||
一、先定位：它是什么，不是什么
三个常见误读，各用一句话排除：
- 不是独立 App。内嵌在千问 App 内，沿用既有账号与授权体系。这决定了它的放量方式只能按申请分批开放，也决定了它能直接复用千问已有的生态接入。
- 不是「更强的问答」。问答的工作止于回复，代办的工作要进入真实世界的博弈 —— 包括被客服搪塞之后继续争取。这是能力量级差异，不是话术差异。
- 不是 RPA 或浏览器插件。这是最容易搞混的一点，第三节单独拆。
它也不是凭空出现的。时间线可以看清它的来路：2025 年 11 月千问 App 上线 → 2025 年 12 月成立千问 C 端事业群 → 2026 年 1 月接入淘宝、淘宝闪购、支付宝、飞猪、高德，上线 400 多项 AI 办事功能 → 2026 年 9 月云栖大会宣布依托 Qwen 3.8 的 Agentic 能力做 Personal Agent → 10 月开放体验。用一句话概括：先用一年把生态接进来，再把「能调用的服务」变成「能独立跑完的任务」。
二、技术架构：四层拆解
| 层 | 公开信息 | 工程含义 |
|---|---|---|
| 模型层 | Qwen 3.8 系列模型的 Agentic 能力 | 决定「能不能想清楚」，含任务分解与策略调整 |
| 决策层 | Agent 架构（规划 / 工具调用 / 环境观察 / 失败恢复） | 决定「能不能在过程中改主意」，这是与脚本的分水岭 |
| 执行层 | 云端执行环境 | 任务不在本机前台跑，因此不受「用户切走 App」直接影响 |
| 接入层 | 阿里生态直连（淘宝、飞猪、支付宝、高德）+ 开放平台（官方披露覆盖 20 多个领域、申请入驻伙伴超 1,000 家） | 决定「能办到多远」，也决定能力上限被生态边界框住 |
| 交互层 | 执行过程实时可见，可随时介入或中止 | 这不是 UI 装饰，是授权设计 —— 见第四节 |
四层里最容易被忽略的是执行层。任务跑在云端，意味着它不依赖你的手机屏幕保持在前台，也不要求设备一直在线；代价是它对「只存在于本机的东西」天然无力（本地文件、本机已登录状态、需要物理确认的操作）。这条边界比模型能力更能解释它能做什么、不能做什么。
三、关键分歧：生态直连 vs 网页自动化
市面上「会办事的 Agent」有两种截然不同的实现路线，混为一谈会导致选型错误：
| 维度 | 浏览器 Agent | RPA 脚本 | 开放 API 直连 |
|---|---|---|---|
| 稳定性来源 | 页面结构识别 | 固定坐标与选择器 | 接口契约 |
| 典型失败 | 元素改版、弹窗遮挡 | 分辨率变化、流程微调 | 接口下线、字段变更 |
| 出错表现 | 看得到，但会瞎点 | 静默错，最危险 | 显式报错，可恢复 |
| 覆盖范围 | 任何有网页的系统 | 任何有界面的系统 | 只限开放了接口的系统 |
核心判断：稳定性来自接口，不来自页面。页面是给人看的，随时会改；接口是给程序用的，变更有契约约束。所以「能操作任意网站」听起来更强，实际运维成本高一个量级 —— 每改一次版就要重新验证一次。
四、一个任务的生命周期：以航班延误理赔为例
官方公开的最完整案例是航班延误理赔，它把 Agent 该有的环节走全了：
- 目标摄入（模糊输入）：「之前的航班有延误，不记得是哪趟了，帮我沟通赔偿」。信息不完整是常态 —— 这正是它与「填表单」的分野。
- 事实核查（关键一步）：先翻机票订单、比对航班动态，锁定延误班次，确认符合赔付条件。先核实、再办理 —— 顺序反了就是越权操作。
- 路径选择：确认后联系平台客服；电话不通时转图文客服。
- 策略调整：客服提出代金券方案，它回到谈判桌明确要求现金赔偿。
- 收尾：现金到账，流程结束。
第二步是整条链里最值得抄的设计。多数 Agent 项目失败在这里：拿到模糊需求就直接动手，出了事才发现前提就是错的。在高风险场景里，「先核实」应当写成硬约束，而不是靠模型自觉。
第四条也值得单独说。代金券到现金的转换不是「更会说话」，而是知道自己的诉求边界：用户的诉求是钱，代金券是对方系统的默认答案，被搪塞时不能收手也不能发火 —— 得翻规则、换路径、把诉求顶到能拍板的层级。这是当前 Agent 最难被复制的部分，也是最难被评测的部分。
五、三条工程边界
| 边界 | 含义 | 对使用者的意义 |
|---|---|---|
| 钱归平台规则 | 70 元是延误赔偿、52 元是价保差价，规则与出资方不同，不能归成一类 | AI 是谈判替身不是出钱方；它不能把「没差价」变成「退钱」 |
| 成功率未公开 | 只有单例叙事，没有完成率/恢复率/介入率 | 案例证明上限存在，证明不了可依赖 |
| 平台围墙仍在 | 能力上限≈阿里生态内交易场景的直连程度 | 出了淘宝/飞猪/支付宝/高德的圈子，能力会明显衰减 |
第三条不是缺点，是商业结构的必然：生态直连的前提是「这个平台愿意开放」。它对自有生态有天然优势，对别人的平台只能退回到界面操作 —— 而界面操作的稳定性，前面已经说过。
六、怎么评估：指标比案例重要
单例叙事（省了 70 元、退了 52 元）说服力有限，因为不可复现。要判断一个代办型 Agent 能不能进生产，看三个数：
- 任务完成率：给它 N 个真实任务，成功几个。
- 失败恢复率：第一次路径失败后，换路径跑通的概率。这是 Agent 与脚本的真正区别。
- 人工介入比例：多少次需要人来接手。低于某个阈值，它才是「代办」而不是「辅助填表」。
还有一个更严格的视角：pass^k 而不是 pass@k。pass@k 问「k 次里成功过几次」，pass^k 问「连续 k 次全部成功」——同一个任务跑 5 次全对的概率，往往比单次成功率低一个量级。代办类任务恰恰属于「失败一次就很贵」的类型（钱、订单、时间都不可回退），所以应该看 pass^k。业内用 τ-bench 一类框架做这件事，思路就是多轮重复执行看一致性。
七、它和同类的位置关系
| 产品 | 形态 | 执行位置 | 接入方式 | 强项 |
|---|---|---|---|---|
| 千问Go | App 内入口 | 云端 | 生态直连 | 国内交易链路短，零门槛 |
| Meta Muse | 独立 App | 端侧操作 | 界面操作 | 覆盖任意手机应用 |
| OpenAI Dots | Agent 产品 | 云端 | 任务代理 | 主动式任务管理 |
| Manus Cue | 多智能体 | 云端 | 分工协作 | 复杂任务拆解 |
| 扣子 Coze | 开发平台 | 用户自建 | 工作流编排 | 结构化流程自动化 |
两条分轴决定差异：执行在端侧还是云端（端侧覆盖面广但受设备与前台上限，云端稳定但碰不到本机），接入靠界面还是接口（界面通用但脆，接口稳定但窄）。千问Go 选的是「云端 + 接口」，所以它在自家生态里最稳，出了生态最弱。
还有一层容易被忽略：扣子和千问Go 不是竞品。扣子做的是「把已经想清楚的流程自动化」，千问Go 做的是「把还没想清楚的流程跑完」。前者要求你能一条条写出步骤，后者恰恰针对写不出步骤的场景。
这也正好接上本站 TOP 10 文档里的一个结论：国内替代国外 Agent 时，真正补不上的只剩「跨网站自主代办」这一项。千问Go 落在这个位置上 —— 但它目前只在自有生态内被验证过，是否算「补上了」，取决于出了生态还剩多少。
八、五个坑
- 把灰度当正式功能。按申请放量、随时可能调整策略，现在不适合接进任何有 SLA 的流程。
- 把案例当指标。两个成功案例不构成成功率，尤其代办涉及钱。
- 默认它走接口。混合实现是常态，跨生态部分要按「界面会改版」来做失败预案。
- 把授权一次开到底。订单、支付、通讯录是三类不同风险等级的授权，应该分开评估，别图省事一把全给。
- 用它替代需要人拍板的决策。它能交涉，但不该替你决定「要不要接受这个方案」—— 目标与边界由人给，它只负责跑。
九、常见问题
千问Go 是独立 App 吗？现在怎么用上？
不是独立 App。它内嵌在千问 App 里，作为一个入口存在，沿用千问既有账号与授权体系。2026 年 10 月 13 日起开放体验申请：在千问 App 内指定入口提交申请、进入 Waiting List，官方按批次逐步放量，目前仍是灰度测试，尚未全面上线。正因为复用了既有账号体系，它的开放节奏只能是「按申请放量」，而不是直接全量上架。
它和千问以前的办事功能有什么区别？
区别在任务的链路长度与流程确定性。千问 App 在 2026 年 1 月接入淘宝、淘宝闪购、支付宝、飞猪、高德，上线 400 多项 AI 办事功能，但这些主要是「目标明确、链路较短」的指令，比如打车、点餐、订票。千问Go 面向的是没有固定流程、需要反复查看、沟通和比选的事务——官方给的说法是「从下指令到给目标」。判断标准很直接：这件事能不能一次说清步骤？能，老功能就够；不能，才需要 Agent。
它靠什么完成跨平台任务？是模拟点击吗？
公开口径是「Agent 架构 + 云端执行环境 + Qwen 3.8 系列模型的 Agentic 能力」，此类能力在 Agent 技术体系中通常包含规划、工具调用、环境观察和失败恢复四个环节。至于每条具体路径走的是接口还是界面操作，官方没有披露。从案例反推：查订单、调航班动态、致电客服必须依赖接口或电话通道；而「在淘宝里找到价保入口」听起来更像界面导航。所以更可能是一个混合实现，而不是纯模拟点击。做技术评估时，不要把「混合」当成「纯接口」来假设稳定性。
它会不会乱花我的钱？授权边界怎么控制？
两个机制可以对照：一是过程可见——执行过程在界面上实时展示，用户可以随时介入或中止；二是钱不由它出。两个公开案例里，70 元是航班延误赔偿、52 元是淘宝价保差价，都是平台规则本就该给用户的钱，规则与出资方都不同。AI 在这里的角色是谈判替身和流程代办，不是支付主体。真正需要盯的是授权范围：它能看到哪些订单、能用哪些账户、能不能代为下单支付——这些在灰度阶段属于应当逐项确认的内容。
它有公开的任务成功率吗？
没有。官方尚未公布完成率、失败恢复率或人工介入比例，公开的都是单例叙事（省了多少、退了多少）。这类案例能证明能力上限存在，但证明不了稳定性。业内常用 τ-bench 一类框架配合 pass^k 指标来测——同一个任务跑 k 次全部成功的概率，这个数往往比单次成功率低得多。在官方数据出来之前，任何「它能替你把事办完」的说法都只能当作方向，不能当作 SLA。
千问Go 和 Meta Muse、OpenAI Dots、扣子有什么不同？
差在两个轴上：执行在哪、靠什么接入。千问Go 执行在云端、接入靠阿里生态直连，优势是交易链路短、劣势是出了生态就弱；Meta Muse 是独立 App、偏端侧操作（能打电话、发消息、操作手机应用），覆盖面广但受设备与前台状态约束；OpenAI Dots 是主动式任务管理；扣子是零代码流程编排，适合步骤能枚举的场景。它们不是同一层的竞品：扣子做「把确定流程自动化」，千问Go 做「把不确定流程跑完」。
十、继续看
概念层先看 AI Agent 入门；横向对比看 TOP 10 Agent 总览，其中 Meta Muse 与 OpenAI Dots 是同一赛道的国外参照，扣子 Coze 是「结构化流程」那条路的代表；日常助手的国产替代见 豆包。想知道国外 Agent 在国内的门槛，看 AI Agent 大全。