从来就没有什么Personal Agent

关于Personal Agent这一概念，近期热度相当高，从Meta Muse、千问Go、OpenAI dots到Manus Cue，大家都在讨论一个能帮你打理日常事务的AI助手。

针对这类产品形态，可以回顾一下8月份千问办公发布的一个开源项目——MyContext。

该项目能够将你在钉钉、飞书里的聊天和协作记录整理成一份持续更新的工作档案，每一条都标注了来源和时间。当前后信息出现矛盾时，系统会先自行判断，如果拿不准就会向你确认。你认可的结果，模型不能擅自修改。

举这个例子的目的是想说明，工作和个人这条线在这里已经变得模糊了。

或者可以这样理解：从来就不存在所谓的Personal Agent，只有Context（上下文）加上Agent。如果这个Context是工作相关的，它就是Work Agent；如果是生活相关的，它就是Personal Agent。

同一个Agent，接入什么Context，就成为什么类型的Agent。

所谓的Context，就是Agent执行任务时需要了解的前因后果，以及事情发生的具体场景。它可能来自你App里的订单，也可能来自你手机上登录的账号。

举个例子，我跟Agent说：“周五帮我订回上海的票。”如果要确保六点前到家，就应该订早一点的班次；如果前一天我在电梯里随口答应客户，走之前再见一面，那就得订晚一点的。这两个约定既没有出现在日历里，也不在邮箱中。模型再强大，也无法猜到我对谁承诺过什么。它要么事先知道这些信息，要么来问我。

两种订票方式，操作本身完全相同，但“这张票”属于工作还是生活？

Meta Muse的智能化购物功能也体现了这一点。

01 工作中的Context在系统里

Context不仅仅是为了让答案更个性化，它更是在定义什么叫“做对”。

比如在日常工作中，涉及合同与折扣的业务场景下，一句“帮我回复一下这个客户”的任务，Agent需要先知道客户签的是哪一档合同、公司制定了什么回复口径、用户是否有提供折扣的权限。这些上下文都存在于系统中：合同在CRM里，口径可能在群聊中，权限和审批则在钉钉、飞书、企业微信这类平台上。

以上这些，都是决定任务执行是否顺畅的关键Context。

年初，美股软件股经历了一轮大跌，背后有个流行的说法：Agent会取代SaaS，企业以后不用再买那么多按人头收费的软件账号。

我对此并不认同。

许多SaaS系统里存储的正是工作中的Context，包括客户、合同、库存、审批记录等。Agent要处理工作事务，离不开这些系统。会改变的是使用系统的方式：过去是人登录进去点击界面，未来将越来越多地由Agent直接调用。

3月17日，阿里发布悟空时，时任钉钉CEO陈航表示：“过去是人用钉钉来工作，未来是AI用钉钉来工作。”他还提到悟空“天然就长在企业组织中”。为此，钉钉重写了底层代码，将上千项功能改为Agent可以直接调用的命令行，AI无需再模拟人点击屏幕。接入后，员工在公司里的账号和权限，Agent会直接继承。

10月14日，腾讯的办公Agent WorkBuddy进入了企业微信的通讯录，双方账号打通，在企业授权范围内可以接入消息、文档和会议。

可以说，Agent冲击最大的，是那些只提供界面、系统里缺乏Context的软件，以及按人头收费的定价模式。而那些存储着客户、合同和审批记录的系统，反而会成为Agent执行任务的地方。

在国内，Work Agent已经拥有千万级用户，而生活Agent仍在探索阶段。Work Agent之所以能率先发展，是因为工作中的Context早已集中在少数几个系统中，且有权限批准的人也都在公司内部。Agent继承了员工的账号和权限，就等于进入了这家公司的Context。

而在国内，生活方面的Context还没有形成一套相对成熟的生态系统。

我们的订单在邮箱里，聊天记录在手机上，至于答应家人几点到家、给哪位长辈回消息需要多斟酌，这些可能记在备忘录里，也可能根本没记录。因此，即使是阿里做个人Agent，也只是先接入淘宝、支付宝这些App。

