这波个人Agent风潮背后，不只有“向人转向”

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，需要