7 月 9 日，OpenAI 发布 ChatGPT Work，一款面向知识工作的智能体产品。三周后，Work 与 Codex 合计用户数突破一千万。更值得注意的信号是，Greg Brockman 已经确认，Work 会在年底前并入 Chat。这意味着 Work 目前呈现的产品形态，不是给一小群高级用户用的实验田，是 ChatGPT 十亿周活跃用户未来默认交互方式的预演版本。

把这件事放在时间线里看会更清楚。从 2023 年的 Plugins，到 2024 年的 Devday，到 2025 年的 Codex，OpenAI 花了三年时间，一直在为全人类构建可部署的智能体基础设施。Work 不是一个孤立产品，是这条长线上一个关键的收束节点，把此前分散在 Chat、Codex、Operator、ChatGPT agent 里的能力，第一次整合进一个统一的产品外壳。

多数关于 Work 的讨论停留在它能做什么，连 Slack 邮件日历、云端跑几小时任务、自动生成文档表格网站。这些是表层能力，几乎每个大模型厂商都在往这个方向补齐。真正决定这个产品未来走向、也决定 OpenAI 在这场平台竞争里站在什么位置的，是它在架构层面做的一个容易被忽略的选择：智能体的计算能力和智能体的记忆连续性，被刻意分离到了两个不同的治理层级里。

Work 的核心运作单元是任务。每个新对话在 Work 里都是一个任务，任务运行在一台隔离的云端微型虚拟机上，Pro 账户配 8 核 CPU、20GB 内存、64GB 磁盘，配合一个独立托管的 Chrome 浏览器服务。桌面端还多了一种本地模式，智能体可以直接操作用户自己的电脑，本质上就是去掉了代码痕迹的 Codex。

关键的设计在于持久化的方式。这台云端计算机不是一台永远开着的机器，而是把工作状态同步到持久化存储，按需恢复到临时的微型虚拟机上。也就是说，承载计算的硬件本身是可以随时销毁重建的，但工作状态会被完整还原。每个任务在 /workspace/scratch 下拿到一个工作目录，智能体在这个目录里享有普通电脑的全部自由，建文件夹、装依赖、写脚本、维护数据库，都可以。同一个线程里继续对话，它会回到同一个工作状态接着改。

但只要涉及跨任务的上下文，情况完全不同。智能体不会把不同任务的工作目录当成一个可以自由穿梭的共享空间去导航，而是必须依赖 ChatGPT 产品层提供的几个专用工具。每个新线程默认收到的是近期任务和文件的压缩摘要，不是原始对话记录。原始对话记录本身根本不存放在计算机里供智能体浏览，跨线程调取上下文，要靠一个叫 Personal Context 的专用工具去查询独立管理的历史服务，取回相关片段。

文件系统走的是同一个模式。用户上传的文件自动进入 Library，一个面向用户的中心文件库，智能体创建的文件则要用户主动要求，或者智能体自己判断值得保留才会存进去。Library 不是计算机上的一个目录，只能通过专用工具触达。更有意思的一个细节，一个文件同时存在两个地方，线程内的工作副本和 Library 里的规范版本，这两者互不同步。如果线程 A 上传了一份文件，线程 B 后来改了 Library 里的版本，线程 A 恢复运行时读到的仍然是自己那份过时的本地拷贝。

记忆和项目也遵循同一套逻辑。ChatGPT 的核心记忆原语，是一份持续综合更新的用户画像，由产品异步维护，在任务开始时提供给智能体做参考，智能体能基于它推理，但不能修改它，也不能像 OpenClaw 那样自己写一份别的任务默认会加载的 Markdown 文件。Projects 把关联对话、标准指令、用户上传的资料打包在一起，一个新任务进入 Project 会收到指令、相关对话摘要、资料的本地拷贝，但 Project 本身并不像在 Codex 里那样，在计算机上以一个真实目录的形式存在，它仍然是产品层维护的一个抽象。

把这几层放在一起看，结论是一致的：智能体在单个任务内部拥有接近无限的自由度，但跨任务的一切连续性，记忆、文件、项目，全部经过一个智能体本身够不到、改不了的产品层来仲裁。

