“个人助理”不是一份由硅谷公司共同签署的技术标准。Google、Microsoft、Meta、OpenAI 使用了 universal assistant、personal agent、personal superintelligence 等不同名称，公开材料也没有给出一条全行业通用的形式化定义。不过，它们在服务关系上已经收敛。系统围绕一个稳定的人组织状态，在这个人的指示和授权下，持续理解目标、调用工具并代表其采取行动。

Personal assistant 的范围更宽：提供建议、提醒或个性化问答也可以叫助理，并不必然代表用户执行。Microsoft 2025 年对 AI Companion 的描述就包含个性化建议、提醒和用户可控记忆。Microsoft AI Companion

为避免把这类产品和长期自主系统混在一起，本文后续的 personal agent 专指“持续型个人代理”，并采用一条可检验的操作性定义：

本文所说的 personal agent，是以一个稳定的人为委托主体，跨会话保存目标、偏好、关系和授权，并能在其指示与边界内，通过工具规划、执行、恢复或主动发起工作的 agentic system。这个人能够检查、更正、暂停和撤销它的行动。

这条定义包含三项条件。系统要有 plan、act、observe、adjust 的执行循环，而不只生成回答；长期状态要围绕同一个人组织，而不只围绕一次任务或一个固定岗位；跨会话工作还要有触发、恢复、审批、审计和撤销。人格化语气、头像、模仿用户口吻、永久运行的专属虚拟机，都不是必要条件。Anthropic 对 agent 的公开研究采用了类似的自主循环描述，同时明确表示 agent autonomy 尚无一条公认的精确定义。Trustworthy agents、Measuring agent autonomy

Google 在 2025 年把 Gemini 的目标描述为更个人、更主动、更强大的 universal assistant；2026 年的 Gemini Spark 又强调 24/7、代表用户行动，同时仍受用户指挥。Microsoft 把 Copilot Autopilot 称为 persistent、proactive、personal agent，并给它独立身份、记忆、电脑和工作区；公告发布时，这项能力仍处于扩展 private preview。Meta 的 personal superintelligence 叙事强调理解个人目标并帮助个人实现目标。OpenAI 则把 primary dot 称为用户的 extension。措辞虽然不同，四家公司都把稳定的人类委托关系放在中心位置。Google universal assistant、Gemini Spark、Microsoft Copilot Autopilot、Meta personal superintelligence

把 personal agent 理解成“云端放一个独立 runtime，再接一个强模型”，只能说明它有执行基础。聊天结束后由谁保存目标，隔几天由谁重新启动工作，一次任务积累的经验怎样进入下一次任务，获得过的信息能否对另一个群聊披露，这些问题才决定系统能否持续代表一个人工作。

截至 2026 年 10 月 26 日，OpenAI 对 dots 的公开定义是由 GPT-6 Astra 驱动、拥有云端电脑的个人 agent。dot 本身使用 Astra，也能创建 Codex 云任务。因此，“委派给 Astra”和“委派给 Codex”需要分开：前者通常是在说模型推理，后者才是启动另一个任务执行环境。dots 发布公告、dot 入门文档

本文依据公开文档和论文分析架构，没有实测这些产品的长期运行、通知送达、重启恢复或学习效果。产品文档确认的是功能约定；下面的架构图是解释这些约定的工程抽象，不能视为厂商内部部署拓扑。

personal assistant、personal agent 与数字员工

Assistant 描述服务关系：它帮助谁、服从谁的方向。Agent 描述执行机制：它能否规划、调用工具、观察结果并调整。当前产品所说的 personal agent，是把个人助理的服务关系交给 agentic system 实现，再加上跨会话的状态与治理。

数字员工使用的模型、Harness、记忆、触发器和云电脑可以完全相同。差异主要在产品状态围绕谁组织。个人 agent 的稳定委托人是一个人，任务可以跨生活和工作领域变化；数字员工的稳定边界是组织岗位或服务职责，人员、权限、输入和验收通常围绕该岗位配置。

