Resource management method, apparatus, medium, and device

Abstract

A resource management method, device, medium and equipment are disclosed, the method comprising: receiving a task request, the task request being initiated by an intelligent system, obtaining first information associated with the intelligent system, the first information indicating a hierarchical relationship between multiple levels; based on the first information and the current task context, generating second information of the task, the second information including at least the corresponding resource amount of each level; checking whether the corresponding resource amount of each level meets the resource requirement of the task in the priority order in the first information; in response to the check of all levels passing, determining the required resource amount of the task based on the historical information of the resource requirement; preoccupying the required resource amount and executing the task, thereby realizing unified management of the resources of the intelligent system in a multi-entry scene.

Description

Technical Field

[0001] This relates to the field of computer technology, specifically to a resource management method, apparatus, medium, and equipment. Background Technology

[0002] With the rapid development of artificial intelligence technology, intelligent systems are being widely applied in enterprise-level scenarios. In enterprise environments, different users may interact with intelligent systems through various entry points such as instant messaging applications, command-line interfaces, web portals, and cloud desktops. How to uniformly manage the resource usage of intelligent systems under multiple access points has become a pressing technical problem in this field. Summary of the Invention

[0003] A resource management method, device, medium, and equipment are provided, which realizes unified governance of intelligent system resources in multi-entry scenarios through a complete closed loop of second information generation, multi-level verification, resource pre-occupation and calculation.

[0004] On one hand, a resource management method is provided, the method comprising: receiving a task request initiated by an intelligent system; obtaining first information associated with the intelligent system, the first information indicating hierarchical relationships between multiple levels; generating second information of the task based on the first information and the current task context, the second information including at least the corresponding resource quantities of each level; sequentially verifying whether the corresponding resource quantities of each level meet the resource requirements of the task according to the priority order in the first information; in response to all levels passing the verification, determining the required resource quantity of the task based on historical information of the resource requirements; pre-allocating the required resource quantity and executing the task.

[0005] On the other hand, a resource management device is provided, the device comprising: An acquisition unit is used to receive a task request initiated by the intelligent system and to acquire first information associated with the intelligent system, wherein the first information indicates the hierarchical relationship between multiple levels. The generation unit is configured to generate second information of the task based on the first information and the current task context, wherein the second information includes at least the corresponding resource quantity of each level; The verification unit is used to verify, in order of priority in the first information, whether the corresponding resource quantity of each level meets the resource requirements of the task. A determining unit is used to determine the required resource quantity of the task based on the historical information of the resource requirement in response to all levels of verification passing. A processing unit is used to pre-allocate the required resources and execute the task.

[0006] On the other hand, a computer-readable storage medium is provided that stores a computer program adapted for loading by a processor to perform the resource management method as described in any of the preceding aspects.

[0007] On the other hand, a computer device is provided, the computer device including a processor and a memory, the memory storing a computer program, the processor executing the resource management method as described in any of the preceding aspects by invoking the computer program stored in the memory.

[0008] One resource management method provided in this scenario involves receiving a task request initiated by an intelligent system, obtaining first information associated with the intelligent system (indicating hierarchical relationships between multiple levels), generating second information about the task based on the first information and the current task context (including at least the corresponding resource quantities for each level), verifying whether the corresponding resource quantities for each level meet the task's resource requirements according to the priority order in the first information, determining the required resource quantity for the task based on historical resource requirement information after all level verifications pass, pre-allocating the required resource quantity, and executing the task. The above description, through chain-like verification and resource pre-allocation based on the hierarchical relationships indicated by the first information, achieves unified mapping and pre-emptive hard-top control of intelligent system resources in multi-entry scenarios. Attached Figure Description

[0009] To more clearly illustrate the text, the accompanying drawings will be briefly introduced below. It should be understood that the following drawings only show certain situations and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained from these drawings without creative effort.

[0010] Figure 1 This is a schematic diagram of the system architecture of a resource management system provided in one scenario.

[0011] Figure 2 This is a schematic diagram of the structure of a resource management model provided in one scenario.

[0012] Figure 3 This is a schematic diagram of the structure of a resource management system provided in one scenario.

[0013] Figure 4 This is a flowchart illustrating a resource management method provided in one scenario.

[0014] Figure 5 This is a schematic diagram illustrating an application scenario of a resource management method provided under certain conditions.

[0015] Figure 6This is a schematic diagram of a resource management device provided in one scenario.

[0016] Figure 7 This is a schematic diagram of the structure of a computer device provided in one scenario. Detailed Implementation

[0017] The following description, in conjunction with the accompanying drawings, clearly and completely describes the text provided in one specific scenario. Obviously, the description represents only a part of one scenario, not the entirety. All other scenarios that a person skilled in the art could obtain without inventive effort under this scenario fall within the scope of protection for the text's description.

[0018] It is understandable that before using publicly available text, all parties should inform users of the type, scope of use, and usage scenarios of the personal information involved in the text through appropriate means in accordance with relevant laws and regulations, and obtain the users' authorization.

[0019] For example, upon receiving a user's proactive request, a prompt message can be sent to the user to explicitly inform them that the requested operation will require the acquisition and use of the user's personal information. This allows the user to autonomously choose whether to provide personal information to the software or hardware, such as electronic devices, applications, servers, or storage media, that perform the operations described in the text, based on the prompt message.

[0020] As an optional but non-limiting implementation, in response to a user's active request, sending a prompt message to the user can be done via a pop-up window, where the prompt message can be presented in text format. Furthermore, the pop-up window can also include a selection control allowing the user to choose "agree" or "disagree" to provide personal information to the electronic device.

[0021] It is understood that the above notification and user authorization process is merely illustrative and does not limit the implementation method in one scenario. Other methods that comply with relevant laws and regulations may also be applied to the implementation method in one scenario.

[0022] It should be understood that the data involved in the text (including but not limited to the data itself, the acquisition or use of the data) shall comply with the requirements of relevant laws, regulations and related provisions.

[0023] It should be noted that, in one context, the terms "first," "second," etc., in the specification, claims, and accompanying drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such usage can be interchanged where appropriate so that, in one context, the description herein can be implemented in an order other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or server that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or devices.

[0024] In one context, the words “exemplary” or “for example” are used to indicate that something is an example, illustration, or illustration. Any example or solution described as “exemplary” or “for example” in one context should not be construed as being better or more advantageous than other examples or solutions. Specifically, the use of words such as “exemplary” or “for example” is intended to present the relevant concepts in a specific manner.

[0025] In one scenario, a resource management method, apparatus, medium, and device are provided. Specifically, in one scenario, the resource management method can be executed by a terminal device or a server. The computer device can be a terminal device or a server. The terminal device can be a smartphone, tablet, laptop, desktop computer, smart TV, smart speaker, wearable smart device, smart vehicle terminal, etc. The terminal device can also include a client, which can be a client of an application capable of resource management. For example, the client includes at least one of a program client, a web client, and a mini-program. The server can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms.

[0026] First, the following explanations are provided for some of the nouns or terms that appear in the description: Intelligent system: refers to an artificial intelligence program unit with autonomous decision-making and task execution capabilities, which can respond to task requests and call on tools, models and other resources to execute corresponding tasks.

[0027] Entry point: refers to the way or channel through which a user accesses the intelligent system. In one context, an entry point includes at least one of the following: instant messaging application entry point, command-line interface entry point, web portal entry point, and cloud desktop entry point.

[0028] First information refers to information used to characterize the hierarchical relationships between multiple levels of an intelligent system. This includes information such as the corresponding resource quantity and priority order at each level, used to characterize the distribution of resources and dependencies between levels. In one scenario, multiple levels include organizations, teams, role templates, user permissions, and intelligent system instances.

[0029] Current task context: refers to the set of background information related to the current task request, used to help determine the task's execution strategy and resource requirements. In one scenario, the current task context may include at least one of the following: the identity information of the task initiator, task type, task complexity, execution time, current session state, and historical interaction records.

[0030] Hierarchy: Refers to the hierarchical system of organizational structure, consisting of organizations, teams, role templates, user licenses, and intelligent system instances. For example, organizations are the highest level, and intelligent system instances are the lowest level.

[0031] Secondary information refers to data generated before task execution that includes the current policy context and corresponding resource quantity information. This secondary information is used to provide a consistent policy basis during task execution and ensure the traceability of historical audits.

[0032] Corresponding resource quantity: refers to the remaining resource quota at each level in the first information that has not yet been consumed before the task is executed. In one case, the corresponding resource quantity includes at least one of the token-corresponding resource quantity, memory-corresponding resource quantity, and CPU core-time-corresponding resource quantity at each level.

[0033] Priority order: This refers to the order in which the resources corresponding to each level are verified, as defined in the first piece of information. It is usually determined based on factors such as business importance and resource dependencies. In one scenario, the priority order can start from the user permission level, proceeding sequentially through the intelligent system instance level, role template level, team level, and finally the organization level.

[0034] Verification: In the resource allocation process, the process of verifying whether the corresponding resource quantity at each level meets the task resource requirements to ensure the rationality and feasibility of resource allocation.

[0035] Historical information refers to resource consumption records generated by an intelligent system during the execution of historical tasks. In one scenario, historical information may include at least one of the following: task type, model context size, and historical average consumption.

[0036] Resource requirements: This refers to the estimated amount of resources that an intelligent system will need to perform its current task. In one scenario, resource requirements can be determined based on historical information.

[0037] Pre-allocation: refers to locking the required resources in the resource record before the task is executed, so that the locked resources cannot be used by other tasks during the task execution.

[0038] Resource consumption data refers to information about the actual resources consumed by the intelligent system during task execution. In one scenario, resource consumption data may include at least one of the following: model input token quantity, model output token quantity, processing time, CPU core time, memory usage, and cloud disk read / write volume.

[0039] Calculation: After the task is completed, the actual resource consumption is compared with the pre-allocated required resources. The difference in resource usage is compared, and the pre-allocated records in the resource records are cancelled based on the comparison results.

[0040] Synchronous update: This refers to deducting the actual resource consumption from the pre-allocated required resources after the calculation is completed, and reflecting the updated corresponding resource amount in real time to each level of the first information.

[0041] A session refers to a continuous interaction between a user and an intelligent system. In one scenario, a session involves at least one task.

[0042] Identifier: Refers to the identity information used to uniquely distinguish a session or task. In one case, this identifier is either a session identifier or a task identifier.

[0043] Immutable state: This refers to the state in which the secondary information remains unchanged during task execution due to external configuration changes. Even if the administrator modifies the role template or policy configuration during task execution, the generated secondary information remains unchanged.

[0044] Lifetime: Refers to the effective duration from the generation of the second information to its automatic recycling. In one scenario, the second information is automatically recycled upon the expiration of its lifetime.

[0045] Resource records: refers to a unified data structure used to record the resource quantity, pre-occupancy records, and consumption status of each level in the first information.

[0046] Plug-in: Refers to an extended functional module that an intelligent system can call during task execution. In one scenario, a plug-in may include at least one of the following: capability module, sub-intelligent system, model context protocol server, built-in tool, and managed tool.

[0047] Policy matching: This refers to the process of matching and judging plugin call requests based on the plugin policy information in the second information. In one scenario, the result of policy matching includes any one of rejection, acceptance, and permission.

