一人一个 Agent

一人一个 Agent：从聊天工具到长期存在的数字实例

从半年 Hermes 实践到 Dots、Muse、TraeWork，我越来越觉得，Agent 真正需要的不是一个聊天框，而是一个长期存在的运行实例。

本文速览

从今年年初开始，我一直在使用 OpenClaw 和 Hermes。后来我们做多用户智能体时，也采用了「每个用户一个 Hermes 实例」的方式。最近 Dots、Muse、Grok Bot、Manus，以及国内的 WorkBuddy、QwenWork、TraeWork，都在把 Agent 从聊天窗口往长期存在的工作环境推进。

我越来越觉得，Persistent Agent 的重点其实不是 Cloud Computer，而是 Identity、Memory、Files、Permissions、Tasks 和 Runtime 能不能一起长期存在。PC 时代是一人一台电脑，移动互联网是一人一部手机，到了 Agent 时代，很可能会变成：一人一个 Agent。

今年年初，我开始比较重度地使用 OpenClaw 和 Hermes。最开始当然还是把它们当成 Agent Framework 用：给模型接一些工具，让它能读文件、跑 Shell、调用搜索、执行 Skill，再给它一些记忆，让它不要每次启动都像第一次见我。

用着用着，我发现使用方式慢慢变了。我不再只是打开一个聊天窗口，问完问题以后关掉，而是会把一些事情直接交给 Hermes。项目放在那里，文件在那里，Skill 也在那里，过一段时间重新回来，它还知道自己在做什么。

后来我们在做公司的多用户智能体产品时，又做了一个看起来有点「重」的设计：每个用户运行一个自己的 Hermes 实例。 不是所有人共享一个 Agent，然后在 Prompt 里塞一个 user_id，而是真正一人一个。

当时并没有觉得这是一个多么特别的产品理念，更多还是工程上的原因：不同用户有不同的文件、记忆、权限、Skill、配置和任务，如果全放在一个 Agent 里面，很多事情反而更麻烦。

但最近一个月，我再看市面上的一些新产品，突然发现大家好像都开始往差不多的方向走了，只是实现方法不一样。

从聊天工具到长期 Agent

我们为什么最后变成了「一人一个 Hermes」

传统 SaaS 的多用户其实很好理解。后端服务只有一套，所有用户共享。数据库里的每一行带上 user_id，文件系统按照租户隔离，权限系统决定你能看到什么。AI 聊天产品最开始基本也是这样：你发一段 Prompt，后端调用模型，模型给你一个答案。即使增加聊天历史，本质上仍然是一个 Request / Response 服务。

但 Agent 开始真正做事情以后，情况会复杂很多。它不只有聊天记录，还可能有自己的工作目录，里面放着正在处理的项目；可能安装了一些专属于这个用户的 Skill；浏览器里可能已经登录了某个服务；Memory 里面保存着用户长期积累的信息；还有一些任务正在运行，甚至有几个任务等着明天继续。

这个时候，一个用户对应的已经不再只是数据库里的几条记录，更像是一个正在运行的工作环境。

我们后来给每个用户单独跑一个 Hermes，很大程度上就是因为这个：

用户 A
  ↓
Hermes A
  ├── Memory
  ├── Files
  ├── Skills
  ├── Profile
  ├── Credentials
  └── Tasks

用户 B
  ↓
Hermes B
  ├── Memory
  ├── Files
  ├── Skills
  ├── Profile
  ├── Credentials
  └── Tasks

底层的大模型当然可以共用，GPU、推理服务、搜索、RAG、ASR、TTS 这些能力也都可以做成公共服务。但上面这一层 Agent 的状态，我越来越不希望共用。

所以我现在理解的「一人一个 Agent」，并不是每个人独占一张 GPU，也不是每个人真的需要一台物理电脑，而是每个人需要一个属于自己的 Agent 状态空间。

一人一个 Agent 的实例架构

最近，大厂也开始给 Agent 找地方住了

9 月 29 日，OpenAI 发布了 Dots。官方对 Dot 的定义很直接：它是一个 always-on Agent，可以在两次对话之间继续推进工作，有自己的 Cloud Computer，可以连接 App，也会保留完成长期任务所需要的上下文。

这和普通 ChatGPT 对话的区别其实很大。普通聊天本质上还是「你来找我」，而 Dot 开始变成「这个事情以后归你负责」。