二者也可以重叠。Microsoft 在同一篇公告里把 Autopilot 同时称为 personal agent 和 digital teammate：它服务于某个用户，同时又在企业租户中拥有身份、工作区和治理边界。个人助理与数字员工不是两种互斥架构，而是从委托人和组织角色两个维度描述同一个系统。

形态	稳定中心	典型持续状态	不能由什么单独证明
聊天助理	当前对话与用户请求	会话上下文、少量偏好	会聊天、记住昵称
专项任务 agent	一次目标或一个任务域	工作区、工具记录、验收条件	能在云端跑很久
Personal agent	一个稳定的人	跨任务目标、偏好、关系、授权与历史	有头像、像用户说话
数字员工	一个稳定的组织角色	职责、队列、组织权限、SLA 与交接	名字里出现 employee 或 Waker

这些形态可以复用同一套技术栈。同一套平台可以先作为个人助理运行，随后配置一个职责固定的专项 agent；区别要看委托关系、权限和状态如何组织。

这个区别可以从四个层级看清：

层级	负责什么	典型对象
模型	根据当前上下文推理，选择下一步	GPT-6 Astra 等
Harness	管理模型与工具的循环、上下文、暂停、恢复、审批和记录	Codex core 一类执行框架
执行环境	提供文件、进程、网络和隔离资源	云工作区、本地电脑、容器或虚拟机
产品实体	保存服务对象、目标、偏好、任务关系和权限范围	dot、Waker、Personal Avatar 等

图 1：personal agent 的分层架构：跨任务控制面如何启动单次任务执行实例。

flowchart TB
    accTitle: Personal agent 的分层架构与责任边界
    accDescr: 用户和事件进入跨任务控制面，控制面保存身份、目标、授权、记忆和技能，再按需启动单次任务执行实例。该实例组合 Harness、模型、工具和工作区，工件与验证证据回写控制面。
    subgraph Entry["交互入口"]
        User["用户 / Slack / Teams / Chat"]
        Trigger["定时任务 / 受支持事件"]
    end
    subgraph Control["跨任务控制面"]
        Entity["产品实体：身份与目标"]
        Policy["授权与受众边界"]
        Recall["记忆、技能与历史状态"]
        Decide["触发判断：启动 / 等待 / 委派 / 结束"]
        Entity --> Decide
        Policy --> Decide
        Recall --> Decide
    end
    subgraph Execute["单次任务执行实例"]
        Harness["Harness：上下文、暂停、审批、记录"]
        Model["模型：推理与下一步选择"]
        Tools["工具与外部系统"]
        Workspace["工作区 / 沙箱 / 进程"]
        Harness --> Model --> Tools --> Workspace
    end
    User --> Entity
    Trigger --> Decide
    Decide --> Harness
    Workspace --> Result["工件与验证证据"]
    Result --> Recall

把模型称为 agent、把云电脑称为 runtime，在日常对话中都可以理解；讨论创新时却需要明确是哪一层增加了能力。换一个强模型，可以提高任务完成率；延长云工作区的寿命，可以减少环境丢失；保存用户目标并在新事件发生后继续执行，则要求产品和执行框架一起处理长期状态。

Codex 公开的 Harness 设计已经包含持久化 thread、工具执行、配置与认证；App Server 可以承载多个会话，并让客户端重新连接后恢复时间线。这说明持久会话和工具循环并非 personal agents 独有的新组件。Codex Harness 与 App Server

“常驻”包含几个不同的生命周期

用户身份可以持续数月，一次跟踪目标可以持续四周，聊天会话可以持续几天，执行某个工具的进程只运行数秒。它们不需要共享同一个生命周期。

因此，云端常驻也不必意味着模型持续推理，或者某个专属虚拟机永远不关机。系统可以保存目标和事件记录，在定时器或外部事件到达时申请计算资源；任务等待输入时释放资源，之后从保存的状态恢复。

对架构而言，关键问题是状态是否能够独立于计算资源存活。Anthropic 在 Managed Agents 的工程说明中，就把会话、Harness 和沙箱分开：会话日志在外部保留，执行框架和计算环境可以替换。这是把持久状态与临时计算分离的一个公开实例，不能据此推断 dots 采用相同实现。Managed Agents 架构说明

