![personal_agent_01_task_to_runtime.png](https://developer.qcloudimg.com/http-save/yehe-8159227/62918e2feaa9568acfecac868d98587f.png)
`Personal Agent` 的出现直接来自现有 `Agent` 生命周期与个人长期任务之间的矛盾。当前大多数 `Agent` 都以一次会话或者一个任务作为执行边界：用户提出目标，`Runtime` 组织上下文，模型进行规划和工具调用，任务完成以后释放执行环境。这种模式可以很好地支持代码生成、资料研究、网页操作等明确任务，但当 `Agent` 开始处理个人日程、长期目标、持续关注事项以及跨应用事务时，任务结束已经不再意味着相关状态可以结束。过去的选择、浏览器登录状态、文件、权限、等待中的外部事件以及尚未完成的长期目标，都需要在下一次执行时继续存在。
`Meta Muse` 把这个问题直接落实到了系统架构上。`Muse` 运行在每个用户独立的 `Muse Secure VM` 中，虚拟机拥有自己的浏览器，并持续保存与这个用户相关的数据和服务连接；用户关闭客户端以后，耗时任务仍然能够继续工作，直到环境发生变化或者需要用户进行授权。`Meta` 对 `Muse` 的产品设计也直接包含长期 `Goal`、主动建议和后台执行，而没有把它限制在一次问答过程中。由此发生的关键变化，是 `Agent` 的生命周期开始从一次 `Task` 扩展到一个持续存在的 `Person`，任务逐渐成为 `Personal Runtime` 内部不断创建、暂停、恢复和结束的运行对象。

# 从 `Task Agent` 到长期 `Personal Runtime`

典型的任务型 `Agent` 在收到用户请求以后创建一次运行，上下文、模型推理、工具调用和执行结果主要围绕当前任务组织。即使任务内部包含几十次甚至上百次模型调用，`Agent Loop` 仍然具有明确的开始与结束位置。任务结束以后，模型上下文可以释放，临时 `Sandbox` 可以销毁，大量中间状态也失去了继续保存的必要。
个人 `Agent` 面对的是另一种时间尺度。假设用户要求 `Agent` 在未来两个月持续准备一次旅行，它可能首先读取 `Calendar` 确定可用时间，几天以后监控航班价格，预订完成后继续处理酒店，临近出发时再根据天气调整计划。这里不存在一条连续运行两个月的 `Agent Loop`，系统实际经历的是大量执行与等待交替出现的阶段。模型每次只负责当前阶段的判断，真正把这些阶段连接成同一个长期任务的是 `Runtime` 中持续存在的 `Goal`、`Task State`、`Schedule` 和环境状态。
因此，`Personal Agent` 的执行过程更接近具有状态持久化能力的工作流。一次运行完成阶段性工作以后，系统产生 `Checkpoint` 并进入 `Suspend`；时间、邮件、日历、外部系统状态或者用户的新输入再次产生 `Event` 时，`Runtime` 找回原来的 `Goal` 和 `Task State`，重新组织当前 `Context`，再从已有状态继续执行。长期任务可能反复经历 `Activate → Execute → Checkpoint → Suspend → Resume`，直到目标完成。
这里开始出现 `Durable Execution` 的典型特征。模型负责一次激活周期中的 `Reasoning` 和 `Action Selection`，`Agent Runtime` 负责跨激活周期保存任务身份、执行位置、等待条件和历史结果。如果所有状态都依赖 `Conversation History` 恢复，模型每次都必须重新从自然语言记录中判断任务执行到了哪里，一旦历史被压缩、工具结果发生变化或者前序动作失败，任务状态就容易发生漂移。长期 `Personal Agent` 因而需要显式的 `Task State`，`Conversation` 负责人与 `Agent` 的交互记录，`Runtime` 则负责真正的执行状态。
# `Personal Agent` 中不同生命周期的状态

当 `Agent` 生命周期从 `Task` 扩展到 `Person`，过去可以统一放进 `Context` 的信息开始表现出完全不同的生命周期。个人偏好可能几年以后仍然有效，一个酒店预订任务可能只存在几天，浏览器 `Cookie` 的有效时间由目标网站决定，等待中的支付授权可能只有几分钟，一次模型推理产生的 `Working Context` 则可能在当前执行周期结束后立即失效。
![personal_agent_02_state_model.png](https://developer.qcloudimg.com/http-save/yehe-8159227/1611ef6a47260807e1f601685c02b3ea.png)

这里至少需要区分四类状态。`Personal State` 保存用户长期稳定的信息、偏好、关系、历史决策和持续目标，承担认知连续性；`Task State` 保存任务当前进度、计划、检查点、等待条件和历史结果，承担执行连续性；`Environment State` 保存浏览器 `Session`、文件、`Workspace`、应用状态和任务产物，承担环境连续性；`Authorization State` 保存连接器权限、确认记录、凭证有效状态和授权范围，承担代理权限的连续性。
这四类状态不能简单进入同一个长期 `Memory`。短期任务进度如果持续写入个人记忆，会逐渐污染用户长期状态；浏览器 `Session` 和文件属于执行环境，也没有必要被转写成自然语言记忆；授权状态更加不能由模型根据历史对话自行推断。`Personal Agent` 因此需要把状态按照生命周期和系统职责分别管理，再在任务启动时将真正相关的信息组装成当前模型需要的 `Context`。
这也是 `Personal Memory` 和普通聊天历史最重要的区别。`Memory` 保存的是能够跨任务继续使用的个人状态，`Context` 则是某一次模型执行真正读取的工作集合。两者之间需要存在独立的形成、检索、更新和失效机制。
# `Muse Secure VM` 让 `Computer` 从 `Tool` 变成运行环境

早期讨论 `Computer Use` 时，`Computer` 通常位于工具层。模型根据 `Screenshot` 或 `Accessibility Tree` 判断界面状态，再产生 `Click`、`Type`、`Scroll` 等 `Action`，浏览器或者远程桌面只是完成某次任务的一种执行工具。这种实现能够解决没有结构化 `API` 的软件操作问题，但 `Computer` 与 `Agent` 之间并不存在稳定的长期关系。
`Muse` 进一步改变了这种关系。`Meta` 为每个用户建立持续存在的 `Muse Secure VM`，`Agent`、浏览器、文件、任务产物和连接服务能够长期存在于同一个执行环境中。一次浏览器自动化建立的登录状态可以被后续任务继续使用，任务创建的文件可以继续留在 `Workspace`，等待数天以后重新恢复的任务也不需要从零重新构建全部环境。`Computer` 因而开始承担 `Persistent Execution Environment` 的角色。
![personal_agent_03_meta_muse_architecture.png](https://developer.qcloudimg.com/http-save/yehe-8159227/bfd266daafb85daa654a2d9c24f6d580.png)
长期存在的计算环境同时放大了安全问题。`Personal Agent` 会读取邮件、网页、文件等大量不可信输入，其中的 `Prompt Injection` 可能改变模型决策；如果模型同时能够直接读取凭证并自由访问外部系统，一次错误推理就可能产生真实的数据泄露或者外部操作。
`Muse` 因此把任务执行与授权能力分开。`Hatch / Agent Harness`、浏览器、工具、`Workspace` 和子 `Agent` 位于受控的运行区域中，凭证、访问控制、审计和持久状态由独立安全组件管理。模型可以产生访问某项服务的动作，但请求仍然需要通过 `Sentinel` 判断是否允许执行、是否需要注入凭证，以及当前行为是否需要用户确认。
这种结构与操作系统的资源访问模型已经非常接近。应用程序不会直接拥有所有设备和文件权限，而是通过受控系统接口访问资源；长期 `Agent` 同样可以采用 `Agent → Action → Security Runtime → Resource` 的执行路径。模型负责产生动作，确定性的安全系统负责约束动作能够到达什么资源。
由此，`Computer Use` 在 `Personal Agent` 中的角色也发生了变化。它仍然承担兼容传统 `GUI` 软件的作用，但浏览器、文件系统、应用和运行进程已经逐渐成为长期 `Runtime` 的一部分。`Computer` 从一次任务中的外部工具，开始转变为保存执行状态并连接数字世界的持续环境。
# `Qwen` 将 `Harness` 推向真实场景

`Qwen` 在真实世界智能体上的技术路径进一步扩大了 `Agent` 的运行边界。`Qwen Intelligence` 把手机侧能力拆成规划、执行和垂直能力，`Mobile Planner Agent` 负责长期任务规划、任务拆解和工具编排，`Mobile-Use Agent` 负责进入真实应用执行动作；设备本身则持续提供屏幕、应用、通知、文件和传感器等当前环境信息。
手机由此不再只是聊天窗口，它开始成为 `Agent` 的执行环境和感知入口。与此同时，复杂推理、持续浏览器任务以及需要运行数小时甚至数天的后台工作更适合云端执行，设备侧和云端自然形成不同的任务分工。
![personal_agent_04_qwen_runtime.png](https://developer.qcloudimg.com/http-save/yehe-8159227/96aa1b6a99c0b7d1455b0982c86d420f.png)
设备侧 `Local Runtime` 更接近用户当前环境，可以直接获得屏幕、应用、文件、通知以及实时多模态信息；云端 `Cloud Runtime` 更适合大型模型推理、长任务执行、云端浏览器、`Android Runtime` 和异步后台工作。位于二者之间的 `Agent Harness` 负责规划、上下文组装、工具路由、`Session`、`Working Directory` 以及 `Skill / Workflow`，把一次任务拆分到合适的执行环境。
真正复杂的问题由此从模型路由变成状态迁移。一个任务可能由用户在手机上通过语音创建，在云端运行半小时，再要求用户在 `PC` 上确认一份文档，随后重新回到云端继续执行。整个过程中，`Goal`、`Task State`、`Memory`、`Artifact` 和 `Authorization State` 都需要保持一致。
这使 `Personal Agent` 开始具有明显的分布式 `Runtime` 特征。设备和云端提供不同能力，任务控制面决定当前阶段应该运行在哪里、哪些状态需要同步、哪些个人数据必须留在设备侧，以及设备离线以后任务是否还能继续运行。
`Qwen Book` 提出的 `OS as Harness` 又把这一思路继续推进到 `PC` 操作系统。传统应用内 `Agent` 只能看到当前应用暴露的上下文和工具，而操作系统天然掌握应用、文件、窗口、设备、通知和权限等跨应用资源。`Harness` 下沉以后，可以统一组织这些能力，并根据应用已有能力选择结构化 `API`、系统语义接口或者 `Computer Use`。
因此，未来真实环境中的执行路径更可能呈现出明确的优先级：优先使用 `Structured Tool / API`，其次使用操作系统或者应用暴露的语义接口，在没有结构化能力时再使用 `Computer Use` 操作现有 `GUI`。这种方式既能够提高执行可靠性，也能够继续兼容大量没有为 `Agent` 重新设计的存量软件。
# `Personal Agent` 的分层架构

从长期任务、状态持久化、安全边界和设备协同继续向下拆解以后，`Personal Agent` 已经可以形成一套相对稳定的系统结构。
![personal_agent_05_layered_architecture.png](https://developer.qcloudimg.com/http-save/yehe-8159227/9a9e2f7f0b19ce53e6c58d1ff17cb469.png)
底层的 `Execution Environment` 提供浏览器、应用、文件系统、设备和云端虚拟机等实际执行能力，并保存大量环境状态。`Security & Identity Plane` 位于模型动作与真实资源之间，负责用户身份、`Credential Store`、权限控制、敏感动作审批和审计。`Agent Runtime` 管理长期 `Goal`、`Task`、`Scheduler`、`Checkpoint` 和 `Suspend / Resume`，决定什么时候执行任务以及任务当前处于哪个生命周期阶段。
`Harness` 负责某一次激活周期内的具体执行过程，包括 `Context Assembly`、规划、工具路由、环境观测和结果验证。`Foundation Model` 位于决策链路上，负责理解当前信息、完成推理并生成下一步动作。`Personal Context` 则横跨这些层次，将用户资料、长期记忆、历史任务和偏好按当前任务需要重新组织给模型使用。
因此，一个完整任务的执行过程可以描述为：用户或者外部事件激活一个 `Goal`，`Runtime` 恢复对应的 `Task State`，系统重新构造当前 `Context`，模型产生下一步动作，安全系统完成权限判断，执行环境进行真实操作，再由 `Harness` 验证结果并更新状态。如果当前阶段已经完成但长期目标还没有结束，任务保存 `Checkpoint` 并重新进入等待状态。
这里的 `Agent Loop` 只是长期 `Personal Runtime` 中的一段短周期执行。模型每次决定当前下一步应该做什么，`Runtime` 则保证整个任务在时间、状态和环境上持续存在。
# 从 `Memory` 到 `Personal Context`，再到 `Skill`

`Memory` 是 `Personal Agent` 的关键组成部分，但它只解决整个状态问题中的一部分。长期 `Agent` 需要知道用户过去做过什么、偏好什么以及哪些信息仍然有效，因此 `Memory` 负责从历史事件中形成可以跨任务使用的个人信息；当前任务真正执行时，`Runtime` 再把相关 `Memory` 与 `Task State`、环境状态、外部数据和最新 `Observation` 重新组合，形成当前模型需要的 `Context`。
一次执行产生的内容也不会全部进入长期 `Memory`。任务进度应该进入 `Task State`，文档和代码等产物进入 `Artifact Store`，浏览器变化留在执行环境，真正具有长期个人意义的信息才进入 `Personal Memory`。这种状态区分能够避免把所有历史都变成越来越大的聊天记录。
长期使用以后，系统还会积累另一类资产：`Skill`。`Memory` 保存“这个用户是谁、过去发生过什么”，`Skill` 保存“这一类事情应该怎样完成”。一个网站第一次可能需要通过 `Computer Use` 探索操作流程，多次成功执行以后可以沉淀成稳定的 `Workflow`、脚本或者结构化工具。
因此，长期 `Personal Agent` 会同时积累三类能力：`Memory` 维持认知连续性，`Skill` 维持执行方法连续性，`Persistent Environment` 维持真实环境连续性。`Durable Task State` 再把这些能力组织进一个持续数小时、数天甚至更长时间的任务生命周期。
# 总结与后话

### `Agent Runtime` 从任务执行器向个人计算环境扩展

过去 `Agent Runtime` 的主要工作是组织模型调用和一组 `Tool`，现在开始增加 `Session`、`Workspace`、`Memory`、`Browser`、`Scheduler`、后台任务、`Credential` 和设备上下文。`Muse` 直接给每个用户建立 `Persistent Secure VM`，`Qwen` 则继续把 `Harness` 推向手机、云端环境和操作系统。
这种扩张不会让模型取代操作系统。进程、文件、网络、权限、凭证、状态存储和故障恢复仍然需要确定性的系统组件负责，模型主要处理当前环境中难以提前编码的理解、规划和决策。随着 `Agent` 自主性增加，概率性的模型决策和确定性的系统控制需要形成更加明确的边界。
### `Person` 开始成为新的计算状态边界

`Conversation` 以消息为边界，任务型 `Agent` 以 `Task` 为边界，`Personal Agent` 则开始以 `Person` 作为长期状态边界。`Memory`、`Task State`、浏览器 `Session`、`Workspace`、`Credential`、`Skill` 和设备状态围绕同一个主体持续存在，短期任务只是在这个 Runtime 中不断产生和结束的执行对象。
因此，`Personal Agent` 更接近一种长期存在的个人数字 `Runtime`：模型负责判断当前应该做什么，`Harness` 负责组织单次执行过程，`Agent Runtime` 负责让任务在时间上持续存在，`Personal Context` 维持对用户的长期理解，执行环境负责连接真实数字世界，安全系统决定 `Agent` 能够代表用户执行到什么程度，设备与云端共同承担不同时间尺度和不同场景下的运行任务。
沿着这一结构继续发展，评价一个 `Personal Agent` 的重点也会逐渐从“模型是否具有足够强的 `Agentic` 能力”转向“是否存在一个能够围绕同一个人长期保存状态、持续执行任务并跨设备连接数字环境的 `Agent Runtime`”。`Muse` 已经把长期虚拟机、后台执行、个人状态和授权机制放进同一个产品形态，`Qwen` 则继续把真实世界执行、设备—云协同和 `OS as Harness` 推向终端与操作系统。`Personal Agent`** 正在从一次任务中的智能执行能力，逐渐形成围绕个人长期状态和数字环境建立的新计算层。**

Personal Agent 的出现直接来自现有 Agent 生命周期与个人长期任务之间的矛盾。当前大多数 Agent 都以一次会话或者一个任务作为执行边界：用户提出目标，Runtime 组织上下文，模型进行规划和工具调用，任务完成以后释放执行环境。这种模式可以很好地支持代码生成、资料研究、网页操作等明确任务，但当 Agent 开始处理个人日程、长期目标、持续关注事项以及跨应用事务时，任务结束已经不再意味着相关状态可以结束。过去的选择、浏览器登录状态、文件、权限、等待中的外部事件以及尚未完成的长期目标，都需要在下一次执行时继续存在。Meta Muse 把这个问题直接落实到了系统架构上。Muse 运行在每个用户独立的 Muse Secure VM 中，虚拟机拥有自己的浏览器，并持续保存与这个用户相关的数据和服务连接；用户关闭客户端以后，耗时任务仍然能够继续工作，直到环境发生变化或者需要用户进行授权。Meta 对 Muse 的产品设计也直接包含长期 Goal、主动建议和后台执行，而没有把它限制在一次问答过程中。由此发生的关键变化，是 Agent 的生命周期开始从一次 Task 扩展到一个持续存在的 Person，任务逐渐成为 Personal Runtime 内部不断创建、暂停、恢复和结束的运行对象。

聊一聊 Personal Agent

Personal Agent 的出现直接来自现有 Agent 生命周期与个人长期任务之间的矛盾。当前大多数 Agent 都以一次会话或者一个任务作为执行边界：用户提出目标，Runtime 组织上下文，模型进行规划和工具调用，任务完成以后释放执行环境。这种模式可以很好地支持代码生成、资料研究、网页操作等明确任务，但当 Agent 开始处理个人日程、长期目标、持续关注事项以及跨应用事务时，任务结束已经

高级系统架构师

人工智能

架构设计

操作系统

PersonalAgent从任务型智能体进化为以个人为中心的长期数字运行时，通过状态持久化、跨设备协同和安全管理，实现任务在时间维度上的持续执行。Muse和Qwen推动Agent生命周期从Task扩展到Person，形成多层次的系统架构。

数据泄露

文件系统

虚拟机

智能体

路由

Agent

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

聊一聊 Personal Agent-腾讯云开发者社区-腾讯云

聊一聊 Personal Agent

聊一聊 Personal Agent

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