贝博平台有供读者了解单机体验的内容入口,相关介绍围绕选择思路展开,因为模拟经营值得结合具体内容来讨论,ballbet将阅读线索作为解读的一部分,贝博平台官网关注读者对玩家创作的实际疑问,所以从体验差异展开介绍,为有兴趣研究经典作品的玩家整理线索,便于进一步了解体验差异。

首页 - 博客- 博客详情

从来就没有什么Personal Agent

从来就没有什么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。

提示词工程 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,它的排序依据是不是透明的?我自己的偏好能不能强制锁定,而不被平台结合自身利益进行优化了呢?

最后再call back一下前面提到的订票问题。

等Agent能把周五那张票订对时,其实我想问的是:它订的是对我最合适的那张,还是对平台来说,最划算的那张?对于这类复杂场景,贝博体育网站或许能提供一些参考,但核心问题依然在于用户能否掌控最终决策权。

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