[0048] Pending Member Record: This refers to a temporary member record created by the system for a user when the user initiates an access request via a link but has not yet been assigned a team or role template. In one scenario, the member status corresponding to this pending member record is pending activation.

[0049] Visible scope: This refers to the range of data and functions that a user can view in the initial information. In one scenario, regular users correspond to the personal view, team administrators to the team view, and organization administrators to the organization view.

[0050] Please refer to Figure 1 , Figure 1 This is a schematic diagram of the system architecture of a resource management system provided in one scenario. The resource management system includes terminal 1 and server 2, etc.; terminal 1 and server 2 are connected via a network, such as a wired or wireless network.

[0051] Terminal 1 can be used to display a graphical user interface. In one scenario, Terminal 1 is a terminal device with an application installed that can manage resources. Terminal 1 can achieve this by downloading and installing the corresponding client and running it, calling and running the corresponding applet, or logging into a website to present the corresponding graphical user interface.

[0052] Server 2 is used to provide background services for the application in terminal 1. For example, server 2 can be the background server for the aforementioned application. Server 2 can be a single server, a server cluster consisting of multiple servers, or a cloud computing service center.

[0053] Please refer to Figure 2 , Figure 2 This is a schematic diagram of a resource management model provided under one scenario. The resource management model 10 includes an enterprise identity and access control module 11, an intelligent system management module 12, a tool management module 13, a sub-intelligent system management module 14, an intelligent system cloud disk management module 15, a memory management module 16, a skill management module 17, a cloud desktop template management module 18, a security and compliance module 19, a cost and usage module 101, and an observability and analysis module 102, etc.

[0054] The Enterprise Identity and Access Control Module 11 is used to implement unified identity authentication and access control management for enterprise users. In one scenario, the Enterprise Identity and Access Control Module 11 enables users to authenticate once and access multiple locations through Single Sign-On (SSO) login, and automatically synchronizes user information from the enterprise identity management system (such as the identity provider) to the resource management model through the user auto-configuration mechanism of the System for Cross-domain Identity Management (SCIM); the role-based access control system assigns corresponding operation permissions to different roles; user license management supports enterprises to add or remove concurrent users as needed; domain name capture and automatic routing automatically routes users to the corresponding organizational environment based on the domain name they access; and organization and team configuration is used to maintain the enterprise's organizational structure and team division.

[0055] The intelligent system management module 12 is used for unified management of intelligent system instances deployed within the enterprise. In one scenario, the intelligent system management module 12 is responsible for planning and configuring tool permissions, determining the scope of tools that different intelligent systems can call; managing the Model Context Protocol (MCP) server to ensure its connection status and availability; managing skills, including enabling, disabling, and versioning; supporting restarting and initialization of the intelligent system's operating environment; and using risk assessment functions to monitor the intelligent system's operating status in real time, promptly identifying and addressing potential risks.

[0056] The tool management module 13 is used to uniformly manage various tools that can be called by the intelligent system. In one scenario, the tool management module 13 provides built-in tools as pre-set basic tools for the intelligent system to call directly; at the same time, it supports the integration of enterprise-customized model context protocol tools, enabling enterprises to flexibly expand tool capabilities according to business needs and meet diverse business scenario requirements.

[0057] The sub-intelligent system management module 14 is used to manage the sub-intelligent systems derived from the main intelligent system. In one scenario, the sub-intelligent system management module 14 supports the creation and scheduling of super-powerful sub-intelligent systems to handle specific sub-tasks in complex tasks; provides an open toolset for sub-intelligent systems to call; and supports enterprises to customize the development of sub-intelligent systems according to their own business characteristics, thereby improving the system's adaptability and scalability.

[0058] The intelligent system cloud disk management module 15 provides cloud-based file storage and management services for the intelligent system. In one scenario, the intelligent system cloud disk management module 15 is responsible for document lifecycle management, including document creation, storage, retrieval, and deletion; through the document retrieval function, users can quickly locate the documents they need; it records user preferences to provide a personalized configuration experience; and it supports full-link tracing and playback, recording the call relationships and resource consumption of each node during task execution.

[0059] The memory management module 16 provides the intelligent system with memory storage and retrieval capabilities. In one scenario, the memory management module 16 focuses on managing user preferences, recent tasks, and historical sessions. By recording and analyzing user behavior data, the system can provide users with a more personalized service experience; simultaneously, it optimizes memory usage and improves system performance.

[0060] The skills management module 17 is used for unified management of skills. In one scenario, the skills management module 17 provides functions such as built-in skills, skill creation, and skill evaluation. Enterprises can create and evaluate new skills according to business needs to continuously improve the capabilities of the intelligent system and meet the increasingly complex business scenario requirements.

[0061] The cloud desktop template management module 18 is used for unified management of cloud desktop runtime environment templates. In one scenario, the cloud desktop template management module 18 is responsible for the creation, modification, and deletion of cloud desktop templates, which define specifications such as operating systems, pre-installed software, and resource configurations. Through functions such as runtime instance specification management, image version control, and template registration and configuration, enterprises can flexibly deploy cloud desktop environments to meet the personalized needs of different users.

[0062] The Security and Compliance module 19 is used to ensure data security and compliance during the operation of the intelligent system. In one scenario, this module is responsible for transmission encryption / static encryption, sensitive information protection, cloud sandbox isolation, zero data retention, behavior control, skill and tool security scanning, intelligent system identity and behavior permission management, and protection against prompt word attacks. It encrypts the transmission channel and stored data to prevent data theft or tampering during transmission and storage; identifies and protects sensitive information to prevent sensitive data leakage; provides an isolated code execution environment through a cloud sandbox to protect user data, ensuring data is not written to disk after task completion; controls user behavior; performs security scanning of skills and tools; manages the identity and behavior permissions of the intelligent system; and protects against prompt word attacks to prevent malicious prompt word injection. Through comprehensive security measures, the system can ensure the security and compliance of enterprise data and reduce potential risks.

[0063] The cost and usage module 101 is used to measure resource usage and manage costs. In one scenario, the cost and usage module 101 collects statistics on indicators such as user license activation rate, token consumption, memory usage, cloud disk usage, average message processing time, and cost distribution. Through detailed cost and usage analysis, enterprises can better understand resource usage, optimize resource allocation, and reduce operating costs.

[0064] The observability and analysis module 102 is used for comprehensive observation and data analysis of the intelligent system's operation. In one scenario, the observability and analysis module 102 provides functions such as audit logs, risk detection, event alarms, and end-to-end tracing and playback. By monitoring and analyzing the system's operational status in real time, enterprises can promptly identify and address potential problems, ensuring stable system operation and business continuity.

[0065] In one scenario, the enterprise identity and access control module 11 provides unified identity authentication and access control services to other modules; the cost and usage module 101 and the observability and analysis module 102 collect data from each module and perform aggregate analysis; and the security and compliance module 19 provides security protection and compliance assurance for each module. These modules cooperate to achieve layered resource governance and runtime control of the enterprise-level intelligent system.

[0066] Please continue to refer to this. Figure 2 In one case, based on Figure 2 The resource management model 10 presented proposes a unified resource governance model consisting of "organization—team—role template—user license—intelligent system instance—runtime environment—plugin asset—resource record". Under this resource governance model, the enterprise identity and access control module 11 maintains hierarchical information such as organization, team, role template, and user license, as well as their hierarchical relationships. When any user accesses the intelligent system through any entry point, the enterprise identity and access control module 11 identifies the user's organization, team, role template, and user license status; the intelligent system management module 12 provides the current status information of the intelligent system instance; the tool management module 13 and the sub-intelligent system management module 14 provide the availability information of plug-in assets; the cloud desktop template management module 18 provides the status information of the runtime environment; and the cost and usage module 101 provides multi-level resource quantity information. Based on this, the observability and analysis module 102 generates runtime secondary information, and the intelligent system management module 12 performs access control on the task. During task execution, the observability and analysis module 102 continuously measures, audits, and detects risks related to model calls, tool calls, file operations, and environmental resources. After the task is completed, the cost and usage module 101 will calculate the actual consumption in the resource record and synchronize it to the individual, team and organization views for subsequent governance feedback.

[0067] Please refer to Figure 3 , Figure 3 This is a schematic diagram of the structure of a resource management system provided in one scenario. The resource management system 20 includes a user layer 21, a product layer 22, a deployment layer 23, an infrastructure layer 24, and a data flow and collaboration layer 25.

[0068] The user layer 21 includes regular users, team administrators, and organization administrators. Regular users are developers who interact with the system through feature development and local coding; team administrators are responsible for team-level resource management and permission allocation; and organization administrators are responsible for organization-level governance strategy configuration and system control.

[0069] In one scenario, a user initiates an access request through a third-party collaboration platform, command-line tool, web portal, or link information in product layer 22. The system parses the user's email address, domain name, organization identifier, and identity provider information, and establishes organizational member relationships based on the domain name or invitation relationship. If the user is a member to be enabled, they are in an enabled state by default. After the administrator assigns team and role templates, the system generates the user's visibility scope and initial permissions in the current organization, and records the access behavior and binding results.

[0070] Product layer 22 includes third-party collaboration platform entry points, command-line tools, management platforms, and related services for intelligent systems. In one scenario, product layer 22 provides capabilities such as intelligent system development toolkits, multi-step tool invocation, intelligent system autonomous workflow orchestration, and custom tool integration. When an intelligent system initiates a task request, the system reads user, team, role template, intelligent system status, and entry information to generate secondary information, estimates task resource consumption, performs corresponding resource quantity checks at each level (organization-team-role-member-intelligent system), and performs environment and plugin availability checks. If the checks are successful, the required resources are reserved and the task is executed; otherwise, the task is rejected and logged. When an intelligent system plans to call a skill, sub-intelligent system, or model context protocol server, the system determines the plugin's activation status, risk level, and connection status, and matches it against the role template and organizational policy. If a rejection policy is hit, the call is directly intercepted; if a confirmation policy is hit, the call enters the approval process; if an allow policy is hit, the call is executed and the result is recorded.

[0071] Deployment layer 23 includes two deployment methods: cloud deployment and on-premises deployment. In the cloud deployment method, the intelligent system instance and management platform run in a containerized manner on the cloud server and provide services to the outside world through the cloud service model; in the on-premises deployment method, developers operate and debug the local file system in the local terminal through command line tools. The management platform acts as a bridge between cloud deployment and on-premises deployment, providing unified identity, unified policies, unified resources, and unified auditing.

[0072] The infrastructure layer 24 includes cloud desktops, cloud sandboxes, model services, memory management services, and audit and analysis services. In one scenario, the cloud desktop provides users with a virtual desktop runtime environment; the cloud sandbox provides a secure and isolated code execution environment, ensuring code execution security through container-level resource limits and network isolation; the model service interface is used to call large language model services, providing intelligent systems with message reasoning, tool invocation, and streaming response capabilities; the memory management service is responsible for persistent storage of session contexts and retrieval and synchronization of cross-session memories; and the audit and analysis service is used for end-to-end auditing of user behavior, task execution, and resource consumption. When a user selects a cloud desktop template and initiates creation, the system verifies the template and resources, generates an environment instance, and binds it to the intelligent system; after the environment is running, login and terminal access are allowed, and the running process records CPU core time, memory usage, tasks, and screen recordings; the stopping, restarting, and deletion of the environment all follow state machine and asynchronous control, and environment information is fed back to the audit and analysis service.

