全部產品
Search
文件中心

Agent Run:資源群組和工作空間最佳實務

更新時間:Aug 22, 2026

本文以多團隊企業情境為例,介紹如何通過資源群組和工作空間的合理規劃,在 AgentRun 中實現團隊間資源隔離與精細化存取控制。

適用情境:單主帳號下存在多個業務團隊,每個團隊有多重專案,需要在測試與生產環境之間、不同團隊之間實現資源隔離,且一線開發人員只能訪問本專案的資源。

架構圖:

yuque_diagram

實踐背景

某公司有兩個業務團隊—團隊 A 和團隊 B,各自負責獨立業務系統。每個業務系統下有若干專案(如資料分析、機器學習),並部署了測試和生產雙環境。隨著 AgentRun 資源增多,公司面臨以下兩類訴求:

資源隔離與歸屬清晰:不同團隊、不同環境的資源完全隔離,能快速檢索某資源的歸屬業務系統。

精細化存取控制:一線開發人員只能訪問本專案資源;業務系統管理員可統一管理本團隊資源,但不能越界訪問其他團隊。

方案設計

設計思路

針對上述訴求,推薦採用“業務團隊 × 環境”維度劃分資源群組、“專案”維度劃分工作空間的兩層架構:

層級

劃分維度

授權對象

資源群組

業務團隊 × 環境(n 團隊 × m 環境 = n×m 個資源群組)

業務系統管理員,管轄本團隊資源群組

工作空間

專案(掛載在對應資源群組下)

一線開發人員,訪問本專案工作空間

帳號和角色規劃

本方案使用 1 個阿里雲帳號(主帳號),通過 RAM 使用者承載多團隊許可權分離:

角色

RAM 使用者

許可權範圍

主帳號管理員

阿里雲帳號(主帳號)

所有資源的完全控制權

團隊 A 管理員

Alice

團隊 A 所有資源群組和工作空間

團隊 B 管理員

Bob

團隊 B 所有資源群組和工作空間

團隊 A 資料分析專案開發

user01

資料分析-測試工作空間內的資源

團隊 A 機器學習專案開發

user02

機器學習-測試工作空間內的資源

資源群組和工作空間規劃

本樣本建立4個資源群組和6個工作空間(團隊 B 的工作空間數量根據實際專案自行擴充):

資源群組

綁定的工作空間

管理員

團隊A-測試環境

資料分析-測試工作空間、機器學習-測試工作空間

Alice

團隊A-生產環境

資料分析-生產工作空間、機器學習-生產工作空間

Alice

團隊B-測試環境

團隊B專案-測試工作空間

Bob

團隊B-生產環境

團隊B專案-生產工作空間

Bob

操作步驟

步驟一:建立RAM使用者

在 RAM 控制台為各業務系統管理員和一線開發人員建立對應的 RAM 使用者。

本樣本建立以下 RAM 使用者:

RAM 使用者

角色定位

Alice

業務系統 A 管理員

Bob

業務系統 B 管理員

user01

團隊 A 資料分析專案開發

user02

團隊 A 機器學習專案開發

操作入口:登入RAM控制台,在身份管理中點擊使用者>建立新使用者,詳細建立步驟,請參見:建立RAM使用者。

說明

命名建議:按照"姓名縮寫"或"角色+編號"規則命名(如 alice、bob、dev-team-a-001),便於授權時快速識別身份。

步驟二:建立資源群組

在資源管理(Resource Manager)控制台建立與業務團隊和環境對應的資源群組。

本樣本建立以下 4 個資源群組:

  • 團隊A-測試環境

  • 團隊A-生產環境

  • 團隊B-測試環境

  • 團隊B-生產環境

操作入口:登入資源管理主控台>資源群組>建立資源群組,詳細建立步驟,請參見:什麼是資源管理。

說明

命名建議:資源群組名稱建議體現團隊和環境資訊,如"teamA-test"、"teamA-prod",方便在控制台列表中快速識別歸屬。

