Managed Agents 演化路径：从单用户 Agent 到多用户 Agent 云服务

① 阅读框架：三个维度

“从单用户 Agent 到多用户 Agent 云服务”同时沿三个相互独立的维度展开，另以技术栈分层描述其纵向结构。本调研的总图、矩阵与结论均按以下框架组织。

说明：大模型的工具调用能力（Function Calling，2023 年起成为各家模型 API 的基础能力）是整条路线的前提，不单列为阶段；模型推理服务本身不在本调研范围内。

② 统一演化路线总图

横轴是时间（2023–2024 压缩显示，2025 起展开）。泳道按第 ① 节的三个维度分组：开放平台线各行的圆点是各厂商首次进入该阶段的时间；产品形态线列出全部产品节点；开放平台线各行标签下注明该阶段厂商托管的技术栈层次（见第 ③ 节）；虚线连接“先自用，后外供”的产品与服务；圆里写的是厂商简称。点击任意标记可以查看依据和出处。

提示：按住 Shift 滚动鼠标滚轮可左右移动；触控板可直接左右滑动。

③ 开放平台线：职责逐级上云

开放平台线描述厂商把 Agent 的哪些职责接管到云端，并以何种形式开放给开发者。L1 至 L5 按首次出现的时间排列；其中 L1 → L2 是职责上云范围的回落：早期黑盒托管因难以定制而让位于开源 harness，此后各家以“解耦托管”的方式重新上云（见第 ⑨ 节“螺旋式演进”）。

技术栈分层：从 Harness 到 Service

开放平台线回答“厂商托管了多少”，技术栈分层回答“托管的是哪几层”。各层的开源与商业产品见第 ⑩ 节。

“Runtime”一词的三种用法：同名、不同层

三种用法指三样不同的东西，而非同一事物的三个特征：它们可以同时出现在同一套系统中，各占一层。例如，腾讯 Octop Harness（③）基于 deepagents 构建，deepagents 运行于 LangGraph（②）之上，整体又可部署到 AgentCore Runtime（①）。三者同名，是因为都承担一部分“运行期”职责，即让 Agent 持续运行并管理运行中的状态，但管理的范围不同。

① 与 ② 都能“恢复”，但粒度不同：② 恢复到执行流中的某一步（检查点），① 恢复整个会话（事件日志与快照）。③ 中的“多个 Agent”指多个不同配置的 Agent（如不同的助手），而非多个用户同时运行；托管 Runtime 中的Harness 实例则是无状态进程，以会话租约同时承载多个用户的会话，会话状态在外部事件日志中，因此可水平扩展。选型或交流时，需先确认对方所说的 Runtime 指哪一种。

从单体 Harness 到托管服务：六步改造与两类协议

Managed Agents 的第一代把会话、harness 与沙箱放在同一个容器中，即单体形态：容器成了不可替换的“宠物”，故障即丢失会话。把一个单体 Harness 改造为 Managed Agents 式的托管服务，可拆为以下六步，每一步解决上一步遗留的问题。

与上方技术栈分层的对应（见“对应分层”一列）：①② 在 Harness 层内完成；③ 构成托管 Runtime 的核心；④ 对应沙箱 / 执行环境；⑤ 对应 Orchestrator；⑥ 对应托管服务（Service）。由此也可看出托管 Runtime的构成：② 的服务化接口 ＋ ③ 的无状态实例与外置会话状态，再加上每会话隔离、伸缩、身份与计量，并经 ④ 的 Executor Protocol 连接沙箱。远程接入不属于上云主线，作为旁路单列一行。

Harness Protocol 是控制面的北向接口（外部调用控制面），Executor Protocol 是控制面与执行面之间的南向接口；按六边形架构，前者为驱动端端口，后者为被驱动端端口。两者均为本页自定义的名称，官方对应见上表。

控制面与执行面：各领域的通用做法：这对术语源自网络设备：控制面计算路由，数据面转发报文；此后软件定义网络（SDN）、Kubernetes 与服务网格均沿用。本页称“执行面”，因为这一面执行工具调用。各领域都在两面之间定义协议，且通常由执行侧主动连接控制面，执行侧因此无需开放入站端口。

Claude Managed Agents 的三个视角

同一个系统可从三个角度描述：本页的技术栈分层；Anthropic 工程博客的内部组件（Managed Agents 内部架构，配图中共五个组件）；官方文档面向开发者的对外资源（四要素）。下表按分层逐行对应，第二列先说明这一层本身由什么组成。