[0073] The Data Flow and Collaboration Layer 25 describes the data flow and collaboration relationships between various roles in the system. Developers build applications using software development kits and debug them locally using command-line tools; administrators use the management platform to monitor usage and costs, manage access permissions, and audit logs and conduct compliance reviews. The platform aggregates session, task, resource, risk, and configuration change events, aggregating metrics by individual, team, and organizational dimensions; managers view resource adoption, utilization, and risk status; the system triggers suggestions or automatic governance actions based on rules, and new strategies continue to take effect in subsequent tasks, forming a closed loop from development, debugging, deployment to governance.

[0074] In one scenario, the user layer 21 interacts with the system through various tools and interfaces provided by the product layer 22; the deployment layer 23 provides the system with both cloud-based and on-premises deployment environments; the infrastructure layer 24 provides underlying capabilities such as cloud desktops, sandbox isolation, model services, memory storage, and audit analysis; and the data flow and collaboration layer 25 connects developers, administrators, the product layer, and the infrastructure layer, forming an end-to-end collaboration link from identity access, task access control, plugin governance, environment operation to audit feedback. These layers cooperate to achieve unified governance and runtime control of the enterprise-level intelligent system.

[0075] Figure 2 The resource governance model 10 shown is... Figure 3 The resource management system 20 shown represents two views that describe the same text from different dimensions, and there is a close mapping relationship between them. Among them, Figure 2 This section describes the multiple functional modules included in the resource management model and their interrelationships from the perspective of functional modules. Figure 3This section explains the layered deployment structure and end-to-end collaboration relationships of the resource management system from the perspective of deployment architecture.

[0076] Specifically, Figure 2 The functional modules shown are deployed in Figure 3 In the corresponding layers shown, for example, the policy configuration parts of the Enterprise Identity and Access Control Module 11, Intelligent System Management Module 12, Tool Management Module 13, Sub-Intelligent System Management Module 14, Skill Management Module 17, Cost and Usage Module 101, Observability and Analysis Module 102, and Security and Compliance Module 19 can be deployed in the management platform of the product layer 22, serving as a unified entry point for enterprise administrators to configure governance policies and manage the system; the Intelligent System Cloud Disk Management Module 15 and Memory Management Module 16 are deployed in the cloud memory management service of the infrastructure layer 24, providing file storage and memory retrieval capabilities for the intelligent system; the Cloud Desktop Template Management Module 18 is deployed in the cloud desktop service of the infrastructure layer 24, providing a virtual desktop operating environment for the intelligent system; the data security protection capabilities in the Security and Compliance Module 19 are deployed in the infrastructure layer 24, achieving encryption, isolation, and zero data retention at the data storage and transmission level. Figure 2 The various modules of the resource governance model 10 in the middle are through Figure 3 The data flow and collaboration layer 25 in the middle realizes data flow and collaboration. Users initiate access requests through the user layer 21, which are then invoked by the management platform through the product layer 22. Figure 2 The governance capabilities of each functional module are ultimately executed by the infrastructure layer 24 to perform specific intelligent system tasks, thus forming a complete governance closed loop from identity access, task access, resource control to audit feedback.

[0077] The following sections provide detailed explanations. It should be noted that the order of description in some of these cases is not intended to limit the priority of certain situations in the text.

[0078] Please see Figures 4 to 5 , Figure 4 This is a flowchart illustrating a resource management method provided in one scenario. Figure 5 This is a schematic diagram illustrating an application scenario for a resource management method provided under certain conditions. The method includes the following steps: Step 110: Receive a task request initiated by the intelligent system, and obtain first information associated with the intelligent system, the first information indicating the hierarchical relationship between multiple levels.

[0079] In one scenario, the first information includes hierarchical relationships among organizations, teams, role templates, user licenses, and intelligent system instances.

[0080] In one situation, it can be done by, for example Figure 2The resource governance model 10 shown is used for unified resource management. This resource governance model 10 can be a multi-layered governance model of "organization—team—role template—user license—intelligent system instance—runtime environment—plugin asset—resource record". Under this resource governance model 10, when any user accesses the intelligent system through any entry point, their organization, team, role template, and user license status are first identified. Unified identity access and object modeling map enterprise users to governance objects such as organizations, teams, role templates, user licenses, and intelligent system instances.

[0081] In one scenario, the primary information serves as the data foundation for the system's resource governance. For example... Figure 3 The resource management system 20 (hereinafter referred to as the system) shown maintains the hierarchical relationships between different levels through the enterprise identity and access control module 11. When the intelligent system initiates a task request, the system parses the user identifier from the task request and uses that user identifier to access the system's resources. Figure 2 The system queries the corresponding first information in the enterprise identity and access control module 11. This first information is stored in a hierarchical tree structure, with the organization at the highest level, the team at the next level, role templates associated with teams, user licenses belonging to teams and bound to role templates, and intelligent system instances belonging to user licenses. The system uses this hierarchical tree structure to determine the affiliation relationships and resource quota inheritance relationships between each level.

[0082] In one scenario, the method further includes: receiving an access request and parsing at least one of a user identifier and an organization identifier in the access request; determining a first organization corresponding to the user based on the organization identifier, or determining a first organization corresponding to the user based on link information in the access request; in response to determining the first organization based on the link information, establishing a record of members to be enabled for the user; and in response to the user being assigned a team and role template, generating the visibility scope and initial permissions of the user in the first organization.

[0083] When an enterprise user accesses the system for the first time, the enterprise identity and permission control module 11 receives access or login requests from different entry points (such as third-party collaboration platforms, single sign-on, command-line interface (CLI) device codes, or web page entry points). It parses the requests to extract user identifiers (such as user email, user ID, etc.) and organization identifiers (such as organization domain names, etc.) for subsequent identity verification and organization mapping. For example, it parses user email, organization domain name, identity provider information, and link information, and performs the following processing: Based on the parsed organization identifier, it queries a preset organization database to find the corresponding organization information, thereby determining the user's primary organization (e.g., determining the user's primary organization based on the organization domain name); if the access request contains link information, it parses the information in the link information to determine the first organization the user is invited to join; it determines the user's membership based on organization configuration or invitation relationships; if the user enters through a link, it first creates a pending member record for the user, containing the user's basic information, organization information, and invitation status, for subsequent confirmation and activation of membership; and it determines membership based on organization role. User types (regular users, team administrators, or organization administrators); based on organizational roles, users are assigned differentiated visibility and initial permissions within the current organization. For example, regular users can only access the personal view, including information such as personal tasks, resource usage, and intelligent system instances. Initial permissions include creating and editing personal tasks, using resources according to the corresponding resource amount, and binding and using a personal intelligent system instance. Team administrators can access personal and team management views, covering information such as team member tasks, team resource usage, and intelligent system instance allocation. Initial permissions, in addition to regular user permissions, include managing team tasks, adjusting the resource amount for team members, and managing team intelligent system instances. Organization administrators have access to the most comprehensive organizational view, including team work summaries, organizational resource quotas and usage, and intelligent system instance management. Initial permissions include the highest level of permissions such as managing all tasks, allocating and adjusting team resource quotas, managing organizational intelligent system instances, and performing system settings. Login and organization switching events are recorded for subsequent auditing and behavioral analysis. To avoid inconsistencies in identity status across different entry points, the system uniformly maps all entry points to the same member object and the same intelligent system instance policy system.

[0084] Organization administrators can create multiple teams and configure team-level quotas for each team. Team administrators can further configure multiple role templates, each bound to a corresponding resource limit and available capabilities. A role template can include at least the following configuration items: monthly resource limit for tokens, memory resource limit, CPU core hourly resource limit, cloud disk resource limit, set of callable plugins, set of usable environment templates, and default entry permission policy. After a member is assigned to a team, the system binds the member to the role template, ensuring the inheritance and maintainability of corresponding resource limits and operation permissions. If a role template changes, the system can automatically apply the new configuration during subsequent task access.

[0085] In one scenario, the method further includes: receiving a request to use the intelligent system; obtaining the entry identifier of the first entry point, the user identifier of the user, and the organization identifier of the user; verifying the member status of the user, the status of the team to which the user belongs, and the validity of the role template bound to the user; verifying whether the first entry point is open to the role corresponding to the role template; if the verification passes, verifying whether an available intelligent system instance exists, and if not, creating or binding an intelligent system instance; generating an authorization token and issuing it to the first entry point; and in response to the first entry point completing the binding, updating the status of the intelligent system instance to authorized or activated.

[0086] Users can initiate access requests to the intelligent system through any of the following entry points: third-party collaboration platforms, command-line desktop tools, cloud desktops, or web pages. The system can set unified access rules for each entry point and execute the following steps when a user clicks on an entry point: In response to the intelligent system access request, obtain the entry point identifier, user identifier, organization identifier, and an optional intelligent system identifier; verify the validity of the user's member status, team status, and role template; verify whether the entry point is open to the current role; verify the existence of an available intelligent system instance, and if not, create or bind it; generate a one-time authorization token or binding token and issue it to the first entry point; after the first entry point completes the binding, it returns the result, and the system updates the intelligent system instance status to authorized or activated; if any condition is not met, access to the entry point is denied and a reason is returned. This prevents users from bypassing organizational governance policies through different entry points.

[0087] Step 120: Based on the first information and the current task context, generate the second information of the task, wherein the second information includes at least the corresponding resource quantity of each level.

[0088] In one scenario, the method further includes: storing the second information in association with an identifier of the session to which the task belongs, and embedding the identifier in the second information.

[0089] In one scenario, the second information is maintained in an immutable state during the execution of the task.

[0090] The second piece of information is associated with each task, ensuring that subsequent audits can accurately reconstruct the policy environment at the time of task execution. Even if the administrator modifies the configuration after task execution, it will not affect the consistency of historical traceability. For example, this second piece of information can be a policy snapshot. Alternatively, it can be stored in association with a session identifier (Session ID), used to identify a continuous interaction between a user and the intelligent system. When generating the second piece of information, the system embeds the session identifier into the data structure of the second piece of information, achieving a one-to-one mapping between snapshots and tasks. During task execution, the second piece of information remains immutable; that is, the data in the snapshot does not change during task execution, and new tasks generate new second pieces of information based on the updated policy. Even if the administrator modifies configurations such as role template versions, team quotas, or plugin policies during task execution, the generated second piece of information retains the old version configuration from when it was generated, ensuring that the currently executing task always runs based on the unified policy environment at the time the snapshot was generated, thereby guaranteeing the consistency and accuracy of audit traceability.

[0091] In one scenario, the method further includes: in response to the completion of the task and the existence of a subsequent task within the session to which the task belongs, executing the subsequent task based on the second information.

[0092] The scope of the second information is applicable to subsequent tasks within the same session. For example, if a task ends but the session between the user and the intelligent system has not yet ended, and there are subsequent tasks within the same session, the system will use the original second information as the policy basis for the subsequent tasks and execute the subsequent tasks according to the second information, thereby maintaining policy consistency during multiple task executions within the same session.