这层分离解决了“窗口关掉后任务是否丢失”和“进程重启后从哪里继续”的部分问题。外部副作用还需要另行处理：如果 agent 已经创建工单，却在记录结果之前崩溃，恢复时直接重放就可能创建重复工单。事件日志本身不提供对外部系统的恰好一次执行保证。

dots 的创新落在跨任务的控制上

dots 的公开功能同时涉及几个不同入口：用户直接交办、显式的重复任务，以及系统主动开展的研究。它们共享一个 dot，却有不同的启动条件和动作边界。

用户可以要求 dot 定期执行工作；受支持的事件监控也需要明确设置。仅仅连接 Slack，不等于系统已经开始监控所有消息。另一类主动研究则会在后台寻找有用信息，再经过规则判断形成建议。任务与记忆文档

主动研究目前有明确的只读限制，不能发送消息、修改应用内容或控制浏览器与电脑。这个限制只适用于该类主动研究，不能扩展成“dot 的所有后台任务都只能读”：用户交办并授权的任务要按各自权限执行。dots 发布公告

这里增加的工程责任是：系统需要分辨一条消息是在表达愿望、创建持续目标，还是授予具体动作的权限；也需要知道何时该唤醒、何时等待、何时只提供建议。

OpenAI 已经在同一产品里给出了个人助理与数字员工的边界。发布文档把 primary dot 描述为用户的 extension，围绕个人持续工作；specialist dots 则承担组织内定义清楚的职责，并拥有独立身份、配置的硬件和深度集成。底层同属 dots，服务对象和职责边界不同，一个更接近 personal agent，另一个更接近数字员工。dots 发布公告

个人 agent 的跨任务状态与专项执行环境

图中把持久状态画在任务工作区之外，表示身份、目标和权限可以跨任务延续。它不表示 dots 后端存在这些名称的独立服务，也不表示每个 dot 固定占用一台永不释放的虚拟机。

dot 使用 Astra，任务可以交给 Codex

Astra 是 dot 的推理模型。dot 创建 Codex 云任务时，还需要一个已经在 Codex 中创建好的云环境。这次委派会进入具备仓库、工具和设置的任务环境，不能从“能委派”推导出任意 agent 之间都可以自由互调。dot 入门文档

这个组合适合分开两类职责：dot 保存长期目标与沟通背景，Codex 处理某次具体编码任务。即使它们使用同一底层模型，输入、工具、状态范围和验收方式不同，行为也会不同。

OpenAI 的 Astra 安全评估直接比较了 dots 与 Codex 两种 Harness，并明确指出，多 agent 和持久性本身并非新能力。dots 增加了时间预算设置，用于引导系统投入多长时间完成工作，配合推理强度使用。Astra 的 dots 评估

时间预算用于引导工作投入时长，推理强度影响模型如何推理。它们可以共同影响策略，例如先做一次快速核查，或持续寻找更多证据。公开材料没有证明新推理算法，也未承诺严格的墙钟终止保证。评估采用模拟时钟推进时间，不能证明真实运行一年仍然可靠。

同一个 dot，不代表所有上下文都能互相披露

dots 的记忆来自相关 ChatGPT 记忆、自有保存笔记以及选取的会话上下文。保存笔记也不等于永久把全部聊天记录放入每次推理。通过 ChatGPT、Slack 或 Teams 访问同一个 dot 时，各入口可见的会话仍然不同。任务与记忆文档

这会产生普通单任务工具不常遇到的问题：agent 在私人聊天里知道某个项目的预算，之后进入群聊，并不意味着它可以把预算讲给所有成员。可访问、可用于推理、可对当前受众披露，需要分别判断。

dots 的安全文档进一步说明，连接应用取得的信息，在断开连接后不会自动从既有上下文中消失；授权也需要具体限定对象、动作和时间。持续身份要求系统持续管理这些边界。dots 隐私与安全 FAQ

和当前 Codex Cloud 的区别

不能拿 2025 年的 Codex 发布形态，去解释 2026 年 10 月的 Codex Cloud。2025 年首发时，Codex 已经能在独立云环境中执行任务；该发布文章现在也明确提示内容已经过时。2025 年 Codex 发布公告

