Personal Agents 的架构演进：dots、Codex Cloud 与 QoderWake
把 personal agent 理解成“云端放一个独立 runtime，再接一个强模型”，抓住了它的执行基础。这个组合却还不能说明：聊天结束后，哪个组件保存目标；隔几天谁再次启动工作；一次任务积累的经验如何进入下一次任务；获得过的信息能否用于另一个群聊。
这些问题决定了 personal agent 能否持续承担一个人的工作。服务器、模型和工具已经存在，新增的系统责任主要落在跨任务的状态、触发、记忆维护和授权管理上。
截至 2026 年 10 月 2 日，OpenAI 对 dots 的公开定义是由 GPT-6 Astra 驱动、拥有云端电脑的个人 agent。dot 本身使用 Astra，也能创建 Codex 云任务。因此，“委派给 Astra”和“委派给 Codex”需要分开：前者通常是在说模型推理，后者才是启动另一个任务执行环境。dots 发布公告、dot 入门文档
本文依据公开文档和论文分析架构，没有实测这些产品的长期运行、通知送达、重启恢复或学习效果。产品文档确认的是功能约定；下面的架构图是解释这些约定的工程抽象，不能视为厂商内部部署拓扑。
personal agent 的“个人”体现在哪里
一个 coding agent 接到“修复这个仓库的测试”后，通常围绕一次任务组织上下文、工具、工作区和结果。个人 agent 的职责可以持续更久：跟踪一个问题四周，记住哪些进展需要汇报，在新证据出现时重新启动工作，调用合适的专项 agent，随后继续跟踪。
“个人”在这里指向稳定的服务对象和跨任务责任。昵称、头像、聊天语气可以帮助交互，但不能代替这层状态。一个只能记住昵称的机器人，与一个能延续目标、应用偏好并接受纠正的系统，承担的责任不同。
这个区别可以从四个层级看清：
| 层级 | 负责什么 | 典型对象 |
|---|---|---|
| 模型 | 根据当前上下文推理，选择下一步 | GPT-6 Astra 等 |
| Harness | 管理模型与工具的循环、上下文、暂停、恢复、审批和记录 | Codex core 一类执行框架 |
| 执行环境 | 提供文件、进程、网络和隔离资源 | 云工作区、本地电脑、容器或虚拟机 |
| 产品实体 | 保存服务对象、目标、偏好、任务关系和权限范围 | dot、Waker 等 |
把模型称为 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 发布公告
这里增加的工程责任是：系统需要分辨一条消息是在表达愿望、创建持续目标，还是授予具体动作的权限；也需要知道何时该唤醒、何时等待、何时只提供建议。
图中把持久状态画在任务工作区之外，表示身份、目标和权限可以跨任务延续。它不表示 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 等任务，保留长期背景 | 在隔离工作区内使用仓库、工具并产出结果 |
| 核心验收问题 | 是否在正确时机持续推进用户目标 | 这次任务是否达到约定的完成条件 |
这是产品默认重心的比较，能力存在重叠。给 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
由此可以区分两类持久性：保留聊天内容，让用户还能看到过去说过什么；保留可恢复的任务状态，让执行器知道如何继续。前者容易在界面上观察，后者需要检查工件、进度、环境和验收证据。
后台启动依赖事件和目标
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 是承载数字员工的产品与运行平台，Waker 是其中的员工实体。一个 Waker 可以拥有职责、执行环境、记忆、技能和工作区；多个 Waker 可以分工，由组长路由和汇总。WakerFlow 则提供多阶段工作流，容纳角色协作与人工介入。QoderWake 概览
在即时通信里，@Waker 是访问入口，消息可以被路由到具体员工。因此，这三个名称分别落在平台、实体和交互入口上，不能仅凭名字相近，把它们解释成三个先后替代的产品。IM 配置
公开历史能确认到哪里
Qoder 官方版本记录显示，2026 年 5 月 26 日的 0.0.10 公测已经使用 QoderWake 和 Wakers 两个名称，描述了本地运行、员工独立身份、记忆、技能和工作区等能力；2026 年 9 月 3 日的版本为 QoderWake 1.0.0。QoderWake 版本记录
早期公测已包含自动触发、记忆整理和技能积累。后续版本记录显示，6 月 10 日的 0.0.18 新增轮次之间的后台记忆整理，也增加了技能自进化冲突处理和时间线。8 月 14 日的 0.2.8 改善空闲超时恢复：释放后台资源后仍保留会话，新消息可以恢复执行。QoderWake 版本记录
这组变化分别处理经验维护占用主会话、技能变更难以检查，以及资源释放后会话无法继续的问题。它展示了“已经有记忆和常驻能力”之后仍需补齐的工作，也支持把会话寿命与计算资源寿命分开。
如果“之前的 Waker”指某个 IDE 内测入口或更早独立版本，目前取得的官方公开材料不足以确认它与 QoderWake 的完整继承关系。这个历史缺口应保留，不能写成“独立 Waker 后来更名 QoderWake”，也不能据此断言这样的内测版本不存在。
唤醒能力与 personal agent 是两个层级
假设某个 Waker 功能仅负责“到点启动任务”，它就提供了触发器。触发器可以启动任意任务执行器；要构成跨任务的个人 agent，还需要稳定身份、长期目标、可维护记忆、权限范围和结果回写。
但当前 QoderWake 文档已经包含这些更广的能力。它既能承载围绕个人工作的 agent，也能承载职责固定的专项员工或团队工作流。“Waker 只是一个定时器”同样不符合当前公开定义。QoderWake 概览
personal agent 是职责与状态组织方式；QoderWake 是实现这类能力的一种产品。一个 Waker 是否承担个人 agent 的角色，取决于它被分配的目标、信息范围和协作方式。
云端在哪里，谁负责让它持续运行
QoderWake 支持本地部署，也提供云桌面或 ECS 部署说明。自部署后，需要让机器与服务保持可用；休眠或关机会中断工作，定时任务也可能错过。断开远程桌面连接与关闭运行机器则是不同操作。QoderWake ECS 部署
Qoder CLI 的 Cloud Mode 另有托管虚拟机说明，可以在本地设备关闭后继续执行。这个产品能力不能直接移用为“QoderWake 默认由厂商托管，任何 Waker 都永远在线”。Qoder CLI Cloud Mode
所以，比较 dots 与 QoderWake，部署责任是一个实际差异：dots 文档提供云端电脑；QoderWake 公开了本地与自部署路线。单看“云端 agent”四个字，会遗漏谁负责进程存活、升级、网络和计划任务的可用性。
记忆与自进化的管理方式
QoderWake 文档提供 MEMORY.md 编辑、记忆范围管理和版本恢复；即时通信中的共享与成员范围也需要区分。用户可以检查或纠正保留下来的内容。QoderWake Memory
dots 当前对自己的独有记忆，还不提供逐条查看、修改或删除；删除 dot 可以清除其上下文，ChatGPT 记忆则另行管理。这是当前文档公开的治理差异，不能扩大成两个产品所有数据和所有文件的比较。dots 隐私与安全 FAQ
QoderWake 的自进化 Skill 描述了任务复盘后更新已有技能或形成新技能，并提供历史、差异和恢复等管理能力。回退技能影响的是后续执行方法，不会撤销过去已经发生的外部动作。QoderWake Skills 与集成
这类“自进化”可以具体落到文本和流程的变更上：新增了什么经验、修改了什么步骤、依据是什么、以后如何验证。公开材料没有证明每个 Waker 在工作时持续训练专属模型权重，也没有证明技能每次更新都会带来单调提升。
架构创新应该用哪些证据判断
personal agents 把几个原本分散的机制组合到了同一条持续工作链路中。云计算使执行不依赖当前设备；持久目标让任务之间有连续关系；事件触发使工作能够再次启动；记忆和技能维护使经验有机会进入后续执行；权限管理则限定它可以使用和披露哪些信息。
评价一个产品，可以沿着一项真实任务提出五个问题：
| 检查项 | 要观察的证据 |
|---|---|
| 目标能否延续 | 结束一次任务后，仍能找回目标、截止日期、当前状态和停止条件 |
| 工作能否恢复 | 换设备、重启执行器后，能从记录与工件继续；外部动作不会因重试无条件重复 |
| 经验是否生效 | 后续独立任务实际读取了相关记忆或技能，并改善了可检查的结果 |
| 授权是否受控 | 当前任务与受众只获得必要信息、工具和动作权限；取消授权能够影响后续工作 |
| 维护是否可审阅 | 能定位失败原因，检查记忆或技能变化，纠正内容并停止计划任务 |
其中，“模型回答得更好”只覆盖一部分问题；“云电脑还开着”也只覆盖一部分问题。恢复、撤销、跨受众披露和经验质量，都需要独立证据。
已有研究和当前产品文档表明，这轮 personal agents 正在把跨任务状态、触发、专项委派和经验维护组织成可使用的产品。相应的管理机制也开始变得具体。dots、Codex Cloud 与 QoderWake 在这些能力上有重叠，默认职责和部署责任却不同。
长期使用之后是否更可靠、更省人工，目前仍要靠持续任务的运行证据回答。能够记住某件事、能够生成一个 Skill、能够在云端启动一轮工作，分别是可验证的能力；把它们组合起来是否能稳定承担一个人的长期目标，是更高一层的验收要求。
参考资料与核查范围
正文链接优先采用厂商文档、工程说明和论文。资料核查时间为 2026 年 10 月 2 日；dots 发布时间较近，Codex Cloud 正处于新旧入口并存阶段，后续比较需要重新确认版本。
- OpenAI：dots 发布、任务与记忆、安全 FAQ；当前 Codex Cloud、Goals、自动化及 Harness；Astra 系统评估。
- OpenClaw：Gateway、Heartbeat、Memory、Dreaming、Memory Provenance 当前官方文档。
- Qoder：QoderWake 概览、版本记录、IM、ECS、Memory、Skills；CLI Cloud Mode 独立文档。
- 研究与工程先例：Generative Agents、Voyager、MemGPT；Anthropic 长程 Harness 与 Managed Agents；Hermes 记忆和技能文档。
运行层面的长期可靠性、实际通知送达、故障恢复和学习效果均为 NOT_RUN。这些内容没有被当作本文已验证的产品表现。