[0093] In one scenario, the method further includes: setting a time-to-live for the second information; and reclaiming the second information in response to the expiration of the time-to-live.

[0094] For example, you can set the Time To Live (TTL) to 1 hour. When this time is exceeded, the second information will be automatically reclaimed to avoid useless snapshots occupying storage resources.

[0095] In one scenario, the method further includes adding at least one of the following to the second information: organization status, team status, role template version, intelligent system instance status, entry policy, plugin policy, and environment policy.

[0096] Organizational status refers to the resource and policy configuration information at the organizational level, including but not limited to the total corresponding resources of the organization (such as the total corresponding resources of tokens, the total corresponding resources of memory, and the total corresponding resources of CPU cores), the access control rules at the organization level, and the global policies configured by the organization administrator.

[0097] Team status refers to resource and policy configuration information at the team level, including but not limited to team resource quotas (such as the amount of resources corresponding to the team's monthly tokens, the amount of resources corresponding to the team's memory, and the amount of resources corresponding to the team's CPU cores per hour), team activity status, and team-level access control rules. Organization administrators can create multiple teams and configure team-level quotas for each team.

[0098] The role template version refers to the version identifier information of the role template bound to a member, used to trace the configuration change history of that role template. The role template version is used to determine the corresponding amount of resources and operation permission scope possessed by the member. If the role template is changed, the system will automatically apply the new version configuration during subsequent task admissions, and tasks already in execution will still use the role template version recorded in the second information.

[0099] The intelligent system instance status refers to the current running status information of the intelligent system instance, including but not limited to whether the intelligent system instance is active, available, currently executing a task, and the client type identifier of the intelligent system instance. The system verifies whether the intelligent system instance is active before executing a task.

[0100] Entry policy refers to the access control rule configuration information for different access points, including but not limited to whether each entry point is open to the current role, the authentication method of the entry point, and the access control rules at the entry point level. The system sets uniform access control rules for each type of entry point to prevent users from bypassing organizational governance policies through different entry points.

[0101] Plugin policies refer to the governance rule configuration information for various plugins that the intelligent system can invoke, including but not limited to the plugin's activation status, risk level, connection status, whether it belongs to the allowed invocation set, and the priority rules for policy matching (rejection priority is higher than confirmation priority, and confirmation priority is higher than allow priority). Plugin policies are used to determine whether to allow the execution of a plugin invocation request when the intelligent system initiates such a request.

[0102] Environment policies refer to the governance rules and configuration information of the operating environment that an intelligent system can use, including but not limited to availability rules for environment templates, environment usage permission rules, and environment resource quota rules. Environment policies are used to verify whether users and teams have the necessary environment usage permissions and sufficient resources when a user creates a running environment instance.

[0103] Specifically, when any user accesses the intelligent system through any entry point, the system first identifies the user's organization, team, role template, and user permission status. Then, combining this information with the intelligent system instance status, runtime environment status, plugin availability, and corresponding resource quantities at various levels, the system generates runtime secondary information and performs access control for the task. When the intelligent system is about to execute a task, it does not rely solely on static configuration but generates secondary information based on the current context. This secondary information includes at least: the current organization and team status, the current member and user permission status, the current role template version, the current intelligent system instance status and client type, the current entry point policy, the current plugin and environment policies, and the corresponding resource quantities at each level among the current organization, team, role, and user. This secondary information is linked to each task, ensuring that subsequent audits can accurately reconstruct the policy environment at the time of task execution. Even if the administrator modifies the configuration after the task is executed, it will not affect the consistency of historical traceability.

[0104] For example, the second piece of information can be stored in a cloud storage service. The second piece of information is generated when the intelligent system receives a task request, based on the current first piece of information and the task context. The second piece of information is stored in association with the identifier of the session to which the task belongs; this identifier is embedded within the second piece of information, thus associating the second piece of information with the task and enabling traceability for historical auditing. During task execution, the system maintains the second piece of information in an immutable state. If a task ends and a subsequent task exists within the same session, the system uses the second piece of information as the policy basis for the subsequent task. The scope of the second piece of information is limited to subsequent tasks within the same session. Furthermore, the system sets a lifespan for the second piece of information (e.g., 1 hour), and automatically reclaims the second piece of information when the lifespan expires.

[0105] Step 130: According to the priority order in the first information, check in turn whether the corresponding resource quantity of each level meets the resource requirements of the task.

[0106] In one scenario, the first information includes a hierarchical relationship between organizations, teams, role templates, user licenses, and intelligent system instances; the step of sequentially verifying whether the corresponding resource quantity of each level meets the resource requirements of the task according to the priority order in the first information includes: sequentially verifying whether the corresponding resource quantity of each level meets the resource requirements of the task according to the priority order of the user license level, the intelligent system instance level, the role template level, the team level, and the organization level.

[0107] In one scenario, the step of sequentially verifying whether the corresponding resource quantity of each level meets the resource requirements of the task, according to the priority order of the user license level, the intelligent system instance level, the role template level, the team level, and the organization level, includes: verifying whether the user license is enabled; in response to the user license being enabled, verifying whether the intelligent system instance is activated; in response to the intelligent system instance being activated, verifying whether the role template is valid and whether the corresponding resource quantity of the role template is sufficient; in response to the role template being valid and the corresponding resource quantity of the role template being sufficient, verifying whether the team is active and whether the corresponding resource quantity of the team is sufficient; in response to the team being active and the corresponding resource quantity of the team being sufficient, verifying whether the total corresponding resource quantity of the organization is sufficient; and in response to any of the above verifications failing, rejecting the task.

[0108] In one scenario, resource control for enterprise-level intelligent systems does not rely solely on post-event statistics, but instead employs a complete chain of "estimation—pre-allocation—in-execution metering—post-execution calculation." Before a task begins, the system estimates resource requirements based on factors such as task type, model context size, historical average consumption, whether cloud environments and plugin calls are involved, and verifies the corresponding resource quantities at each level in the following order: First, the system verifies whether the user is enabled. It reads the user status field from the initial information to determine if the user account initiating the task request is enabled. If the user is not enabled (e.g., in a pending or disabled state), the verification fails, the system rejects the task, and returns a "user not enabled" resource insufficiency result.

[0109] Secondly, if the user is in an enabled state, the system verifies whether the user's license is enabled. The system reads the user license status field from the first information and determines whether the user license is enabled. If the user license is not enabled (e.g., disabled or expired), the verification fails, the system rejects the task, and returns a resource insufficiency result of "user license not enabled".

[0110] Next, assuming the user license is enabled, the system verifies whether the intelligent system instance is active. The system reads the intelligent system instance status field from the first information to determine if the intelligent system instance is active. If the intelligent system instance is not active (e.g., disabled or in an abnormal state), the verification fails, the system rejects the task, and returns a resource insufficiency result stating "Intelligent system instance not active".

[0111] Then, with the intelligent system instance active, the system verifies whether the role template is valid and whether its corresponding resources are sufficient. The system reads the role template status field and corresponding resource quantity field from the first information, determining whether the role template is valid and whether its corresponding resource quantity exceeds the task requirements. If the role template is invalid or its corresponding resource quantity is insufficient, the verification fails, the system rejects the task, and returns a resource insufficiency result: "Role template invalid or corresponding resource quantity insufficient."

[0112] Next, assuming the role template is valid and its corresponding resources are sufficient, the system verifies whether the team is active and whether its corresponding resources are sufficient. The system reads the team status field and corresponding resource quantity field from the initial information to determine if the team is active and whether its corresponding resources exceed the task requirements. If the team is inactive or its corresponding resources are insufficient, the verification fails, the system rejects the task, and returns a resource insufficiency result: "Team inactive or corresponding resources insufficient."

[0113] Finally, assuming the team is active and has sufficient resources, the system verifies whether the organization's total corresponding resources are sufficient. The system reads the organization's total corresponding resources field and used corresponding resources field from the initial information, calculates the total corresponding resources, and determines if it exceeds the task requirements. If the organization's total corresponding resources are insufficient, the verification fails, the system rejects the task, and returns a "Total corresponding resources insufficient" result.

[0114] Step 140: In response to all levels of verification passing, determine the required resource quantity for the task based on the historical information of the resource requirements.

[0115] In one scenario, the historical information includes at least one of the following: task type, model context size, and historical average consumption.

[0116] In one scenario, the historical information includes historical average consumption; determining the required resource quantity for the task based on the historical information of resource demand includes: determining the required resource quantity based on the historical average consumption.

[0117] For example, the resource requirement estimation process is as follows: The system queries the historical consumption database for historical consumption records of recent tasks of the same type as the current task (i.e., of the same type and model context size), and calculates their average value as the historical average consumption. The statistical dimensions of the historical average consumption include, but are not limited to: model input token quantity, model output token quantity, CPU core time, and memory usage. The system uses the historical average consumption as the resource requirement for the current task. When multiple entry points simultaneously initiate task requests, Step 150: Reserve the required resources and execute the task.

[0118] For example, if all levels pass the validation, a pre-reservation record is created in the resource record; if the resource quantity corresponding to any level is insufficient, the task is rejected directly and a resource insufficiency result is returned.

[0119] In one scenario, pre-allocating the required resource quantity includes: creating a pre-allocation record in the resource record corresponding to the required resource quantity, and locking the resource corresponding to the pre-allocation record.

[0120] In one scenario, the pre-allocation of the required resources further includes: locking the resource record in the order in which multiple entry points initiate task requests simultaneously; and releasing the lock when the task ends or times out.

[0121] For example, the system locks resource records according to the order in which task requests are initiated, ensuring data consistency during pre-allocation operations. Specifically, a distributed lock mechanism can be used, with organization identifier + team identifier as the lock granularity. Locks are acquired sequentially according to the arrival time of task requests. After successfully acquiring a lock, the pre-allocation operation is performed, and the lock is released after the operation is completed. If any task times out while waiting for the lock during the pre-allocation process, the task returns a resource insufficiency result, avoiding deadlocks and long waiting times.

[0122] For example, the data structure of a pre-allocation record can include: a pre-allocation record identifier, a corresponding task identifier, the type of pre-allocated resource (such as tokens, memory, CPU cores, cloud disk space, etc.), the amount of pre-allocated resource, a pre-allocation timestamp, and the pre-allocation status (such as locked, released, consumed, etc.). Pre-allocation records are stored in association with task identifiers, and the corresponding pre-allocation record can be queried through the task identifier. Locking the resource corresponding to a pre-allocation record means that after the pre-allocation record is successfully created, the system deducts the resource amount of the pre-allocation record from the corresponding resource amount at the corresponding level in the resource record, and simultaneously marks this portion of the resource as "pre-allocated," preventing other tasks from using the locked resource during task execution. The corresponding resource amount maintained in the resource record is the available corresponding resource amount after deducting the pre-allocation amount.

[0123] In one scenario, the method further includes: collecting resource consumption data during the task execution process, the resource consumption data including actual resource consumption; and, in response to the completion of the task, calculating and synchronously updating the corresponding resource quantities at each level in the first information based on the actual resource consumption and the pre-allocated required resource quantity.

[0124] This includes collecting resource consumption data during task execution, which includes the actual amount of resources consumed.

[0125] In one scenario, the method further includes: continuously collecting at least one type of resource consumption data during the execution of the task, including model input tokens, model output tokens, processing time, cloud desktop CPU core time, cloud desktop memory usage, cloud disk read / write and storage changes.

[0126] During task execution, the system can continuously collect the following resource consumption data: model input token quantity, model output token quantity, processing time, cloud desktop or sandbox CPU core time, cloud desktop or sandbox memory usage, cloud disk read / write and storage changes, tool call count, plugin call results, and external connection results.

[0127] In one scenario, the collection of resource consumption data can be handled by... Figure 2 The cost and usage module 101, as shown, executes during task execution. The cost and usage module 101 acquires resource consumption data related to each resource provider through detection: the intelligent system management module 12 records model call events, the tool management module 13 and the sub-intelligent system management module 14 record tool call and plugin call events, and the cloud desktop template management module 18 and the intelligent system cloud disk management module 15 record environment operation and cloud disk read / write events. When each module generates resource consumption, it pushes the event data to the cost and usage module 101. Upon receiving the data, the cost and usage module 101 associates it with the current task identifier and stores it. Specifically: The model input token quantity and model output token quantity are collected as follows: When the intelligent system management module 12 calls the model service interface, the model service carries the input token quantity and output token quantity consumed in this call in the response result. The intelligent system management module 12 extracts the data from the response and reports it to the cost and usage module 101. The cost and usage module 101 associates the data with the task identifier and records it.

[0128] The processing time is collected as follows: the intelligent system management module 12 records the start timestamp when the task starts and the end timestamp when the task ends, calculates the difference between the two as the processing time, and reports it to the cost and usage module 101.

[0129] The method for collecting virtual desktop CPU core time and virtual desktop memory usage is as follows: The cloud desktop template management module 18 obtains the CPU usage and memory usage of the virtual desktop instance through the detection interface of the virtual desktop infrastructure according to a preset period, and reports the data of each sampling point to the cost and usage module 101. The cost and usage module 101 associates the data with the task identifier and records it.

[0130] The method for collecting cloud disk read / write and storage changes is as follows: The intelligent system cloud disk management module 15 obtains the number of cloud disk read / write operations, data volume, and storage space changes in real time through the cloud disk storage service detection interface, and reports them to the cost and usage module 101. The cost and usage module 101 associates and records the data with the task identifier.

[0131] The collection methods for tool call counts, plugin call results, and external connection results are as follows: the tool management module 13 and the sub-intelligent system management module 14 record the call event (including call time, caller ID, callee ID, and call result status (success or failure)) each time the intelligent system calls a tool or plugin, and report it to the cost and usage module 101. The cost and usage module 101 associates the data with the task ID and records it.

[0132] The collected resource consumption data includes the actual resource consumption. The cost and usage module 101 associates various resource consumption data with task identifiers and stores them in the resource record.

[0133] In one scenario, the cost and usage module 101 categorizes and summarizes various resource consumption data-related events collected during task execution according to task identifiers. Each collected resource consumption event is a raw consumption record, including event type, occurrence time, consumption value, and task identifier. The cost and usage module 101 continuously receives resource consumption events reported by other modules; multiple resource consumption event records may correspond to the same task. After the task ends, the cost and usage module 101 uses the task identifier as the grouping key to accumulate or aggregate all resource consumption events belonging to the same task according to resource type, ultimately obtaining the actual resource consumption of the task.

[0134] In response to the end of the task, the corresponding resource quantities at each level in the first information are updated synchronously based on the actual resource consumption and the pre-allocated required resource quantity.

[0135] In one scenario, the calculation based on the actual resource consumption and the pre-allocated required resource quantity includes: submitting the actual resource consumption to the resource record; and releasing the unconsumed resources from the pre-allocated required resource quantity in the resource record based on the actual resource consumption.

[0136] In one scenario, the method further includes: in the event of task failure, immediately releasing any unconsumed resources from the pre-allocated required resources.

[0137] After a task is completed, the system compares the actual resource consumption with the pre-allocated required resources: the portion corresponding to the actual resource consumption is submitted to the resource record; and the unconsumed resources in the pre-allocated required resources in the resource record are released; failed tasks can roll back the ineffective portion according to the rules; and the aggregated results are synchronously updated to the individual, team, and organizational level statistical views.

[0138] In one scenario, task completion can be categorized into two situations: normal completion and abnormal failure. When a task completes normally, the system calculates resource consumption based on the actual resource consumption collected during task execution and the pre-allocated resource requirement before the task began. The calculation logic is as follows: First, the cost and usage module 101 reads the pre-allocation record corresponding to the task from the resource record to obtain the pre-allocated required resource quantity. Then, it summarizes the actual resource consumption of various types collected during task execution according to resource type to obtain the total actual consumption of each type of resource. For each resource type, the total actual consumption is compared with the pre-allocation quantity. If the actual consumption is less than the pre-allocation quantity, the difference in pre-allocated resources is released, making that part of the resources available again; if the actual consumption is equal to the pre-allocation quantity, the pre-allocation record is fully cancelled without additional operation; if the actual consumption is greater than the pre-allocation quantity, it means that the pre-allocation quantity is insufficient to cover the actual consumption, and the system supplements the calculation for the excess part according to the actual consumption quantity. After the calculation is completed, the cost and usage module 101 submits the actual consumption quantity to the resource record as the final consumption record of the task.

[0139] In one scenario, the release operation of a pre-reserved record includes: updating the status of the pre-reserved record corresponding to the task in the resource record to "released"; restoring the amount of resources that have not been actually consumed from the "pre-reserved" status to the "available" status, and re-entering them into the corresponding resource amount at the corresponding level. The pre-reserved record is retained in the resource record after release as a basis for audit traceability, but it does not participate in the verification of the corresponding resource amount for subsequent tasks.

[0140] In one scenario, when a task fails abnormally, the system does not need to wait for the normal computation process but immediately releases the unconsumed resources from the pre-allocated required resources. Specifically, after detecting a task failure event, the intelligent system management module 12 sends a task failure notification to the cost and usage module 101. Upon receiving the notification, the cost and usage module 101 immediately executes the release operation of the pre-allocated resources. This immediate release mechanism avoids resources being ineffectively occupied for a long time due to task failure, improving resource utilization. Resources actually consumed by the failed task (e.g., model call token consumption generated before the task failure) are still submitted to the resource record according to the actual consumption. For the portion of the pre-allocated resources that has been actually consumed, the cost and usage module 101 marks it as "consumed"; for the portion of the pre-allocated resources that has not been actually consumed, the cost and usage module 101 marks it as "released".

[0141] In one scenario, after the calculation is complete, the cost and usage module 101 synchronously updates the aggregated results to the corresponding resource quantities at each level in the first information. This may include updating the corresponding resource quantities at the intelligent system instance level, user license level, team level, role template level, and the total corresponding resource quantity at the organization level. After the synchronous update, the corresponding resource quantities at each level instantly reflect the latest resource usage, providing an accurate data foundation for verifying the corresponding resource quantities for subsequent tasks. Furthermore, the cost and usage module 101 also aggregates session, task, resource, risk, and configuration change events and sends them to the observability and analysis module 102. The observability and analysis module 102 aggregates and generates usage metrics by individual, team, and organization dimensions for subsequent audit analysis and governance feedback.

[0142] In one scenario, the method further includes: when the intelligent system initiates a plugin invocation request, obtaining second information about the task; performing policy matching on the plugin based on the plugin policy information in the second information to obtain a matching result; if the matching result is a rejection, intercepting the invocation request; if the matching result is a confirmation, triggering an approval process; and if the matching result is an allowance, executing the invocation request.

[0143] In one scenario, the plugin has at least one attribute selected from asset type, version, tag, source type, risk level, availability status, connection status, and number of uses; the strategy matching of the plugin based on the plugin strategy information in the second information includes: strategy matching based on the plugin's risk level and availability status.

[0144] Skill modules, sub-intelligent systems, model context protocol servers, built-in tools, and enterprise-managed tools are all treated as plugin assets, and governance is performed on them at runtime. Each plugin asset has at least the following attributes: asset type, version, tag, source type, risk level, availability status, connection status, and usage count. When the intelligent system plans to call a plugin, the system executes the following steps: obtain the second information of the current task; determine whether the plugin is enabled; determine whether the plugin belongs to the allowed call set; if the plugin is a model context protocol server, determine whether its connection status is normal; perform matching according to policy priority, which can be that rejection priority is higher than confirmation priority, and confirmation priority is higher than allow priority; if the rejection policy is hit, it is directly blocked; if the confirmation policy is hit, it enters the approval or manual confirmation process; if allowed, the call result, time consumption, resource consumption, and risk status are recorded. Through the above description, plugins are no longer just "displayable asset catalogs" but become real runtime objects participating in task access and execution control.

[0145] In one scenario, the unified management of plug-in assets is jointly undertaken by the tool management module 13 and the sub-intelligent system management module 14. The tool management module 13 manages plug-in assets such as built-in tools and model context protocol servers; the sub-intelligent system management module 14 manages plug-in assets of the sub-intelligent system type. All types of plug-in assets are registered and maintained in the system using a unified data structure, and each plug-in asset is assigned the aforementioned attributes upon registration. The attributes of plug-in assets can be stored in the system configuration database. Administrators can configure and update the attributes of plug-in assets through the management platform, such as adjusting the risk level of a plug-in, enabling or disabling a plug-in, and setting plug-in tags. When the attributes of a plug-in asset change, the system automatically applies the new configuration during subsequent task access.

[0146] In one scenario, plugin policy information refers to a set of rules embedded in the second information, used to match and determine plugins when the intelligent system initiates a plugin call request. This rule set includes the plugin's enabled status, allowed call set, risk level threshold, and matching priority rules for rejection, confirmation, or permission. The plugin policy information is embedded in the second information as a component of it. When the intelligent system initiates a plugin call request, the system reads the plugin policy information from the second information of the current task. The matching logic for the plugin policy information is as follows: The system first determines whether the plugin is enabled based on the plugin policy information in the second information; if the plugin is disabled, it is directly matched as a rejection. If the plugin is enabled, the system further determines whether the plugin belongs to the allowed call set recorded in the second information; if it does not belong to the allowed call set, it is matched as a rejection. If the plugin belongs to the allowed call set, the system further obtains the plugin's risk level and availability status; if the risk level exceeds a preset threshold or the availability status is unavailable, it is matched as a rejection. If all the above checks pass, the system performs the final matching according to policy priority: rejection policies take precedence over confirmation policies, and confirmation policies take precedence over permission policies. If the matching result is rejection, the system intercepts the call request and records the interception event; if the matching result is confirmation, the system triggers the approval process and sends the approval request to the administrator or designated approver. Execution can only proceed after approval is granted. Approval timeout or rejection is considered a rejection; if the matching result is permission, the system executes the call request.

[0147] In one scenario, after a plugin invocation request is executed, the tool management module 13 or the sub-intelligent system management module 14 records the result, time consumption, resource consumption, and risk status of the invocation, and reports the recorded data to the cost and usage module 101 and the observability and analysis module 102 for usage statistics and audit traceability. The recorded data includes at least: plugin identifier, invocation time, invocation time, invocation result status, and the amount of resources consumed (such as token consumption, CPU core time, etc.).

[0148] In one scenario, the method further includes: in response to an environment creation request, verifying the environment usage permissions of the organization, team, and members to which the intelligent system belongs; if the permission verification passes and the corresponding resources are sufficient, creating a runtime environment instance, the runtime environment instance including a sandbox container or a virtual desktop instance; binding the runtime environment instance to the intelligent system instance; and recording a state change event when the state of the runtime environment instance changes.

[0149] In one scenario, the runtime environment instance has at least one of the following states: creation in progress, running, stopped, stopped, restarting, abnormal, and deletion; the method further includes: allowing login or opening of the terminal of the intelligent system instance when the runtime environment instance is in the running state; allowing deletion of the runtime environment instance when the runtime environment instance is in the stopped state; and triggering a restart, isolation, or manual processing procedure when the runtime environment instance is in an abnormal state.

[0150] For virtual desktops or cloud sandbox environments, a runtime environment object bound to an intelligent system instance can be introduced. When a user creates a virtual desktop, the system can perform the following actions: select an environment template; read the specifications of the operating system, image, CPU, memory, and hard disk from the template; verify whether the user and team have the necessary permissions to use the environment; verify whether the corresponding resources are sufficient to support the environment instance; create a runtime environment record and call the underlying infrastructure to create the instance; bind the environment to the intelligent system instance; and update the management platform display and audit records when the environment status changes. Under certain circumstances, the runtime environment must have at least the following states: creating, running, stopped, stopped, restarting, abnormal, or deleting. The system sets different operational constraints for different states: login or opening a terminal is allowed only when the environment is in the running state; deletion is allowed only when the environment is in the stopped state; the corresponding button is disabled during any asynchronous change execution to prevent duplicate submissions; and restart, isolation, or manual handling processes can be triggered when the environment is abnormal.

[0151] In one scenario, runtime environment lifecycle management is performed by the cloud desktop template management module 18. In response to a user's environment creation request initiated through the entry point, the cloud desktop template management module 18 first obtains the identity information of the organization, team, and members to which the intelligent system belongs based on the first information, and then queries the enterprise identity and permission control module 11 to determine if the user has environment usage permissions. If the user does not have environment usage permissions, the creation request is rejected and an insufficient permission result is returned. If the user has environment usage permissions, the cloud desktop template management module 18 further queries the cost and usage module 101 to determine the corresponding resource quantities at each level of the organization, team, and members, and whether these are sufficient to support the operation of the environment instance. If the corresponding resource quantities are insufficient, the creation request is rejected and a corresponding insufficient resource quantity result is returned. If both permission verification and corresponding resource quantity verification pass, the cloud desktop template management module 18, based on the environment template selected by the user, reads the configuration information defined in the template, such as the operating system type, image version, CPU specifications, memory specifications, and hard disk specifications, and calls the application programming interface of the underlying infrastructure (such as container services or virtual machine services) to create a runtime environment instance. The runtime environment instance includes a sandbox container or a virtual desktop instance. The sandbox container is a lightweight code execution environment used to run code and tool calls generated by the intelligent system; the virtual desktop instance is a complete graphical desktop environment used to support interactive coding and graphical operations. After successful creation, the cloud desktop template management module 18 binds the runtime environment instance to the intelligent system instance, making the runtime environment instance exclusively belonging to that intelligent system instance. The binding relationship is stored in the system database, and subsequent tasks can query the bound runtime environment instance through the intelligent system instance. Throughout the entire lifecycle of the runtime environment instance, the cloud desktop template management module 18 monitors its status changes in real time, recording the status change event and updating the display and audit logs of the management platform each time a status change occurs.

[0152] In one scenario, the state management of a runtime environment instance follows state machine constraints. A runtime environment instance has the following states: Creating (creating the environment instance), Running (the environment instance is running normally and can be logged in and used by users), Stopping (performing a stop operation), Stopped (the environment instance has stopped running), Restarting (performing a restart operation), Abnormal (the environment instance has encountered an abnormality, such as an operating system crash or resource exhaustion), and Deleting (performing a deletion operation). The transitions between states are constrained by preset rules: users are allowed to log in or open the intelligent system instance's terminal only when the environment is in the running state to avoid data corruption caused by accessing the environment in an unstable state; users are allowed to delete the environment instance only when the environment is in the stopped state to avoid resource failure during deletion while running; during any asynchronous change operation, the corresponding operation button is disabled to prevent users from repeatedly submitting the same operation, leading to state conflicts; when the environment is in an abnormal state, the system can automatically trigger a restart operation to attempt recovery according to preset policies, or trigger an isolation operation after a failed restart to isolate the abnormal environment from the normal environment to prevent the fault from spreading, while simultaneously sending an alarm notification to the administrator to trigger manual processing.

[0153] Please refer to Figure 5 , Figure 5 This is a schematic diagram illustrating an application scenario. After a user initiates a login request through an entry point such as instant messaging software (e.g., a third-party collaboration platform), the task execution process of the intelligent system is triggered. During the task execution process, the system is scheduled under unified management of intelligent system permissions, security policies, cloud disk, model context protocol, skills, and memory. On one hand, the intelligent system can create multiple sub-intelligent systems (sub-intelligent systems × N) according to task needs, breaking down complex tasks into multiple sub-tasks for parallel or serial processing by each sub-intelligent system. On the other hand, the intelligent system can execute code and operations in a local sandbox or virtual desktops (e.g., 10 in total), and complete specific task steps by calling external tools 1, 2, 3, etc. The local sandbox provides a lightweight code execution isolation environment, and the virtual desktops provide a complete graphical operating environment; both provide a secure and isolated runtime environment for the intelligent system. Throughout the task execution process, the intelligent system uses permissions to control the scope of operations it can perform, security policies to ensure the security of the execution process, cloud storage to store task-related files and data, a model context protocol server for standardized communication between the intelligent system and external tools, skills to provide reusable functional modules, and memory to store and retrieve context information during task execution. Through the coordinated operation of these mechanisms, the intelligent system completes the entire process from task reception to execution completion within a controlled and secure environment.

[0154] In one scenario, upon receiving a request from a user through an entry point such as instant messaging software, the intelligent system enters an iterative cycle. Specifically, the intelligent system cycle refers to the continuous iterative process of "planning-invoking-observing-replanning" during task execution. The intelligent system first performs semantic understanding and task decomposition on the user request, planning the task execution path. Then, based on the planning results, it invokes external tools, skills, or model context protocol servers to obtain information or perform operations. Next, it observes the invoking results to determine if the current task objective has been achieved. If not, it replans the next action based on the observation results, repeating the invoking and observation process until the task is completed or the termination conditions are met. In each iteration of the intelligent system cycle, the intelligent system is constrained by intelligent system permissions and security policies, ensuring that the intelligent system operates within the permitted scope and continuously collects resource consumption data during the cycle for subsequent resource calculations and audit analysis.

[0155] In one scenario, the method further includes: decomposing the task into a session object, a task object, and an execution topology object, wherein the session object records a continuous interaction between the intelligent system and the user, the task object records an execution unit within the session object, and the execution topology object belongs to the task object; recording the calling relationships between model nodes, tool nodes, plugin nodes, and environment nodes through the execution topology object; associating the resource consumption data with the nodes in the execution topology object to perform attribution analysis on resource consumption; and writing the association relationship between the session object, the task object, and the execution topology object into an audit log.

[0156] To achieve interpretability and traceability, a single interaction with the intelligent system can be broken down into session objects, task objects, and execution topology objects. The session object records a continuous interaction between the user and the intelligent system; the task object records the specific execution unit within the session; the execution topology object records the call relationships between model nodes, tool nodes, plugin nodes, and environment nodes; the session replay object records historical screen recordings and replay addresses in virtual desktop scenarios; and the audit object records actions such as login, configuration modification, task execution, policy hits, and risk handling. By associating topology nodes with resource events, risk events, and audit logs, the system can answer questions such as: Why did a certain task consume so many tokens? Which intelligent system, plugin, or environment triggered a high-risk command? Is a team's high cost primarily due to the cloud environment or local tasks? Is a failed task related to abnormal connection to the model context protocol server, disabled plugins, or environmental anomalies?

[0157] In one scenario, session objects, task objects, and execution topology objects are organized according to a hierarchical relationship. Specifically, the session object is at the top level, representing the complete user interaction process from login to logout; a session object can contain multiple task objects, each representing an independent execution unit within the session; a task object can contain an execution topology object, which records all calling nodes and their calling relationships during the task's execution. The identification and association method for each object is as follows: the task object records the identifier of its parent session object, and the execution topology object records the identifier of its parent task object, thereby achieving a hierarchical association between the three layers of objects.

[0158] In one scenario, the execution topology object records the call relationships between model nodes, tool nodes, plugin nodes, and environment nodes. The definitions of each node are as follows: a model node represents a model inference call, recording information such as call time, model identifier, input token quantity, output token quantity, and processing time; a tool node represents an external tool call, recording information such as call time, tool identifier, input parameter summary, output result summary, call duration, and call result status (success or failure); a plugin node represents a plugin call, recording information such as call time, plugin identifier, plugin type, risk level, matching result (reject / confirm / allow), and approval result (e.g., triggered approval); and an environment node represents a runtime environment operation, recording information such as operation time, environment instance identifier, operation type (create / start / stop / restart / delete, etc.), and operation result. The call relationships between nodes are represented by directed edges—for example, a model node pointing to a tool node indicates that the model called the tool, and a tool node pointing to an environment node indicates that the tool operated on the runtime environment during execution. The execution topology object is dynamically built and updated during task execution as new call events are generated by each node.

[0159] In one scenario, the specific method for associating resource consumption data with nodes in the execution topology object is as follows: When each node in the execution topology object is generated, the cost and usage module 101 allocates a consumption record container for that node. During execution, when the intelligent system management module 12, tool management module 13, sub-intelligent system management module 14, or cloud desktop template management module 18 reports resource consumption data, the cost and usage module 101 fills the consumption data into the corresponding node's consumption record container based on the currently executing node. After the task is completed, each node in the execution topology object is associated with the actual resource consumption data generated by that node.

[0160] In one scenario, the specific method for writing the relationships into the audit log is as follows: After the task is completed, the observability and analysis module 102 writes the session object identifier, task object identifier, the complete structure of the execution topology object and the resource consumption data associated with each node, as well as various behavioral events recorded by the audit object (login, configuration modification, policy hit, risk handling, etc.) into the audit log for storage. The audit log is stored in an immutable data structure to ensure the integrity and immutability of the log. Administrators can query the audit log through the management platform, and search based on fields such as session object identifier, task object identifier, node type, resource consumption, and risk events to achieve full-link audit traceability.

[0161] In one scenario, the method further includes generating a session replay object, which records historical screen recordings and replay addresses within the virtual desktop scenario. Specifically, when the intelligent system performs tasks in a virtual desktop instance, the cloud desktop template management module 18 continuously records the virtual desktop's operation screen, generates a screen recording file, and stores it in a cloud disk or object storage service. The session replay object contains the storage address (replay address) of the screen recording file, as well as the corresponding session object identifier and task object identifier. Administrators can replay the complete operation process during the session using the replay address, and perform in-depth auditing by combining execution topology node and resource consumption data.

[0162] In one scenario, the method further includes: collecting session events, task events, resource events, and risk events; generating usage metrics for individual, team, and organizational dimensions based on the collected events; and triggering governance actions based on the usage metrics, wherein the governance actions include at least one of adjusting corresponding resource amounts, adjusting role templates, disabling plugins, disabling intelligent systems, and reclaiming resources from the environment.

[0163] In one scenario, the usage metrics include at least one of the following: number of conversations, number of input tokens, number of output tokens, total token consumption, memory usage, CPU core time, average processing time, number of active user licenses, adoption rate, number of plugin uses, cost distribution, number of risk events, and compliance rate.

[0164] The text-based descriptions not only record data but also feed that data back into governance actions. The system can collect data on the following events: entry point clicks; team creation, editing, and deletion; member addition, activation, disabling, and removal; intelligent system activation and disabling; plugin viewing, searching, filtering, and invocation; cloud drive upload, search, and deletion; environment creation, startup, stop, restart, and deletion; session and task start, end, and failure; risk hits and compliance export. The aggregation service generates usage metrics at the individual, team, and organization levels, including but not limited to: number of conversations this month, input tokens, output tokens, total token consumption, memory usage, CPU core time, average processing time, number of active user licenses, team adoption rate, plugin usage frequency, team cost distribution, number of risk events, and compliance rate.

[0165] For example, the governance feedback module can perform the following actions based on the analysis results: when team resources are underutilized for a long period of time, prompt to reduce the corresponding resource amount for the team; when a role frequently triggers quota shortages, prompt to adjust the role template; when a model context protocol server continuously fails to connect, automatically downgrade or disable its automatic invocation permissions; when an intelligent system triggers multiple high-risk events in a short period of time, automatically set the intelligent system to a disabled or abnormal state; when an environment is inactive for a long time, automatically stop or reclaim the environment according to the cleanup rules.

[0166] In one scenario, event collection can be performed by the Observability and Analysis Module 102. The Observability and Analysis Module 102 captures various events in real time by detecting the operation logs and status change events of each module (Enterprise Identity and Access Control Module 11, Intelligent System Management Module 12, Tool Management Module 13, Sub-Intelligent System Management Module 14, Intelligent System Cloud Disk Management Module 15, Memory Management Module 16, Skill Management Module 17, Cloud Desktop Template Management Module 18, and Security and Compliance Module 19). When each module performs an operation, it reports information such as operation type, operation object, operation result, operation time, and operator identifier to the Observability and Analysis Module 102 in a standardized event format. After receiving the event, the Observability and Analysis Module 102 stores the event data in the event log storage.

[0167] In one scenario, the generation of metrics is performed by the aggregation service in the observability and analysis module 102. The aggregation service reads raw event data from the event log storage according to a preset time period (e.g., daily, weekly, monthly) and performs aggregation calculations according to the individual dimension (using user identifier as the grouping key), team dimension (using team identifier as the grouping key), and organization dimension (using organization identifier as the grouping key). Specifically, the number of conversations is obtained by counting the conversation start events; the number of input tokens, the number of output tokens, and the total token consumption are obtained by summing the token fields in the resource events reported by the cost and usage module 101 by dimension; the memory usage and CPU core time are obtained by summing or averaging the memory and CPU fields in the resource events reported by the cost and usage module 101 by dimension; the average processing time is obtained by averaging the difference between the start and end times of the task events; the number of active user licenses is obtained by counting the enabled user licenses in the user license status events; the adoption rate is obtained by dividing the number of active users by the total number of users; the number of plugin usages is obtained by counting plugin call events; the cost distribution is obtained by multiplying the resource consumption of each dimension by the corresponding unit price and then grouping and summarizing by resource type; the number of risk events is obtained by counting risk events; and the compliance rate is obtained by dividing the number of compliant events by the total number of events.

[0168] In one scenario, governance actions can be triggered by the governance feedback module. After generating usage metrics, the observability and analysis module 102 sends the metric data to the governance feedback module. The governance feedback module has a built-in rule engine configured with multiple governance rules, each containing a correspondence between triggering conditions and governance actions. When a usage metric meets the triggering condition of a rule, the rule engine automatically executes the corresponding governance action: when team resource utilization is below a preset threshold, a corresponding resource reduction suggestion is generated and sent to the administrator; when a role frequently triggers quota shortages, a role template adjustment suggestion is generated and sent to the administrator; when the number of times a model context protocol server experiences continuous connection failures exceeds a preset threshold, its automatic invocation permission is automatically downgraded or disabled; when the number of times an intelligent system triggers high-risk events within a preset time window exceeds a preset threshold, the intelligent system is automatically set to disabled or abnormal status; when no active operations are detected in an environment instance within a preset time window, the environment instance is automatically stopped or reclaimed according to cleanup rules. After the governance actions are executed, the system writes the records of the governance actions to the audit log and applies the updated policy configuration to the subsequent task access process, forming a complete closed loop of "collection - aggregation - analysis - governance - feedback".

[0169] In one scenario, this application provides a resource management method, apparatus, medium, and device for enterprise-level intelligent systems to address the fragmentation between multiple access points, quota control, plug-in and environment governance, audit attribution, and organizational-level asset accumulation. Specifically, the above method has at least the following beneficial effects: (1) Achieve unified identity access and object modeling. By responding to task requests initiated by the intelligent system from any of the multiple entry points, the first information of the intelligent system is obtained. This first information includes the hierarchical relationship of organizations, teams, role templates, user permissions, and intelligent system instances. Enterprise users can be mapped to governance objects such as organizations, teams, role templates, user permissions, and intelligent system instances, thereby achieving unified mapping of identity and permissions in multi-entry scenarios and avoiding the problem of inconsistent permission and quota systems between different entry points.

[0170] (2) Implement unified resource and permission policies. By incorporating the corresponding resource quantity of an organization, the corresponding resource quantity of a team, the corresponding resource quantity of a role, the member status, the status of the intelligent system, the entry policy, the plug-in policy, and the environment policy into a unified runtime judgment system of second information, and performing chain verification on the corresponding resource quantity of each level based on the second information, the problem of scattered management of different modules and the inability to execute policies uniformly is avoided.

[0171] (3) Achieve dynamic control during runtime. During the task admission phase, the corresponding resource quantity is verified and the resource is pre-allocated. During the task execution phase, resource consumption data is continuously collected. After the task is completed, the corresponding resource quantity is calculated and updated synchronously. This achieves complete closed-loop control of admission, pre-allocation, verification, interception and calculation at key nodes such as login, authorization, task execution, plugin invocation, environment creation and file operation. This avoids the problems of source management being biased towards post-event statistics and lacking pre-event pre-allocation and in-event quotas.

[0172] (4) Achieve end-to-end data collection and attribution. By uniformly collecting sessions, tasks, tool calls, resource consumption, policy hits, risk events and environmental status changes, and recording the call relationships between model nodes, tool nodes, plugin nodes and environment nodes through execution topology objects, resource consumption data is associated with each node, realizing accurate attribution analysis of resource consumption and solving the problem that auditing and analysis cannot be traced back to specific execution units.

[0173] (5) Achieve a closed-loop governance feedback mechanism. Based on usage indicators and compliance results across three dimensions—individual, team, and organization—automatic governance actions are triggered, including adjusting corresponding resource amounts, adjusting role templates, disabling plugins, disabling intelligent systems, and reclaiming environments. This solves the problem that observable data is difficult to use to drive governance decisions, forming a complete closed loop from collection and analysis to governance.

[0174] All the above textual expressions can be combined in any way to form specific implementations of textual expressions, which will not be elaborated on here.

[0175] One resource management method provided in this scenario involves receiving a task request initiated by an intelligent system, obtaining first information associated with the intelligent system (indicating hierarchical relationships between multiple levels), generating second information about the task based on the first information and the current task context (including at least the corresponding resource quantities for each level), verifying whether the corresponding resource quantities for each level meet the task's resource requirements according to the priority order in the first information, determining the required resource quantity for the task based on historical resource requirement information after all level verifications pass, pre-allocating the required resource quantity, and executing the task. The above description, through chain-like verification and resource pre-allocation based on the hierarchical relationships indicated by the first information, achieves unified mapping and pre-emptive hard-top control of intelligent system resources in multi-entry scenarios.

[0176] To facilitate better implementation of resource management methods, a resource management device is also provided. Please refer to [link / reference]. Figure 6 , Figure 6 This is a schematic diagram of a resource management device provided in one scenario. The resource management device 200 may include: The acquisition unit 210 is used to receive a task request initiated by the intelligent system and to acquire first information associated with the intelligent system, wherein the first information indicates the hierarchical relationship between multiple levels. The generation unit 220 is configured to generate second information of the task based on the first information and the current task context, wherein the second information includes at least the corresponding resource quantity of each level; The verification unit 230 is used to verify, in order of priority in the first information, whether the corresponding resource quantity of each level meets the resource requirements of the task. The determining unit 240 is configured to determine the required resource quantity of the task based on the historical information of the resource requirement in response to all levels of verification passing. Processing unit 250 is used to pre-allocate the required resources and execute the task.

[0177] In one scenario, the generation unit 220 is further configured to: associate and store the second information with the identifier of the session to which the task belongs, and embed the identifier in the second information.

[0178] In one scenario, the generation unit 220 is further configured to execute the subsequent task based on the second information in response to the completion of the task and the existence of a subsequent task within the session to which the task belongs.

[0179] In one scenario, the generation unit 220 is further configured to add at least one of the following to the second information: organization status, team status, role template version, intelligent system instance status, entry strategy, plugin strategy, and environment strategy.

[0180] In one scenario, the generation unit 220 is further configured to: set a time-to-live for the second information; and reclaim the second information in response to the expiration of the time-to-live.

[0181] In one scenario, the first information includes the hierarchical relationship between organizations, teams, role templates, user licenses, and intelligent system instances; the verification unit 230 is used to verify, in order of priority, whether the corresponding resource quantity of each level meets the resource requirements of the task, according to the user license level, the intelligent system instance level, the role template level, the team level, and the organization level.

[0182] In one scenario, the historical information includes historical average consumption; the pre-allocation unit 240 is configured to determine the required resource quantity for the task based on the historical information of resource demand, including: determining the required resource quantity based on the historical average consumption.

[0183] In one scenario, the processing unit 250 is configured to pre-allocate the required resource quantity, including: creating a pre-allocation record corresponding to the required resource quantity in the resource record, and locking the resource corresponding to the pre-allocation record.

[0184] In one scenario, the processing unit 250 is further configured to: collect resource consumption data during the task execution process, the resource consumption data including the actual resource consumption; and, in response to the end of the task, calculate and synchronously update the corresponding resource quantities at each level in the first information based on the actual resource consumption and the pre-allocated required resource quantity.

[0185] In one scenario, the processing unit 250 is configured to perform calculations based on the actual resource consumption and the pre-allocated required resource quantity, including: submitting the actual resource consumption to a resource record; and releasing unconsumed resources from the pre-allocated required resource quantity in the resource record based on the actual resource consumption.

[0186] In one scenario, the resource management device 200 is further configured to: in response to the intelligent system initiating a plugin invocation request, obtain second information about the task; perform policy matching on the plugin based on the plugin policy information in the second information to obtain a matching result; in response to the matching result being rejected, intercept the invocation request; in response to the matching result being confirmed, trigger an approval process; and in response to the matching result being allowed, execute the invocation request.

[0187] In one scenario, the resource management device 200 is further configured to: receive an access request and parse at least one of a user identifier and an organization identifier in the access request; determine a first organization corresponding to the user based on the organization identifier, or determine a first organization corresponding to the user based on link information in the access request; in response to determining the first organization based on the link information, establish a record of members to be enabled for the user; and in response to the user being assigned a team and role template, generate the visibility scope and initial permissions of the user in the first organization.

[0188] The resource management device 200 can be integrated into a terminal device or server that has storage and a processor and thus computing power, or the resource management device 200 can be the terminal device or server.

[0189] In one embodiment, a computer device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in some of the methods described above.

[0190] In one situation, such as Figure 7 As shown, Figure 7 This is another schematic diagram of a computer device provided in one scenario. The computer device 300 further includes a processor 301 with one or more processing cores, a memory 302 with one or more computer-readable storage media, and a computer program stored on the memory 302 and executable on the processor. The processor 301 is electrically connected to the memory 302. Those skilled in the art will understand that the computer device structure shown in the figure does not constitute a limitation on the computer device, and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0191] The processor 301 is the control center of the computer device 300. It connects various parts of the computer device 300 through various interfaces and lines. By running or loading software programs and / or modules stored in the memory 302, and calling data stored in the memory 302, it performs various functions of the computer device 300 and processes data, thereby performing overall detection of the computer device 300.