步驟三:為RAM使用者授權資源群組許可權

使用阿里雲帳號(主帳號)為各業務系統管理員分別授權,確保其只能管理本團隊的資源群組。

授權範圍樣本:

RAM 使用者

授權的資源群組

授與權限策略

Alice

團隊A-測試環境、團隊A-生產環境

AdministratorAccess

Bob

團隊B-測試環境、團隊B-生產環境

AdministratorAccess

兩種授權方式可選:

  • 在資源群組控制台授權:進入資源群組詳情頁,選擇對應 RAM 使用者並授予權限原則

  • 在 RAM 控制台授權:進入 RAM 使用者詳情頁,指定資源群組範圍和權限原則

說明

最小許可權原則:如果團隊管理員只需要管理 AgentRun 相關資源,建議授予 AgentRun 相關精微調權限策略,而非 AdministratorAccess。本樣本使用 AdministratorAccess 以簡化示範,實際生產環境請按需調整。

以下為僅授權 AgentRun 操作、限定在指定資源群組內的自訂權限原則樣本:

{
  "Version": "1",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "agentrun:*",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "acs:ResourceGroupId": [
            "rg-xxxx1",
            "rg-xxxx2"
          ]
        }
      }
    }
  ]
}
說明

將 rg-xxxx1、rg-xxxx2 替換為實際資源群組 ID(可在資源管理主控台的資源群組列表中查看)。agentrun:* 表示授予全部 AgentRun 操作許可權;如需進一步收窄,可替換為具體 Action,例如 agentrun:GetWorkspace、agentrun:ListWorkspace 等。

步驟四:在AgentRun中建立工作空間並綁定資源群組

由業務系統管理員(如 Alice)登入 AgentRun 控制台,建立本團隊各專案對應的工作空間,並將每個工作空間綁定到對應的資源群組。

Alice 需要建立以下 4 個工作空間:

工作空間名稱

綁定的資源群組

資料分析-測試工作空間

團隊A-測試環境

機器學習-測試工作空間

團隊A-測試環境

資料分析-生產工作空間

團隊A-生產環境

機器學習-生產工作空間

團隊A-生產環境

操作入口:登入AgentRun控制台,點擊控制台左上方的工作空間下拉式功能表,選擇建立工作空間,在建立表單中填寫名稱並選擇對應的資源群組。

說明

注意:工作空間與資源群組的綁定關係在建立時確定,建立後不支援變更。請在建立前規劃好對應關係。

步驟五:為一線開發人員授予工作空間許可權

一線開發人員只需訪問和操作本專案的工作空間,需要進行分層授權。以下以"為 user01 授予資料分析-測試工作空間許可權"為例,說明 4 個子步驟。

說明

前提:完成步驟三和步驟四後,由 Alice(團隊 A 管理員)執行以下授權操作。

授予資源群組維度工作空間查詢許可權

user01 需要能看到"團隊A-測試環境"資源群組下的工作空間列表,才能進入對應工作空間。

在 RAM 控制台為 user01 授予以下許可權,授權範圍限定在"團隊A-測試環境"資源群組:

  • 權限原則: 包含 AgentRun操作的權限原則

  • 授權範圍: 僅限"團隊A-測試環境"資源群組

{
  "Version": "1",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "agentrun:ListWorkspaces",
      "Resource": "*"
    }
  ]
}

完成此步驟後,user01 可在工作空間列表中看到該資源群組下的所有工作空間(資料分析-測試工作空間、機器學習-測試工作空間),但尚未獲得具體資源的操作許可權。

授予指定工作空間內的 AgentRun 資源操作許可權

在 AgentRun 控制台,將"資料分析-測試工作空間"的操作許可權授予 user01,包括該工作空間內的以下資源類型:

  • Agent 運行時

  • 沙箱(Sandbox)

  • 模型

  • 工具

  • 知識庫

  • 記憶

  • 憑證

  • 監控大盤

