目录
1.三款产品的共同起点：连接应用
3.Hark 与 dots：线上内容和小团队协作
4.权限与自动化：任务怎样推进
5.国内的难题：微信与跨应用权限
6.个人代理的完整形态：硬件与软件
7.从应用商店看个人代理的入口归属
用过 Hark、Grok Bot 和 dots 之后，我对三者有了各自的定位：Grok Bot 适合个人开发者，Hark 擅长处理线上内容，dots 的吸引力在于小团队协作。决定这些体验差异的，是应用连接、任务分工和权限设置。
三款产品的共同起点：连接应用
三款产品有一个共同的起点：连接其他应用。Gmail、Google Docs 等服务是它们开展工作的基础。邮件里有待回复的消息，文档里有项目材料，应用里有等着执行的操作。一个 personal agent 能替人做多少事，取决于它能拿到哪些信息、获得哪些操作权限。
正是这个连接过程，让我看清了个人代理的能力边界。用户交给它的任务，都发生在自己的工作和生活里。代理需要找到相关材料，理解事情的来龙去脉，进入对应的应用，把操作完成。每多一处连接，它就能多承接一部分工作。
Grok Bot：组建自己的 Bot 团队
Grok Bot 给我留下的最深印象，是可以组建一支 Bot 团队。我可以给不同的 Bot 分配职责，让它们共享材料、传递任务。Bot 之间有消息、群聊和任务交接机制，角色分工有相应的产品能力支撑。
在我这轮体验里，Hark 和 dots 呈现的都是人与单个助手的交互：我交代事情，助手去处理。Grok Bot 则给了我组织角色的空间。对一个人同时承担研发、资料整理和项目推进的开发者来说，这种方式很有吸引力。只要角色和交接能按要求运转，人就能少花精力在任务之间搬运材料、反复解释上下文。
所以我认为 Grok Bot 适合个人开发者。开发者有自己的项目，知道任务该怎么拆，也能判断结果是否达标。组建 Bot 团队，相当于给这些工作安排专人负责。至于分工有没有价值，要看任务交接是否顺畅、结果是否过关。
Hark 与 dots：线上内容和小团队协作
Hark 给我的感觉更偏向线上内容处理。我是从网页端开始体验的，它借助云端电脑和浏览器处理网站上的事务，并连接邮件与在线文档。官方提供网页、iOS 和 Android 三个入口，我的感受主要来自网页端和线上工作场景。如果你的工作以邮件、网页资料和在线文档为中心，这种方式会很顺手。
dots 吸引我的地方，是能在 Slack 里直接调用。用户可以私信自己的 dot，也可以在拉了 dot 的频道里 @ 它。在我体验的三款产品中，这是 dots 在协作上的优势。
对在 Slack 上推进项目的小团队来说，需求、讨论和代理的反馈都能留在熟悉的工作环境里。成员讨论时可以顺手把任务交给代理，查看结果，再补充要求。如果说 Grok Bot 的角色分工让我想组建一支 AI 团队，那么 dots 的沟通入口则让我想把代理放进人的团队里。
权限与自动化：任务怎样推进
本地电脑的访问与审批，是另一处影响体验的差异。dots 经授权后可以使用本地的文件、代码和应用，但前提是电脑在线，并且 ChatGPT 应用保持打开。Grok Bot 也支持本地执行，默认需要逐次审批，用户也可以选择始终允许。实际使用中审批是否频繁，要结合权限配置和任务内容来看。
在自动化体验上，我更偏向 Grok Bot。任务可以交给有明确职责的 Bot，交接也可以在 Bot 之间完成。每个角色能保留上下文、专门承担一类工作，给我一种团队在运转的感觉。
定时任务是我理解 Hark 和 dots 自动化能力的一个切入点，但它们的自动化不止于此：Hark 提供能记住工作流程的 Specialties；dots 能判断任务何时暂停、何时唤醒，并调用后台代理处理工作。我感受到的区别在于用户如何安排工作：Grok Bot 把角色和分工直接摆在用户面前，而 Hark 和 dots 在我的体验里仍保留着助手式的交互。
国内的难题：微信与跨应用权限
这些体验让我开始关心一个问题：这样的 personal agent 放到国内，会遇到什么？
我对国内能否出现 Muse 这样的跨应用个人代理持怀疑态度。Muse 展示的方向，是让个人代理通过云端电脑，跨应用处理一个人的各类事务。这样的产品必须深入用户的数字生活，找到与任务相关的信息，并取得完成任务所需的操作能力。
让我形成这一判断的，是微信的封闭生态。很多人的工作沟通和生活安排都在微信里，个人代理要发挥作用，前提是能访问这些消息和服务。我担心的是：一个外部代理，要从哪里获得读取这些信息、执行这些操作的入口？用户愿意把事情托付给 AI，和平台愿意向 AI 开放能力，是两个需要分别解决的问题。
以订阅管理为例。帮用户梳理订阅、节省开支，背后是一连串具体操作。国内的订阅扣款渠道有支付宝、微信支付和应用内购买。识别出一笔扣款后，代理还要找到对应的服务、订阅关系和取消入口。账单在支付应用里，管理入口在订阅服务里，要完成这件事，就得把两边打通。
应用连接的问题贯穿个人代理工作的全过程。信息决定它能理解什么，权限决定它能做什么。对于散落在微信、支付应用和各类应用内部的个人事务，跨应用执行所需的入口从哪里来，是我对国内产品路线最大的疑问。
因此我认为，国内更有可能落地的形态，是各家生态内部的个人代理。平台掌握着账号、信息和操作入口，代理的服务范围也就跟着这些权限走。而跨平台处理个人事务，需要多个平台为同一项任务开放信息与操作，这正是我持怀疑态度的原因。
个人代理的完整形态：硬件与软件
顺着这个问题想下去，我对 personal agent 的产品形态有了一个判断：完整的个人代理，需要硬件与软件共同构成。
这里的硬件，指人日常使用的手机、电脑和其他设备。设备承载着人的日常活动，提供语音、图像和操作输入；系统管理着应用、文件和权限；模型与软件负责理解意图、规划任务和调用工具。个人代理要真正融入生活，就需要把这几部分连起来。
苹果的 Siri、华为的小艺，以及小米基于 MiMo 推进的系统级代理，都指向了这个方向。苹果把个人情境与应用操作接入 Siri 和系统；华为把小艺定位为 HarmonyOS 的系统级智慧助手；小米则用 MiMo 模型打造 Xiaomi miclaw，探索系统级代理。它们的产品位置，都与设备和操作系统绑在一起。
从应用商店看个人代理的入口归属
这让我想起当年的豌豆荚和应用宝。第三方产品帮用户寻找、安装和管理应用，手机厂商则把应用商店直接放进设备和系统，用户一拿到手机就能用上。厂商还能把应用分发与账号、安装、更新等能力串起来，形成一条随设备交付的使用路径。
应用宝至今仍有自己的业务，那段历史也包含第三方商店与厂商商店的长期共存。我从中看到的，是设备厂商掌握系统自带入口所带来的优势：第三方产品得先让用户下载安装、再培养使用习惯，而厂商的入口随设备直接到达用户手中。
我认为个人代理有可能走上相似的路径。Hark、Grok Bot 和 dots 在探索任务组织、应用连接和交互方式；设备厂商则有机会把这些能力整合进手机，让代理成为系统的一部分。这是我对未来方向的判断。
不过，这两轮竞争争夺的入口并不相同。应用商店承接的是“下载应用”的需求，个人代理承接的是“完成任务”的需求。后者需要理解个人上下文、取得操作权限、协调多个应用，而设备和系统厂商恰好具备组织这些能力的条件。
就国内市场而言，我倾向于认为，面向日常生活的个人代理入口会向手机厂商及其生态集中。第三方代理要守住自己的位置，就得在具体任务上给用户一个非选它不可的理由。开发、研究或某类专业工作都可以成为这样的理由；而想要覆盖日常生活的代理，则必须直面设备和系统入口的竞争。
当然，设备厂商虽然在组织系统能力上占优，各个应用自身的数据与操作边界，仍会限制这条路线能完成的任务。手机上的代理能否替用户处理微信里的沟通、支付应用里的账单和各类应用里的服务，决定了它能承接多少个人事务。
豆包手机的变量：能做到多大体量
豆包手机需要放进这个判断里。它让我关心另一条路径：一家拥有模型和用户基础的 AI 公司，能否通过与手机厂商合作，把自己的代理变成系统入口？这条路径能够做到多大体量，会影响个人代理入口的归属。
这里的体量，需要区分手机销量、助手覆盖的设备数量，以及使用助手完成任务的活跃用户数量。一款手机卖出多少台，衡量的是硬件销售；一个代理进入多少款手机，衡量的是分发能力；用户在日常生活里交给它多少任务，衡量的是它占据了多少使用场景。豆包 App 的用户规模，转化为设备上的代理用户，需要经过新的选择和使用过程。
我会关注用户是否愿意为了代理能力更换手机。手机购买涉及价格、品牌、影像、续航和售后，代理能力需要进入这些购买理由。用户买下手机之后，助手能否承担一组日常任务，决定着它能形成怎样的使用规模。
厂商合作的范围，会影响另一部分体量。如果豆包手机助手能够进入多个品牌、多个价位的设备，它面对的市场会随合作范围扩大。对于拥有系统助手的手机厂商，这种合作涉及入口位置、用户关系、权限和服务收益。厂商愿意提供什么位置，豆包能为设备增加什么价值，会决定合作能走多远。
应用的接入范围会影响代理的使用频率。用户交给它的事情，涉及微信、支付、购物、出行等服务。一个代理能够在这些地方承接多少任务，会影响用户把多少日常事务交给它。设备覆盖提供触达用户的机会，任务完成能力支撑使用。
因此，豆包手机是我判断国内个人代理路线时需要保留的变量。它如果形成跨品牌的设备覆盖和日常任务使用，就有机会让 AI 公司成为系统入口的重要参与者；如果覆盖范围集中在少数合作机型，手机厂商自有助手的分发优势会影响竞争结果。