[0192] Optionally, the computer device 300 can be a terminal device, and the processor 301 can call software programs and modules stored in the memory 302 to perform the following operations: Upon receiving a task request initiated by the intelligent system, the system obtains first information associated with the intelligent system, which indicates the hierarchical relationship between multiple levels. Based on the first information and the current task context, it generates second information for the task, which includes at least the corresponding resource quantities for each level. According to the priority order in the first information, it sequentially verifies whether the corresponding resource quantities for each level meet the resource requirements of the task. In response to all levels passing the verification, it determines the required resource quantity for the task based on historical information on resource requirements. It then pre-allocates the required resource quantity and executes the task.

[0193] For details on the specific implementation of each of the above operations, please refer to the previous examples; they will not be repeated here.

[0194] In one situation, such as Figure 7 As shown, the computer device 300 also includes a display unit 303, a radio frequency circuit 304, an audio circuit 305, an input unit 306, and a power supply 307. The processor 301 is electrically connected to the display unit 303, the radio frequency circuit 304, the audio circuit 305, the input unit 306, and the power supply 307. Those skilled in the art will understand that... Figure 7 The computer device structure shown does not constitute a limitation on the computer device and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0195] Display unit 303 can be used to display information input by the user or information provided to the user, as well as various graphical user interfaces of computer devices. These graphical user interfaces can be composed of graphics, text, icons, videos, and any combination thereof. Display unit 303 may include a display panel and a touch panel.