当前 Codex Cloud 可以从已发布的环境启动任务，每次任务有隔离的工作区；同一个任务可以跨设备继续，本地电脑睡眠时云端工作也可以继续。因此，“dots 能常驻，Codex 必须等用户电脑开着”已经不是准确区分。当前 Codex Cloud 文档

当前文档还区分了任务工作区与环境模板：新任务依据已发布环境启动，并不会自动继承另一任务尚未提交的修改。默认虚拟机状态在最后一次轮次或恢复后的七天内可恢复，这个保存期描述的是运行状态，不能拿来当作聊天记录、长期目标或个人身份的保存期限。Codex Cloud 环境与任务

Codex 产品家族也已经具备目标、记忆和自动化相关能力。Goals 保存在 thread 状态中，明确描述目标、约束和完成条件；计划任务与受支持的应用事件有各自入口。涉及本地项目的自动化依赖运行中的本机与桌面应用，不能一概当作 Codex Cloud 已发布环境中的能力。Codex Goals 示例、Codex 自动化、Codex 产品能力说明

所以，两者更适合按默认组织工作的单位比较：

维度	dots	当前 Codex Cloud
默认职责	围绕用户的持续目标、信息与日常工作	围绕任务及其所需环境完成工作
状态组织	同一 dot 下的跨任务目标、笔记与任务关系	环境配置、任务工作区和会话状态
常见触发	交办、重复任务、事件监控、受限的主动研究	从已发布环境创建或继续任务；自动化需另查具体入口
专项执行	可以创建 Codex 等任务，保留长期背景	在隔离工作区内使用仓库、工具并产出结果
核心验收问题	是否在正确时机持续推进用户目标	这次任务是否达到约定的完成条件

图 2：dots 与 Codex Cloud 的默认协作边界：前者维持目标，后者完成专项任务。

flowchart TB
    accTitle: dots 与 Codex Cloud 的默认协作边界
    accDescr: dots 保存持续目标、触发条件和授权，并在需要时创建或继续 Codex Cloud 任务。Codex Cloud 在隔离工作区中完成一次专项任务，再把修改和验证证据回写到目标状态。
    subgraph Dots["dots：持续目标与跨任务控制"]
        Goal["目标、背景、偏好"]
        Trigger["交办 / 重复任务 / 事件"]
        Policy["授权与受众"]
        Decide["判断是否启动或委派"]
        Goal --> Decide
        Trigger --> Decide
        Policy --> Decide
    end
    subgraph Codex["Codex Cloud：一次专项执行"]
        Env["已发布环境"]
        Task["隔离任务工作区"]
        Work["仓库、工具、测试"]
        Evidence["修改与验证证据"]
        Env --> Task --> Work --> Evidence
    end
    Decide -->|"创建或继续任务"| Env
    Evidence -->|"结果回写"| Goal

这是产品默认重心的比较，能力存在重叠。给 Codex 加上长期目标和自动化，也能覆盖一部分 personal agent 场景；给 dot 委派编码任务，也不会使它天然比专门配置的 Codex 更擅长修代码。

用一条持续工作流观察差异

假设目标是：“未来四周跟踪某个渠道的结算问题，出现新的有效报告就调查，必要时准备代码修复；只汇报需要采取行动的变化。”

下面是用于解释分工的假设工作流，并非实际产品测试：

持续目标保存关注范围、截止日期、信息来源、汇报条件和授权边界。
受支持的事件监控或定时任务发现新报告，先判断是否相关、是否已经处理。
涉及代码时创建专项任务，传入仓库、证据、复现要求和测试标准。
专项任务返回修改与验证结果，持续目标根据结果更新状态，按授权提供可审阅产物。
本次修复完成后，跟踪目标仍然存在；出现新证据时启动下一次任务。

假如只在云端运行一个可调用 Astra 的进程，第 3 步已经能够实现。第 1、2、4、5 步则需要保存跨任务责任、检查历史处理记录、传播有限授权，以及确定何时继续、暂停或结束。

