千问Go! 个人AI助理开放体验申请，能办航班理赔和餐厅预订

阿里旗下的千问APP正在灰度上线一个叫「千问Go!」的新功能。10月13日，千问官方公众号确认，Personal Agent「千问Go!」的体验申请页面已经出现在千问APP内，用户通过指定入口提交申请后，官方会逐步释放体验资格。

从「能聊」到「能办」：千问Go! 想解决什么问题

过去两年，AI助手的主战场集中在对话质量和知识问答上。用户问一句、模型答一句，交互闭环很短。但真正消耗时间的日常事务——退改签、订场馆、比价下单、投简历——往往需要在多个APP之间来回切换，AI助手很难插手。

「千问Go!」的定位正是切这个缺口。官方公告的说法是，让每个人拥有自己专属的AI助理一直是千问的目标，而依托阿里生态与开放平台，千问此前已经具备购物、出行、物流等数十个领域的个人办事能力。「千问Go!」作为Personal Agent内嵌在千问APP中，被打包成一个更集中的执行入口，处理更多类型、更多领域的个人事务。

换句话说，它不是再造一个聊天机器人，而是把千问已有的生态能力收拢到一个Agent框架里。

什么是 Personal Agent（个人智能体）

Personal Agent 指以大语言模型为决策核心、能够代替用户自主完成多步骤任务的 AI 系统。与传统问答式助手不同，它具备三个关键特征：一是目标导向，用户只需描述想要的结果（如「把延误航班的赔偿要回来」），而不用逐步下达指令；二是工具调用能力，Agent 可以调用外部 API、打开应用、填写表单、与客服对话，把模型的语言能力转化为实际操作；三是多步规划与状态跟踪，它需要在执行过程中记住已完成和待完成的环节，并根据中间反馈调整下一步动作。这类系统通常由「规划—执行—反思」循环驱动，其能力上限既取决于底层模型的推理水平，也取决于可调用的服务生态是否丰富、接口是否稳定。

实测能做什么：航班理赔拿到70元

根据记者体验和已有用户测试，「千问Go!」目前覆盖的任务类型包括：

• 航班延误理赔：查询航班延误状态，并代替用户与平台客服沟通、提交理赔申请。测试案例中，一位用户通过这条链路拿到了70元赔偿。
• 场馆及演出预约：直接完成预订类操作，而非只给出建议链接。
• 餐厅筛选与预订：从筛选到下单的流程可以在对话内走完。
• 商品比价与下单：利用阿里电商生态做跨平台比价，并执行购买动作。
• 求职投递：辅助完成简历投递类任务。

这些场景的共同点是：有明确的执行终点（赔款到账、订单生成、简历送出），而不是停留在信息检索层面。航班理赔拿到70元这个案例之所以有说服力，是因为它验证了Agent能串联「查状态→找客服→提交材料」多个步骤，且最终有可量化的结果。

为什么「航班延误理赔」是 Agent 的试金石

航班延误理赔看似简单，实则是一个典型的长链路任务：Agent 需要先查询航班实时状态与延误证明，判断是否符合航司或第三方平台的赔付条件，再定位对应的理赔入口，代为填写乘机人信息、上传证明材料，并与客服进行可能多轮的沟通确认。整条链路涉及身份信息、真实资金和第三方系统对接，任何一步出错都可能导致申请失败。因此，能否跑通理赔并最终拿到赔款，往往被视为检验 Agent 执行可靠性的硬指标。相比「推荐一家餐厅」这类只输出信息的任务，它要求 Agent 具备跨系统状态追踪、异常重试和结果核验能力，这也是当前 Personal Agent 落地的主要难点所在。

Personal Agent 的竞争焦点正在转移

「千问Go!」的出现，放在更大的行业背景下看更有意味。

Personal Agent 赛道目前的分歧主要在两条路线上：一条是通用执行型，强调跨应用、跨平台的自动化操作能力，代表思路是「你说目标，我来跑流程」；另一条是生态内闭环型，把Agent能力绑定在自有服务矩阵里，用生态深度换取执行成功率。

千问Go! 明显偏向后者。购物、出行、物流这些能力本来就长在阿里生态里，Agent调用它们时的摩擦成本天然更低。代价是，它在阿里体系之外的服务上能走多远，目前还是未知数。官方公告中提到的「更多类型和更多领域」具体包括哪些，也没有给出清单。

另一个值得观察的点是体验资格的分批释放策略。官方明确表示会「基于收集到的使用反馈，持续优化产品体验」。这种先小范围灰度、再逐步放量的节奏，说明产品在任务成功率和边界处理上可能还有需要打磨的地方。

通用执行型与生态内闭环型的取舍

通用执行型 Agent 通常依赖视觉识别加模拟点击（如读取屏幕内容、操控鼠标键盘）或开放的第三方 API，理论上可以操作任意应用，但每一步都面临界面变动、验证码、风控拦截等不确定性，成功率难以保证。生态内闭环型 Agent 则直接调用自家服务的底层接口，绕开了图形界面这一层不确定性，执行更快也更稳定，但能力被限制在自有服务矩阵之内。业内的普遍判断是，短期内闭环路线的任务成功率明显占优，更适合先跑通商业闭环；而随着跨应用协议和 Agent 间通信标准的成熟，通用路线可能在更长周期内获得更大的想象空间。千问Go! 选择绑定阿里生态，本质上是拿能力广度换取执行确定性。

值得关注的几个问题

对于想申请体验的用户，有几个实际问题值得留意：

任务失败的兜底机制是什么？ 航班理赔这类操作涉及真实资金，如果Agent沟通出错或提交了错误信息，责任如何划分，官方目前没有说明。

权限边界在哪里？ Agent代替用户与客服沟通、执行下单，需要拿到哪些账号权限，用户能否逐条确认关键操作，这些细节会影响实际使用意愿。

生态外的任务怎么处理？ 如果用户想让千问Go! 处理一个非阿里系平台的事务，它是直接拒绝，还是尝试通过通用方式操作，这决定了它的能力上限。

目前「千问Go!」仍处于体验申请阶段，功能清单和限制条件会随着灰度推进逐步清晰。对Personal Agent方向感兴趣的开发者，或者日常有大量事务性操作需求的用户，可以先去千问APP内提交申请，实际跑几个任务看看成功率。

Agent 代操作场景下的责任与授权机制

当 Agent 代替用户与客服沟通、提交理赔材料、执行下单扣款时，涉及的是授权代理问题。目前行业常见的做法有三种：一是事前逐条确认，在执行关键操作前弹窗让用户签字，安全但会打断流程；二是白名单授权，用户预先授予某些固定动作（如不超过某金额的扣款）的免确认权限；三是事后可追溯，Agent 记录完整操作日志，出错后可回滚或申诉。责任划分上，如果 Agent 提交了错误信息导致损失，责任究竟归平台、模型提供方还是用户，现行法律和平台协议都尚无明确约定。这也是 Personal Agent 从演示走向日常使用前必须解决的合规问题。