由此可见：四要素中没有 Harness 与 Orchestration，因为二者不对外暴露；五组件中没有 Agent 与 Environment，因为二者是配置与模板，而非运行中的部件。OpenAI 未公开内部组件，其对外资源同样可按四要素对照；两家的对应见上方六步改造表。

各阶段托管的层

下表按技术栈分层列出 L1–L5 中各层由谁承担。

接口演化：从补全 API 到托管 Agent API

从 API 的角度看，开放平台线表现为接口的代际更替：每一代都把一项职责从调用方移到服务端。L1、L3、L5 各对应一代接口；L2 与 L4 以开源 SDK 和托管运行时的形式交付，不形成新的接口代际。

Managed Agents 产品全景（厂商托管与开源自托管）

汇总 L5 Managed Agents 服务。2026 年 7 家厂商推出与四要素模型同构的服务，另有 1 家提供面向合作伙伴的运行底座；开源侧有多个可自托管的同类平台。表中节点可点击查看依据。

读表要点：① 厂商服务的资源模型高度一致，差异主要在执行环境能否自托管：Anthropic、OpenAI 支持自托管执行环境，腾讯 WMA 支持专有云与私有云部署，其余未见说明。② 厂商服务均托管自家 harness，并以自家模型为主；需要接入第三方模型或满足数据境内驻留时，宜自建同构服务。③ 开源侧没有完整等同于厂商服务的项目：Omnara 最接近，kagent 最契合 Kubernetes；多数项目的服务层成熟、执行面与多租户需自行补齐。

案例：DeerFlow 2.x 深度评估（开源实现）

DeerFlow 是字节跳动开源的超级 Agent Harness（MIT，约 8.4 万星）。2.0 版（2026-06）从深度研究框架重写为通用的 Agent 运行环境，并在 2.x 中补齐了多用户认证、Kubernetes 部署与按需沙箱；网关多副本所需的运行控制改造已合入主干，待正式版发布（2.1.0 的 chart 说明仍要求网关保持 1 个副本）。它在架构上已具备 Managed Agents 的主要特征，是开源侧接近“WorkBuddy 类云端多用户服务”的实现之一。以下依据官方 README、认证设计文档、Helm chart 与沙箱 provisioner 文档整理（截至 2026-10-14），未经实测。

① 与 Managed Agents 架构的对标

② 多用户与权限

• 认证：邮箱密码登录与通用 OIDC 单点登录（Keycloak、Google、Azure AD、Okta 等，支持自动开通账号与邮箱域名限制）；脚本与系统集成使用个人访问令牌（PAT），令牌只能收窄所属用户的权限，不具备管理员能力。
• 隔离：认证设计文档写明“默认强制认证”“服务端持有所有权：客户端 metadata 不能声明 user_id”“隔离默认开启”。会话线程、文件（users/{user_id}/threads/{thread_id}/）、长期记忆与自定义 Agent 均按用户隔离。
• 不足：角色只有 admin 与 user；可插拔 RBAC 默认关闭；无组织或租户层级；未见按用户的配额与计量；官方提示 Gateway 管理员权限等同于在主机上执行代码。

③ Kubernetes 部署与多实例

多实例的前提条件（主干版本，待正式版发布；缺一项时启动检查会拒绝）：PostgreSQL；Redis 推流桥（stream_bridge.type: redis）；运行归属心跳（run_ownership.heartbeat_enabled: true）；运行事件写入数据库（run_events.backend: db）；声明 deployment.multi_instance: true；各副本共享同一个凭证加密密钥 DEER_FLOW_CREDENTIALS_KEY。登录限速计数存于共享数据库表，IM 渠道由租约选定一个副本持有，避免消息重复处理。

资源参考（需实测校准）：官方建议长期运行的单机部署从 8 vCPU、16 GB 起，推荐 16 vCPU、32 GB。多副本部署时，控制面（gateway、frontend、nginx、provisioner）规模较小；资源主要消耗在执行面：活跃沙箱按每个约 1 vCPU、2 GB 估算（AIO 内含浏览器与开发工具，实际占用待实测），采用 Kata 时每个 Pod 另有约 0.1 核、100 MiB 的额外开销。

④ 与 WorkBuddy 的功能对照