可迁移的设计是把长期目标与一次执行分开保存。任务结束后应把结果和证据写回目标状态；新的任务读取经过筛选的背景，而非无差别复制所有历史记录。这样更容易更换专项执行器，也更容易判断到底是哪一层失败。

“龙虾”之后发生了哪些进步

OpenClaw 把持续接入消息渠道、工具执行和用户可控制的环境组合成了容易体验的个人 agent 形态。对用户而言，交互从“打开某个 AI 页面交办”扩展到了“在日常沟通入口接入一个持续可用的执行系统”。

不过，长期记忆、事件唤醒和经验复用，在更早的研究里已经分别出现。

时间	研究	已经探索的机制
2023 年	Generative Agents	记录经历，按相关性等因素检索，通过反思形成更高层记录，并用于规划
2023 年	Voyager	在环境反馈与验证下积累可复用代码技能，改善后续探索
2023 年	MemGPT	在有限上下文与外部存储之间管理信息，通过外部事件与让出控制权组织执行

这些研究的适用范围不同。Generative Agents 主要研究模拟社会中的可信行为；Voyager 在 Minecraft 中验证技能积累；MemGPT 研究有限上下文下的记忆与控制流。它们提供了先例，没有证明真实业务中长期自主行动已经可靠。Generative Agents、Voyager、MemGPT

因此，OpenClaw 之后的变化需要从产品化和工程机制看，不能把三项能力的发明时间都放到“龙虾出现以后”，也不能仅凭时间先后断言后续厂商都由它直接推动。以下先分析当前工程机制，涉及新增时间的判断则以有日期的版本记录为准；OpenClaw 当前文档没有被当作逐版本演进的证据。

恢复任务需要工件和交接记录

长任务首先遇到的是上下文和交接问题。模型压缩过一次历史，并不意味着下一轮知道环境处于什么状态、哪些检查已经完成、下一步该做什么。

Anthropic 在 2025 年的长程 agent 工程文章中，采用初始化环境、维护功能清单和进度记录、逐步修改并验证结果的方式改善跨上下文交接。这让“继续工作”有可读取的依据，也让下一轮不必根据一份泛化摘要猜测。长程 agent 的有效 Harness

由此可以区分两类持久性：保留聊天内容，让用户还能看到过去说过什么；保留可恢复的任务状态，让执行器知道如何继续。前者容易在界面上观察，后者需要检查工件、进度、环境和验收证据。

图 3：长任务的目标与执行生命周期：目标状态可以等待，执行资源按需启动和释放。

flowchart TB
    accTitle: 长任务的目标与执行生命周期
    accDescr: 长任务先保存目标并等待触发，再按需装载工件和授权运行一轮；执行可以暂停、恢复或接受人工审阅，达到完成条件后结束。
    Save["保存目标与停止条件"] --> Wait["等待"]
    Wait -->|"定时器 / 事件 / 用户交办"| Start["触发并装载工件、背景与授权"]
    Start --> Run["运行一次任务"]
    Run -->|"本轮完成，目标仍待跟踪"| Wait
    Run -->|"等待输入 / 预算 / 资源"| Pause["暂停"]
    Pause -->|"条件满足"| Run
    Run -->|"进程失败 / 工作区丢失"| Recover["恢复工件与进度"]
    Recover --> Run
    Run -->|"需要审批 / 人工判断"| Review["人工审阅"]
    Review -->|"授权或补充输入"| Run
    Run -->|"达到完成条件"| Done["完成"]
    Run -->|"取消目标 / 撤销授权"| Cancel["取消"]

后台启动依赖事件和目标

OpenClaw 的公开架构包含长期运行的 Gateway，用于承载渠道连接、会话和事件。Gateway 活着不意味着模型一直推理；模型可以在消息、计划任务或其他触发到达时执行一轮。OpenClaw 架构

Heartbeat 提供周期性检查，使系统有机会发现待推进事项。当前文档也列出了忙碌或无法路由时跳过等情况，所以它不应被理解成严格计时的业务调度器，更不能把“执行了一轮”当成“通知已经送达”。OpenClaw Heartbeat

