Alibaba's Qwen Bets on Lifestyle Personal Agents, Says Reliability Beats Demos

Personal Agent 已经渡过早期产品验证，进入了新一轮产品竞争阶段：Meta Muse、OpenAI Dots 等纷纷把产品从“炫技”推向了“长期稳定地替用户做事”。

不过，身处一线研发的阿里千问事业部 AI 算法负责人蒋冠军对现状的真实评价是：今天的 AI 依旧不好用。

“虽然对话里已经可以点奶茶、购物，但从能调用工具完成任务，到真正理解用户、稳定完成任务，对产品可靠性的要求完全不同，AI 仍然存在很大的差距。”他解释道。

在蒋冠军看来，Personal Agent 真正更广阔的市场最终可能在生活场景。这是因为生活里充满了大量用户自己知道、却没有明确表达的偏好。真正的 Personal Agent 需要在长期使用中逐渐知道这些答案，同时判断这些答案什么时候发生了变化、什么值得提醒、什么时候必须停下来。

阿里千问当下也已入局生活类 Personal Agent。蒋冠军认为，千问最核心的差异来自对用户需求的理解。“今天大家的实现框架都差不多，基础模型的核心能力差别也没有想象中那么大，生态能力会有强弱差别。因此，最核心的差异还是来自我们怎样理解用户需求，以及选择哪些重点方向。”

当前，Personal Agent 的执行稳定、个人 Context 等技术问题是千问同样需要解决的，此外还有背后的生态开放、权限边界和商业模式等尚未定型的公众担忧。

千问的特殊之处在于背靠阿里庞大的电商、支付和生活服务生态。当这类庞大业务生态上长出的 Personal Agent，替用户选品、预订服务甚至完成交易时，交付如何更加可靠？应该优先调用谁的服务？万一用户需求与平台商业利益发生冲突，又该如何保证决策真正符合用户利益？显然，这不只是千问会面临的问题。

Personal Agent，为什么下限比上限更重要？

过去一年，Agent 产品不断刷新能力上限的 Demo 吸引了公众关注，尤其是自主完成数十步任务、在后台持续运行数十个小时等能力。但展示能力上限和提高实际任务完成率是两件不同的事情。

以 Muse 为例，在蒋冠军看来，它的爆火有一定的炒作成分，Muse 真正解决的问题是：今天的互联网生态并不是围绕模型建立的，当 AI 没有结构化接口可以调用时，就让它像人一样通过 GUI 使用现有互联网服务。

这可以迅速提高能力上限，但不一定自动提高能力下限。比如“订机票”，通常会默认大部分正常的任务都能完成，但很少有人会把它理解成“在部分网站、部分条件下有较高概率成功”。如果十次任务中有三四次无法完成，那么再惊艳的 Demo 也很难形成高频使用。

蒋冠军用“理论能力上限”与“实际交付能力”之间的差距来解释这一现象。他分享了一组数据：在不考虑人机交互成本和计算代价的前提下，Personal Agent 解决一般工作、学习和生活问题的理论能力上限接近 100%，而系统实际交付能力目前只有 60%～70%。

在他看来，现有系统并非完全缺乏解决问题的能力，而是经常无法在第一次执行任务时找到正确的解决路径。即使模型具备完成任务所需的知识和推理能力，实际交付仍可能因为工具选择、信息获取或执行路径不当而失败。

这种错配具体体现在任务执行的不同环节。比如，一个财经问题可以依赖模型自己的知识，也可以调用实时行情和专业数据库；旅游任务可以让模型浏览大量网页，也可以直接调用票务服务；个人信息不足时，可以让模型推测，也可以从长期记忆中补充。路径不同，任务成功率、执行速度和计算成本可能完全不同。

围绕这一问题，千问开始从真实用户需求出发，反向拆解 Agent 完成任务所需的能力。千问建立了一张覆盖 30 多个头部行业的需求透视图，将大量真实需求归纳为不同意图，进一步拆解成 8000 多项原子模型能力要求。