结论：WorkBuddy 的“桌面端”体验，Octop 更接近；WorkBuddy Managed Agents 那样的“云端多用户托管服务”，DeerFlow 更接近。

⑤ 风险与需要改造的部分

1. 默认按本地可信环境设计：官方安全声明要求在公网或局域网部署时另加认证网关、IP 白名单与网络隔离。
2. 沙箱隔离强度：AIO Sandbox 是普通容器，官方示例关闭了 seccomp；provisioner 未提供 RuntimeClass 配置；Kubernetes 1.36 起可用内置准入策略（MutatingAdmissionPolicy）按沙箱标签注入 RuntimeClass、节点选择与容忍，接入 gVisor 或 Kata 均无需修改代码。
3. 宿主机目录挂载：provisioner 默认以 hostPath 挂载技能与用户数据，须改用 PVC（SKILLS_PVC_NAME、USERDATA_PVC_NAME）；多个沙箱 Pod 共享用户数据卷需要 ReadWriteMany 存储，需确认所用云盘或文件存储是否支持。
4. provisioner 尚未完成的能力：按超时自动清理沙箱、NetworkPolicy 模板、按沙箱设置资源均在路线图中未完成，需自行补齐。
5. 治理能力：无组织层级与按用户配额；RBAC 默认关闭；通用工具审批未见说明。
6. 版本节奏：2.0 于 2026-06 发布、2.1 于 2026-09 发布，迭代频繁；默认沙箱镜像使用 latest 标签，须同步到自有镜像仓库并锁定版本。

各阶段定义

④ 产品形态线：从对话到常驻

产品形态线描述最终用户使用的 Agent 形态。各形态的根本区别在于长期存在的主体：对话型是一段对话；任务型是一个任务及其执行环境，交付后结束；常驻型是 Agent 实例本身，任务由其派生。

常驻型判定：须同时满足三项：① 实例与工作环境跨任务持续存在并保有记忆；② 拥有独立身份，而非仅以用户的委托令牌行事；③ 能主动发起（定时、事件或目标驱动），并经对外渠道触达用户。仅增加定时触发的任务属于“定时 / 事件任务”，不构成常驻型。

常驻型的三波演进

三波并非替代关系：自托管与云托管的开源形态在第三波出现后仍持续发展。

各形态定义

隔离粒度：每 Agent、每用户、每会话

常驻 Agent 在 A 形态的基础上分化出两种粒度：一台计算机服务一个 Agent，或服务同一用户的全部 Agent。二者的区别决定了同一用户名下的多个 Agent 之间是否存在安全边界。

Agent 专属计算机产品一览（云电脑、远程桌面与云手机）

只收录“用户或 Agent 可使用一台远程计算机（或手机）”的产品。此前已收录于总图的同类产品：每 Agent 一台 dotsManus Cue；每用户一台 Grok BotMeta MuseGemini Spark；每任务一台 ChatGPT agentOK ComputerAutoGLM 2.0；每用户一台云主机 LighthouseKimi ClawArkClawJVS Claw；开发者执行底座 无影 AgentBay。下表为本次补充。

读表要点：① 中国云厂商与运营商在 2026 年普遍以“云电脑 ＋ 预装 Agent”的方式面向用户，多为每用户一台；阿里与腾讯另有面向开发者的执行底座（无影 AgentBay、AGSX），以及面向企业的桌面环境（无影 Agentic Computer）。② 开源侧，Octop、Bytebot 为每部署一个桌面；Cua、E2B Desktop、AIO Sandbox、Kortix 可按 Space、沙箱或会话分配，更接近多租户所需的隔离粒度。③ 选型参考：A 形态（每用户专属计算机）可参照云电脑与运营商方案；需要多租户时，宜采用按会话或按 Agent 分配的沙箱。

⑤ 部署形态与多租户改造

单用户 Agent（如 Claude Code、Codex CLI、OpenClaw）的默认设计前提是：单进程、单机、单用户，且权限与用户本人等同。向多用户云服务演进的过程中，各厂商均完成了以下五项关键改造。

三种部署形态（2026 年同时存在）

产品形态 × 部署形态

依据各节点公开资料中的运行位置说明自动归类；资料未说明运行位置的列入“未公开”。点击条目查看依据。

C 形态下“本机执行 ＋ 远程接入”的各厂商方案见下文与总图“C 远程接入”行。

C 形态的定义

C 形态的技术机制：内网穿透的产品化

