Personal Agent是个伪命题？真正拉开差距的，是Context和授权

导语：Personal Agent 最近异常火爆，从 Meta Muse、千问 Go 到 OpenAI Dot、Manus Cue，大家都说的是同一件事——一个能替你打理生活的 AI。但回头看看 8 月份千问办公的开源项目 MyContext，会发现 Work 和 Personal 这条线其实分不太清。世界上没有所谓的 Personal Agent，有的只有 Context + Agent：接上工作上下文就是 Work Agent，接上生活上下文才是 Personal Agent。真正的瓶颈，不在模型，而在谁把上下文喂给它、谁给它授权。

Personal Agent 最近确实火得不行。Meta Muse、千问 Go、OpenAI Dot、Manus Cue，讲的都是同一个故事：一个能替你打理生活的 AI。

关于这个产品形态，可以回过头看看 8 月份千问办公的一个开源项目——MyContext。它能把你在钉钉、飞书里的聊天和协作记录整理成一份不断更新的工作档案，每条都记着从哪来、什么时候的。前后信息对不上，系统会先自己判断，拿不准就问你，你确认过的结论，模型不能自己改掉。

举这个例子是想说明，Work 和 Personal 这条线在它这里已经分不太清了。或者可以这样说：这个世界上从来就没有什么 Personal Agent，有的只有 Context（上下文）+ Agent。这个 Context 如果是工作，它就是 Work Agent；如果是你的生活，它就是 Personal Agent。同一个 Agent，接上什么 Context，就是什么 Agent。

所谓的 Context，就是 Agent 执行任务要用到的前因后果，加上事情实际发生的地方。它可以是你 App 里的订单，也可能是你手机上登着的账号。

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

两种订票，动作本身一模一样，但“这张票”算工作，还是生活？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。

突然热起来的 Personal Agent 概念，在中、美市场有个很明显的分歧。美国的个人 Agent 大多上了云，Dot 给每个 Agent 配一台云端电脑，Muse 跑在一台专属的云端虚拟机里。作为对比，国内的厂商很多都在尝试做 Agent 手机，阶跃星辰发布了 Agent 手机，豆包手机助手已经出到第二代。

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

ChatGPT 今年能接美国医疗机构的病历，也能经 Plaid 接 1.2 万多家金融机构的账户；Dot 一上线就能连 4000 多个应用。出差的机票确认、酒店订单也会进收件箱。Meta 的 Muse 接邮箱时，读邮件和代发邮件是分开授权的。没有接口的服务，只要网页上能办、网站也允许，云端电脑上的浏览器就能去点。支付有 Stripe 这样的支付公司发的一次性受限凭证，真实卡号不用交出去。

国内厂商争相在手机这种典型的端侧设备上讲 Personal Agent 的故事，原因在于相关服务生态碎片化。比如，同样一趟出差，信息在中国散得多。机票在航旅 App 里，酒店在携程、美团，同事的确认在微信群，改签要进航司的小程序。登录和支付也绑在手机上，靠的是已经登录状态的会话、短信验证码和设备确认，云端新开一台电脑，很难继承这些关键上下文。

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

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

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

问题是，手机厂商愿意做这样的开放吗？以及，做出这样的开放，会向 Agent 开出什么样的价码？更有甚者，如果这种开放很容易，怎么会有“豆包手机”、“阶跃手机”？

离 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 月二审法院撤销了一审的初步禁令，但到目前为止，双方的官司还没打完。

Agent 产品能够跑起来，依赖 Context 上下文这个飞轮，而且跑起来之后就会呈现螺旋向上的能力和体验提升。接入早期，它所依赖的是已经存在的 Context，比如邮箱里的订单、手机上的会话等去执行任务。当用户逐步提供更多的上下文，它手里就多出一些原来没有的“内容”：用户批准过什么、改过什么、哪次出错之后把授权收紧了。

聊天里提过的偏好各家 Agent 都能记一些，办过事的经验则更难得。Agent 照章办事，用户交待的资料更少，出错也少了，那么用户提供的资料也就会相应更多。换句话说，上下文的飞轮是否能转起来，要看产品能否正确地记住这些。

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

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

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

Context 飞轮的运行逻辑

飞轮攒下的东西归谁，对于工作和生活领域的 Agent，结论也不一样。按惯例，各种 Work 类的 Agent 积累的内容归公司，Agent 学会的“这个团队怎么做事”还留在公司的系统里。而生活里攒下的上下文，按理该归用户自己。

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

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

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

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

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

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

最后再 call back 一下前面提到的订票问题。等 Agent 能把周五那张票订对时，其实我想问的是：它订的是对我最合适的那张，还是对平台来说，最划算的那张？