说到作者，刘军

Managed Agents 让 Agent 运行在云端环境中

长周期任务不再依赖本地设备持续在线——即使个人电脑关机。任务依然可以在云端持续运行。话说回来，

基于 AgentScope 的 Harness 内核与 Sandbox 隔离能力。AgentScope 可以作为 Managed Agents 的底层运行时 Runtime，为其提供稳定可靠的执行环境。

• 把 AgentScope 中已经工程化的 Harness Agent 直接作为 Brain 运行时托管内核提供稳定的推理与 Harness 能力，文件程序、workspace、工具执行则完全隔离在 Sandbox 沙箱环境。
• 网站层负责租户、权限、版本、事件和执行面选型。按理说，控制面和数据面把这些能力组织成可多租、可审计、可运维的托管产品。

Managed Agents 背景

使用者痛点：市面上已有百炼、Claude Code、LangChain 等 Managed Agents 产品。但业务开发者仍需手动拼装大量 Harness 配置项，导致调试成本高且易出错。

Managed Agents 解决主要问题了两大痛点：

. 不再让业务开发者拼装 Harness

传统网站把记忆维护、上下文压缩、状态恢复、工具权限和子任务回收拆成大量配置项。Managed Agents 把这些通用工程能力收进统一 Harness，开发者只需定义业务相关的 Skills、Tools、Subagents 和权限策略。网站保证机制的一致性与可升级性，但最终任务效果仍取决于模型、system prompt、Skill 质量、工具返回值和业务评测。不过，

. 让客户掌握工具执行和数据回传边界

对公司使用者而言。Agent 真正产生价值的地方是与公司数据资产连接，而 shell、文件读写、MCP 和业务工具正是数据流动的入口。程序刻意拆分 Brain 与 Hands

• Brain 负责下一轮推理、状态恢复和上下文管理；
• Hands 负责真正接触文件、网络与业务程序。可运行在网站托管的 Cloud Sandbox，也可以运行在客户 VPC 内的 Self‑hosted Worker。按理说，

使用者痛点：传统低代码网站把 Harness 的工程责任转嫁给业务开发者。同一个 Agent 因配置者经验不同而表现差异巨大。Managed Agents 将压缩时机、会话恢复等工程细节统一交给持续演进的 Harness。实现一次升级全体 Agent 获得一样改进，无需逐个修改流程图。

信任边界问题：模型决定“要调用什么”，不等于模型所在进程必须“亲自执行什么”。只要工具调用被表示为稳定的 schema、tool_use_id 和结果事件。Hands 就可以迁移到云沙箱或客户 VPC，而不改变 Brain 中的推理循环。这让安全团队能够分别回答三个关键问题：

1. 模型能看到哪些上下文？怎么说呢，
2. 工具能访问哪些网络和文件？
3. 工具结果中哪些内容可以回传给 Brain？

拆分后权限审核和故障定位比“一整个 Agent 容器”清晰得多。

Claude Managed Agents 示例

User Pain Point：Coding 场景往往需要长时间保持会话状态，而本地机器掉线会导致会话丢失。Claude Managed Agents 通过可恢复的会话状态与工程化运行策略，将这种痛点解决掉。

为什么 AgentScope 适合做 Managed Agents 底座

User Pain Point：持久化与多副本部署困难

AgentScope 的模型抽象、工具与 MCP 、消息与事件 、状态存储 、远程文件程序 / 分布式 BaseStore 、还有可插拔沙箱。都为进程外持久化和多副本部署预留了 点，使得 Managed Agents 无需从零实现会话恢复、工具结果落盘与跨请求上下文延续。怎么说呢，

主要能力概览

• 工作区驱动的人格与知识：AGENTS.md / MEMORY.md / KNOWLEDGE.md
• 会话持久化：
• 压缩与溢出处理：
• S­kills / Subagents：
• 统一文件程序抽象：

User Pain Point：If a long task runs across multiple nodes。developers often lose consistency 娱乐ween in‑memory state and persisted files. 使用统一抽象后无论文件落在哪种后端，模型看到的工具语义保持一致，从而避免“记得做过但工作区不存在”的错误。

S​ession 与 HarnessAgent 的区别

S​ession 是有稳定 ID 、事件序列和持久状态的产品资源；HarnessAgent 是具备共享 AgentStateStore/Workspace 后端的数据面节点上的运行对象。按理说，区分二者才能实现真正水平 ：节点挂掉时可以丢弃 Java 对象。但对话与长期记忆必须从共享状态恢复；工作区是否连续取决于 BaseStore 或沙箱快照，而不是本地目录。

公司级 Managed Agents 网站详解

总体部署架构

主要组件图

1. C​ontrol Plane：

2. D​ata Plane：

主要数据流转

*使用者常见困惑*：客户端请求到底是进入 Brain 还是直接落到 Worker？按理说，下面给出清晰的数据流向说明。

