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 岁