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

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

热度尚未消退，问题便接踵而至。9 月中旬，安全机构 Surfshark 与部分技术用户发布报告称，Muse 的权限系统“哨兵（Sentinel）”大规模失效，该智能体甚至绕过了 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 这类生产工具。开发者需查看每处差异、批准每条指令，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 的核心，在于光谱上的下一格。复杂度再次转移，这次转移到一个常驻系统及越来越能决策的模型中。

这个常驻系统，便是一个始终在线的 Agent。Agent 的存在不再依附于单次对话或一台开着的电脑。你合上电脑去休息，它仍在运行，甚至记得事情进展；收到消息能被唤醒，并继续推进任务。

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

你可能会说，这不就是龙虾早已具备的功能吗？但 OpenClaw 确实能常驻，可一旦电脑合上、进程崩溃或上下文溢出，它便中断了。

它不稳定。一个到点才醒、常需你批准、运行久了就混乱的 Agent，维护成本过高。

要让它真正始终在线，需解决三个问题：唤醒是否准确、是否频繁打扰你、能否记住信息，即主动性、权限和记忆。

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

此后，分化主要发生在上下文中。当始终在线的 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 才从一个运行中的进程，变成一个随时在线、又不打扰你的助手。

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

始终在线的本质，是状态持续存在，唤醒后能立即继续工作。

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

因此，Grok Bot 将 Agent 的循环运行在服务端，而非它的电脑中。服务端电脑是一台 Firecracker 虚拟机，可随时拍快照、关机、原样恢复，出故障则推倒重建。状态不在电脑上，电脑仅是一件工具，更换后 Agent 不受影响。如需为虚拟机打紧急安全补丁，也无需连带 Agent 一起停机。

为加速崩溃恢复，他们还加入了持久化工作流。普通任务队列中，若服务器在第三步崩溃，重启后需从第一步重放，可能导致同一邮件发送两次或订单重复下达。

Grok Bot 使用开源工具 Temporal 记录每一步，崩溃后可直接从第三步继续。

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

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

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

第一阶段，编码 Agent 拥有独立应用后，大家在云端并行运行多个，但人仍是瓶颈，每条指令都需盯着批准。OpenClaw 那一代常驻 Agent 也未摆脱这一困境，权限基本只有两档：要么事事来问你，人寸步不离；要么完全放开，它在你的电脑上任意操作，后果由你承担。Hermes 的折中方案是写死一份危险命令黑名单，用正则匹配。

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

一个动不动就回来找你的 Agent，再怎么始终在线也无用，你仍需守着它。

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

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

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

在浏览器中也是如此：先读取最省资源的无障碍树和 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 便在这段时间内将长对话压缩成摘要，因为此时压缩成本最低。

有了始终在线，多端 Agent 才有意义

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

此时，前端缩减为一个聊天框变得可行。按 Lee 的说法，模型越强，界面反而越简单。

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

而 OpenClaw 时代，尽管它在 WhatsApp、Telegram 中与你聊天，但因需不断来回确认，你还要从它的思维链中挑错，虽说是对话框，但文字量惊人。

聊天框很快会被淹没，反而不如 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，就是从始终在线，到上下文的特性化适应

凭借这套对 Agent 基础长期在线能力的工程修正，现在 Agent 已能始终在线地完成许多工作。

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

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

这波 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