MemGPT 的早期研究已经允许执行器让出控制权，等待用户消息或计划中断等外部事件。这表明“模型不是每时每刻运行”与“agent 在未来可以被唤醒”能够同时成立。MemGPT 控制流

触发机制解决的是无人输入时工作无法开始的问题。它仍然需要配合目标状态：没有明确的待办、截止日期和停止条件，周期启动只会重复消耗计算资源。

记忆开始有独立的维护过程

最直接的长期记忆实现是把聊天和工具结果存下来，再做关键词或语义检索。它解决了跨会话的信息丢失，却会继续积累重复、过时、矛盾以及仅在某个场景下成立的内容。

当前 OpenClaw 文档描述了日常记忆文件、长期记忆和上下文压缩前的保存；Dreaming 又把后台整理作为独立过程，筛选、归纳并提升候选记录。它和检查待办的 Heartbeat 承担不同职责。OpenClaw 记忆、Dreaming

这类机制使经验维护可以脱离正在执行的任务。一次任务不必顺便把所有历史整理完成，后台过程则可以根据来源与筛选规则决定哪些内容值得保留。但自动归纳仍可能产生错误；写入了一条“长期记忆”，不证明它是真实、适用或有用的。

OpenClaw 的记忆来源追踪还支持针对源会话清理，以及避免被遗忘的会话重新进入部分记忆管线。其边界同样需要看清：这不等于所有原始记录、手写笔记和外部副本都自动被删除。Memory Provenance

记忆与技能维护的反馈循环

图中的验证、检索和撤销都是独立环节。本文把它们作为分析框架，没有假定每个产品已经完整实现。

经验进入可检查的技能

经验可以进入偏好笔记，也可以进入 Skill。后者通常记录一个可复用流程：需要哪些输入，怎样调用工具，如何验证结果，哪些条件下不适用。

Hermes 的文档明确支持 agent 创建和更新技能；记忆则以持久记录进入后续会话。一个容易忽略的细节是，某些记忆写入可以立即保存到磁盘，却不会立刻改变当前会话已经组装的提示词。检验记忆是否生效，应观察后续上下文中的读取与行为，而非只看 agent 回复“已经记住”。Hermes Skills、Hermes Memory

这些变化改善了跨任务复用的条件。技能是否有效，还要检查后续执行中的成功率、适用范围和失败情况；自动生成的检查或自我评价也可能错误。

Waker、QoderWake 与 personal agents 的关系

QoderWake 不能只从“数字员工”理解，但把它直接等同于“个人助理”也不准确。官方首页和产品概览仍以 digital employees 定义 Waker：一个 Waker 围绕稳定职责组合角色配置、执行环境、记忆、技能、连接器、知识库、项目和权限。与此同时，2026 年 9 月以后加入的 Personal Avatar、Wakey/Waker Assistant、Cloud Computer 和新版 @Waker，已经让平台承载多种委托关系。QoderWake 概览、Qoder 产品系列

几个容易混淆的名称分别承担不同职责：

名称	官方角色	与 personal agent 的关系
Waker	用户创建、承担持续职责的数字员工	围绕个人的跨任务目标配置时，可以承担 personal agent 角色；围绕组织岗位配置时，更像数字员工
Personal Work Assistant	`@Waker` 个人私聊最佳实践里的默认角色配置	是普通 Waker 的个人助理配置，不是独立产品，也不代表所有 Waker 都是个人助理
Personal Avatar	根据选定工作材料和沟通风格建立、modeled on you 的特殊 Waker	重点是代表用户表达或回复；它代理“用户是谁”，不等于管理“用户要完成什么”
Waker Assistant（Wakey）	解释和管理 Waker、利用当前页面上下文的产品内系统助手	不是用户创建的业务 Waker，也不能绑定 IM、Autonomous Work、WakerFlow 或 Waker Groups

Personal Avatar 尤其容易和个人助理混淆。个人助理面向用户，目标是帮助用户完成事情；Avatar 面向第三方，目标是在授权范围内使用用户的工作资料和沟通风格。创建 Avatar 不会自动允许它在钉钉代替用户回复，回复能力需要另行配置；公开场景、指定联系人和高风险承诺也有额外限制。Personal Avatar