例如，回答“这家公司现在值得投资吗”，可能需要综合财报、公告、实时行情、行业数据和市场信息。千问会继续判断每个环节究竟缺数据、缺工具还是缺模型能力，再针对性地补齐短板，以此“把整个水位往上抬”。

这套方法不只是把用户问题拆得更细，还包括如何构造训练样本、判断什么样的回答才算好，以及让模型在训练中逐步学会完成任务。千问会根据真实需求构造 Query 和优质 Response，再进一步形成评价标准，明确回答需要覆盖哪些关键要点、使用什么知识和信息、信息是否足够权威。评价标准可以由模型迭代生成，也会引入行业专家参与判断和修正，最终用于模型训练和强化学习。

在路径选择上，千问的做法更像是一种“分工”：能够通过确定性工具或专业 Skill 解决的问题，尽量不要完全依赖模型即兴推理；个人 Context 能够提供的信息，不要让模型凭空猜；模型重点承担理解、规划、推理以及失败后的重新规划。此外，模型优化和后训练需要考虑实际线上环境中的工具、Skill 和 Harness 体系，并根据真实需求分布进行强化学习，实现“训推一体化”。

“Personal Agent 的模型与 Harness 并不是两套彼此独立的体系”，蒋冠军强调，外界所说的“模型能力接近”，通常基于公开评测或通用任务，但真正进入应用后，模型、记忆、工具、Skill 和生态需要紧密配合。如果把底层的千问模型替换成其他模型而保持 Harness 不变，Agent 的整体能力会大幅变化。

在实际执行中，Harness 本质上是在给模型提供大量 Context，工具、Skill、记忆和其他上下文都会成为模型决策的一部分。系统需要让模型知道有哪些工具可用、各自适合解决什么问题，同时围绕当前任务检索真正相关的记忆，而不是把全部历史记录和所有工具说明都塞进上下文。

据千问团队透露，在部分场景中，Harness 层优化可以减少约 40% 的 Token 消耗；在金融等专业场景，通过封装专业能力，可以将回复效果提升接近 20%。

“这种模型与 Harness 深度耦合的方式，是提升 Personal Agent 稳定性和任务完成率的关键。”蒋冠军说道。

从用户需求反推应该记住什么

Personal Agent 的个性化则更多需要在记忆系统上下功夫，目前各家的记忆设计已经出现了明显的路线差异。

Town 走极简路线，只维护约 5～20 页 Wiki 摘要，记录用户画像、目标、项目和常联系人，并允许用户逐行修改；Instinct 更强调可控性，记忆统一通过后台批处理写入，采用 Git 管理，支持 Diff 和回滚，并以关键词和别名检索为主；Muse 强调记忆溯源，每小时将新记忆与原始对话核对，每晚还会通过“Dream”整理对用户的观察；Grok Bot 则按照法务、财务等不同角色划分记忆，但记忆会在会话中静默写入，缺少额外的后台整理。

这些差异说明，Personal Agent 的记忆不只是“记住多少”，还涉及记忆是否可编辑、是否可追溯、如何更新，以及不同 Agent 之间如何共享和隔离信息。

千问在记忆设计上的核心思路，则是从用户需求反推应该记住什么。蒋冠军认为，真正的难题并非单条记忆能不能准确召回，而是到底什么信息值得成为记忆，以及应该按照什么粒度记录。

例如用户说“工资 8000 元”，系统的记忆可以是原样记住这个事实，也可以抽象成“有稳定收入”，甚至进一步形成某种经济状态判断。三种粒度都可能合理，但真正的问题是未来完成什么任务时需要这些信息。

传统互联网做用户画像，往往先设计年龄、性别、职业、收入、兴趣等字段，再把信息往里面填。千问则反过来：先看真实用户未来有什么需求，完成这些需求需要哪些个人信息，再由任务反推记忆体系的结构。