Meta 更早一点，在 9 月 8 日发布了 Muse。Muse 后面直接配了一台 Secure VM：一个 persistent、isolated 的 Linux 虚拟机，带完整浏览器。Meta 的描述也很有意思——这是「你和 Agent 共享的一台电脑」，文件、浏览器以及计算资源都长期存在。

xAI 的 Grok Bot 走得更直接。官方把它称为 always-on agents。Bot 有浏览器、文件系统和终端，可以在你合上电脑以后继续工作，还可以保存长期上下文，甚至可以把你演示过的一套工作流程保存成 Skill，以后定时重新执行。

Manus 这条路线也越来越明显。它在今年 6 月推出 Cloud Computer，把以前任务结束后会销毁的临时 Sandbox，变成 persistent、always-on 的虚拟环境。到了 Manus 2.0，Cloud Computer、Automations、Remote Control 和 Agent Team 又进一步组合到一起。

如果只看产品名字，这些东西差别很大。但把 UI 拿掉以后，底下开始出现一些越来越相似的东西：Agent 有自己的文件、浏览器、长期状态、账号权限、任务和调度器，而且你离开以后，它还可以继续运行。

这已经不是以前那个「给 LLM 加几个 Tool」的概念了。

海外 Persistent Agent 产品

国内也在走同一条路

最近国内几个产品也挺有意思。

腾讯的 WorkBuddy 更偏本地。它获得授权以后，可以直接读取和操作本地文件，在本机规划和执行任务，同时支持 Skills、MCP、多任务和多智能体协作。腾讯自己对它的定义已经不是聊天机器人，而是一个「桌面工作台」。

千问办公 QwenWork 又是另一种形态。它把 Workspace、文件、Connector、Computer Use 和定时任务放到了一起。尤其是定时任务，我觉得是一个挺关键的变化：浏览器关掉以后，任务仍然可以在云端按照计划执行。官方自己说得很直接——从「你问它才动」变成「到点自己干」。

TraeWork 可能是最近这些产品里，最能体现「本地 + 云端」这种变化的一个。桌面版可以选择本地运行，也可以选择云端运行；网页版本身就在云端。手机则更像一个 Agent 调度器，可以管理云端和多台个人电脑上的任务。设备离线以后，任务还可以切换到云端继续跑，任务状态在手机、Web 和桌面之间同步。

看到这里，我反而觉得有一个区别挺有意思：有些产品是在给 AI 一台电脑，另外一些产品是在让 AI 住进我的电脑。

Dots、Muse、Grok Bot、Manus 的 Cloud Computer 更接近前一种；WorkBuddy、QwenWork 的桌面能力更接近后一种；TraeWork 则明显在试图把两边连起来。

我自己的 Hermes 使用方式，其实也一直比较偏后一种。很多事情直接在自己的机器上做，文件在本地，Skill 在本地，模型也可以在本地。但两条路最后解决的是同一个问题：

Agent 总得有一个地方活着。

国内 Agent 产品也在走同一条路

Cloud Computer 其实不是重点

最近很多产品开始强调 Cloud Computer，很容易让人觉得 Agent 下一阶段就是「每个 AI 发一台虚拟机」。我觉得没有那么简单。

虚拟机只是一个比较容易理解的实现方式。真正重要的是，Agent 能不能把这些东西长期保存下来：

Identity
   ↓
Memory
   ↓
Files
   ↓
Skills / Tools
   ↓
Credentials / Permissions
   ↓
Tasks / Goals
   ↓
Scheduler / Events
   ↓
Runtime

它可以跑在 VM、Container、本地进程或者某种受控 Sandbox 里。实现形式并不是关键，真正发生变化的是：这些东西开始跟 Agent 绑定，而不是跟某一次聊天绑定。

以前我打开一个 AI 产品，大多数时候面对的是一个「能力」。我要写代码，就叫 Codex；要搜索，就叫 Search；要分析文件，就把文件扔进去。任务结束以后，这些能力还在那里，但「这个正在工作的对象」消失了。

Persistent Agent 反过来了。底下的模型可以换，浏览器可以换，搜索工具也可以换，但这个 Agent 自己还在。它记得这个项目，知道上次做到哪里，文件还在原来的地方，昨天授权过的工具今天还可以继续用。

这才是我觉得最近这些产品真正有意思的变化。

Persistent Agent 的关键组件

真正麻烦的是任务能不能继续

前几天我在用 Codex 做 AI Infra 漫画项目，一个任务跑到一半，额度用完了。那一刻我第一反应并不是「额度什么时候恢复」，而是另外一个问题：

为什么它不能自己等额度恢复以后接着干？