02 美国上云，中国争“端”

突然热起来的Personal Agent概念，在中、美市场存在一个明显的分歧。

美国的个人Agent大多基于云端运行，dots为每个Agent配备一台云端电脑，Muse运行在一台专属的云端虚拟机中。相比之下，国内厂商很多都在尝试做Agent手机，阶跃星辰发布了Agent手机，豆包手机助手已经出到第二代。

美国公司做Personal Agent倾向于上云，是因为很多人使用同一个邮箱注册和登录各种服务，银行、医疗、购物等领域不少都有现成的接口。用户授权一次，云端的Agent就能获取相应信息。

ChatGPT今年可以接入美国医疗机构的病历，也能通过Plaid连接1.2万多家金融机构的账户；dots一上线就能连接4000多个应用。出差的机票确认、酒店订单也会进入收件箱。Meta的Muse在接入邮箱时，读取邮件和代发邮件是分开授权的。对于没有接口的服务，只要网页上能操作且网站允许，云端电脑上的浏览器就可以去点击。支付方面，有Stripe这类支付公司提供的一次性受限凭证，真实卡号无需交出。

OpenAI展示其Agent产品Dot协同参与科研，跟踪项目执行并滚动更新图表及注释。

国内厂商争相在手机这类典型的端侧设备上讲述Personal Agent的故事，原因在于相关服务生态碎片化。

例如，同样是一次出差，信息的分散程度在中国要高得多。

机票在航旅App里，酒店在携程、美团上，同事的确认在微信群中，改签需要进入航司的小程序。登录和支付也绑定在手机上，依赖的是已登录状态的会话、短信验证码和设备确认。在云端新开一台电脑，很难继承这些关键上下文。

为了应对生态碎片化带来的问题，阶跃星辰作为国产大模型的一员，直接下场探索硬件，推出了自研手机STEPX Neo。

苹果是美国“上云潮”中的一个例外，反而走的是端侧路线，原因同样在于Context：iPhone用户的许多Context留在本机，iMessage不向第三方提供读取接口，照片和健康数据需要在手机上一项一项授权。苹果9月开始推出的新版Siri，主打的就是根据个人Context在系统内直接操作。

因此，在Personal Agent这件事上，握有操作系统的公司确实占便宜，验证码、通知、屏幕上刚发生的事件，都是系统先看到。但如果这些设备事件和平台接口以同样的条件开放给云端Agent，手机的优势会缩小。

问题是，手机厂商愿意做出这样的开放吗？以及，如果开放了，会向Agent开出什么样的条件？更进一步，如果这种开放很容易实现，怎么还会有“豆包手机”、“阶跃手机”？

03 生活没有“管理员”

靠近Context只是Agent需要突破的第一步，之后还需要有人给Agent授权。

谁能授权，取决于这些信息存放在哪里。工作中的内容可能集中在同一个平台上，批准的人和制定规则的人都在其中。但生活信息的上下文散落在十几个互相竞争的平台手中，没有一个统一的主人，任何一家都可以单独拒绝。

在中国，最接近管理员角色的是超级App。

这些App中，接入得最顺畅的是各家自己的Agent。一个Agent去操作第三方App，并且还是依靠屏幕自动化，对方随时可以拒绝；但一个专为自家Agent重写底层的产品，就不会出现这种尴尬，因为修改的是自家系统。

阶跃手机虽然逻辑不同——不是操作App界面，而是调用App的接口——但理念相似：Agent执行任务的程度，取决于超级App的开放程度。

据了解，支付宝开放了300多项服务，美团只开放了跑腿、外卖未开放；腾讯首批接入的是WorkBuddy、企业微信和微信读书。

与直接操作App的区别在于，通过调用服务接口，超级App产生的生活化上下文仍然掌握在平台手中。它们只是给手机厂商Agent开放了入口，最终执行仍然是平台和超级App本身，第三方Agent只是发送了一个需求，并得到了执行结果。