这背后是千问所谓的“事件关系”。例如，一位已经退休的母亲曾经谈过自己的养老金不高，后来又问“三十多岁的孩子一直没有工作、想写网文怎么办”。这是两个不同的问题，但两者联系在一起，可能共同意味着这个家庭正处在一定经济压力之下。如果只回答“成年人应该如何找工作”，内容未必错误，却没有真正理解用户正在面对什么。

千问希望记住的不只是“发生过哪些事实”，还包括这些事件之间的关联。通过分析现实世界知识中的事件关系，系统可以反向定义记忆 Schema，判断什么信息应该被记录、以什么粒度记录，以及在什么场景下使用。

这会让记忆从传统用户画像变成某种持续更新的“个人状态模型”。系统不仅要知道用户经历过什么，还需要判断这些信息今天是否仍然有效、是否会影响用户当前的决策。

目前，千问在 PC 端提供了显性记忆的编辑入口，用户可以直接修改这部分记忆；而对于一些隐性记忆，以及与具体功能或服务相关的临时性记忆，用户则可能无法直接编辑。

这也意味着，用户对不同类型记忆的控制程度并不一致。尤其当 Agent 开始根据多个事件推断用户没有明确表达的个人状态时，这些判断未必准确。如何区分事实与推测，并让用户发现、纠正错误的隐性记忆，将直接影响个性化服务的可靠性和用户信任。

千问的用户画像和记忆会随新的个性化信息持续更新，但不同信息没有统一的失效周期。比如，用户当天要参加一场活动，这条信息可能只在当天有用；而收入、职业和家庭状态则可能影响更长时间的决策。千问认为，不能给所有记忆设一个统一删除周期，而要根据它本身代表的事件和实际有效期来处理。

“技术实现上当然可以区分长短期记忆，或者明确记忆、模糊记忆，但我觉得真正重要的是怎样构建一套能够持续更新的记忆体系，以及怎样识别其中变化非常快的信息。我们会在 Schema 中判断哪些内容时效性特别强、变化特别快，哪些信息一旦发生变化以后会显著影响用户个性化画像或者后续行为，再按照不同层级进行更新和使用。”

这也可能成为 Personal Agent 比模型更难迁移的壁垒。用户长期使用一个 Agent 后，它已经理解其工作背景、家庭状态、长期目标、消费偏好以及这些事情之间的关系，那么换 Agent 的成本还包括了用户需要重新让另一个 AI“认识自己”。

由于记忆主要以文本形式存储，单个用户的文本信息经过合理整理后，Agent 的存储成本并不高，主要成本仍来自模型训练和推理，其中 Context 压缩是降低推理成本的重要手段。

千问的做法是，不在每次推理时加载用户全部历史记录，而是将部分长期 Context 压缩为记忆，并进一步压缩近期会话，以更小的 Context 实现接近使用全量历史记录的效果。对于需要持续关注用户任务和外部信息的 Always-on Agent，这种优化尤其重要。

此外，团队还会压缩包含 Skill 等信息的系统 Context，避免大量无关工具说明进入模型；同时通过 Auto 模式，根据任务复杂度选择合适的大小模型，并持续优化模型自身的推理效率。蒋冠军认为，过去两三年模型“单位智力”的推理成本已经大幅下降，单 Token 所承载的智能密度仍在持续提高。

生态可能是最大的墙

“随着模型能力和 Harness 技术的持续发展，未来几年，不健全的生态体系会成为 Personal Agent 发展的最大阻碍。”蒋冠军判断。

Coding Agent 是一个很好的例子。代码仓库本身就是高度完整的 Context，编辑器、Terminal、Compiler 和测试工具又天然适合机器调用；模型变强后，可以比较顺畅地进入整个工作流。Office 和图文任务也类似，核心能力主要来自搜索、知识库、文档处理和生成工具，这些服务比较容易开放成可调用接口。

