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等命令去查找。
除了这些要点，何时需要压缩，都由Grok Bot让模型自行规划。
除了记不住，长上下文还有一个问题：成本过高。每来一条新消息，整段对话历史都需重新发送给模型，费用高昂。唯一的绕路方法是利用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能否始终在线、不打扰你、不闯祸。特化到个人之后，要管的变成了它能否懂你、替你办事。
当然，第一步是获得更多关于你的上下文，通过你授权让它链接你的邮箱、日程
+1.5万 