开放进程缓慢，还有一个责任划分的问题：工作中的Agent出错，有公司兜底；生活中订错一张票，承担损失的只能是用户自己。

在这个问题上，美国公司和相关产品的做法是先推进，平台不满意再拦截。

据美国科技媒体GeekWire报道，9月20日，Amazon拦截了Muse代用户购物，理由是Muse未表明身份；Meta此前表示Muse看不到用户的密码和支付方式。去年，Amazon还因类似理由起诉过AI浏览器Comet的开发商Perplexity，今年8月二审法院撤销了一审的初步禁令，但截至目前，双方的官司尚未结束。

04 Context飞轮

Agent产品能够顺利运行，依赖于Context这个飞轮，而且一旦启动，就会呈现螺旋上升的能力和体验提升。

在接入初期，它依赖的是已有的Context，比如邮箱里的订单、手机上的对话等来执行任务。当用户逐步提供更多上下文时，它就会积累一些原本没有的“内容”：用户批准过什么、修改过什么、哪次出错后收紧了授权。

聊天中提到的偏好，各家Agent都能记录一些，但办过事的经验则更为珍贵。Agent按规则办事，用户需要提供的资料更少，出错也少了，那么用户提供的资料也会相应更多。换句话说，上下文的飞轮能否转动，取决于产品能否正确记录这些信息。

用户纠正一次，产品是否问清了原因；一次性的要求和长期的偏好，是否分开存储；事情办完后，结果是否记录下来。

之前千问团队开源的MyContext明确规定，用户确认过的结论，模型不能自行修改，做的就是这一层。

可以总结一下：Agent站在同一起跑线时，比的是谁手中已有的Context更多；往后比的是谁的飞轮转得更快，差距会越拉越大。

飞轮积累的内容归谁所有，对于工作和生活领域的Agent，结论也不同。

按惯例，各种Work类Agent积累的内容归公司所有，Agent学到的“这个团队如何做事”仍留在公司系统里。而生活中积累的上下文，按理应归用户自己。

不过，现阶段用户实际能带走的内容并不多。

ChatGPT和Claude可以导出聊天记录，Claude和Gemini可以导入其他平台的记忆摘要，Gemini还能导入聊天记录的压缩包。能带走的基本是聊过的内容，但授权边界、纠错记录、进行中的任务，目前都很难迁移。

带不走的这部分反而会成为Personal Agent的壁垒，用户换一家，飞轮就得从头转。至于壁垒有多高，要看规则是否会像当年携号转网那样，要求将这些内容也做成可携带的。

05 谁来定义“对错”？

模型现在是可以租赁的，比如苹果的下一代基础模型就是基于Gemini定制的。但Context租不到，只能掌握在“自家”手里，或者靠飞轮一点点积累。

Context可以定义执行任务的“对与错”，掌握Context也就掌握了这个判断标准。在这个前提下，飞轮转得越久，不仅积累的上下文越多，Agent也越清楚对用户来说“什么叫做对”。

但障碍在于，掌握着生活Context、转动这个飞轮的，大多是各种在线服务平台，包括订票、订外卖等。这带来了一个很关键的问题：生活中的“做对”标准，本应由用户自己定义，但实际上，替我办事的Agent往往夹杂着平台的利益。

Meta发布Muse时专门承诺，对话和虚拟机中的数据不会进入广告系统，但这只是一家公司的政策。一个替我在商家之间做选择的Agent，它的排序依据是否透明？我自己的偏好能否强制锁定，而不被平台结合自身利益进行优化？

最后再回到前面提到的订票问题。

等Agent能把周五那张票订对时，其实我想问的是：它订的是对我最合适的那张，还是对平台来说最划算的那张？从本质上讲，这涉及到大小分规则的界定——Agent在权衡任务优先级时，究竟是以用户需求为核心，还是以平台利益为导向。

本文来自“界面新闻”，作者：李彪，编辑：苏扬，36氪经授权发布。