[0196] The radio frequency circuit 304 can be used to transmit and receive radio frequency signals to establish wireless communication with network devices or other computer devices, and to transmit and receive signals with network devices or other computer devices.

[0197] Audio circuitry 305 can be used to provide an audio interface between a user and a computer device via a speaker and a microphone. Audio circuitry 305 can convert received audio data into electrical signals and transmit them to the speaker, where the speaker converts them into sound signals for output. Conversely, the microphone converts collected sound signals into electrical signals, which are then received by audio circuitry 305, converted back into audio data, and then processed by processor 301 before being transmitted via radio frequency circuitry 304 to, for example, another computer device, or output to memory for further processing. Audio circuitry 305 may also include an earphone jack to facilitate communication between peripheral headphones and computer devices.

[0198] The input unit 306 can be used to receive input numbers, characters, or object feature information (such as fingerprints, irises, facial information, etc.), and to generate keyboard, mouse, joystick, optical, or trackball signal inputs related to user settings and function control.

[0199] Power supply 307 is used to supply power to the various components of computer device 300.

[0200] although Figure 7 As not shown in the diagram, computer equipment 300 may also include a camera, sensor, wireless fidelity module, Bluetooth module, etc., which will not be described in detail here.

[0201] In one instance, a computer-readable storage medium is also provided for storing a computer program. This computer-readable storage medium can be applied to a terminal device or server, and the computer program causes the terminal device or server to execute corresponding processes in a resource management method; for brevity, further details are omitted here.