客户端 →→ Managed Data Plane（B​rain ) → 从共享状态恢复 Agent → 执行推理 & 编排 → 若出现工具调用 → 按 Environment 配置将调用路由到 Worker → 工具结果回传 → B​rain 完成下一轮推理

整套程序可视为四层：控制面 → 数据面 → Worker → 基础设施。每层职责单一且易于独立演进。

创建一个 Agent 并运行

登录示例

定义示例 Agent

{
"name"这方面，"Workspace Copilot","description": "blog demo agent"。"system": "You are a workspace copilot. Prefer tools when listing or reading files. Keep answers concise.","tools":
}]
}

三种 Worker 模式对比

• . Local 模式 : 开发联调专用；Brain 与 Tools 同处托管集群宿主机命名空间，无独立 Hands 队列；老实说，适合可信内网调试。
• . Cloud Sandbox 模式 : Brain 保持在托管集群；文件 & shell 被迁移至独立沙箱；Brain 主动发起沙箱 API 调用，实现安全隔离并支持快照持久化。
• . Self‑hosted 模式 : Hands 完全跑在客户 VPC 内部；Brain 收到 tool_use 后挂起 turn。将任务写入 Work Queue，由客户侧 Worker 拉取并回传结果；按理说，适用于需要保留数据库/内部程序访问权的公司场景。不过，

Worker in Local 模式示例代码

Worker in Cloud Sandbox 模式关键配置

Worker in Self‑hosted 模式关键配置

更复杂的 Agent Team 编排示例

至于痛点概述。团队协作中的最小权限 & 审计需求

• A​gent 定义越复杂，越容易出现权限泄露或审计缺失的问题；通过拆分为多个角色型 Agent，可以实现最小权限原则并独立审计每个子任务日志。说起来，

定义三个角色 Agent

两种编排方式对比

• # Harness 原生委派： Team Lead 在推理过程中使用 sessions_spawn / wait_async_results` 动态拆解子任务。实现父子关系闭环，不过，适合需要实时交互或结果依赖链路场景。
• # 网站 fan‑out： /api/multiagent/run` 为每个成员创建独立 Session 并并行发送相同或不同输入；适合批量分析或投票类需求，不涉及跨 Session 状态共享。

工作原理 —— 控制面 vs 数据面 vs Worker

控制面

C​ontrol Plane 管理「定义什么可以运行，还有谁可以使用它」——包括 Agent 定义及其版本、副本 Model／Tool／Skill／MCP／Environment／Memory／Vault 等资源。所有资源遵循「定义 → 引用 → 挂载」三阶段关系，实现细粒度 ACL 与租户隔离。同时提供变更治理，确保生产环境能够安全灰度升级与快速回滚。

概念层次	职责
C​ontrol Plane	- 定义 & versioning - ACL & tenancy - 全局预置公共 Skill/Tool
E​nvironment	- 执行面模板 - 可被多个 Session 引用 - 支持 rotate & archive
S​ession	- 实际运行实例 - 包含 Event 流 + 状态机 - 生命周期受 Data Plane 管控

数据面

D​ata Plane 把记录了 Agent 版本信息的 Session 真正跑起来并完整记录过程。包括模型调用 → ReAct Loop → Hooks → Turn 租约 → 事件持久化 → SSE 推送，还有 interrupt/HITL 等异常处理。它通过无状态副本实现水平 每一次请求都会根据 sessionId + environmentKey 重建等价 RuntimeContext，从而保证不同实例之间语义一致性。关键是四层状态必须分别恢复：

• S​ession Events – 对话历史记录 ✔︎  
• A​​gentStateStore – & memory ✔︎  
• E​​FS/Sandbox – 文件/脚本实际产出 ✔︎  
• E​​xternal Services – 数据库/API 调用结果 ❓  

当 Harness 推理需要调用 Tool 时由 Environment 决定具体执行方式——全托管模式下 Brain 主动发起 E2B 调用；Self‑hosted 下则挂起 turn 并交给外部 Worker 完成后再继续推理。这种职责划分让故障定位更明确：全托管关注沙箱生命周期，全自托管关注 Worker 可达性及业务幂等性。

worker

p>Worker 专注于「如何把 Tools 真正落地」——两条方法对应不同责任主体：

li>Full‑managed : Brain 创建&回收 sandbox，网站统一设置超时&快照。li>Self‑hosted : Brain 把 tool_use 持久化为 work item，客户侧 Worker 拉取并自行管理 sandbox 生命周期。ul>

p>安全团队所以只需检查 schema 定义即可判断模型可能触发哪些外部操作，而实际执行细节由对应方负责审计。

p>Work 状态机示例：

pre>queued → starting → active → stopping → stopped

h2

p>AgentScope 面向公司级分布式场景，可同时支撑内部 DataAgent/SreAgent 开发还有公司级 Managed Agents 托管两种模式。一套 Harness 内核即可满足「自己拼积木」与「完全黑盒托管」之间的不确定性，让公司无需在灵活性和运维成本之间二选一。

strong>相关链接：

ul li>AgentScope Builder li>文档 li>

---