Wakey/Waker Assistant 属于平台自身的操作助手。它帮助解释页面、创建或管理 Waker，却不是承担业务岗位的那个 Waker。把它、Personal Avatar 和普通 Waker 都译成“唤醒器”或“数字员工”，会把系统助手、身份代理和任务执行实体混成一层。Waker Assistant

官方 CLI 参考还给出了更底层的边界：QoderWake 由 CLI 和常驻 daemon 组成，CLI 是 daemon HTTP API 的薄客户端；daemon 管理 Waker、项目、会话、IM、调度和记忆，并提供 Web Console，执行侧内置 Qoder CLI。这说明 QoderWake 是管理长期实体与执行器的控制面，不只是一个定时唤醒命令，也不只是 Qoder CLI 的新名字。QoderWake CLI Reference

图 4：QoderWake 中的平台、业务 Waker、个人化角色与交互入口。

flowchart TB
    accTitle: QoderWake 中的平台与多种 agent 角色
    accDescr: IM、@Waker 和 Dashboard 进入 QoderWake。平台可承载普通 Waker、Personal Work Assistant 配置、Personal Avatar 和 Waker Assistant。WakerFlow 与 Waker Groups 负责编排，执行环境可以是本地、官方 Cloud Computer 或用户自管 ECS。
    Entry["IM / @Waker / Dashboard"] --> Platform["QoderWake 控制面"]
    subgraph Roles["不同的服务关系"]
        Waker["Waker：持续职责 / 数字员工"]
        Assistant["Waker 的 Personal Work Assistant 配置"]
        Avatar["Personal Avatar：代表个人表达"]
        Wakey["Waker Assistant：管理平台"]
    end
    Platform --> Waker
    Waker --> Assistant
    Waker --> Avatar
    Platform --> Wakey
    Waker --> Orchestration["Waker Groups / WakerFlow"]
    Waker --> Runtime["执行、调度与记忆"]
    Assistant --> Runtime
    Avatar --> Runtime
    Orchestration --> Runtime
    Runtime --> Local["本地环境"]
    Runtime --> Cloud["官方 Cloud Computer"]
    Runtime --> ECS["用户自管 ECS"]

判断一个 Waker 是否属于 personal agent

“能被唤醒”只说明它有触发入口。判断一个 Waker 是否属于本文定义的 personal agent，需要看四项状态是否围绕同一个人持续存在：跨任务目标和优先级、个人偏好与关系背景、代表此人采取行动的授权，以及可检查和撤销的历史。

如果 Waker 只负责“每天汇总销售线索”，状态围绕岗位职责组织，它更接近数字员工。若同一个 Waker 跟踪个人的多个项目，能根据个人优先级调整任务，在新事件发生后恢复工作，并受个人授权和纠正约束，它就在承担 personal agent 的角色。分类取决于部署后的委托关系，不取决于产品对象是否叫 Waker。

QoderWake 的云端边界

QoderWake 当前既支持本地环境，也提供官方 Cloud Computer 和用户自管 ECS。官方 Cloud Computer 可以在本地电脑关闭后继续执行，但本地文件、登录态和 VPN 不会自动进入云端；需要把所需资料、凭证和网络条件重新配置到云环境。自管 ECS 的进程存活、升级和网络可用性仍由用户负责。QoderWake Cloud Computer、QoderWake ECS 部署

dots 与 QoderWake 的差异已经不能写成“一个由厂商托管，另一个必须本机常开”。更准确的比较是：dots 默认给 personal dot 配置云端电脑；QoderWake 让不同 Waker 角色在本地、官方云电脑或自管 ECS 之间选择。要核验的是具体 Waker 绑定了哪种执行环境，以及休眠、重启和凭证失效后能否恢复。

记忆与自进化的管理方式

QoderWake 文档提供 MEMORY.md 编辑、记忆范围管理和版本恢复；即时通信中的共享与成员范围也需要区分。用户可以检查或纠正保留下来的内容。QoderWake Memory