[0202] In one scenario, a computer program product is also provided, comprising a computer program stored in a computer-readable storage medium. The processor of a computer device reads the computer program from the computer-readable storage medium and executes the computer program, causing the computer device to perform the corresponding flow in the resource management method; for brevity, this will not be elaborated further.

[0203] A computer program is also provided, which includes a computer program stored in a computer-readable storage medium. The processor of a computer device reads the computer program from the computer-readable storage medium and executes the computer program, causing the computer device to perform the corresponding processes in the resource management method; for brevity, these will not be elaborated further here.

[0204] It should be understood that a processor may be an integrated circuit chip with signal processing capabilities. In implementation, certain steps of the above methods can be completed by integrated logic circuits in the processor's hardware or by software instructions. The processor can be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the disclosed methods, steps, and logic block diagrams. A general-purpose processor can be a microprocessor or any conventional processor. The steps of the resource management method can be directly implemented by a hardware decoding processor, or implemented by a combination of hardware and software modules in the decoding processor. The software modules can reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the field. This storage medium is located in memory; the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above methods.

[0205] It is understood that memory can be volatile memory or non-volatile memory, or a combination of both. Non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous DRAM (SDRAM), Double Data Rate Synchronous DRAM (DDR SDRAM), Enhanced Synchronous DRAM (ESDRAM), Synchlink DRAM (SLDRAM), and Direct Rambus RAM (DRRAM). It should be noted that the memory used in the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0206] Those skilled in the art will recognize that the units and algorithmic steps of the examples described in connection with certain situations disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints described herein. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the description herein.