这个任务本身没有消失，代码还在那里，Todo 还在那里，目标也没变，唯一变化的只是现在暂时不能调用模型。

对一个真正长期存在的 Agent 来说，这其实应该只是：

RUNNING
   ↓
RESOURCE_UNAVAILABLE
   ↓
WAITING
   ↓
RESOURCE_AVAILABLE
   ↓
RUNNING

而不是：

RUNNING
   ↓
聊天结束

这也是我前几天研究 Paperclip，以及重新看 Hermes 里的 /loop、/goal 这些东西时越来越强烈的感受。

如果 Agent 只是一个聊天产品，那么「退出聊天」就是一个很自然的边界。但如果我把一个目标交给它，聊天就不应该再是生命周期，Goal 才应该是。

真正做起来以后，问题都很传统

当然，「一人一个 Agent」说起来很好听，真正做起来以后会碰到很多很传统的问题。

一个聊天请求结束以后，服务器基本可以把资源释放掉；一个 Agent 如果长期存在，它什么时候算「不用了」？一个用户十分钟没说话，要不要停？停掉以后 Memory、文件和任务状态放在哪里？还有任务正在运行怎么办？第二天重新拉起来以后，如何恢复到之前的状态？

Agent 越来越多以后，这些问题就不再只是 LLM 问题，而开始变成进程管理、任务队列、资源调度、权限、隔离、持久化、故障恢复和成本核算问题。

Memory 也是一样。一个 Agent 如果真的跟着我几个月甚至几年，它当然不能每次都从零开始，但「什么都记住」同样不对。项目会结束，偏好会改变，昨天的信息今天可能已经过期。如果所有东西都不断往 Memory 里面加，Agent 最后不一定越来越懂你，也可能只是越来越乱。

所以长期 Agent 真正需要的，不是无限增长的聊天记录，而是一套能够更新、淘汰、归档和重新组织的信息系统。这个问题现在远没有解决，包括我自己在用 Hermes 的时候，也仍然在不断试。

本地和云端，最后可能会混在一起

Cloud Agent 最大的优势很明显：它永远在线，电脑关掉也没关系。但本地 Agent 也有自己的优势，因为我的很多东西本来就在电脑上——代码、照片、文档、Git 仓库、开发环境、ComfyUI、各种自己写的脚本和工具。

如果为了让 Agent 做一个任务，先把这些东西全部上传到另外一台云电脑，有时候反而绕了一圈。

前几周我用本地 Qwen3.8-27B，再接 Qwen-Image 2.1，让 Agent 自己生成绘本和漫画。以前是我操作软件一张一张做图，现在更像是把任务交给 Agent，中间隔一会儿看看它做到哪里。

回头看，我觉得这其实也是同一件事情：本地图像模型只是它的一个 Tool，LLM 也只是其中一个组件，真正有价值的是那个一直存在的 Agent。

所以未来大概不会是 Cloud Agent 和 Local Agent 二选一。更可能的情况是：需要长期在线的任务放云端，涉及大量本地数据、隐私或者本地软件的事情留在自己的电脑，手机则变成一个控制入口。

TraeWork 现在这种「电脑 + 云端 + 手机调度」的形态，我觉得已经能看到一点这个方向。

从「功能」变成「实例」

写到这里，我觉得可以重新回答一个问题：最近这些 Agent 产品到底有什么新东西？

如果只是 Browser Use、Shell、MCP、Skill，其实都不新，OpenClaw、Hermes 这些开源项目很早就在做，我自己从年初也一直在用。

真正开始变化的，是产品正在从：

「这里有一个 Agent 功能。」

慢慢变成：

「这里有一个属于你的 Agent。」

这两个东西看起来只差几个字，背后的系统设计完全不一样。前一种是能力，后一种是实例。能力可以随时被调用和替换，实例则会留下历史、积累状态，并且可以在你不在的时候继续工作。

所以我现在再看 Dots、Muse、Grok Bot、Manus、QwenWork、WorkBuddy、TraeWork，反而不会特别纠结哪一个功能多一点、哪个模型 Benchmark 高一点。

底层模型当然仍然重要，但往后走，Agent 好不好用，很可能越来越取决于另外一些东西：它住在哪里，它记得什么，它拥有什么权限，它能不能在我不在的时候继续工作，出了问题能不能恢复，我重新回来以后，它是不是还知道自己做到哪里。

这些东西以前看起来都不像 AI，现在反而越来越像 Agent 最核心的部分。

从一人一台电脑、一人一部手机，到一人一个 Agent