这套架构选择，和此前引发广泛讨论的 OpenClaw 走的是完全相反的路线。OpenClaw 让智能体拥有一台真正属于自己的常驱计算机，可以在一台一直开着的笔记本或云主机上创建目录、安装软件、维护数据库，跨对话跨子任务全部复用，状态不局限于对话历史或某个记忆系统，而是分散在整台计算机里。这种架构给了智能体极大的自主权和连续性，代价是一旦智能体判断失误或被恶意诱导，波及的是整台机器上的一切，这正是多家科技公司以安全理由封禁 OpenClaw 的直接原因。

OpenAI 没有选这条路，原因可以拆成三层，且这三层的重要性并不对等。

第一层是存量成本约束。Work 建立在 Conversations、Library、Personal Context、Memory 这些已经服务着十亿用户的既有产品原语之上，把这套体系推倒重建，代价过高，这是一个工程现实层面的解释，但不是最有意思的那层。

第二层是安全边界。一个智能体如果对承载全部文件、对话、记忆的单一环境拥有无限制访问权，对用户是不安全的，OpenClaw 的遭遇已经验证了这一点。这一层更接近监管和产品责任层面的考量。

第三层最容易被忽略，却是这个架构选择里唯一真正具有战略意义的一层：把跨任务连续性的控制权收在产品层，而不是交给智能体本身，本质上是在决定谁能够定义用户迁移成本的大小。 如果智能体自己能够自由读写、自由组织跨任务的全部记忆和文件，那么这套连续性理论上是可以被导出、被复制、被迁移到另一个平台的。一旦这套连续性只能通过 OpenAI 自己设计的几个专用工具、以摘要和片段的形式间接触达，用户在这个平台上积累的时间越长，这份连续性本身就越难以被搬走，因为它从来没有以一种完整、可迁移的形式存在过。

这是一个经济学意义上非常清晰的机制设计问题，不是产品美学问题。控制资产的可迁移性，是控制转换成本最直接的方式，而转换成本是决定用户粘性、进而决定平台议价能力的核心变量。OpenAI 选择把智能体的计算能力做成随时可销毁重建的商品化资源，同时把承载用户历史和身份的连续性牢牢留在自己可控的产品层，这个组合不是偶然的工程决策，是一次清醒的、面向十亿用户默认体验的护城河设计。

这套逻辑并不新鲜，在每一次基础设施跃迁里都出现过同构的版本。大型机分时租赁时代，账单按计算时长结算，但真正决定客户留存的，从来是积累在系统里的数据和流程沉淀，不是租用了多少小时的 CPU。移动互联网的操作系统之争，最终的胜负也不取决于处理器主频快慢，取决于身份认证、应用生态、数据存续是否被锁定在一个封闭体系内部。云计算的公有云竞争里，计算和存储本身早已是高度商品化、价格趋同的资源，真正锁住客户的是数据引力，迁移一套跑在某个云上多年的数据管道和依赖关系，成本远高于迁移计算负载本身。Work 的架构选择，是同一套护城河逻辑在智能体这一层的重新演绎：计算被商品化，连续性被平台化。

这个判断也解释了原文提出但没有回答的一个问题，为什么 Work 缺一个能跨任务、跨项目统筹调度的元层智能体。答案很可能不是技术上做不到，而是一旦存在这样一个元层智能体，它天然需要触达全部跨任务的连续性数据才能发挥作用，这恰好会打穿当前刻意维持的分离结构。这道题不解决，不是因为难，是因为解决它本身有战略成本。

文章里提到的两个功能，主动任务建议和 Scheduled Tasks，表面看是用户体验层面的锦上添花，放进上面的框架里看，其实是同一个逻辑的自然延伸。

主动任务建议，是 Work 基于日历、邮件里的信号，结合记忆里的用户偏好，异步推理出一个用户大概率需要的任务，预先写好一个可以直接执行的提示词。这个功能能够成立的前提，恰恰是那份跨任务、跨渠道积累的用户画像已经沉淀在产品层里，且只有 OpenAI 自己的产品层能够调用它做这种异步推理。这不是通用能力，是那份不可迁移连续性资产的一次直接变现。

Scheduled Tasks 则把这套连续性从被动查询，升级成主动触发。标准的做法是从一个保存的提示词开始，每次运行都开一个新任务，适合自包含的一次性工作。另一种是在已有对话内触发，通过一个叫心跳的机制，重新唤醒一个上下文完整的任务，适合监控长期运行的操作。无论哪一种，背后依赖的都是同一份产品层维护的连续性，用户越依赖这类自动化，越是在往这份不可迁移的资产里加码投入，退出成本随之上升。