生活服务却完全不同。订一次酒店不是找到酒店名字就结束，还涉及实时库存、会员权益、房型、支付、取消和售后；保险理赔不只是查询规则，还需要找到订单、确认用户身份、提交材料、与客服沟通，最终把资金真正退回来。

所以在蒋冠军看来，“MCP 或 Skill 并不等于一个 App 完整的业务能力”。开放接口只是连接的开始，真正让模型完成现实服务，需要的是一整套业务逻辑和履约体系。

GUI Agent 的流行，在一定程度上反映出当前互联网服务生态尚未完全做好被 AI 直接调用的准备。豆包手机助手尝试通过手机系统层实现跨 App 操作，但这一模式也面临来自现有应用生态的限制。对于许多高频互联网服务而言，允许 AI 跨应用执行任务，不只是技术接口问题，还涉及账户安全、交易风险和平台对业务流程的控制。

这也是为什么千问没有只押 GUI，而是在不同执行路径之间做组合：能够走 MCP/API 就直接调用；网页可以利用 UC 的浏览器内核；需要专业 Agent 时可以通过 A2A；只有缺少其他方式时，再使用 GUI、云手机和云电脑。不同方式各有适用范围，核心是根据任务选择更合适的执行路径，而不是让模型对所有事情都采用同一种方式。

千问的一张牌，是阿里已经拥有大量可以连接现实生活的服务资源。淘宝、支付宝、飞猪以及电商、本地生活、物流、出行等业务体系，都可能成为 Personal Agent 执行真实任务的基础。千问同时也在扩大外部生态，接入瑞幸、东航等第三方服务，并围绕医疗、教育、财经、法律、买房和升学等领域，通过 Skill 沉淀专业经验。今年 9 月，千问开放平台公布的数据显示，其已覆盖 20 多个领域，申请入驻伙伴超过 1000 家，可见其也在努力扩圈。

不过，生态建设并不意味着简单地把更多服务接进来。蒋冠军认为，千问需要围绕真实用户需求判断哪些服务和工具最值得优先建设。比如，即使阿里已经有飞猪，千问仍然可以接入东航；不同服务可以并存，具体选择应当服务于用户需求，而不是只看服务属于哪个平台。

从这个角度看，千问当前首先要解决的是生态覆盖和任务完成能力。只有当 Agent 能够稳定调用服务、理解业务规则并完成实际履约，Personal Agent 才可能从信息处理工具进一步进入真实生活场景。

克制比主动更重要

如果 AI 仍然必须等待用户发出命令，它再强也只是一个工具。真正从 Agent 走向助理的一步，是主动服务。

Muse 已经把主动执行放在产品定位中：它可以在用户离开后继续工作，状态变化或者需要批准时再回来；OpenAI Dots 强调 Always-on，可以持续推进目标；Google Spark 同样被定义成能够在云端长期运行的个人 Agent。不同产品都在尝试让 AI 不再局限于一次性的对话，而是持续围绕用户目标工作。

千问的主动服务，建立在模型、记忆和专业生态的共同判断之上。

比如在康复场景中，Personal Agent 理想中的主动服务，不只是回答康复问题，还可能结合用户的身体状况、家庭角色和生活习惯，在适当的时候提供康复信息、生活安全提醒或情绪支持。其中不少需求，用户并不会主动提出，而需要系统结合长期记忆和当前状态进行判断。

这是助理和工具的分界线，但主动服务也是最容易越界的一步。用户曾经咨询一种疾病，并不意味着 AI 以后每次都应该主动提起，用户表达过家庭焦虑也不代表系统应该不断提醒。模型判断两件事“有关联”，和用户认为“你现在应该说这件事”，完全是两个标准。

因此，Personal Agent 最终需要一套明确的主动边界：哪些事情可以提醒，哪些可以直接执行，哪些必须获得确认，以及哪些敏感 Context 即使相关也不应该主动使用。一个真正成熟的 Personal Agent，最大的能力之一可能恰恰是克制。

