这波个人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，需要做什么调整？

放入的上下文越私人