{
  "Version": "1",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "agentrun:GetAccessToken",
        "agentrun:GetAgentDiscoveryResult",
        "agentrun:GetAgentRuntime",
        "agentrun:GetAgentRuntimeEndpoint",
        "agentrun:GetApigLLMModel",
        "agentrun:GetBrowser",
        "agentrun:GetBrowserSession",
        "agentrun:GetCodeInterpreter",
        "agentrun:GetCodeInterpreterSession",
        "agentrun:GetCredential",
        "agentrun:GetKnowledgeBase",
        "agentrun:GetMemoryCollection",
        "agentrun:GetModelProxy",
        "agentrun:GetModelService",
        "agentrun:GetSandbox",
        "agentrun:GetTemplate",
        "agentrun:ActivateTemplateMCP",
        "agentrun:CreateAgentRuntime",
        "agentrun:CreateAgentRuntimeEndpoint",
        "agentrun:CreateApigLLMModel",
        "agentrun:CreateBrowser",
        "agentrun:CreateCodeInterpreter",
        "agentrun:CreateCredential",
        "agentrun:CreateKnowledgeBase",
        "agentrun:CreateMemoryCollection",
        "agentrun:CreateModelProxy",
        "agentrun:CreateModelService",
        "agentrun:CreateSandbox",
        "agentrun:CreateTemplate",
        "agentrun:CreateWorkspace",
        "agentrun:DeleteAgentRuntime",
        "agentrun:DeleteAgentRuntimeEndpoint",
        "agentrun:DeleteApigLLMModels",
        "agentrun:DeleteBrowser",
        "agentrun:DeleteCodeInterpreter",
        "agentrun:DeleteCredential",
        "agentrun:DeleteKnowledgeBase",
        "agentrun:DeleteMemoryCollection",
        "agentrun:DeleteModelProxy",
        "agentrun:DeleteModelService",
        "agentrun:DeleteSandbox",
        "agentrun:DeleteTemplate",
        "agentrun:DeregisterExternalService",
        "agentrun:PublishRuntimeVersion",
        "agentrun:RegisterExternalService",
        "agentrun:StartBrowserSession",
        "agentrun:StartCodeInterpreterSession",
        "agentrun:StopSandbox",
        "agentrun:UpdateAgentRuntime",
        "agentrun:UpdateAgentRuntimeEndpoint",
        "agentrun:UpdateApigLLMModel",
        "agentrun:UpdateCredential",
        "agentrun:UpdateKnowledgeBase",
        "agentrun:UpdateMemoryCollection",
        "agentrun:UpdateModelProxy",
        "agentrun:UpdateModelService",
        "agentrun:UpdateTemplate",
        "agentrun:ListAgentRuntimeEndpoints",
        "agentrun:ListAgentRuntimes",
        "agentrun:ListAgentResources",
        "agentrun:ListAgentRuntimeVersions",
        "agentrun:ListApigLLMModels",
        "agentrun:ListBrowsers",
        "agentrun:ListBrowserSessions",
        "agentrun:ListCodeInterpreters",
        "agentrun:ListCodeInterpreterSessions",
        "agentrun:ListCredentials",
        "agentrun:ListKnowledgeBases",
        "agentrun:ListMemoryCollections",
        "agentrun:ListModelProviders",
        "agentrun:ListModelProxies",
        "agentrun:ListModelServices",
        "agentrun:ListSandboxes",
        "agentrun:ListTemplates",
        "agentrun:ListTools",
        "agentrun:GetTool",
        "agentrun:CreateTool",
        "agentrun:DeleteTool",
        "agentrun:UpdateTool"
      ],
      "Resource": "acs:agentrun:*:<your-account-id>:workspaces/DataAnalysis-Test/*"
    }
  ]
}

