9月8日，Meta推出了个人智能体Muse。上线12天内，下载量达到约280万次，增速甚至超过了当年ChatGPT移动端的表现。

热度尚未消退，问题便接踵而至。9月中旬，安全机构Surfshark与一批技术用户发布报告指出，Muse的权限系统“哨兵（Sentinel）”大面积失效，Muse甚至绕过了macOS的“完全磁盘访问”防线，读取了用户本地的iMessage聊天记录。几天后，亚马逊等零售和SaaS公司便在防火墙上拦截了Muse的自动化流量。

然而，资本市场并未因此受惊。9月下旬，一家仅有14名员工的公司Instinct获得了10亿美元融资，估值突破百亿。月底，Manus的Cue与OpenAI的dots相继发布。

这批新Agent产品的社区叙事迅速统一为“Agent正从专注任务转向专注人”。

但这真的是故事的全貌吗？

让我们回顾一下。早在8月，xAI与Cursor合并而成的SpaceXAI便上线了Grok Bot，它在公司内部主要用于销售外联、运维和修复Bug，毫无“个人”色彩。9月15日，飞书8.0发布的豆包工作伙伴服务于整个团队，它能自主巡视群聊，判断是否需要介入。

这些Agent的服务对象截然不同，但能力却似乎朝着相同方向演进：它们始终在线，持续记忆上下文，主动寻找任务，且权限不断扩大。

那么，如果“转向人”并非这批Agent新产品潮的全部解释，它真正推动的转变方向是什么？

要回答这个问题，得先回到年初那只龙虾。

Harness的演进，就是让人逐步放手

如果我们将今年的Agent产品按“人需要管理多少事务”来排序，会得到一条清晰的光谱。

最左边是Claude Code、Codex这类生产工具。开发者需审核每一处diff，批准每一条命令，Agent的每一步都在人类监控下。这是产品定位决定的，在真实业务中，精确控制始终是首位。

向右一格是OpenClaw。今年初，它让许多人首次体验到“养Agent”的感觉。它常驻于电脑，通过WhatsApp、Telegram与你聊天，靠Heartbeat定时唤醒，并使用USER.md和MEMORY.md记住你的信息。

但维护它相当繁琐。部署需自行完成，技能需手动安装，记忆仅当上下文快满时才自动存档。

社区热度随后下降，原因在于维护成本过高。

再向右一格是Hermes。2月底首发后，连续数周霸占GitHub Trending榜单。从功能清单对比，它和OpenClaw几乎无异，但这些功能的控制权已有所不同。

每当任务调用工具超过5次或被用户纠正，Hermes会默默将这套流程保存为技能。每对话约15轮，系统会强制给Agent一条反思指令，让它回顾值得记录的内容。

这条“替你做决定”的路线迅速成为共识。4月，OpenClaw连续补充了两项功能：离线整理记忆的Dreaming，以及回复前专门调取记忆的Active Memory。

然而，Hermes并未消除这些决策，只是将其转化为固定规则。例如5次工具调用、15轮对话、85%的压缩阈值、危险命令的黑名单，均由开发团队提前设定。

而这一波Agent的核心，是光谱上的再下一格。复杂度再次转移，这次转移到了一个常驻系统以及越来越能决策的模型。

这个常驻系统，就是一个always-on的Agent。Agent的存在不再依赖于一次对话或一台开着的电脑。你合上电脑去睡觉时它仍在工作，甚至记得事情进展到哪一步，有消息能被唤醒，唤醒后能继续推进。

只有它始终在线，你才敢将事务托付给它。

你可能会说，这东西龙虾不早就有了吗？但OpenClaw确实能常驻，可电脑一合、进程一崩、上下文一爆，它就中断了。

它不稳定。一个到点才醒、动不动需要你批准、运行久了就糊涂的Agent，维护成本太高。

要让它真正持续在线，必须解决三个问题：唤醒是否及时、是否需要频繁找你、能否记住信息，即主动性、权限和记忆。

这一波Agent在这三个方面都有实质进展。这是无论我们需要何种助手、何种更能替我们干活的Agent所必需的基础。

之后，分化主要发生在上下文中。当你将Always on Agent接入一个团队的群聊和工作软件，或接入一个人的日历、聊天和账单，这三个功能和产品就需相应调整。例如，在办公场景中，我们希望Agent替团队主动行动，它就会关注项目进度和无人认领的任务。替个人干活，它就会关注孩子的报名截止日期。

这一步，可称为针对上下文的产品特化。特化为团队，它就是同事；特化为个人，它就是管家。

沿着这条光谱看下去，未来常驻在线、手握上下文和权限、能自主推进事务的Agent，很可能成为Agent产品的标配。这次下场的OpenAI、Meta、xAI，在记忆分层和常驻架构上，已各自触及相似答案。