用户电脑通常位于 NAT 或防火墙之后，没有公网地址。各家方案的共同做法是由本机主动向厂商中继建立出站连接，手机端指令经中继转发至本机执行，从而无需开放端口或配置 VPN。

开源远程接入项目的演进

开源项目先于厂商补位；官方 Remote Control 陆续推出后，单纯的远程接入被覆盖，开源项目转向更上层的能力。

启示：Omnara 官方公告说明，其早期版本以包装 Claude Code CLI 的方式实现，因 Claude Code 频繁更新而难以维护，随后改用 Claude Agent SDK 重做。远程接入宜建立在自有协议之上，而不是解析第三方 CLI 的终端输出。

安全隔离阶梯（S1→S6）

隔离单位逐步从“开发者自己负责”收紧到“每个会话一台 microVM，凭证放在沙箱外，Agent 有自己的身份”。

弹性扩缩阶梯（E1→E6）

扩缩的单位从“请求”变成“会话 / 沙箱”，计费也从只按 token 扩展到按会话时长和 vCPU 秒。

⑥ 9 家时间轴（按厂商分泳道）

每个标记代表一个已核实的节点：颜色和编号表示所属阶段（代码见第 ① 节），方块是 F2 任务型产品，菱形是协议或标准。虚线空心表示日期是估计值。悬停可以预览，点击打开详情和出处。下方的筛选仅作用于本时间轴。

提示：按住 Shift 滚动鼠标滚轮可左右移动；触控板可直接左右滑动。

⑦ 阶段 × 厂商矩阵：各厂商在各阶段的实践

这一节是总图的表格版，每格列出该厂商在该阶段的全部节点，点击条目可看详情。灰色斜体表示该厂商未涉及该阶段或依赖生态伙伴，空缺本身也反映了路线差异。

提示：按住 Shift 滚动鼠标滚轮可左右移动；触控板可直接左右滑动。

⑧ 先后顺序验证：共同规律与例外

按每家进入各阶段的最早日期排序，开放平台线与产品形态线分行展示。开放平台线的共同规律是：L1（2023–24）→ L2 / L3（2025 上半年）→ L4（2025）→ L5（2026）；产品形态线为：F2 任务型（2025-01 起）→ F3 常驻型（自托管 2025-11 起，云托管 2026-01 起，厂商自研 2026-05 起）。两条线相互独立，常驻型的出现不以 L5 为前提。

⑨ 共同特征与关键洞察

⑩ 技术栈分层生态全景（开源与商业）

行按第 ③ 节的技术栈分层排列（核心分层自下而上，其后为横切能力与其他能力），列为 9 家调研对象以及行业与开源社区。每个条目标注类型：开源 指采用 OSI 认可许可证并注明许可证；“源码可得”指可查看源码但有商用限制（SSPL、BSL、ELv2）；“商业”指闭源产品或托管服务；“许可证未核实”指未查到明确许可证。点击条目可查看事件依据或官方原文；“—”表示本次调研范围内未见公开资料，不代表不存在。

说明：许可证依据各项目 GitHub 仓库于 2026-10-06 的声明；Daytona 自 2026-06 起核心开发转入私有代码库，故标为商业。

提示：按住 Shift 滚动鼠标滚轮可左右移动；触控板可直接左右滑动。

⑪ 对独立 Agent 平台厂商的启示

独立 Agent 平台厂商，指独立于大模型厂商、不自建大模型，通过集成第三方模型提供 Agent Harness 及其多用户云服务的企业。下图参考架构提炼自 9 家厂商 2026 年的共性设计：控制面承载 harness 与会话状态，执行面承载可随时回收的沙箱，模型经统一网关接入、可按需替换。

提示：以上是对调研结论的归纳，不是对某个具体产品的推荐；选型前要按企业自身的模型清单、合规要求（数据驻留、ZDR）和规模开展 PoC。注意：Claude Managed Agents、OpenAI Agents API 目前都不支持 ZDR，OpenAI Agents API 的数据驻留目前只有美国。

⑫ 资料来源与可信度

官方厂商官网、文档、changelog、官方账号　媒体主流科技媒体报道　第三方社区、博客、百科、会后笔记（可信度较低，相关节点已在正文注明）

附 术语、缩写与编号

汇总本页使用的编号约定、缩写及核心术语。可输入关键词筛选；带“ⓘ 详解”的条目可点击查看详细解释。