这两个功能今天看起来只是体验优化，但它们的存在恰恰印证了三、里提出的判断：连续性资产一旦被平台层垂直整合，接下来所有建立在它之上的新功能，无论主动建议还是自动化调度，天然都会进一步加深用户对这个平台的沉没依赖，而不会削弱它。

Work 的云端浏览器同样不运行在智能体所在的计算机上，而是一个独立托管的 Chrome 服务，智能体通过工具调用远程操作它。这个设计延续了同一套治理原则，智能体能操作浏览器，但浏览器的凭证、会话、权限记录，由一份独立同步的许可清单管理，智能体本身从不直接接触这些凭证。

有意思的是这套架构暴露出的现实局限。因为云端浏览器运行在数据中心而不是用户本地设备上，它会遭遇本地浏览器不会遇到的问题，亚马逊美国站直接把它识别成不受支持的客户端予以拒绝，谷歌相册的操作反复超时，而这两个任务切换到本地模式都能顺利完成。这说明云端浏览器这条路径，短期内注定要和越来越多网站的反自动化机制正面遭遇，这是把浏览器也纳入平台化连续性架构必须承受的代价，代价目前还不小。

Work 依赖的插件体系，是 OpenAI 过去三年反复试错后收敛出的连接外部世界的主路径，从最初的 Plugins，到 GPTs 和 Actions，到连接器，到应用和应用商店，最终在今年七月统一成插件目录，覆盖 Chat 和 Codex 两端。一个插件可以包含应用、技能、企业专属的应用模板三种成分，插件本身又分为操作型、角色型、服务型三类。

目前插件目录已经收录超过一千个插件，覆盖大多数主流应用和服务。但文章里一个具体案例值得单独拎出来分析。作者让 Work 搜索机票和酒店，它绕开了几个已经安装、理应更适合这个任务的旅行类插件，直接用网页搜索完成，即便在提示词里直接点名 Expedia，也没有触发对应插件的调用。

这不是一个简单的产品体验 bug，是一个典型的双边市场发现失灵问题。插件目录本质上是一个连接开发者供给和用户需求的双边市场，一千个插件已经在供给侧铺开，但需求侧的匹配和路由机制明显落后于供给规模。这里牵涉一个不轻松的产品判断：系统要判断一个任务该自己直接完成，还是该推荐一个插件，还是该在多个可用插件之间做选择，任何一个环节判断错误，都会造成插件被闲置、用户体验变差、开发者激励不足的连锁反应。

这道题为什么重要，值得多说一句。搜索引擎最终的核心资产，不是抓取了多少网页，是把海量网页和海量查询精确匹配起来的排序算法，广告拍卖机制建立在这套排序能力之上。应用商店最终的核心资产，也不是收录了多少应用，是能把用户意图和合适应用连接起来的推荐算法，抽成和定价权建立在这套推荐能力之上。插件目录今天面对的，是完全同构的问题，谁能先把一千个插件和用户任务之间的匹配路由问题解决，谁就拿到了未来这个新兴双边市场里定价和抽成的主导权，这道题现在还没人解开，意味着这块蛋糕的分配方式还没有定型，窗口目前还是开着的。

Work 值得持续关注的原因，不是它现在能不能把一份会议纪要写好，也不是它今天的插件调用还不够聪明。这些都是会随着迭代持续改善的执行细节。真正重要的，是 OpenAI 已经在为十亿用户即将默认使用的体验，提前做出一个关于连续性归属权的架构决定，这个决定一旦成为十亿人的默认使用习惯，几乎不可逆。

如果把视野放宽到整个 AI 平台竞争的尺度上，一个可以推导出的判断是，这场竞争最终分出胜负的变量，大概率不是哪家的基础模型在跑分上领先几个百分点，模型能力这件事，历史已经反复证明会被同行迅速拉平、被开源迅速下沉。真正难以拉平、也难以下沉的，是哪个平台把最多用户的持久记忆、连续上下文、跨任务的身份沉淀，用一种用户离不开却又搬不走的方式，握在了自己手里。这不是一句空泛的战略口号，是从 Work 目前公开的架构细节里，可以逐层推导出来的一个具体机制。模型会被拉平，用户在一个平台上日积月累的连续性资产不会，这才是这场竞争里真正稀缺、真正值得押注的那个变量。