那么，“一直在线”究竟是如何实现的？讲得最透彻的，恰恰是那个最不“个人”的Grok Bot。

Grok Bot，做实“一直在线”

8月11日，SpaceXAI发布了Grok Bot测试版。它最初只是公司内部原型，后来在销售、运营、工程团队中传播开来。

它的使用方式很简单。你可以创建几个有名字、有分工的Bot，像给同事发消息一样分配任务。每个Bot背后有一台云端电脑，配备浏览器、文件系统和终端，那些没有API、也未连接MCP的网站，它能直接登录操作。

你合上电脑后它会继续工作，仅在需要你决策时才回来找你。你还可以当面操作一遍，它看完后便将这套流程整理成技能，之后定时自动运行。

多个Bot之间还能互相发消息，由一位“幕僚长”Bot统一调度。

Grok Bot不是个人Agent。它沿袭了OpenClaw的路线，先不管服务对象，而是将“一直在线”这件事本身做扎实。

前不久，SpaceXAI的Lee Robinson在斯坦福CS146S课上，完整讲解了Grok Bot的架构。

拿他讲的内容对照OpenClaw，就能看出进步之处。在Grok Bot中，几乎所有能力在OpenClaw时代都有，但非常粗糙。

这种粗糙主要体现在四个方面。

卡点一，唤醒太死板

OpenClaw的常驻依靠Heartbeat，进程始终运行，每隔一段时间醒来检查是否有事。

这个方法有两个问题。一是唤醒时机不当。你那边情况紧急，它却要等到下一次心跳。没事时它也会醒来，空转一圈，浪费token。二是它寄居在一台机器、一个进程中。电脑一合、进程一崩，它就不在了。崩溃后重启，之前做到哪一步也不清楚。

Grok Bot则不是按点唤醒，而是按事件唤醒。

它的Agent大部分时间处于休眠状态，云端电脑也在休眠。一条Slack消息、一封邮件、一个会议开始，或一个运行数天的后台任务完成，这些事件才是闹钟。被唤醒后，它从数据库中提取状态。如果需要上网，再唤醒云端电脑。工作完成后，两者一起休眠，并将对话记录、记忆、定时任务全部存回数据库。

按事件唤醒也有一个麻烦：事件太多。有人@你、有人来电、会议开始，所有事件涌入，Agent很容易被淹没而不知所措。

因此，这些信号在Grok Bot中会先经过路由，去除重复项，再区分优先级。你亲自发出的消息可以插队，直接打断当前任务；群聊和后台任务则按顺序排队；连续几条消息会被打包成一轮处理。

每次唤醒后，它处理完事务，也会判断此事是否值得打扰主人。同事每推进一点就来汇报，会让人厌烦，大多数事务一天同步一次即可。

从按点唤醒变为按事件唤醒，Agent才从一个开着的进程，变成一个随时在线、又不打扰你的助手。

卡点二，容易崩溃，状态难以恢复

Always-on的本质是状态持续存在，唤醒后能立即继续工作。

状态持续存在，就必须稳定。龙虾的问题之一就是不够稳定。它运行在你的本地电脑上，一旦出错导致电脑崩溃，重启后信息也会丢失。整体恢复非常耗时。

因此，Grok Bot将Agent的循环运行在服务端，而非它的电脑中。服务端电脑是一台Firecracker虚拟机，可以随时拍快照、关机、原样恢复，坏了就推倒重建。状态不在电脑上，电脑就只是一件工具，更换后Agent毫发无损。即使需为虚拟机打紧急安全补丁，也无需连带Agent一起停止。

为了加快崩溃恢复速度，他们还加入了持久化工作流（durable workflow）。普通任务队列中，执行到第三步时服务器崩溃，重启后需从第一步重放，可能导致同一封邮件被发送两次，或订单被重复提交。

Grok Bot使用开源工具Temporal记录每一步，崩溃后直接恢复到第三步继续执行。

卡点三：需要你确认的事项太多

能唤醒只是第一步。唤醒后，它能否自主完成事务？

Lee回顾了开发者使用AI的几个阶段。

在第一阶段，编码Agent有了独立App后，大家在云上并行开启多个，但人仍是瓶颈，每条命令都需要盯着批准。OpenClaw那一代常驻Agent也未能摆脱困境，权限基本只有两档：要么事事来问你，人必须时刻守在旁边；要么完全放开，它在你的电脑上任意操作，出了问题算你的。Hermes的折中方案是写死一份危险命令的黑名单，用正则表达式匹配。

另一种需要你介入的情况是权限卡住。没有API的网站进不去，未连接MCP的服务用不了，它只能回复“这个我做不了”。

