从来就没有什么Personal Agent - 悟空体育

Personal Agent 近期热度极高，从 Meta Muse、千问 Go、OpenAI dots 到 Manus Cue，各家都在推出一款能代劳日常生活的 AI。

针对这一产品形态，不妨回顾一下今年 8 月千问团队开源的项目——MyContext。

该项目能将用户在钉钉、飞书中的聊天与协作记录，整合为一份持续更新的工作档案，每一条都标注了来源和时间。当前后信息出现矛盾时，系统会先自行判断，拿不准的再向用户询问；用户确认过的结论，模型无权自行修改。

举这个例子是想说明，在它这里，Work 和 Personal 的界限已经模糊了。

换句话说，世界上从来就不存在纯粹的 Personal Agent，只有 Context（上下文）+ Agent。如果 Context 是工作，它就是 Work Agent；如果是生活，那就是 Personal Agent。

同一个 Agent，接入什么 Context，就是什么 Agent。

所谓的 Context，就是 Agent 执行任务所需的前因后果，以及事情实际发生的场所。它可以是 App 里的订单，也可能是手机上登录的账号。

比如，我告诉 Agent：“周五帮我订回上海的票。”如果要确保六点前到家，就该选早一点的班次；但如果前一天我在电梯里随口答应客户，走之前再见一面，就得订晚一点的。这两个约定既不在日历里，也不在邮箱中。模型再强也猜不到我答应过谁什么，它要么事先知晓，要么来问我。

两种订票，动作本身完全一样，但“这张票”算工作，还是生活？

Meta Muse 的智能化购物功能。

01 工作的 Context 在系统里

Context 不只是让答案更个性化，而是在定义“什么才算做对”。

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

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

提示词工程 vs. 上下文工程。

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

我不太认同这个观点。

很多 SaaS 里存储的正是工作的 Context——客户、合同、库存、审批记录都在里面，Agent 要处理工作事务，离不开这些系统。会变化的是使用系统的方式：过去是人登录进去点界面，以后越来越多是 Agent 直接调用。

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

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 多；往后比的是谁的飞轮转得快，差距会越拉越大。

Context 飞轮的运行逻辑。

飞轮积累的东西归谁，对于工作和生活领域的 Agent，结论也不一样。

按惯例，各种 Work 类 Agent 积累的内容归公司，Agent 学会的“这个团队怎么做事”还留在公司的系统里。而生活里积累的上下文，按理该归用户自己。

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

ChatGPT 和 Claude 能导出聊天记录，Claude 和 Gemini 能导入别家的记忆摘要，Gemini 还能导入聊天记录的压缩包。能带走的基本是聊过的内容，但授权边界、纠错记录、办到一半的任务，目前都很难跟着走。

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

05 谁来定义“对错”？

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

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

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

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

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

等 Agent 能把周五那张票订对时，其实我想问的是：它订的是对我最合适的那张，还是对平台来说，最划算的那张？

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