操作入口:進入AgentRun控制台>資料分析-測試工作空間>成員管理>新增成員,選擇 user01 並分配對應角色(如開發人員角色)。

完成此步驟後,user01 可在資料分析-測試工作空間內建立、查看和管理上述資源,但無法操作機器學習-測試工作空間內的任何資源。

授權帳號維度全域資源許可權

部分 AgentRun 資源屬於帳號層級的全域資源,不歸屬於特定工作空間,需要在帳號維度單獨授權。

自訂網域名是典型的帳號級全域資源。如果 user01 需要配置或查看自訂網域名,在 RAM 控制台為其授予帳號層級的相關權限原則(授權範圍選擇"整個雲帳號")。

{
  "Version": "1",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "agentrun:*CustomDomain*"
      ],
      "Resource": "*"
    }
  ]
}
說明

並非所有使用者都需要此許可權。如果 user01 不需要管理自訂網域名,可跳過此子步驟。

按需授權其他依賴雲產品許可權

AgentRun 資源運行時可能依賴其他阿里雲產品(如Object Storage Service、Function Compute FC 等)。常見的依賴許可權樣本:

依賴情境

需授權的雲產品

建議的權限原則

知識庫資料存放區

Object Storage Service

OSS 指定 Bucket 的讀寫權限

Agent 運行時底層計算

Function Compute FC

FC 相關唯讀或調用許可權

日誌與監控查詢

Log Service SLS

SLS 指定 Logstore 的讀許可權

說明

最小許可權原則:按一線開發的實際業務需求授權,優先使用資源級權限原則,限定到具體的 Bucket、Logstore 等資源範圍。

步驟六:將 AgentRun 資源劃分到對應的工作空間

完成許可權配置後,確保各類 AgentRun 資源歸屬在正確的工作空間中。

建立資源:在建立 AgentRun 資源的表單中,直接選擇對應的工作空間,資源自動歸屬到該工作空間所在的資源群組。

存量資源遷移:如果已有 AgentRun 資源尚未劃分到工作空間,通過資源轉移功能遷移。

操作入口:進入AgentRun控制台對應資源的管理頁面,找到目標資源,選擇目標工作空間後確認。

說明

資源轉移操作可能影響正在運行中的任務,建議在業務低峰期操作,並提前通知相關開發人員。

實踐效果

完成上述配置後,各角色的許可權隔離效果如下:

身份

可見的資源群組

可操作的工作空間

資源操作範圍

阿里雲帳號(主帳號)

所有資源群組

所有工作空間

無限制

Alice

團隊A-測試環境、團隊A-生產環境

團隊 A 下全部工作空間

團隊 A 所有工作空間的所有資源

Bob

團隊B-測試環境、團隊B-生產環境

團隊 B 下全部工作空間

團隊 B 所有工作空間的所有資源

user01

團隊A-測試環境(列表可見)

資料分析-測試工作空間

該工作空間內的所有資源類型

user02

團隊A-測試環境(列表可見)

機器學習-測試工作空間

該工作空間內的所有資源類型

user01 和 user02 都能在工作空間列表中看到"團隊A-測試環境"下的所有工作空間,但各自只能操作被授權的那個工作空間內的資源。團隊 A 與團隊 B 之間、測試環境與生產環境之間完全隔離。

常見誤區

誤區

問題

建議做法

所有專案共用一個工作空間

無法實現專案級許可權隔離,開發人員可以互相看到對方的資源

每個專案對應一個獨立工作空間

在帳號維度直接授予 AdministratorAccess

開發人員獲得超出職責範圍的許可權,存在誤操作風險

在工作空間維度按角色精細化授權

測試和生產環境共用同一資源群組

開發人員可能誤操作生產資源

測試和生產環境分別建立獨立資源群組

先建立工作空間再規劃資源群組

工作空間與資源群組的綁定關聯建立後不可更改,規劃不當會導致後續無法調整

先完成資源群組規劃,再建立工作空間並綁定