一个动不动就回来找你的Agent，即使始终在线也没用，你仍需守着它。

Grok Bot从三个方向，将人从旁解放出来。

第一，给它一台自己的电脑。Agent在自己的虚拟机中工作，不碰你的电脑。没有API的网站，它就自己登录操作，即使出错，影响也局限在那台机器中。

第二点最为关键，让Agent遇到问题时先自行解决。Grok Bot为Agent设定了一条能力阶梯：先翻阅对话中已知信息。不够，就调用插件、MCP或API。还不够，就上网搜索。再不行，开浏览器自行查阅。最后动用整台电脑，编写脚本、运行命令、搭建工具。

在浏览器中也是如此，先读取最省资源的无障碍树（accessibility tree，原本为读屏软件设计，能将页面上的按钮和链接整齐列出）和HTML，实在不行才截图、按像素坐标点击。只有所有这些都失败，例如遇到两步验证或人机验证，才回来找你。

这里的判断，例如在数百个工具中该用哪一个、尝试到哪一步才算“实在不行”、这条命令是否放行，Hermes用黑名单兜底，Grok Bot则交给了模型。

第三，仍不放心怎么办，让模型替你审核。每条命令执行前，先让另一个模型审核一遍，业内称为auto review。Lee有一个反直觉的说法：让模型审核命令，比让人逐条审核数百条命令更安全，因为人会疲劳。他甚至表示，如果进行盲测，大多数情况下模型比人审核得更好。

剩下真正需要你的，只有登录、付款、发送邮件等无法撤销的几处。如果授权完备，密码等凭证通过产品流程处理，根本不进入模型的对话。

人从“每一步都批准”，退到了“只在关键处点头”。第一节那条光谱上向右移动的最大一格，其实就在这里。

卡点四：记忆维护成本高

前两处问题解决后，Agent就能持续运行数周、数月。此时第三个问题浮现：它的上下文记忆能否支撑得住。

OpenClaw的记忆是被动的，上下文快满时才自动存档。对话越长，模型越容易遗忘之前的内容，表现越来越差。达到上限后只能压缩，而压缩是有损的，压缩不当，关键细节就会丢失。

Lee表示，这个问题足以撰写数篇博士论文。实际上，Arxiv上相关论文至少已有上百篇。

Grok Bot的思路分两步。

第一步是减少主Agent的信息量，从而降低总量。

主Agent只负责总调度，对话尽量简洁。运行命令、调用工具等消耗上下文的操作，都交给子Agent，完成后只将结果带回主上下文。对于子Agent，也需节省上下文，例如工具说明，上下文中只保留工具名称，工具输出直接写入外部文件，真正需要时再从文件中读取完整说明。

第二步是精炼压缩。

压缩时保留什么、丢弃什么，Grok Bot将其分为三层。

第一层是核心事实，每次对话都必须携带，例如“这个用户发消息喜欢全小写”，并定期清理。第二层是带日期的日志，你问一句“我上周干了啥”，它直接翻阅日志即可。第三层是临时便签，仅在接下来一两个小时内有价值，用完即弃。

其余一切信息都存放在文件中，需要时让模型自行使用grep等命令查找。

除了记不住，长上下文还有一个问题：成本太高。每来一条新消息，整段对话历史都要重新发送给模型，费用昂贵。唯一绕路的方法是利用KV Cache，模型厂商对缓存过的上下文收费较低，只要命中就能大幅节省成本。但今年龙虾爆火时，Harness尚未为上下文缓存进行优化，导致缓存大面积失效，账单瞬间飙升。

Grok Bot在此处进行了大幅优化。要享受折扣，前缀必须保持不变，系统提示词、工具定义能不改就不改，让过去的上下文尽可能在缓存中命中。

另一招省钱方法就是趁热压缩。你和Bot聊了十几万token后走开，模型厂商的缓存还会热一段时间，可能10分钟，可能60分钟。Grok Bot就在这段时间内，将长对话压缩成摘要，因为此时压缩成本最低。

有了Always on，多端Agent才变得有意义

四个卡点解决后，目前在后台运行的Agent，已能在不打扰你的情况下完成许多事务。

此时，前台缩减为一个聊天框成为可能。按照Lee的说法，模型越强，界面反而越简单。

过去模型不可靠，产品只能堆满diff视图、审批弹窗和配置面板，让人盯着每一步。现在Agent能自主完成工作，人只需交代任务、等待结果。一个聊天框足矣。

而OpenClaw那个时代，虽然它在WhatsApp、Telegram里与你聊天，但因为它需要不断来回确认，你还要从它的COT中挑错，说是对话框，但内容冗长。

