Agent 工作区架构（Agent Workspace Architecture）
| 分类 | 🏗️ 架构范式 |
| 阅读时间 | ⏱️ 18 分钟 |
| 更新时间 | 📅 2026-10-16 |
| 条目编号 | ENC-ARCH-18-agent-workspace-architecture |
关键要点 ✦
- 为每个智能体分配独立的云端计算机或虚拟桌面，而非直接操控用户本机设备。
- 工作区自带浏览器与图形界面，智能体以「看屏幕、点按键」的方式操作应用，复用人类软件生态。
- 隔离边界带来安全与隐私优势：用户真实设备不被干扰，权限范围与执行结果可独立审计。
- 常驻型智能体依赖工作区实现跨小时或跨天的长任务执行与状态持久化。
- 工作区与托管运行时互补：前者提供「操作面」，后者提供任务调度与生命周期管理。
- 工程要点包括权限网关、会话可观测、人机接管与状态快照迁移。
概念与动机
随着常驻型智能体（Always-on Agent）与计算机操作（Computer Use）能力的成熟，一个工程问题逐渐凸显：让智能体直接控制用户的个人电脑，既会干扰用户正在做的工作，也难以在权限、审计与安全上形成清晰边界。Agent 工作区架构的回答是——给每个智能体一台「属于自己的电脑」。据 OpenAI 在 2026 年 9 月 DevDay 发布的 Dots 介绍，每个 Dot 都拥有一台云托管的虚拟计算机与独立浏览器，作为智能体的工作区，用户可随时查看其执行过程；这正是工作区架构的典型落地。
典型构成
一个工作区通常由三层组成。其一是执行面：一台云端虚拟机或容器，运行操作系统、桌面环境与浏览器，智能体通过计算机操作能力观看屏幕并模拟键鼠。其二是接入面：通过浏览器或桌面应用连接外部服务，例如 Cua Spaces 以本地虚拟机（Lume）构建 Space，并提供远程桌面协议让人类与智能体共享同一桌面、各自持有光标。其三是控制面：权限网关、会话录制、状态快照与人工接管开关。三者结合，使工作区既是智能体的「工位」，也是可治理的执行边界。
与相邻架构的关系
工作区架构常与两种相邻概念一起出现，但侧重不同。托管智能体运行时（Managed Agent Runtime）关注任务调度、凭据管理与生命周期，是工作区的「后台」；工作区则是运行时向前端暴露的「操作面」。计算机操作（Computer Use）是工作区内部的核心能力之一，负责把视觉理解转化为界面动作。常驻型智能体则依赖工作区承载跨天的持续任务与记忆，使「交代一个目标」成为产品原语。理解这三者的分工，有助于在系统设计时正确分层。
安全与隐私边界
工作区的最大价值之一在于把风险关进隔离盒。智能体的联网、文件读写与凭据使用都被限制在工作区内部，除非用户显式授权，否则不会触碰本机数据；即便智能体出错或越权，影响范围也被限制在沙箱内。实践中仍需关注：工作区凭据的存放与轮换、跨工作区的数据泄漏、以及长时间会话带来的上下文膨胀成本。将工作区与零信任权限网关、出网白名单结合，是当前主流的加固做法。
实践要点
落地工作区架构时，建议显式声明每个工作区的出网白名单与可用工具，拒绝依赖默认值；为工作区配置独立的凭据保管而非复用个人账号；保留会话录制与状态快照，以便人工接管与事后审计；并通过远程桌面协议实现「人类与智能体同屏协作」，在关键决策点把控制权交还给人。Cua Spaces 等方案还提供会话迁移（Teleport）与端到端密封，可作为参考实现。
局限与争议
工作区并非没有代价。云端计算机带来持续的算力与计费开销，长会话的上下文累积也会推高成本；图形界面操作相比直接 API 调用通常更慢、更脆弱，对动态布局与验证码场景仍不稳定。此外，「给每个智能体一台电脑」是否会放大拒绝钱包（Denial of Wallet）类风险，也是工程上需要前置设防的问题。工作区适合需要操作既有图形软件的长任务，而对结构化 API 可达的任务，直接工具调用往往更经济。
🎯 应用场景
✅ 最佳实践
- 显式声明工作区的出网白名单与可用工具，拒绝依赖默认开放配置。
- 为工作区配置独立凭据保管，避免复用个人账号带来的权限扩散。
- 保留会话录制与状态快照，支撑人工接管与事后审计。
- 对长会话设置步数与深度上限，防止上下文膨胀与成本失控。
🔮 未来展望
工作区架构正从「演示级能力」走向「生产级基础设施」。值得跟踪的节点包括：云厂商是否把工作区作为托管智能体运行时的标准交付形态、远程桌面协议在人机协作上的延迟与体验优化、以及工作区与本地设备的受控互通标准。随着计算机操作模型能力提升，工作区有望成为常驻型智能体的默认执行底座，但成本可控性与安全边界仍是决定其普及速度的关键变量。