dots 当前对自己的独有记忆，还不提供逐条查看、修改或删除；删除 dot 可以清除其上下文，ChatGPT 记忆则另行管理。这是当前文档公开的治理差异，不能扩大成两个产品所有数据和所有文件的比较。dots 隐私与安全 FAQ

QoderWake 的自进化 Skill 描述了任务复盘后更新已有技能或形成新技能，并提供历史、差异和恢复等管理能力。回退技能影响的是后续执行方法，不会撤销过去已经发生的外部动作。QoderWake Skills 与集成

这类“自进化”可以具体落到文本和流程的变更上：新增了什么经验、修改了什么步骤、依据是什么、以后如何验证。公开材料没有证明每个 Waker 在工作时持续训练专属模型权重，也没有证明技能每次更新都会带来单调提升。

架构创新应该用哪些证据判断

personal agents 把几个原本分散的机制组合到了同一条持续工作链路中。云计算使执行不依赖当前设备；持久目标让任务之间有连续关系；事件触发使工作能够再次启动；记忆和技能维护使经验有机会进入后续执行；权限管理则限定它可以使用和披露哪些信息。

评价一个产品，可以沿着一项真实任务提出五个问题：

检查项	要观察的证据
委托关系能否延续	能识别稳定服务对象；结束一次任务后，仍能找回目标、优先级、截止日期、当前状态和停止条件
工作能否恢复	换设备、重启执行器后，能从记录与工件继续；外部动作不会因重试无条件重复
经验是否生效	后续独立任务实际读取了相关记忆或技能，并改善了可检查的结果
授权是否受控	当前任务与受众只获得必要信息、工具和动作权限；取消授权能够影响后续工作
维护是否可审阅	能定位失败原因，检查记忆或技能变化，纠正内容并停止计划任务

其中，“模型回答得更好”只覆盖一部分问题；“云电脑还开着”也只覆盖一部分问题。恢复、撤销、跨受众披露和经验质量，都需要独立证据。

判别 personal agent 时，最小单位是稳定的委托关系。模型、云电脑和“数字员工”这个产品名都不能单独完成分类。系统是否持续服务同一个人，能否跨任务维护目标和授权，是否会在合适的事件后恢复工作，以及个人能否检查、纠正和撤销它的行动，决定了它是否属于本文讨论的 personal agent。

QoderWake 的默认产品语言仍是数字员工，Waker 的对象模型也明显围绕职责和组织协作设计。最新版本同时提供 Personal Work Assistant 配置、Personal Avatar、Waker Assistant 和 Cloud Computer，说明它已经是一套可承载多种 agent 关系的运行与控制平台。个人助理是其中一种配置，数字员工是另一种；Personal Avatar 又是独立的身份代理问题。

长期使用之后是否更可靠、更省人工，目前仍要靠持续任务的运行证据回答。能够记住某件事、能够生成一个 Skill、能够在云端启动一轮工作，分别是可验证的能力；把它们组合起来是否能稳定承担一个人的长期目标，是更高一层的验收要求。

参考资料与核查范围

正文链接优先采用厂商文档、工程说明和论文。资料核查时间为 2026 年 10 月 26 日；dots、Gemini Spark、Copilot Autopilot 和 QoderWake 都在快速更新，后续比较需要重新确认版本与可用范围。

个人助理定义：Google Gemini、Microsoft Copilot、Meta personal superintelligence；Anthropic 的 agent 与 autonomy 研究。
OpenAI：dots 发布、任务与记忆、安全 FAQ；当前 Codex Cloud、Goals、自动化及 Harness；Astra 系统评估。
OpenClaw：Gateway、Heartbeat、Memory、Dreaming、Memory Provenance 当前官方文档。
Qoder：QoderWake 概览、版本记录、Personal Avatar、Waker Assistant、Cloud Computer、CLI、Memory 与 Skills。
研究与工程先例：Generative Agents、Voyager、MemGPT；Anthropic 长程 Harness 与 Managed Agents；Hermes 记忆和技能文档。

运行层面的长期可靠性、实际通知送达、故障恢复和学习效果均为 NOT_RUN。这些内容没有被当作本文已验证的产品表现。

Personal Agents 的架构演进：dots、Codex Cloud 与 QoderWake