聊天框很快就会被淹没，反而不如Codex清晰。

但现在，聊天窗确实够用了。

前两天OpenAI在ChatApp中突然增加了生成式UI，其实就是让这个聊天框更好用。有些展示，仍需UI更直观、更简洁。要登录某个网站，就弹出专门的登录框，连接1Password；要付款，就跳转到Stripe Link或X Money；要发送邮件、Slack消息等无法撤销的操作，就生成一张草稿卡片，你修改确认后才发送。

聊天框负责沟通，确认和输出交给按需生成的界面。人越来越少需要确认的关键点，被做成了一个个点击即可的按钮。

这样多端才真正可用。否则后台越强，人在前台翻消息越累。

把模型练到能决策

回顾这些卡点，Grok Bot这套解法的重要进步，在于它将更多机制交给了模型判断。

在Harness工程中，Grok Bot埋下了基本能力，例如睡眠唤醒、持久化工作流、独立虚拟机、缓存和压缩，将能确定的事交给系统。

但判断是否值得叫醒你、该不该回来问你、哪句话值得记住，这些一半无法写成规则，只能交给模型。

所以绕到最后，模型必须可靠，这些判断才有意义。

Hermes那个时代的答案是模型不可靠，因此写死规则。到了Grok Bot这个时代，解法是让模型学习到可信。

为了让模型更好地适应具体工作，Grok Bot有两个学习循环。

内循环是每天都在运行的。Agent犯了一个错，例如调用了不该调的工具，就变成一条评测用例，团队去修复Harness、修改提示词，或查找推理上的问题，测试通过后再上线。

外循环则是每隔一段时间进行一次，将内循环中积累的问题和用例用于更新训练新模型，让它从这些错误中学习。通过SFT让它查看大量Harness中的样例，熟悉手上有哪些工具。再通过RL让它学会听指令，在数百个技能中选对那一个，在网页上点对位置。

新模型上线，判断又准确一截，交给它的事务就能再多一点。

个人Agent，就是从Always on，到上下文的特性化适应

凭借这套对Agent基础长期在线能力的工程修正，现在Agent已经可以Always on地完成许多事务。

那么接下来的问题就是具体让它去做什么。

这道题是开放的。同一套底座，可以替团队盯工作，也可以替你盯生活；可以催项目进度，也可以提醒你孩子的报名截止日期。

这一波Agent热潮中的五款产品，恰好在这条光谱上各站了一个位置。

OpenAI的dots是9月29日DevDay的压轴，底层是GPT 6 Astra。你在ChatGPT桌面端布置完任务就能关电脑，几个小时后它会在Slack里@你汇报。

DevDay上最抢眼的演示是，它潜伏在公司群里，看到客服报了一个Bug，自己读取报错、定位、修复、运行测试，最后给工程师提交一个PR。

对已经拥有Codex的OpenAI来说，给它接一个跨端的个人信息入口，比从零造一个个人Agent划算得多。

Manus的Cue于9月28日上线，给每个Agent配备了一整套真家伙：电话号码、邮箱、云电脑，外加一个受你预算管着的钱包。它能直接打电话给餐厅订位，跟客服语音砍价，多个Agent还能拉群，分头规划一趟海外旅行。

Instinct的创始人Noah Shinn年仅23岁，是Reflexion论文和τ-bench的合著者。公司一个月估值翻了四倍。它干脆将App都舍弃了，只用短信、iMessage和电话与你沟通。

它还演示了A2A的愿景，两个人要约时间，双方的Instinct在后台直接加密沟通，人连前面的来回拉扯都省了。

而在这其中，Muse是在个人这条光谱上走得最远的。日历、备忘录、聊天软件，连财务应用都要连接。借助Stripe Link，填表、结账、续费、与商家谈账单，它自己全包了。

你在WhatsApp里发一句语音，它能在云上闷头跑几个小时，将整趟差旅订好。

五款产品摆在一起看，渗透的方向不同，但底座其实还是同一套，往哪推、推多深，是各家自己的选择。

往不同方向推，上下文的需求、要记住的事情和权限的管理都有不同，需要根据要处理的上下文进行特性化处理。

下面我们就主要围绕Muse这个在个人方向上推得最远的产品，来聊聊这种不同来自哪里。

个人Agent，需要做什么调整？

放进来的上下文越私人，主动性、权限、记忆这三样就得调得越细。

Grok Bot搭好了架子，管理的是Agent能否始终在线、不打扰你、不闯祸。特化到个人后，要管理的变成了它能否懂你、替你办事。

当然第一步是获得更多关于你的上下文，通过你授权让它连接你的邮箱、日程、IM等上下文丰富的应用，这一步很容易实现。

但用好这些上下文，