千问目前更倾向于让 Agent 以“助理”身份行动，而不是完全假装成用户本人。搜索、整理、比较和部分沟通可以由系统完成；涉及支付、订单确认、个人信息修改等高风险操作时，仍然需要用户授权。这也是未来 Personal Agent 能否真正进入生活场景的关键。

此外，从厂商成本角度看，Always-on Agent 不只是单次任务需要多少 Token。用户没有主动发起请求时，Agent 也可能需要持续检查用户安排的任务或外部信息，判断是否出现值得提醒的变化。这意味着产品需要在主动服务价值、任务频率和计算开销之间找到平衡。如果 Agent 频繁检查，却很少产生真正有价值的提醒，计算成本就很难转化为用户价值。

当 AI 开始替用户选服务，应该优先推荐谁？

Personal Agent 的商业模式仍在探索中，不同产品已经开始尝试不同路径。

Muse 探索通过交易分成等方式变现，并尝试利用用户意图提升广告转化；Instinct 暂不计划向用户收费，未来考虑广告模式；OpenAI Dots 则与现有订阅体系结合，并开始面向企业推进专业 Agent 的试点。这些尝试分别对应交易、广告、订阅和企业服务，但最终能否成立，仍然取决于产品实际创造的价值以及持续运行的成本。

对于千问而言，商业化的问题尤其复杂。一旦用户从“打开 App 购物”转向“让 Agent 帮我买”，千问就可能站到交易链路更上游。它不仅知道用户想买什么，还可能直接决定去哪里买。

目前千问的做法是：结合具体需求判断最合适的服务。比如用户明确想点一杯星巴克，那就优先选用星巴克自身的 Agent 或 Skill，链路更直接；但需求没有这么明确，且多个服务存在价差时，也可以帮用户做对比。

蒋冠军表示，未来模型的第三方生态或者整个模型生态体系，会和今天互联网服务提供体系比较类似。外部可以提供服务，阿里内部也可以提供服务。“对于用户和我们来说，功能重复本身没有问题，因为用户需求是个性化的。”

不过，允许不同服务并存，并不等于解决了如何选择的问题。当多个服务都能完成同一项任务时，Agent 依据什么标准决定调用谁，仍然是一个需要回答的问题。

蒋冠军强调，目前 Personal Agent 产品的第三方生态普遍都不够丰富，行业尚未进入需要对大量同类 Skill 进行复杂排序或竞价的阶段。对于千问而言，现阶段更关注的是补齐服务能力、提高任务完成率，让 Agent 能够真正完成用户交付的任务。

但随着生态逐渐成熟，服务排序迟早会成为所有 Personal Agent 产品都要面对的重要问题。

此外，对于厂商来说，当越来越多知识库、专业 Skill、行业 Agent 和真实服务需要进入 Personal Agent，厂商可能逐渐形成类似应用商店的生态体系：开发者和服务商提供能力，Agent 根据用户任务动态调用。

结束语

“把一件事情交给 AI 完成”已是趋势。千问从用户行为中看到了一些早期变化。据团队披露，在较深度用户群体中，Agent 类需求和即时对话类需求的比例已经达到约 1；过去三个月，复杂任务平均 Token 消耗量增长了 1.6 倍；主动订阅和主动推送类服务的占比也已经达到约 15%。

在蒋冠军看来，现阶段 Personal Agent 首先要把目标明确、边界清晰的单项任务做好，并在此基础上提供合理的建议和必要信息。随着能力进步，未来才有可能进一步连接多个任务、多个专业 Agent，共同支持更复杂的长期目标。

千问的资源优势让它有机会比许多竞争对手更早地把 Personal Agent 带入真实交易场景，但真正的考验可能不只是让 Agent 完成更多任务，而是当它越来越了解用户、能够调用越来越多服务，甚至开始替用户花钱时，用户是否仍然相信，它做出的每一个选择，首先是为了自己。

当然，这不是千问自己一家面临、且尚未解决的问题，而是任何入局玩家都需要解决的现实课题。