[0207] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in certain situations of the aforementioned methods, and will not be repeated here.

[0208] In the scenarios presented in the text, it should be understood that the disclosed systems, devices, and methods can be implemented in other ways. For example, some of the devices described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the couplings or direct couplings or communication connections shown or discussed may be through interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.

[0209] The units described as separate components may or may not be physically separate. The components displayed as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of text representation, depending on the actual needs.

[0210] In addition, the functional units can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0211] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the essence of a textual expression, or the part that contributes to the prior art, or a portion of the textual expression itself, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which can be a personal computer or a server) to execute all or part of the steps of the methods described in the text. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, external hard drives, ROM, RAM, magnetic disks, or optical disks.

[0212] The above are merely specific embodiments of the text description, but the scope of protection of the text description is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the text description should be included within the scope of protection of the text description. Therefore, the scope of protection of the text description should be determined by the scope of protection of the claims.

Claims

1. A resource management method, the method comprising: Receive a task request, which is initiated by the intelligent system, and obtain first information associated with the intelligent system, which indicates the hierarchical relationship between multiple levels. Based on the first information and the current task context, second information of the task is generated, the second information including at least the corresponding resource quantity of each level; According to the priority order in the first information, check in turn whether the corresponding resource quantity of each level meets the resource requirements of the task; In response to all levels of verification passing, the resource requirement of the task is determined based on the historical information of the resource requirement. Reserve the required resources and execute the task.

2. The resource management method as described in claim 1, further comprising: The second information is associated with and stored in relation to the identifier of the session to which the task belongs, and the identifier is embedded in the second information.

3. The resource management method as described in claim 2, further comprising: In response to the completion of the task and the existence of a subsequent task within the session to which the task belongs, the subsequent task is executed according to the second information.

4. The resource management method as described in claim 1, further comprising: Add at least one of the following to the second information: organization status, team status, role template version, intelligent system instance status, entry policy, plugin policy, and environment policy.

5. The resource management method as described in claim 1, further comprising: Set a timeout for the second information; In response to the expiration of the said time-to-live, the second information is reclaimed.

6. The resource management method as described in claim 1, wherein the first information includes the hierarchical relationship between organizations, teams, role templates, user licenses, and intelligent system instances; The step of sequentially verifying whether the corresponding resource quantity of each level meets the resource requirements of the task according to the priority order in the first information includes: According to the priority order of the user license level, the intelligent system instance level, the role template level, the team level, and the organization level, the corresponding resource quantity of each level is checked in turn to see if it meets the resource requirements of the task.

7. The resource management method as described in claim 1, wherein the historical information includes historical average consumption; Determining the resource requirements of the task based on historical information about resource needs includes: The required resource quantity is determined based on the historical average consumption.

8. The resource management method as described in claim 1, wherein the pre-allocation of the required resource amount includes: Create a pre-reservation record in the resource record corresponding to the required resource quantity, and lock the resource corresponding to the pre-reservation record.

9. The resource management method as described in claim 1, further comprising: Collect resource consumption data during the execution of the task, including the actual amount of resources consumed; In response to the completion of the task, the corresponding resource quantities at each level in the first information are updated synchronously based on the actual resource consumption and the pre-allocated required resource quantity.

10. The resource management method as described in claim 9, wherein the calculation based on the actual resource consumption and the pre-allocated required resource amount includes: Submit the actual resource consumption to the resource record; Based on the actual resource consumption, release the resources that were not actually consumed from the pre-allocated required resource quantity in the resource record.

11. The resource management method as described in claim 1, further comprising: In response to the intelligent system initiating a plugin call request, the second information of the task is obtained; Based on the plugin strategy information in the second information, the plugin is matched with a strategy to obtain a matching result; In response to the matching result being rejected, the call request is intercepted; In response to the matching result being confirmed, the approval process is triggered; If the matching result is allowed, the invocation request is executed.

12. The resource management method as described in claim 1, further comprising: Receive an access request and parse at least one of the user identifier and organization identifier in the access request; The first organization corresponding to the user is determined based on the organization identifier, or the first organization corresponding to the user is determined based on the link information in the access request; In response to determining the first organization based on the link information, a record of the user's members to be enabled is established; In response to the user being assigned a team and role template, the user's visibility scope and initial permissions within the first organization are generated.

13. A resource management device, the device comprising: An acquisition unit is used to receive a task request initiated by the intelligent system and to acquire first information associated with the intelligent system, wherein the first information indicates the hierarchical relationship between multiple levels. The generation unit is configured to generate second information of the task based on the first information and the current task context, wherein the second information includes at least the corresponding resource quantity of each level; The verification unit is used to verify, in order of priority in the first information, whether the corresponding resource quantity of each level meets the resource requirements of the task. A determining unit is used to determine the required resource quantity of the task based on the historical information of the resource requirement in response to all levels of verification passing. A processing unit is used to pre-allocate the required resources and execute the task.

14. A computer-readable storage medium storing a computer program adapted for loading by a processor to perform the resource management method as described in any one of claims 1-12.

15. A computer device comprising a processor and a memory, the memory storing a computer program, the processor executing the resource management method according to any one of claims 1-12 by invoking the computer program stored in the memory.

Images